컨테이너 보안 기초: 오케스트레이션

이 시리즈를 처음 접하신다면 처음부터 시작하는 것이 좋습니다:
컨테이너 보안 기초: 소개
컨테이너 보안 기초: 파이프라인

According to Tripwire의 2019년 컨테이너 보안 현황에 따르면, 현재 조직의 약 3분의 1(32%)이 프로덕션 환경에서 100개가 넘는 컨테이너를 운영하고 있습니다. 500개가 넘는 컨테이너를 운영하는 조직의 비율은 이보다 낮은 13%이며, 적극적으로 도입한 조직 중 6%는 현재 1,000개가 넘는 컨테이너를 관리하고 있습니다. 대규모로 컨테이너를 운영하면서 이를 지원할 오케스트레이션 시스템을 사용하지 않는 조직은 거의 없습니다.

컨테이너 보안의 오케스트레이션 계층은 컨테이너의 일상적인 운영을 담당하는 환경에 중점을 둡니다. 현재 이용 가능한 데이터에 따르면 컨테이너를 사용하고 있다면 오케스트레이터로 Kubernetes를 활용하고 있을 가능성이 매우 높습니다.

다른 오케스트레이터도 존재하지만, 대부분 Kubernetes에서 파생된 구성 요소와 개념을 활용하고 있다는 점에 유의해야 합니다. 따라서 여기서는 Kubernetes와 그 구성 요소의 보안에 중점을 두겠습니다.

Kubernetes 환경

Kubernetes는 여러 구성 요소가 유기적으로 작동하는 구조로 이루어져 있습니다. 따라서 관련 구성 요소가 많을 뿐만 아니라 이러한 구성 요소가 서로 상호 작용하는 방식 때문에 보안을 강화하기가 더욱 어렵습니다. 일부는 API를 통해 통신하고, 다른 일부는 호스트 파일 시스템을 통해 통신합니다. 이 모든 요소는 오케스트레이션 환경으로 침투할 수 있는 잠재적 진입점이므로 반드시 대응해야 합니다.

기본 Kubernetes 환경

주의가 필요한 핵심 구성 요소를 간략히 살펴보겠습니다:

• API 서버 및 Kubelet
• Pod
• Etcd

그러니 커피 한 잔 준비하세요. 이번 내용은 살펴보는 데 시간이 좀 더 걸릴 테니까요.

1. 인증은 선택 사항이 아닙니다

예리한 독자라면 이 내용이 익숙하게 들릴 것입니다. 보안 규칙 2, 즉 ‘문을 잠가라’라는 원칙으로 들어보셨을 수도 있습니다. 흔히 무시되는 원칙이기에 앞으로도 계속 강조할 주제입니다. 강력한 인증은 필수입니다. 실제로 컨테이너와 관련된 허술한 보안 관행으로 인해 보안 사고가 계속 증가하고 있습니다. 이러한 사고의 흔한 원인 중 하나는 인증을 사용하지 않는 것이며, 특히 퍼블릭 클라우드에 배포할 때 자주 발생합니다.

강력한 자격 증명을 요구하고 자주 교체하세요. 보안이 취약한 콘솔을 통해 API 서버에 접근할 수 있게 되면 전체 오케스트레이션 환경을 제어할 수 있으므로 모든 것이 끝나는 상황으로 이어질 수 있습니다. 즉, 파드를 배포하고 구성을 변경하며 컨테이너를 중지하거나 시작할 수 있다는 뜻입니다. Kubernetes 환경에서 API 서버는 모든 것을 지배하는 ‘절대 API’이므로 악의적인 행위자의 손에 들어가지 않도록 해야 합니다.

API 서버와 Kubelet을 보호하는 방법
이러한 권장 사항은 현재의 Kubernetes 권한 부여 모델을 기준으로 한다는 점에 유의해야 합니다. 사용 중인 버전에 대한 최신 문서를 항상 확인하세요.

• 모든 곳에서 mTLS 활성화
  - 서비스별로 전용 CA 사용 – k8s, etcd, 애플리케이션
  - 인증서를 주기적으로 교체하고 디스크에 저장된 개인 키의 권한에 유의
  
• 보안 주소에만 바인딩
  - API 설정의 “insecure-bind-address” 및 “insecure-port”에 주의
  - 이를 _모든_ 서비스(SSH, Vault, etcd)에 적용
  
• “익명 인증” 비활성화
  - “익명 인증”이 좋은 생각처럼 들리나요?
  - 1.5부터는 기본적으로 비활성화되며, “--anonymous-auth=True”를 사용해 수동으로 활성화할 수 있습니다.
  
• 권한 부여 활성화
  - “--authorization-mode=AlwaysAllow”를 사용하지 마세요.
  - API 서버에는 “--authorization-mode=RBAC,Node”를 설정해야 합니다.
  - Kubelet에는 “--authorization-mode=Webhook”을 설정해야 합니다.
  - Kubelet 제한을 통해 자체 노드의 리소스에만 액세스할 수 있도록 하세요.
  

이러한 권장 사항은 현재 Kubernetes 권한 부여 모델을 기반으로 한다는 점에 유의해야 합니다. 사용 중인 버전에 대한 최신 문서를 항상 확인하세요.

• Kubernetes 권한 부여 참조
• Kubelet 인증 및 권한 부여 참조

2. Pod 및 권한

Pod은 컨테이너의 집합입니다. Kubernetes의 가장 작은 구성 요소이며, 사용하는 컨테이너 네트워크 인터페이스(CNI) 플러그인에 따라 기본적으로 모든 Pod이 서로 통신할 수 있습니다. 일부 CNI 플러그인은 ‘네트워크 정책’을 사용하여 이러한 기본 동작을 제한할 수 있습니다. Pod은 서로 다른 Kubernetes 노드(물리적 서버에 해당)에 스케줄링될 수 있으므로 이 점에 유의해야 합니다. 또한 Pod은 일반적으로 비공개 키, 인증 토큰 및 기타 민감한 정보가 포함될 수 있는 시크릿을 마운트합니다. 이러한 이유로 ‘시크릿’이라고 부릅니다.

이는 Pod와 보안과 관련해 고려해야 할 사항이 여러 가지라는 의미입니다. F5에서는 위협 모델링을 시작할 때 항상 Pod가 침해되었다고 가정합니다. 애플리케이션 워크로드가 Pod에 배포되기 때문입니다. 애플리케이션 워크로드는 신뢰할 수 없는 액세스에 노출될 가능성이 가장 높으므로 침해 지점이 될 가능성도 가장 높습니다. 이러한 가정을 바탕으로 잠재적 위협을 완화할 방법을 계획하기 위해 네 가지 기본 질문을 던질 수 있습니다.

1. 공격자가 하나의 Pod에 액세스할 수 있다면 다른 Pod에서 무엇을 보거나 어떤 작업을 수행할 수 있을까요?
2. 공격자가 클러스터 내의 다른 서비스에 액세스할 수 있나요?
3. 어떤 시크릿이 자동으로 마운트되나요?
4. Pod 서비스 계정에 어떤 권한이 부여되었나요?

이러한 질문에 대한 답변을 통해 공격자가 클러스터 내의 Pod에 액세스할 경우 악용할 수 있는 위험이 드러납니다. Pod 침해 위협을 완화하려면 구성 옵션, 권한 제어, 시스템 수준의 제한을 아우르는 다각적인 접근 방식이 필요합니다. 여러 Pod가 동일한 물리적 또는 가상 노드에 배포될 수 있으므로 운영 체제(일반적으로 Linux OS)에 대한 액세스를 공유한다는 점을 기억하세요.

Pod 위협을 완화하는 방법
Kubernetes에는 Pod의 보안에 민감한 측면을 제어하는 Pod Security Policy 리소스가 포함되어 있습니다. 이를 통해 운영자는 Pod가 시스템에 허용되기 위해 준수해야 하는 운영 조건을 정의하고, Pod Security Context의 기준선을 적용할 수 있습니다. 기본 설정이 안전할 것이라고 단정해서는 안 됩니다. Pod 위협을 방지하려면 안전한 기준선을 구현하고 예상대로 적용되는지 확인해야 합니다.

Pod Security Policy의 구체적인 옵션에서는 다음 사항을 다뤄야 합니다:

• 권한 있는 컨테이너 사용 방지
  • kube-api 및/또는 kubelet에서 “—allow-privileged” 설정을 확인하세요
  • Pod 사양에서 “privileged: true”를 찾습니다.
  • “--allow-privileged=false”로 보안 위험 줄이기
• Docker의 기본 컨테이너 사용자는 root입니다
  • 어떤 워크로드도 root 권한으로 실행하지 마세요
  • Pod Security Policy에서는 “runAsUser”, “runAsGroup” 및 “runAsNonRoot: true”를 사용할 수 있습니다.
  • Dockerfile에서도 유사한 옵션을 정의할 수 있습니다
• 컨테이너 내에서 권한 상승 허용 안 함
  • “allowPrivilegeEscalation: false”
• SELinux / AppArmor 사용
  • SELinux는 다중 범주 보안(Multi Category Security)을 사용하여 컨테이너를 서로 격리합니다.
  • 활성화된 상태로 두고 거부 문제를 하나씩 해결합니다
  • 비활성화하거나 허용 모드로 변경하면 보안 수준이 크게 저하됩니다
• 심볼릭 링크/엔트리포인트 공격 방지
  • 공격자는 엔트리포인트 바이너리를 덮어쓰거나 악성 심볼릭 링크를 생성할 수 있습니다.
  • “readOnlyRootFilesystem: true”로 설정하여 이를 방지하세요.
• host* 구성 옵션 사용 금지
  • 호스트 리소스에 액세스할 수 있는 공격자는 호스트 및/또는 인접 컨테이너로 침해 범위를 확대할 가능성이 더 높습니다.
  • hostPID, hostIPC, hostNetwork, hostPorts와 같은 옵션은 사용하지 마세요.
• 읽기 전용 hostPath 마운트
  • 호스트에 대한 읽기/쓰기를 구성해야 하는 경우에는 배포 시 주의하고, 이를 기본 관행으로 삼지 마세요.
  • 공격을 방지하려면 모든 allowedHostPaths에 “readOnly”를 사용하세요
• Seccomp 프로필
  • 허용되는 시스템 호출을 제한하여 위협 표면 축소
  • Docker 기본값을 사용하면 일부 위협을 줄일 수 있지만 범용 프로필입니다
  • 애플리케이션별 프로파일이 가장 큰 보안 효과를 제공합니다

3. Etcd

Etcd는 구성 정보와 시크릿을 저장하는 저장소입니다. 이곳이 침해되면 민감한 데이터가 유출되거나 악성 데이터가 삽입될 수 있습니다. 어느 쪽도 바람직하지 않습니다. etcd에 대한 위협을 완화하려면 액세스를 제어해야 합니다. 가장 좋은 방법은 mTLS를 적용하는 것입니다. Kubernetes는 시크릿을 etcd에 base64로 인코딩하여 저장합니다. 민감한 시크릿을 더욱 안전하게 저장하려면 알파 기능인 ‘암호화 공급자’ 사용을 고려하거나 HashiCorp Vault 사용을 고려하세요.

시리즈의 다음 블로그를 읽어보세요:
컨테이너 보안 기초: 워크로드