[Kubernetes Best Practice] 10. 파드와 컨테이너 보안

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다.모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다.

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

Pod의 보안을 강화할 수 있는 쿠버네티스 API에는 PodSecurityPolicy와 RuntimeClass라는 2가지 방법이 존재합니다. 

---

PodSecurityPolicy

PodSecurityPolicy는 클러스터 수준의 리소스로 클러스터에서 실행할 수 있는 권한 수준을 제한해 보안 취약 부분을 줄일 수 있는 효과적인 방법입니다. 

 

PodSecurityPolicy 활성화

PodSecurityPolicy를 사용하기 위해서는 먼저 PodSecurityPolicy API가 활성화되어 있는지 확인해야 합니다. 이는 kubectl get psp 명령어를 통해 확인할 수 있습니다.

다음으로는 PodSecurityPolicy에 대한 Admission Controller를 활성화해야 합니다. 클라우드 프로바이더에서 해당 활성화가 디폴트로 적용되지는 않지만 일반적으로는 선택 옵션으로 존재합니다. 

 

PodSecurityPolicy 생성 및 권한 부여

먼저 제한된 정책을 가진 PodSecurityPolicy를 생성해보겠습니다. 해당 PodSecurityPolicy는 pod이 privileged 모드로 실행되는 것을 제한하며, volume 플러그인 중 emptyDir을 사용하는 것을 제한하는 정책입니다. (나머지 부분들은 required 필드이기 때문에 임의의 값으로 설정하였습니다.)

다음으로는 해당 PodSecurityPolicy에 대한 use 권한을 가진 ClusterRole을 생성하고 이를 테스트에 사용할 ServiceAccount에 바인딩함으로써 제한된 정책을 적용합니다.

Service Account 생성

ClusterRole & RoleBinding

아래와 같이 해당 서비스 어카운트를 사용하게 하여 Pod의 특권모드가 적용될 수 없으며 Volume 플러그인으로 EmptyDir가 사용될 수 없는 정책을 적용할 수 있습니다. 

Demo

---

PodSecurityPolicy는 클러스터의 관리자나 사용자가 특정 수준의 워크로드를 API를 통해 손쉽게 제어할 수 있다는 장점이 존재합니다. 하지만, 이를 적용하는 과정에서 러닝 커브가 높고 정책이 워크로드에 대해 원하는 대로 제어하는지 디버깅하는 과정이 번거롭다는 단점이 존재합니다. 

책에서 제시하는 podSecurityPolicy 모범사례는 다음과 같습니다.

• PodSecurityPolicy는 RBAC에 의해 결정됩니다. 따라서 RBAC와 PodSecurityPolicy의 생성, 유지, 관리에 대해 자동화가 중요합니다.
• 정책의 범위를 정확하게 파악하여 합니다. 범위는 클러스터 전체가 될 수도 있으며 특정 네임스페이스 및 워크로드가 될 수도 있습니다.

---

워크로드 격리와 런타임 클래스

일반적으로 컨테이너는 호스트를 공유하기 때문에 워크로드가 격리된 VM보다 보안상 취약점을 가지고 있다고 말합니다. 이런 이슈를 해결하기 위해 CRI를 구현한 다양한 컨테이너 런타임이 등장하였습니다. gVisor, Kata Container와 같은 컨테이너 런타임은 중첩된 가상화나 시스템 호출을 필터링하는 방식을 사용해 워크로드의 격리를 보장합니다. 

동일한 클러스터 내에서도 이러한 요구사항에 따라 다양한 컨테이너 런타임을 선택할 수 있습니다. 런타임 클래스를 선택하는 과정을 간단히 살펴보면 다음과 같습니다.

1. RuntimeClassName 필드를 통해 특정 런타임 클래스 정의
2. 런타인 클래스가 구현할 CRI로 전달되는 RuntimeHandler를 지정
3. 원하는 런타임 클래스를 지원하는 노드에 워크로드 배치

런타임 클래스는 워크로드 격리를 제공하지만 여전히 kubernetes API를 통한 악의적 수정이 가능하다는 점을 기억해야합니다. 또한, 단일 클러스터에서 여러 런타임 클래스를 사용할 경우 런타임 클래스마다 워크로드 격리를 제공하는 방식이 다르기 때문에 이식 과정에서 예상치 못할 문제를 마주할 가능성이 높아집니다. 따라서 단일 워크로드를 갖는 개별 클러스터를 유지하는 것을 권장합니다.

---

PodSecurityPolicy와 컨테이너 런타임 클래스 이외에도 런타임 내부에서 정책을 확인하고 실행하려면 시스템 콜을 감시하거나 BPF를 사용해야 합니다. (이를 수행하는 오픈소스로 CNCF의 Falco가 존재합니다.)