파드와 컨테이너 보안

쿠버네티스 모범 사례을 요약한 내용입니다.

• 파드 보안에는 파드시큐리티폴리시(PodSecurityPolicy)와 런타임 클래스(RuntimeClass)라는 두가지 방법이 있음
• 각 API의 목적과 사용법에 대해서 살펴보기

10.1 파드시큐리티폴리시 API

• 클러스터 수준 리소스인 파드시큐리티폴리시는 파드 명세에서 보안에 민감한 모든 필드를 정의하고 관리할 수 있는 유일한 곳
• 리소스를 생성하기 전, 클러스터 관리자와 사용자는 SecurityContext 설정을 워크로드마다 개별적으로 정의해야 함
• 클러스터에서 맞춤형 어드미션 컨트롤러를 활성화해 파드 보안을 시행
• 파드시큐리티폴리시는 효과적으로 구현하기 어려움
• 클러스에서 실행할 수 있는 대상과 권한 수준을 제한하여 공격에 취약한 영역을 줄이는 가장 효과적인 방법

10.1.1 파드시큐리티폴리시 활성화

• 파드시큐리티폴리시 리소스에 정의된 조건을 실행하려면 어드미션 컨트롤러를 활성화시켜야 함
• 요청 처리 과정 중 어드미션 단게에서 정책이 시행된다는 뜻

<aside> 💡 어드미션 컨트롤러의 동작 방식에 대한 자세한 내용은 17장 참고

</aside>

• 모든 공개 클라우드 공급자와 클러스터 운영 도구에서 파드시큐리티폴리시의 활성화가 널리 제공되지 않음
  • 사용할 수 있는 경우에는 일반적으로 옵트인(opt-in) 기능으로 제공

<aside> ⚠️ 파드시큐리티폴리시를 활성화할 때 워크로드가 차단될 수 있으므로 주의해야 함

</aside>

• 파드시큐리티폴리시를 사용하려면 두가지를 완료해야 함
  • 파드시큐리티폴리시 API가 활성화되어 있는지 확인
    • kubectl get psp를 실행하여 활성화 여부를 확인 가능
    • server doesn’t have a resource type PodSecurityPolicies 응답이 아니라면 진행하면 됨
  • api-server flag —enable-admission-plugins를 이용해 파드시큐리티폴리시 어드미션 컨트롤러를 활성화함

<aside> 💡 이미 워크로드가 실행중인 클러스터라면 어드미션 컴트롤러를 활성화하기 전에 필요한 모든 정책, 서비스 계정, 롤, 롤바인딩을 생성해야함

</aside>

• —use-service-account-credentials=true 플래그를 kube-controller-manager에 추가할 것을 권장
  • kube-controller-manager 내의 개별 컨트롤러에서 서비스 계정을 사용할 수 있음
  • kube-system 네임스페이스에서 정책을 보다 세밀하게 제어할수 있음
  • 플래그가 설정되 있는지 확인할 수 있음

  kubectl get serviceaccount -n kube-system | grep `.*-controller`
  

<aside> 💡 PodSecurityPolicies를 정의하지 않으면 암묵적으로 거절된다는 것을 명심해야함, 워크로드와 일치하는 정책이 없으면 파드가 생성되지 않음

</aside>

10.1.2 파드시큐리티폴리시 살펴보기

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

• 컨테이너 런타임 워크로드 격리 경계로 보면 여전히 보안상 안전하지 않다고 간주 됨
• 쿠버네티스는 다양한 격리 수준을 제공하는 여러 컨테이너 런타임이 개발되었음
  • 친숙하고 신뢰할 수 있는 기술 스택을 기반
  • 문제를 해결 하기 위한 완전히 새로운 시도
    • 카타 컨테이너, gVisor, 파이어크래커와 같은 오픈 소스 프로젝트
    • 중접된 가상화 또는 시스템 호출 필터링과 서비스를 이용
• 다양한 워크로드 격리를 제공하는 컨테이너 런탐임의 등장으로 사용자는 동일한 클러스터에서 격리 보장 수준에 맞춰 다양한 런타임을 선택할 수 있음
• 런타임 클래스는 컨테이너 런타임 선택을 가능하게 하는 API
• 클러스터 관리자가 구성한 컨테이너 런타임 중 하나를 선택
• 파드 명세의 RuntimeClassName을 사용해 워크로드에 특정 런타임 클래스를 정의할 수 있음
  • 구현되는 방법은 런타임클래스가 구현할 컨테이너 런타임 인터페이스로 전달되는 RuntimeHandler를 지정
  • 노드 라벨링 또는 노드 테인트가 노드 셀렉터 또는 톨러레이션과 함께 사용되어 워크로드가 원하는 런타임 클래스를 지원하는 노드에 배치
  • 파드를 시작할 때 kubelet이 런타임 클래스를 사용하는 방법

10.2.1 런타임클래스 사용

• 클러스터 관리자가 다른 런타임클래스를 설치한 경우, 파드 명세에 runtimeClassName을 지정하면 사용할 수 있음
• apiVersion: v1 kind: Pod metadata: name: nginx spec: runtimeClassName: firecracker

10.2.2 런타임 구현

• 다양 수준의 보안과 격리를 제공하는 오픈 소스 컨테이너 런타인 구현
• CRI containerd
  • 단순화, 견고성, 이식성을 강조한 컨테이너 런타임을 위함 API 퍼사트
• cri-o
  • 특수한 목적으로 제작된 경량 오픈 컨테이너 이니셔티브 기반의 쿠버네티스 컨테이너 런타임 구현
• 파이어크래커
  • 커널 기반 VM위에 구축되었으며, 이 가상화 기술로 전통적인 VM의 보안과격리를 사용하여 가상화되지 않은 환경에서 격리된 가상환경인 microVM을 매우 빠르게 시작할 수 있음
• gVisor
  • 새로운 사용자 공간 커널로 컨테이너를 실행하는 OCI호환 샌드박스 런타임으로, 오버헤드가 적고 안전하며 격리된 컨테이너 런타임을 제공
• 카타 컨테이너
  • 컨테이너와 흡사하게 동작하는 경량 VM을 실행하여 VM과 유사한 보안과 격리르 제공하는 안전한 컨테이너 런타임을 구축하는 커뮤니티

10.2.3 워크로드 격리와 런타임클래스 모범 사례

• 런타임 클래스를 사용하여 다양한 워크로드 격리 환경을 구현하면 운영 환경이 복잡해짐
  • 컨테이너 런타임마다 격리의 근본적인 특성이 다르기 때문에 워크로드 이식이 어려울수 있음
  • 다양한 런타임에 대한 지원 기능 매트릭스를 이해하는 것은 어려움
  • UX 저하를 초래할 수 있음
  • 가급적 단일 런타임을 갖는 개별 클러스터를 보유하는 것이 좋음
• 워크로드 격리로 멀티테넌시 보안이 유지되는 것은 아님
  • 안전한 컨테이너 런타임을 구현한다고 해도 쿠버네티스 클러스와 API까지 동이랗게 안전하다는 뜻은 아님
  • 쿠버네티스의 시작부터 끝까지 전체 영역을 살펴봐야함
  • 워크로드가 격리되었다고해서 쿠버네티스 API를 통한 악의적 수정이 불가능한 것은 아님
• 런타임마다 도구가 다름
  • 디버깅과 내부 검사에 컨테이너 런타임 도구를 사용하는 사례가 있음
  • 런타임이 바뀌면 더는 docker ps로 실행 중인 컨테이너를 볼 수 없음으로 문제 해결에 혼란을 줄수 있음

10.3 파드와 컨테이너 보안 고려사항

10.3.1 어드미션 컨트롤러

• 파드시큐리티폴리시를 깊게 이해하는 것이 부담스럽다면, 완벽하지 않지만 사용 가능한 대안이 있음
• 어드미션 웹푹으로 SecurityContext 워크로드 설정을 추가하고 DenyExecOnPrivileged와 DenyEscalatingExec과 같은 어드미션 컨트롤러를 사용하면 비슷한 결과를 얻을 수 있음

10.3.2 오픈 소스 도구

• 컨테이너 런타임 내에서 정책을 조사하고 실행하려면 어떻게 해야할까?
  • 리눅스 시스템 호출을 감시하고 필터링하거나 버클리 패킷 필터를 사용
    • 오픈 소스 도구중 하나로 팔코가 있음
    • CNCF 프로젝트인 팔코는 데몬셋으로 간단히 설치할 수 있고 실행중 정책을 설정하고 시행할 수 있음
  • 다양한 도구를 살펴보고 적잡한 것을 찾아보기를 권장

10.4 마치며

• 워크로드의 보안 수준을 세미랗게 구설할 수 있는 파드시큐리티폴리시와 런타임 클래스 API에 대해서 알아봄
• 컨테이너 런타임 내에서 정책을 모니터링하고 시행할 때 사용할 수 있는 오픈소스 생태계 도구도 살펴봄
• 워크로드 요구사항에 가장 적합한 보안 수준을 제공하는 방법에 대한 현명한 결정을 내릴 수 있도록 빈틈없는 개용을 제공했음