Azure Kubernetes Service의 기밀 컨테이너에 대한 보안 정책
CCC(기밀 컴퓨팅 컨소시엄)에서 설명한 대로 "기밀 컴퓨팅은 하드웨어 기반의 증명된 TEE(신뢰 실행 환경)에서 계산을 수행하여 사용 중인 데이터를 보호하는 것입니다." AKS 기밀 컨테이너는 이러한 Pod 외부의 무단 액세스로부터 사용 중인 Kubernetes Pod 데이터를 보호하도록 설계되었습니다. 각 Pod는 사용 중인 데이터를 암호화하여 AMD SEV-SNP TEE에 의해 보호되는 UVM(유틸리티 VM)에서 실행되고 호스트 OS(운영 체제)에서 데이터에 대한 액세스를 방지합니다. Microsoft 엔지니어는 기밀 컨테이너의 설계 및 구현에 대해 CoCo(기밀 컨테이너) 및 Kata Containers 오픈 소스 커뮤니티와 협력했습니다.
보안 정책 개요
Kata Containers 시스템 아키텍처의 주요 구성 요소 중 하나는 Kata 에이전트입니다. Kata 컨테이너를 사용하여 기밀 컨테이너를 구현하는 경우 에이전트는 하드웨어 기반 TEE 내에서 실행되므로 Pod의 TCB(신뢰할 수 있는 컴퓨팅 베이스)의 일부입니다. 다음 다이어그램에 표시된 것처럼 Kata 에이전트는 TEE 외부의 시스템 구성 요소가 기밀 기반 Kubernetes Pod를 만들고 관리할 수 있도록 하는 ttrpc API 세트를 제공합니다. 이러한 다른 구성 요소(예: Kata Shim)는 Pod의 TCB에 속하지 않습니다. 따라서 에이전트는 잠재적으로 버그가 있거나 악의적인 API 호출로부터 자신을 보호해야 합니다.
AKS 기밀 컨테이너에서 Kata 에이전트 API 자체 보호는 기밀 Pod의 소유자가 지정한 보안 정책(Kata 에이전트 정책이라고도 함)을 사용하여 구현됩니다. 정책 문서에는 업계 표준 Rego 정책 언어를 사용하여 각 Pod에 해당하는 규칙 및 데이터가 포함되어 있습니다. UVM(유틸리티 VM) 내의 정책 적용은 CNCF(Cloud Native Computing Foundation)의 등급별 프로젝트인 OPA(Open Policy Agent)를 사용하여 구현됩니다.
정책 내용
보안 정책은 기밀 Pod를 만들고 관리하는 데 필요한 에이전트의 ttrpc API(및 이러한 API 호출의 매개 변수)에 대한 모든 호출을 설명합니다. 각 Pod의 정책 문서는 Rego 언어를 사용하는 텍스트 파일입니다. 정책 문서의 세 가지 개략적인 섹션이 있습니다.
데이터
정책 데이터는 각 Pod에 따라 다릅니다. 예를 들어 다음이 포함됩니다.
- Pod에 생성될 것으로 예상되는 컨테이너 목록입니다.
- 기본적으로 정책에 의해 차단되는 API 목록입니다(기밀 유지를 위해).
Pod의 각 컨테이너에 대한 정책 문서에 포함된 데이터의 예:
- 이미지 무결성 정보입니다.
- 컨테이너에서 실행되는 명령입니다.
- 스토리지 볼륨 및 탑재.
- 실행 보안 컨텍스트, 예를 들어 루트 파일 시스템은 읽기 전용인가요?
- 프로세스가 새 권한을 얻을 수 있나요?
- 환경 변수입니다.
- OCI(Open Container Initiative) 컨테이너 런타임 구성의 다른 필드입니다.
규칙
Rego 형식으로 지정된 정책 규칙은 UVM(유틸리티 VM) 외부에서 각 Kata 에이전트 API 호출에 대해 OPA에 의해 실행됩니다. 에이전트는 OPA에 모든 API 입력을 제공하고 OPA는 규칙을 사용하여 입력이 정책 데이터와 일치하는지 확인합니다. 정책 규칙 및 데이터가 API 입력을 허용하지 않는 경우 에이전트는 "정책에 의해 차단됨" 오류 메시지를 반환하여 API 호출을 거부합니다. 다음은 몇 가지 규칙 예제입니다.
- 각 컨테이너 계층은 UVM(유틸리티 VM)에 읽기 전용 virtio 블록 디바이스로 노출됩니다. 이러한 블록 디바이스의 무결성은 Linux 커널의 dm-verity 기술을 사용하여 보호됩니다. dm-verity 해시 트리의 예상 루트 값은 정책 데이터에 포함되며 런타임 시 정책 규칙에 의해 확인됩니다.
- 예기치 않은 명령줄, 스토리지 탑재, 실행 보안 컨텍스트 또는 환경 변수가 검색되면 규칙은 컨테이너 생성을 거부합니다.
기본적으로 정책 규칙은 모든 Pod에 공통적으로 적용됩니다. genpolicy 도구는 정책 데이터를 생성하며 각 Pod에 따라 다릅니다.
기본값
정책 데이터 및 API 입력을 매개 변수로 사용하여 Rego 규칙을 평가할 때 OPA는 입력 데이터를 기반으로 true 값을 반환하는 규칙 세트를 하나 이상 찾으려고 합니다. 규칙이 true를 반환하지 않으면 OPA는 에이전트에 해당 API의 기본값을 반환합니다. 정책의 기본값 예:
default CreateContainerRequest := false- 정책 규칙 세트가 명시적으로 해당 호출을 허용하지 않는 한 CreateContainer API 호출이 거부됨을 의미합니다.default GuestDetailsRequest := true- API에서 반환된 데이터가 고객 워크로드의 기밀성에 민감하지 않기 때문에 TEE 외부에서 GuestDetails API로의 호출이 항상 허용됨을 의미합니다.
Kata 에이전트에 정책 보내기
모든 AKS 기밀 컨테이너 UVM(유틸리티 VM)은 UVM(유틸리티 VM) 루트 파일 시스템에 포함된 일반 기본 정책을 사용하여 시작합니다. 따라서 실제 고객 워크로드와 일치하는 정책을 런타임 시 에이전트에 제공해야 합니다. 정책 텍스트는 앞에서 설명한 대로 YAML 매니페스트 파일에 포함되며 UVM(유틸리티 VM) 초기화 초기에 에이전트에 이러한 방식으로 제공됩니다. 정책 주석은 AKS 기밀 컨테이너 시스템의 kubelet, Containerd 및 Kata shim 구성 요소를 통해 이동합니다. 그런 다음, OPA와 함께 작동하는 에이전트는 자체 API에 대한 모든 호출에 대한 정책을 적용합니다.
정책은 TCB에 속하지 않는 구성 요소를 사용하여 제공되므로 처음에는 이 정책을 신뢰할 수 없습니다. 다음 섹션에 설명된 대로 원격 증명을 통해 정책의 신뢰성을 설정해야 합니다.
정책 문서에 대한 신뢰 설정
UVM(유틸리티 VM)을 만들기 전에 Kata shim은 정책 문서의 SHA256 해시를 계산하고 해당 해시 값을 TEE에 연결합니다. 이 작업은 정책의 내용과 UVM(유틸리티 VM) 간에 강력한 바인딩을 만듭니다. 이 TEE 필드는 나중에 UVM(유틸리티 VM) 내부 또는 외부에서 실행되는 소프트웨어에서 수정할 수 없습니다.
정책을 받으면 에이전트는 정책의 해시가 변경할 수 없는 TEE 필드와 일치하는지 확인합니다. 에이전트는 해시 불일치가 감지되면 들어오는 정책을 거부합니다.
중요한 정보를 처리하기 전에 워크로드는 원격 증명 단계를 수행하여 예상된 버전의 TEE, OS, 에이전트, OPA 및 루트 파일 시스템 버전을 사용하여 워크로드가 실행된다는 것을 신뢰 당사자에게 증명해야 합니다. 증명은 AMD SEV-SNP 하드웨어에서 서명된 증명 증거를 가져오는 UVM(유틸리티 VM) 내에서 실행되는 컨테이너에서 구현됩니다. 증명 증거의 필드 중 하나는 앞에서 설명한 정책 해시 TEE 필드입니다. 따라서 증명 서비스는 이 필드의 값을 Pod 정책의 예상 해시와 비교하여 정책의 무결성을 확인할 수 있습니다.
정책 적용
Kata 에이전트는 정책을 적용할 책임이 있습니다. Microsoft는 각 에이전트 ttrpc API 호출에 대한 정책을 확인하는 에이전트 코드를 Kata 및 CoCo 커뮤니티에 제공했습니다. API에 해당하는 작업을 수행하기 전에 에이전트는 OPA REST API를 사용하여 정책 규칙과 데이터가 호출을 허용하거나 차단하는지 확인합니다.