Print
카테고리: [ Cloud Computing & MSA ]
조회수: 15181

1. 소개

쿠버네티스 보안에 대해 알아보자.


2. Conrol Plane 보안

2.1. RBAC

쿠버네티스는 API Server를 통해 정책에 따른 요청 승인을 수행한다.

쿠버네티스 기본 인증 방법은 ABAC(Attribute-Base Control)이다. 사용자마다 기능에 대해 권한을 주는 방식이다. 1.6부터는 RBAC이 소개됐다. 그리고 1.8부터는 디폴트가 됐다. 

2.2. 대시보드

대시보드에는 별도의 접근 통제가 없다. 1.8 이전의 경우 클러스터에 모든 접근이 가능한 서비스 어카운트가 바인딩되어 있어 위험하다. (테슬라가 당했다고 한다?)

대시보드는 꼭 필요한 경우가 아니면 사용하지 말고, 꼭 사용이 필요하면 계정 인증, 접근 통제 등을 구현하도록 하자.

2.3. etcd

2.3.1. 암호화

etcd는 중요한 데이터를 담고 있다. 따라서 해당 데이터는 암호화된 상태로 저장되어야 한다.

암호화시에 DES, MD5, RC4 등과 같이 해독 기법이 공개된 알고리즘을 사용하는 것보다는 보다 안전한 알고리즘을 사용해야 한다.

/etc/kubernetes/manifests/kube-apiserver.yaml 파일에서 --experimental-encryption-provider-config 설정을 확인한다.

2.3.2. 권한

데이터 디렉토리에 대한 권한을 체크한다.

ls -alR /var/lib/etcd 로 확인하며 700 권한을 부여한다.

2.4. 인증

쿠버네티스는 여러 인증 방식을 제공한다. 이 중 BASIC_AUTH는 패스워드가 그대로 네트워크를 통해 전송되기 때문에 패킷을 통해 누출될 수 있다.

다른 인증 방식으로는 Bootstrap token, Static token, X.509 인증서, Open ID 연동 등이 있는데 Open ID 인증을 사용하는 것이 좋다.

2.5. TLS

2.5.1. API Server

쿠버네티스에서 API 서버와 kubelet이나 사용자 통신 시 TLS를 통해 secrets, 키 정보와 같은 중요 데이터를 보호하고 API Server와 클라이언트 간의 검증을 해야 한다. 또 주기적으로 인증서를 교체하고 안전한 암호화 방식을 사용한다. 관련 파일은 /etc/kubernetes/manifests/kube-apiserver.yaml 이다.

2.5.2. etcd

etcd는 중요한 데이터를 저장하고 있는 분산 key-value 저장소로 여기에 저장된 각종 데이터(쿠버네티스 설정, 파드/서비스 상태, DNS 등)는 구간 암호화 및 접근 클라이언트 인증을 통해 보호되어야 한다. (etcd와 클라이언트 통신, 또는 etcd 클러스터의 다른 peer와 통신 시) 관련 파일은 /etc/kubernetes/manifests/etcd.yaml 이다.

2.6. kubectl

kubectl은 관리 도구이기 때문에 접근 제어 등이 필요하다. 예를 들어,

2.7. 서비스 어카운트 토큰 마운트

파드는 기본적으로 서비스 어카운트를 사용한다. 별도로 서비스 어카운트를 지정하지 않으면 디폴트로 정의된 서비스 어카운트를 사용한다. 이 디폴트 서비스 어카운트를 사용하면 서비스 어카운트의 API 토큰을 볼륨으로 마운트한다. /var/run/secrets/kubernetes.io/serviceaccount 에 마운트되는데 이 안에 API 인증을 위한 인증서와 토큰이 들어있다. 그런데 이 토큰이 유출되면 쿠버네티스 API 접근이 가능해진다. 

일반적인 파드는 서비스 제공을 위한 애플리케이션 실행 목적이 대부분이기 때문에 쿠버네티스 API 접근이 필요할 일이 많지 않다. 따라서 서비스 어카운트 사용 시 디폴트로 서비스 어카운트 토큰을 마운트하지 않게 하는 것을 권장한다.

2.8. 감사

쿠버네티스 클러스터 상에서 파드 생성, 서비스 생성 등의 명령어에 대한 로그를 남겨 정상적인 접근 여부를 확인하고 비정상적 접근 발생 시 감지/추적할 수 있는 장치가 있는게 좋다.


3. 노드 보안

3.1. IP

노드 서버의 IP는 내부 IP만 사용하여 외부 인터넷으로부터의 접속 경로를 차단한다.

3.2. OS

노드 서버의 OS는 필요한 기능만을 가지고 있는 OS를 설치하는 것이 좋다. 메일, FTP 등 불필요한 서비스가 기동되면서 접근 경로가 생성될 수있다.

3.3. 패치

새롭게 발견되는 보안 위협을 방지하기 위해 정기적인 보안 패치를 수행한다.

3.4. 격리

외부 오픈 웹 서비스와 내부 어드민 서비스 등 민감도 수준이 다른 서비스 등을 네트워크와 호스트에서 격리 운영한다.

3.5. kubelet  파라미터

기본적인 IP 포워드 관련 파라미터 튜닝을 수행하여 DOS 공격 경유지로 이용되거나 스푸핑 등을 차단한다.


4. 컨테이너 보안

4.1. 이미지 관리

도커 이미지 생성 시 외부의 이미지를 많이 사용하게 되는데 이 때 해킹된 이미지를 사용하거나 최신 보안 패치가 적용되지 않는 등 이미지 등을 사용하여 악성 코드에 감염되거나 데이터가 누출되는 등 보안에 취약해질 수 있다.

따라서 베이스 이미지는 반드시 보안이 검증된 이미지를 사용하고 지속적으로 OS 패치가 적용되어야 한다. 또 베이스 이미지와 애플리케이션 컨테이너 이미지 모두 신뢰할 수 있는 이미지 레지스트리를 사용하고 해당 클러스터와 허가된 IP만 접근토록 한다. 일부 서비스 중에는 이미지의 보안 위협을 스캔하는 기능을 제공하기도 한다.

추가로 이미지 내에 환경 정보를 넣는 경우가 있는데 이는 굉장히 위험하다. (secrets, DB 연결 정보, X.509 개인키 등)

4.2. 이미지 레지스트리 관리

레지스트리는 자체 구성하거나 외부 서비스를 사용한다. 이미지 레지스트리는 AWS ECR, Docker Hub, Quay Container Registry, Docker Trusted Registry 등이 있다.

이미지 내에는 계정 정보 등 중요한 구성요소와 정보가 포함될 수 있고, 이미지를 이용한 컨테이너 실행이 가능하므로 이에 대한 보안 장치가 필요하다.

4.3. Security Context

파드 정의 시 불필요한 root 접근이나 커널 접근 권한을 최소화한다. Security Context를 사용하면 통제가 가능하다.

4.4. Security Context 통제

PSP(PodSecurityPolicy)는 클러스터 전체에 적용되는 파드 보안 정책으로 Admission Control Plugin을 통해 활성화된다.

PSP를 통해 생성되는 파드 내 컨테이너가 불필요하게 과도한 권한을 갖지 않도록 해야 한다.

4.5. Network Policy

파드로의 네트워크 접근을 통제한다. 예를 들어 MySQL DB로의 접근은 label이 app=apiserver인 서버들만 3306 인바운드가 가능하게 설정한다.