[SK shieldus Rookies 16기] 클라우드 기반 스마트 융합 보안 과정 교육 정리(55일차)

오늘 학습 주제

1. 클라우드 컴퓨팅 서비스 프레임워크 및 기술

 

 

클라우드 컴퓨팅 서비스 프레임워크 및 기술

---

- 하이퍼바이저 -

하드웨어를 가상화하기 위해 하드웨어들을 관장하고

각각의 가상머신들을 관리하는 가상머신모니터(중간관리자)

VM이 동작할 수 있는 환경을 제공

호스트 시스템에서 다수의 게스트 OS를 구동할 수 있음

 

 

Hypervisor (하이퍼바이저) 종류	설명
Type1 하이퍼바이저 : 베어메탈(Bare-metal)기반	• Type1은 하이퍼바이저가 하드웨어 바로 위에서 실행되는 방식이다. 하이퍼바이저가 하드웨어를 직접 제어하기 때문에 자원을 효율적으로 사용할 수 있고, 별도의 호스트OS가 없으므로 오버헤드가 적지만 여러 하드웨어 드라이버를 세팅해야 하므로 설치가 어렵다. ex) VMware ESX/ESXi, Xen, Microsoft Hyper-V, Oracle VM Server, KVM
Type2 하이퍼바이저 : 호스트(Host) 기반	• Type2는 하드웨어 위에 호스트 운영체제(Host OS)가 있고, 그 위에서 하이퍼바이저가 다른 응용프로그램과 유사한 형태로 동작한다. 이 타입의 하이퍼바이저에 의해서 관장 되는 가상머신의 게스트OS는 하드웨어 위에서 3번째 수준으로 구동된다. 기존의 컴퓨터 환경에서 하이퍼바이저를 활용하는 것이기에 설치가 용이하고 구성이 편리한 장점이 있다. 반면, Type1 보다는 성능이 떨어질 수 있다 ex) VMware server, VMware Workstation, VMware Player, Virtual box

 

 

- 가상화와 클라우드컴퓨팅 -

구분	가상화(Virtualization)	클라우드 컴퓨팅(Cloud Computing)
정의	기술	방법
목적	1개의 물리적 하드웨어 시스템에서 다수의 시뮬레이터 환경 생성	온디맨드 사용을 위한 가상 리소스 풀링과 자동화
용도	특정 용도의 패키징 된 리소스를 특정 사용자에게 제공	다양한 용도의 다양한 리소스를 사용자 그룹에 제공
설정	이미지 기반	템플릿 기반
평균 수명	연 단기(장기)	시간/월 단위(단기)
비용	높은 자본지출, 낮은 운영비용 (부대 설비, 데이터 베이스 등)	프라이빗 클라우드: 높은 자본지출, 낮은 운영비용 퍼블릭 클라우드: 낮은 자본지출, 높은 운영비용
확장성	Scale-Up	Scale-Out
워크로드	스테이트풀: 애플리케이션과 프로세스는 온라인 뱅킹이나 이메일처럼 여러번 반환 사용자에게 받은 요청을 처리할 때마다 같은 서버를 사용	스테이트리스: 프로세스 또는 애플리케이션 격리 ex) 컨텐츠 전달 네트워크(CDN), 웹, 프린트 서버
테넌시	싱글 테넌트	멀티 테넌트

 

 

- 클라우드컴퓨팅 인스턴스 -

인스턴스
개념	• 클라우드 컴퓨팅에서 인스턴스는 타사 클라우드 서비스에서 제공하는 서버 리소스 • 온프레미스에서 물리적 서버 리소스를 관리하고 유지할 수도 있지만, 그럴 경우 비용이 많이 들고 비효율적이다. 클라우드 제공업체는 데이터 센터에서 하드웨어를 유지 관리하고 인스턴스라는 형태로 컴퓨팅 리소스에 대한 가상 액세스를 제공 • 클라우드 인스턴스를 사용하여 컨테이너, 데이터베이스, 마이크로서비스, 가상 머신 등의 컴퓨팅 집약적인 워크로드를 실행할 수 있음
확장성	• 개발자는 워크로드 요구 사항에 따라 클라우드 인스턴스의 컴퓨팅 리소스를 조정한다 ex), 소프트웨어 개발자는 인스턴스에 애플리케이션을 배포한다 →앱이 더 많은 사용자를 확보할수록 엄청난 트래픽이 발생하여 응답 시간이 느려지게 된다 →  개발자는 CPU, 메모리, 스토리지 및 네트워크 리소스를 특정 인스턴스로 늘려 클라우드 리소스를 수평적으로 조정할 수 있음
내결합성	• 조직에서는 백업을 위해 여러 중복 인스턴스를 사용하여 중복성을 만듬 • 특히 데이터 처리와 같이 메모리 집약적인 워크로드를 관리하는 데 유용하다 ex) 유럽에서 호스팅 되는 클라우드 인스턴스에 장애가 발생하더라도 애플리케이션은 미국과 아시아의 다른 인스턴스에서 계속 실행될 수 있음

 

글로벌 인스턴스
AWS 인스턴스 Types	• General Purpose Instances(범용 목적 인스턴스) • Compute Optimized Instances(컴퓨팅 최적화 인스턴스) • Memory-Optimized Instances(메모리 최적화 인스턴스) • Accelerated Computing Instances(가속화된 컴퓨팅 인스턴스) • Storage Optimized Instances(스토리지 최적화 인스턴스)

 

- 가상머신 VS 컨테이너 -

	가상머신	컨테이너
특징	▪ 가상 머신(VM)은 하이퍼바이저 라고 하는 소프트웨어 리소스가 파티셔닝되어 VM 전용으로 할당될 수 있도록 리소스를 물리 머신에서 분리됨 ▪ 사용자가 물리 환경의 추가 리소스를 요구하는 VM 명령을 발행하면 하이퍼바이저는 이 요청을 물리시스템으로 전달하고 변경사항을 캐싱함 ▪ VM은 물리 서버처럼 보이고 작동하므로  플리케이션 종속성 및 대규모 OS 설치 공간 (단일 애플리케이션이나 마이크로서비스를 실행하는데는 거의 필요하지 않음)의 단점을 증대시킬 수 있음	▪ 컨테이너는 마이크로서비스 또는 애플리케이션과 이를 실행하는 데 필요한 모든 것이 포함되어 있음 ▪ 컨테이너에 있는 모든 것은 '이미지’라고 하는 모든 라이브러리와 종속성을 포함하는 코드 기반 파일에 저장됨 ▪ 컨테이너는 너무 작기 때문에 일반적으로 수 백개가 서로 느슨하게 결합되어 있으므로 컨테이너 오케스트레이션 플랫폼(예: Red Hat OpenShift 및 쿠버네티스)을 사용하여 컨테이너를 프로비저닝하고 관리함

 

컨테이너의 장점
응용프로그램 동작 환경	애플리케이션 레벨 고립
환경구축 시간	하이퍼바이저 기반의 가상머신보다 빠른 셋업
메모리 사용	하이퍼바이저 기반의 가상머신보다 메모리 소모가 적음
응용프로그램 마이그레이션 및 전송 속도	가상머신과 비교해 크기가 작기 때문에 마이그레이션, 백업, 전송이 쉬움
응용프로그램 배치 및 유지보수	애플리케이션 배치와 유지보수를 향상 효과가 있음 MSA 기반
데이터 전달 속도	애플리케이션 전달 시간 감소

 

 

- Top 10 컨테이너 -

1.Docker	세계에서 많이 사용하고 있는 오픈 플랫폼. 1800만 개발자,7백만 App
2.Kubernetes	Docker와 전세계 많이 사용하고 있는 컨테이너. Kubernetes는 컨테이너화된 관리를 위한 이식 가능하고 확장 가능한 오픈 소스 플랫폼
3.AWS Fargate	서버를 관리하지 않고도 애플리케이션 구축에 초점을 맞출 수 있도록 지원하는 종량제 서버리스 컴퓨팅 엔진
4.Google Kubernetes Engine (GKE)	구글 인프라를 사용하여 컨테이너식 애플리케이션을 배포, 관리, 확장할 수 있는 관리형 환경을 제공하는 서비스
5.Amazon ECS/ECR/EKS ECS(Elastic Container Service) EKS(Elastic Kubernetes Service)	• ECS : Docker 지원 컨테이너 • EKS : Kubernetes 지원 컨테이너 • ECS가 EKS보다 좀 더 가상화 레벨이 높은 것으로 분류 • ECR(Elastic Container Registry): Img저장
6.Core OS Container Linux	RedHat의 컨테이너 네이티브 운영 체제, 변경 가능한 컨테이너 최적화 Linux 호스트를 제공
7.Microsoft Azure Container (AKS)	Azure에서 관리되는 Kubernetes 클러스터 배포형 서비스
8.NCP Ncloud Kubernetes Service	NCP의 컨테이너 배포, 관리, 확장 등 컨테이너를 사용하는 데 필요한 작업을 자동화하는 서비스
9.NHN NHN Kubernetes Service (NKS)	NHN의 Kubernetes 기반의 컨테이너 서비스
10. COCKTAIL CLOUD (나무기술)	Kubernetes 기반 국산 클라우드 네이티브 플랫폼

 

 

- 쿠버네티스 -

 

쿠버네티스
개념	▪ Kubernetes, 또는 쿠버네티스, 또는 간단히 “큐브(kube)”는 Linux 컨테이너 작업을 자동화하는 오픈소스 플랫폼을 의미한다 ▪ 이 플랫폼에서는 컨테이너화된 애플리케이션을 배포하고 확장하는 데 수동 프로세스가 필요하지 않는다 즉, Linux 컨테이너를 실행하는 호스트 그룹을 함께 클러스터링할 수 있으며 쿠버네티스를 통해 이러한 클러스터를 쉽고 효율적으로 관리할 수 있다 ▪ 클러스터는 퍼블릭 클라우드, 프라이빗 클라우드 또는 하이브리드 클라우드 전체로 호스트를 확장할 수 있다
주요 기능	오케스트레이션 쿠버네티스를 이러한 워크로드를 위해 규모에 맞는 컨테이너를 배포하는 데 필요한 오케스트레이션 및 관리 기능을 제공 관리기능 쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속적으로 관리할 수 있음. 쿠버네티스를 활용하면 IT 보안을 한층 강화할 수 있음 쿠버네티스 구축환경 요건 쿠버네티스는 종합적인 컨테이너 인프라를 제공할 수 있도록 네트워킹, 스토리지, 보안, 텔레메트리, 기타 서비스와 통합해야 함 애플리케이션 리소스 관리 기능 하드웨어를 최대한 활용하여 엔터프라이즈 애플리케이션을 실행하는 데 필요한 리소스를 극대화 애플리케이션 배포 및 업데이트를 제어하고 자동화 스토리지를 장착 및 추가해 스테이트풀(stateful) 애플리케이션을 실행

 

UI	Client, CSU, CSD
CLI	쿠버네티스 클러스터에 명령을 내리는 Command Line Interface
Master Node
Control Plane
API Server
Scheduler

 

 

 

- 도커 -

도커
개념	▪ 컨네이너 기반의 오픈 소스 가상화 플랫폼 ▪ 인프라에서 애플리케이션을 분리하여 컨테이너로 추상화시켜 소프트웨어를 빠르게 제공 할 수 있으며,  주어진 하나의 호스트 OS안에서 여러 컨테이너를 동시에 실행 가능 ▪ 컨테이너의 라이프 사이클을 관리하고 애플리케이션을 오케스트레이션된 서비스로 배포 가능 ex) 백엔드 프로그램, DB서버, 메시지 큐 등 어떤 프로그램도 컨테이너로 추상화 가능하며 조립 PC, AWS, Azure, NBP 등 어디에서든 실행 가능

 

Docker API	TCP 소켓 기반으로 Docker Engine에 명령어를 이용하여 Docker를 제어하기 위한 인터페이스
Docker CLI	Docker Engine에 사용하는 Command Line Interface
Distribution	Docker 이미지를 저장할 수 있는 사설 Docker 이미지 저장소 소스
Orchestration	개별 구성 요소와 애플리케이션 계층의 작업을 정리하는 과정으로 컨테이너의 시작 및 중단 시점 제어, 클러스터로 그룹화, 애플리케이션을 구성하는 모든 프로세스 조정을 수행
Volumes	도커 컨테이너에서 도커 내부에 도커 엔진이 관리하는 볼륨 생성된 볼륨은 호스트 디렉터리의 /var/lib/docker/volumes 경로에 저장되며, Docker를 사용하여 관리가 용이
Containerd	일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 파일 시스템 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 것들로 구성
Docker Build (buildKit)	새로운 도커 이미지를 빌드할 때 사용하는 용어 도커는 도커파일에 작성되어 있는 명령어를 읽어 들여 자동으로 이미지를 빌드 가능 도커 파일을 실행하기 위해서는 도커 빌드 명령어를 사용하여 실행하며, 실행 시 도커파일에 작성되어 있는  명령어들로 도커 이미지를 빌드
Networking	도커 애플리케이션을 컨테이너 안에서 실행하고, 실행되는 애플리케이션은 기존에 존재하던 네트워크과 VLAN으로 연결을 지원하여 통신 도커네트워킹은 CNM이라고 불리우는 오픈소스 Pluggable 아키텍처에 기반

 

 

 

- 도커와 가상머신 차이점 -

구분	가상화(Virtualization)	도커(Docker)
OS 지원	많은 메모리 공간 필요	적은 메모리 공간 사용
Boot-up 시간	부팅시간이 오래 걸림	부팅 시간이 짧음
성능	여러 개의 VM 사용 시 불안정한 성능 발생	단일 Docker Engine을 통해서 컨테이너가 더 좋은 성능 발휘
Scaling (확장성)	Scale-Up 어려움	Scale-Up 쉬움
Efficiency (효율성)	낮음 물리적 서버를 추상화한 것	높음
이동성	다른 플랫폼을 통해 설치 시 호호나성 이슈가 있음	다른 플랫폼 간에 이동하기 쉬움 컨테이너 위에 올라가 있기 때문
저장공간 할당	데이터 크기를 공유하기 어려움	데이터 크기를 공유할 수 있고, 다중 컨테이너 사이에서 재사용 가능

 

- 컨테이너 보안 -

보안이슈	보호대책
컨테이너의 응용프로그램 접근 (Application)	컨테이너(Kubernetes, Docker 등)의 Application 별 ACL(Access Control List)를 통해 관리자, 사용자, 개발자에 대한 접근권한을 직무 목적에 따라 부여
컨테이너 이미지 보안	사용이 종료된 컨테이너 이미지가 검증되지 않은 레지스트리에 저장되면 위험 (악성코드의 존재 가능성이 있으며 각종 지원을 받을 수 없음) • 신뢰된 Container 제공자를 통한 Registry 사용 : Docker Registry, Kubernetes Registry 등 • 컨테이너 운영체제 또는 라이브러리(Libs)의 취약점 분석평가 • 불필요한 이미지 종속성 제거 1) 호스트의 Volume 내 데이터 읽기 제한 설정 2) 파일 시스템으로부터 읽기 제한 설정 3) Kubelet 등 구성 설정 읽기 제한 : 관리자 권한 부여자만 접근
루트 권한으로 이용하는 컨테이너 동작	• 컨테이너에 지정된 서비스 사용자 계정으로 컨테이너 Image를 생성한다 • 컨테이서 서비스는 Root 권한을 제거한다
사용자 권한	• 권한을 가능한 한 제한적으로 유지 설정 • Pod의 보기(View) 및 목록(List) 권한 제한: 일반 사용자의 해당 권한 제거 • 컨테이너의 응용프로그램 업무 목적에 따른 RBAC(Role Based Access Control) 적용 • 컨테이너의 응용프로그램에 대한 사용권한 설정 • Pod 간 데이터 통신 규칙 정의
Pod 통신 구간 암호화	• 2개 이상의 Pod 간 토신을 안전하게 하기 위해서는 TLS(Transport Layer Security) v.1.2(권고) 이상을 적용한다 • Pod 간에 연결하고자 하는 구간은 평문 전송이 되지 않도록 한다
중요 데이터 보안	• 평문 저장하지 않음 • Base64 기반 암호화 적용 • 암호화 구성 자원(Container 환경 암호화 SaaS 솔루션)을 이용하여 데이터 암호화 적용 • 3rd Party 보안 관리 솔루션(예: HashiCorp Vault 등) 사용
etcd 보안	• etcd에 저장하는 모든 Kubernetes 구성 데이터에 대한 보안(무결성, 암호화 등) 적용 • 모든 클러스터 데이터에 대해 Kubernetes 백업 저장 • 공격자가 etcd에 접근 한다면, API Server를 우회 할 수 없도록 설정 • 클러스터(클러스터는 애플리케이션 컨테이너를 실행하기 위한 일련의 노드 머신)에 무제한 접속 제한 설정
컨테이너 데이터, 이미지 백업 및 복구	• Leaking Data(취약한 데이터), Losting Data(손실 데이터), Ransomware에 대한 데이터 보호 정책 적용 - 신용카드 정보 - 개인의료정보 - 기타 개인정보, 고유식별정보 • 데이터 백업 정책 적용 • 쉽게 데이터 복원될 수 있는 환경 고려 : 주기적 백업 및 복구 테스트 등
컨테이너 보안정책 구성	• 컨테이너 보안정책을 정의하여 특정 구성을 적용한다 • 컨테이너가 루트 권한으로 실행하고 있는 Pod를 허용하지 않음 • 컨테이너의 네트워크 보안정책은 모든 Pod에 대해 정의한다 • 컨테이너 환경에 대해 잘못된 구성 설정되지 않도록 보안점검을 하여야 하며, 보안 구성의 검증을 자동화 설정 고려
컨테이너 재해 복구 계획	• 클라우드컴퓨팅서비스 환경의 컨테이너 재해 복구 전략계획 수립 - 클라우드컴퓨팅서비스 BCP 조직 및 역할 구성 - 클라우드 데이터, 컨테이너 구성정보 백업 정책 - 컨테이너 복구 절차 - 컨테이너 복구 테스트 계획 및 시행(복구 테스트 시 오류사항 해결) - 컨테이너 이중화 구성 - 컨테이너 제공한 클라우드서비스제공자(CSP) 관련 클라우드컴퓨팅서비스 업무 연속성 출구전략 계획 • 자동화된 컨테이너 데이터, 구성 환경 백업 및 복구 테스트 시행 • 어떠한 환경이든 사용하고 있는 클러스터(클러스터는 애플리케이션 컨테이너를 실행하기 위한 일련의 노드 머신) 복구

 

 

- 클라우드 네이티브 보안 -

클라우드 네이티브 보안의 4C
Cloud Native Container Security의 4C 개념	• 보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud), 클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다 • 이 계층화 된 접근 방식은 보안에 대한 심층 방어 컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 널리 알려져 있다
Cloud Native Security’s 4C 구조	• 클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다 • 코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다. 코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준을 보호할 수 없다

 

 

클라우드 보안 관점
클라우드 관점 보안	• 여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 신뢰 컴퓨팅 기반(trusted computing base) 이다. 클라우드 계층이 취약하거나 취약한 방식으로 구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는 보장은 없다 • 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 위한 보안 권장 사항을 제시한다
클라우드 공급자 보안	자신의 하드웨어 또는 다른 클라우드 공급자에서 쿠버네티스 클러스터를 실행 중인 경우, 보안 모범 사례는 설명서를 참고한다.

 

 

클라우드 보안 관점: 인프라스트럭처 보안(Kubernetes 관점)
API 서버에 대한 네트워크 접근 (컨트롤 플레인)	쿠버네티스 컨트롤 플레인에 대한 모든 접근은 인터넷에서 공개적으로 허용되지 않으며 클러스터 관리에 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록에 의해 제어된다.
노드에 대한 네트워크 접근 (노드)	지정된 포트의 컨트롤 플레인에서 만 (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다.
클라우드 공급자 API에 대한 쿠버네티스 접근	각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 최소 권한의 원칙을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. Kops 설명서는 IAM 정책 및 역할에 대한 정보를 제공한다
etcd에 대한 접근	etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 etcd 문서에서 확인할 수 있다.
etcd 암호화	가능한 한 모든 스토리지를 암호화하는 것이 좋은 방법이며, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.

 

클라우드 보안 관점
인증 /전송 보안 부문	• 기본적으로 쿠버네티스 API 서버는 TLS에 의해 보호되는 첫번째 non-localhost 네트워크 인터페이스의 6443번 포트에서 수신을 대기한다. 일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다 해당 포트를 다른 포트로 변경해야 한다 • 포트번호는 --secure-port 플래그를 통해, 수신 대기 IP 주소는 --bind-address 플래그를 통해 변경될 수 있다
인증 / 권한 부문	• TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다. 이는 다이어그램에 1단계로 표시되어 있다. 클러스터 생성 스크립트 또는 클러스터 관리자는 API 서버가 하나 이상의 인증기 모듈(MFA)을 실행하도록 구성한다.  • 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다 • 인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰, JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
인증 / 인가 부문	• 특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 2단계로 표시되어 있다 • 요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다

 

클라우드 보안 관점
애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등)	• 시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 파드 명세나 컨테이너 이미지에 포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를 애플리케이션 코드에 넣을 필요가 없음을 뜻한다 • 시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에, 파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이 노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스 및 클러스터에서 실행되는 애플리케이션은 비밀 데이터를 비휘발성 저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다 • 시크릿은 컨피그맵과 유사하지만 특별히 기밀 데이터를 보관하기 위한 것이다
파드(Pod)가 파드(Pod) 보안 정책을 만족하는지 확인하기	• 쿠버네티스 파드 보안 표준은 파드에 대한 다양한 격리 수준을 정의한다 • 이러한 표준을 사용하면 명확하고 일관된 방식으로 파드의 동작을 제한하는 방법을 정의할 수 있다 • 쿠버네티스는 파드 보안 표준을 적용하기 위해 기본 제공 파드 보안 어드미션 컨트롤러를 제공한다. 파드 보안 제한은 파드가 생성될 때 네임스페이스 수준에서 적용된다

 

클라우드 보안 관점
서비스 품질 (및 클러스터 리소스 관리)	• 특정 서비스 품질(QoS) 클래스를 할당하기 위해 어떻게 파드를 구성해야 하는지 보여준다. 쿠버네티스는 QoS 클래스를 사용하여 파드 스케줄링과 축출을 결정한다 • QoS 클래스 : 쿠버네티스가 파드를 생성할 때, 파드에 다음의 QoS 클래스 중 하나를 할당한다 - Guaranteed - Burstable - BestEffort • 네임스페이스 생성 : 생성한 리소스가 클러스터의 나머지와 격리되도록 네임스페이스를 생성한다.

 

클라우드 보안 관점

네트워크 정책

• IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 파드가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다. 네트워크폴리시는 한쪽 또는 양쪽 종단이 파드인 연결에만 적용되며, 다른 연결에는 관여하지 않는다 • 파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다 1) 허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음) 2) 허용되는 네임스페이스 3) IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨) • 파드 격리에는 이그레스에 대한 격리와 인그레스에 대한 격리의 두 가지 종류가 있다 - 이들은 어떤 연결이 성립될지에 대해 관여한다. 여기서 "격리"는 절대적인 것이 아니라, "일부 제한이 적용됨"을 의미한다. 반대말인 "이그레스/인그레스에 대한 비격리"는 각 방향에 대해 제한이 적용되지 않음을 의미함. 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 두 종류 모두 파드 간 연결과 연관된다

 

클라우드 보안 관점
쿠버네티스 인그레스 (Ingress)를 위한 TLS	• TLS 개인 키 및 인증서가 포함된 시크릿(Secret)을 지정해서 인그레스를 보호할 수 있다. 인그레스 리소스는 단일 TLS 포트인 443만 지원하고 인그레스 지점에서 TLS 종료를 가정한다( 서비스 및 해당 파드에 대한 트래픽은 일반 텍스트임). 인그레스의 TLS 구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해 지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱 된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는 tls.crt 와 tls.key 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와 개인 키가 있다
인그레스(Ingress) 개념 ※ 인그레스 반대 개념 : 이그레스(Egress)	• 인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출하며, 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다 • 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다 • 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다 • HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 Service.Type=NodePort 또는 Service.Type=LoadBalancer 유형의 서비스를 사용한다 • 이그레스(Egress)는 서버 내부에서 외부로 나가는 트래픽을 의미

 

 

컨테이너 보안 관점
컨테이너 취약점 스캔 및 OS에 종속적인 보안	이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다
이미지 서명 및 시행	컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다
권한 있는 사용자의 비 허용	컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다
더 강력한 격리로 컨테이너 런타임 사용	더 강력한 격리를 제공하는 컨테이너 런타임 클래스를 선택한다.

 

코드 보안 관점
TLS를 통한 접근	코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 실행하는 mTLS(상호 TLS 인증)를 통해 수행할 수 있다
통신 포트 범위 제한	가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다
타사 종속성 보안	애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다
정적 코드 분석	대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다.
동적 탐지 공격	• 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다 • 여기에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시이다

 

 

- DevSecOps -

DevOps 프로세스:

1. Design (설계, 개발 계획)

2. Coding 

3. Build

4. Test

5. 배포

6. 출시

7. 운영

8. 모니터링

 

 

- DevSecOps 프로세스별 보안 역할 -