다음을 통해 공유

AKS(Azure Kubernetes Service)를 사용하는 기밀 컨테이너(미리 보기)

  • 아티클

기밀 컨테이너는 더 높은 데이터 보안, 데이터 개인 정보 보호 런타임 코드 무결성 목표를 달성하기 위해 표준 컨테이너 워크로드를 더욱 안전하게 보호하는 기능 세트를 제공합니다. AKS(Azure Kubernetes Service)에는 AKS의 기밀 컨테이너(미리 보기)가 포함되어 있습니다.

기밀 컨테이너는 컨테이너 메모리를 암호화하기 위해 Kata 기밀 컨테이너와 하드웨어 기반 암호화를 기반으로 합니다. 계산 중에 메모리의 데이터가 읽기 쉬운 텍스트 형식이 되지 않도록 하여 새로운 수준의 데이터 기밀성을 설정합니다. 하드웨어 증명을 통해 컨테이너에서 트러스트를 획득하여 신뢰할 수 있는 엔터티에 의해 암호화된 데이터에 액세스할 수 있습니다.

Pod Sandboxing과 함께 Azure에서 격리된 중요한 워크로드를 실행하여 데이터와 워크로드를 보호할 수 있습니다. 컨테이너를 기밀로 유지하는 이유:

  • 투명성: 민감한 애플리케이션이 공유되는 기밀 컨테이너 환경으로, 사용자는 안전한지 확인할 수 있습니다. TCB(신뢰할 수 있는 컴퓨팅 기반)의 모든 구성 요소는 오픈 소스로 제공됩니다.
  • 감사 가능성: Linux 게스트 OS를 포함하는 CoCo 환경 패키지의 버전을 확인하고 모든 구성 요소가 최신 상태인지 확인할 수 있습니다. Microsoft는 증명을 통해 확인하기 위해 게스트 OS 및 컨테이너 런타임 환경에 서명합니다. 또한 게스트 OS 빌드의 SHA(보안 해시 알고리즘)를 릴리스하여 문자열 감사 가능성 및 제어 사례를 빌드합니다.
  • 전체 증명: TEE의 일부인 모든 항목은 원격으로 확인할 수 있는 기능을 사용하여 CPU에서 완전히 측정되어야 합니다. AMD SEV-SNP 프로세서의 하드웨어 보고서는 증명 클레임을 통해 컨테이너 계층 및 컨테이너 런타임 구성 해시를 반영해야 합니다. 애플리케이션은 게스트 OS 이미지 및 컨테이너 런타임을 반영하는 보고서를 비롯한 하드웨어 보고서를 로컬로 가져올 수 있습니다.
  • 코드 무결성: 런타임 적용은 변경할 수 없는 정책 및 컨테이너 서명과 같은 컨테이너 및 컨테이너 구성에 대한 고객 정의 정책을 통해 항상 사용할 수 있습니다.
  • 운영자로부터의 격리: 고객/테넌트 관리자를 포함하여 신뢰할 수 없는 모든 당사자로부터 보호하는 최소 권한 및 가장 높은 격리를 가정하는 보안 설계입니다. 여기에는 기밀 Pod에 대한 기존 Kubernetes 컨트롤 플레인 액세스(kubelet)를 강화하는 것이 포함됩니다.

전체 아키텍처에서 일부로 다른 보안 조치 또는 데이터 보호 제어를 사용하면 중요한 정보를 보호하기 위한 규정, 산업 또는 거버넌스 규정 준수 요구 사항을 충족하는 데 도움을 줍니다.

이 문서는 기밀 컨테이너 기능과 다음 사항을 구현 및 구성하는 방법을 이해하는 데 도움이 됩니다.

  • Azure CLI를 사용하여 AKS 클러스터 배포 또는 업그레이드
  • Pod YAML에 주석을 추가하여 Pod가 기밀 컨테이너로 실행되는 것으로 표시합니다.
  • Pod YAML에 보안 정책 추가
  • 보안 정책 적용 사용
  • 기밀 컴퓨팅에 애플리케이션 배포

지원되는 시나리오

기밀 컨테이너(미리 보기)는 중요한 데이터가 포함된 배포 시나리오에 적합합니다. 예를 들어 PII(개인 식별 정보) 또는 규정 준수에 필요한 강력한 보안을 가진 모든 데이터입니다. 컨테이너를 사용하는 몇 가지 일반적인 시나리오는 다음과 같습니다.

  • 금융 부문의 사기 패턴 인식을 위해 Apache Spark를 사용하여 빅 데이터 분석을 실행합니다.
  • CI/CD(연속 통합 및 지속적인 배포) DevOps 사례의 일부로 코드에 안전하게 서명하기 위해 자체 호스팅 GitHub 실행기를 실행합니다.
  • 신뢰할 수 있는 원본에서 암호화된 데이터 세트를 사용하여 ML 모델의 Machine Learning 추론 및 학습. 개인 정보 보호를 유지하기 위해 기밀 컨테이너 환경 내에서만 암호를 해독합니다.
  • 디지털 광고를 사용하는 소매업과 같은 업계에서 다자간 계산의 일환으로 ID 일치를 위한 빅 데이터 클린 룸을 구축합니다.
  • 클라우드로의 애플리케이션 마이그레이션에 대한 개인 정보 보호 규정을 충족하기 위해 기밀 컴퓨팅 제로 트러스트 랜딩 존을 구축합니다.

고려 사항

다음은 기밀 컨테이너의 이 미리 보기에서 고려해야 할 사항입니다.

  • runc Pod 및 커널 격리 Pod에 비해 Pod 시작 시간이 늘어납니다.
  • 버전 1 컨테이너 이미지는 지원되지 않습니다.
  • 비밀 및 ConfigMaps에 대한 업데이트는 게스트에 반영되지 않습니다.
  • 임시 컨테이너 및 컨테이너에 exec, 컨테이너의 로그 출력 및 stdio(ReadStreamRequest 및 WriteStreamRequest)와 같은 기타 문제 해결 방법에는 정책 수정 및 재배포가 필요합니다.
  • 정책 생성기 도구는 cronjob 배포 유형을 지원하지 않습니다.
  • 컨테이너 이미지 레이어 측정값이 보안 정책에 인코딩되므로 컨테이너를 지정할 때 latest 태그를 사용하지 않는 것이 좋습니다.
  • 서비스, Load Balancer 및 EndpointSlices는 TCP 프로토콜만 지원합니다.
  • 클러스터의 모든 Pod에 있는 모든 컨테이너는 imagePullPolicy: Always로 구성해야 합니다.
  • 정책 생성기는 IPv4 주소를 사용하는 Pod만 지원합니다.
  • Pod가 배포된 후 환경 변수 메서드를 사용하여 설정하는 경우 ConfigMaps 및 비밀 값을 변경할 수 없습니다. 보안 정책은 이를 방지합니다.
  • Pod 종료 로그는 지원되지 않습니다. Pod는 Pod 매니페스트에 지정된 경우 /dev/termination-log 또는 사용자 지정 위치에 종료 로그를 작성하지만 호스트/kubelet은 해당 로그를 읽을 수 없습니다. 게스트에서 해당 파일로 변경된 내용은 호스트에 반영되지 않습니다.

리소스 할당 설정

이 릴리스의 메모리 및 프로세서 리소스 할당 동작을 이해하는 것이 중요합니다.

  • CPU: shim은 Pod 내의 기본 OS에 하나의 vCPU를 할당합니다. 리소스 limits가 지정되지 않은 경우 워크로드에 별도의 CPU 공유가 할당되지 않으면 vCPU가 해당 워크로드와 공유됩니다. CPU 제한을 지정하면 CPU 공유가 워크로드에 명시적으로 할당됩니다.
  • 메모리: Kata-CC 처리기는 UVM OS 및 XMB 추가 메모리에 2GB 메모리를 사용합니다. 여기서 X는 YAML 매니페스트에 지정된 경우 리소스 limits입니다(컨테이너에 대한 암시적 메모리 없이 제한이 지정되지 않으면 2GB VM이 발생함). Kata 처리기는 리소스 limits가 YAML 매니페스트에 지정된 경우 UVM OS 및 XMB 추가 메모리에 256MB 기본 메모리를 사용합니다. 제한을 지정하지 않으면 1,792MB의 암시적 제한이 추가되어 컨테이너에 대해 2GB VM 및 1,792MB의 암시적 메모리가 생성됩니다.

이 릴리스에서는 Pod 매니페스트에서 리소스 요청을 지정하는 것은 지원되지 않습니다. Kata 컨테이너는 Pod YAML 매니페스트의 리소스 요청을 무시하므로 컨테이너가 shim에 요청을 전달하지 않습니다. 리소스 requests 대신 리소스 limit를 사용하여 워크로드나 컨테이너에 메모리 또는 CPU 리소스를 할당합니다.

VM 메모리에서 지원되는 로컬 컨테이너 파일 시스템을 사용하면 컨테이너 파일 시스템에 쓰기(로깅 포함)가 Pod에 제공되는 사용 가능한 메모리를 채울 수 있습니다. 이 조건으로 인해 잠재적인 Pod 충돌이 발생할 수 있습니다.

다음 단계