정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#ConfidentialContainers#CoCo#ConfidentialComputing#TEE#Kubernetes#KataContainers#RemoteAttestation#KeyBrokerService#PeerPods
최종 업데이트 · 2026-09-27

Confidential Containers(CoCo) 기반 Kubernetes 기밀 워크로드 보호

1. 개요

가. 정의

Confidential Containers(CoCo)는 Kubernetes Pod를 하드웨어 기반 TEE(Trusted Execution Environment) 안에서 실행하여, 처리 중인 데이터와 워크로드 코드를 호스트 인프라·하이퍼바이저·다른 테넌트로부터 보호하는 클라우드 네이티브 기밀 컴퓨팅 방식이다.

일반적인 컨테이너는 프로세스와 파일시스템을 격리하지만, 컨테이너가 공유하는 호스트 커널과 하이퍼바이저는 워크로드의 신뢰 경계 밖에 있지 않을 수 있다. 클라우드 운영자나 호스트 관리자에게 강한 권한이 있으면 메모리 덤프, 이미지 저장소 접근, 디버깅 인터페이스 악용을 통해 처리 중인 정보가 노출될 수 있다. 암호화된 디스크와 전송 구간 암호화만으로는 애플리케이션이 메모리에서 평문을 처리하는 순간을 보호할 수 없다는 점이 핵심 문제다.

CoCo는 Kata Containers의 Pod 단위 경량 가상 머신 격리와 AMD SEV-SNP, Intel TDX 같은 하드웨어 메모리 암호화·무결성 기능을 결합한다. 또한 원격 검증자가 실행 환경의 측정값을 확인한 뒤에만 이미지 복호화 키와 비밀을 전달하도록 하여, “암호화된 VM을 켰다”는 사실을 “승인된 소프트웨어가 승인된 TEE에서 실행 중이다”라는 신뢰 판단으로 확장한다. 따라서 CoCo의 본질은 단순한 컨테이너 보안 옵션이 아니라 격리, 측정, 검증, 비밀 전달을 연결하는 워크로드 신뢰 공급망이다.

나. 등장 배경과 필요성

첫째, 클라우드 컴퓨팅에서는 인프라 제공자와 데이터 소유자가 동일하지 않다. 금융기관이 외부 클라우드에서 분석을 수행하거나 제조기업이 여러 협력사의 모델을 공동 실행할 때, 인프라 운영자를 완전히 신뢰하지 않고도 업무를 처리할 필요가 있다. CoCo는 관리형 Kubernetes의 운영 편의성을 유지하면서도 워크로드 내부의 민감한 데이터와 모델을 인프라의 신뢰 경계에서 분리하는 선택지를 제공한다.

둘째, 생성형 AI와 데이터 협업은 입력 데이터뿐 아니라 모델 가중치와 프롬프트도 보호해야 한다. 컨테이너 이미지가 호스트 레지스트리와 노드 캐시에 평문으로 남으면 메모리 암호화만으로는 충분하지 않다. CoCo는 이미지 서명 검증, 암호화 이미지, 원격 증명 기반 키 릴리스와 결합하여 이미지·실행 환경·비밀의 생명주기를 함께 통제한다.

셋째, 기존 Kubernetes 도구를 버리지 않는 것이 중요하다. CoCo는 Pod YAML의 runtimeClassName, 표준 OCI 이미지, Kubernetes 스케줄링을 활용하므로 애플리케이션을 전면 재작성하지 않고 보호된 실행 프로파일을 선택할 수 있다. 다만 모든 Pod가 자동으로 안전해지는 것은 아니며, 컨트롤 플레인·레지스트리·키 브로커·로그·스토리지의 신뢰 경계를 별도로 설계해야 한다.

다. 목표와 범위

CoCo의 1차 목표는 사용 중 데이터(data in use)의 기밀성과 실행 코드의 무결성이다. 저장 데이터는 디스크 암호화와 암호화 이미지로, 전송 데이터는 TLS와 서비스 간 인증으로, 처리 중 데이터는 TEE의 메모리 암호화와 접근 제어로 보호한다. 원격 증명은 이 세 보호 수단을 연결하는 판단 근거이며, 그 자체가 데이터 암호화를 대신하지는 않는다.

CoCo의 보호 대상은 워크로드 Pod와 Pod를 보조하는 제한된 게스트 구성요소다. Kubernetes API 서버, 컨트롤 플레인, 호스트 커널, 하이퍼바이저, 다른 Pod는 기본적으로 기밀 영역 밖의 신뢰되지 않은 요소로 다룬다. 이처럼 보호 범위를 명확히 해야 “노드 전체가 보호된다”거나 “Kubernetes 운영자가 모든 정보를 볼 수 없다”와 같은 과장된 보안 주장을 피할 수 있다.

2. 위협 모델과 신뢰 경계

가. 공격 가정

CoCo는 클라우드 호스트 관리자 또는 악성 하이퍼바이저가 게스트 메모리와 CPU 실행을 관찰·변조하려고 할 수 있다고 가정한다. 또한 공격자가 노드의 컨테이너 런타임을 장악하거나, 이미지 레이어를 복사하거나, Kubernetes API를 통해 디버깅·exec 요청을 시도할 수 있다고 본다. 이 가정은 애플리케이션 취약점과 악성 코드를 해결해 주는 모델이 아니며, 승인된 이미지와 정책을 먼저 전제한다.

대표 위협은 네 가지로 분류할 수 있다. 첫째, 호스트가 VM 메모리 페이지를 읽어 평문을 획득하는 메모리 노출이다. 둘째, 이미지·초기화 스크립트·시크릿을 호스트 저장소에서 복사하는 공급망 노출이다. 셋째, 하이퍼바이저가 게스트 부팅 이미지나 런타임 구성을 바꿔 승인되지 않은 코드를 실행하는 무결성 훼손이다. 넷째, 운영자가 과도한 Kubernetes 권한으로 Pod 내부에 진입하거나, 로그와 임시 볼륨으로 민감한 데이터를 다시 노출하는 운영 경계 실패다.

나. Pod 중심 신뢰 경계

flowchart LR
    U[Workload Pod] --> G[Guest helper and Kata agent]
    G --> T[TEE boundary]
    T --> H[Encrypted guest memory]
    H -. untrusted .-> HV[Hypervisor]
    HV -. untrusted .-> N[Host kernel and node]
    N -. untrusted .-> CP[Kubernetes control plane]
    CP -. untrusted .-> O[Other pods]

CoCo의 설계 문서가 설명하는 핵심은 enclave 안에 워크로드 Pod와 이를 돕는 프로세스·데몬을 두고, 하이퍼바이저·다른 Pod·컨트롤 플레인은 밖에 둔다는 것이다. 이는 노드 전체를 TEE에 넣는 node-centric 방식과 컨테이너 하나만 분리하는 container-centric 방식의 절충이다. Pod 안의 여러 컨테이너는 동일한 네트워크 네임스페이스와 볼륨을 공유할 수 있으므로, 서비스 메시나 사이드카를 무조건 enclave 밖으로 내보내는 추가 통신 경로를 만들지 않는다.

node-centric 방식은 kubelet과 노드 에이전트까지 TCB(Trusted Computing Base)에 포함되기 쉬워 게스트의 공격 면과 검증 범위가 커진다. 반대로 container-centric 방식은 컨테이너 사이의 정상적인 공유를 위해 네트워크·IPC 경계를 다시 연결해야 하므로 구성 복잡도와 성능 비용이 증가한다. Pod-centric 방식은 이 두 극단 사이에서 TCB를 비교적 작게 유지하고, 하나의 업무 단위를 Pod로 묶어 운영하기 쉽게 만든다.

다만 TEE가 보호하는 범위와 애플리케이션의 신뢰 범위는 다르다. Pod 안에 취약한 애플리케이션이 있으면 TEE는 그 취약성을 숨겨 주지 않으며, 악성 입력에 의한 권한 탈취도 막지 못한다. 따라서 이미지 취약점 분석, 애플리케이션 보안, Kubernetes RBAC, 네트워크 정책은 CoCo와 함께 적용해야 한다.

구분 신뢰 경계 주요 책임
기밀 영역 워크로드 Pod, 제한된 guest helper 애플리케이션 실행과 비밀 사용
검증 계층 TEE 측정값, attestation agent 실행 환경 증거 생성
키 릴리스 계층 KBS, attestation service, 정책 저장소 증거 검증과 비밀 전달 결정
플랫폼 영역 하이퍼바이저, 호스트, 다른 Pod 스케줄링·자원 제공, 기본적으로 비신뢰
제어 영역 API 서버, CI/CD, 레지스트리, 운영자 배포 승인·감사·정책 변경

3. 구성요소와 처리 흐름

가. 전체 아키텍처

sequenceDiagram
    participant Dev as Developer or CI
    participant K8s as Kubernetes API
    participant Kata as Kata runtime and Pod VM
    participant TEE as TEE guest
    participant AS as Attestation service
    participant KBS as Key Broker Service
    participant Reg as Registry
    Dev->>K8s: Deploy Pod with RuntimeClass
    K8s->>Kata: Start confidential Pod VM
    TEE->>AS: Send hardware and guest evidence
    AS-->>KBS: Return appraisal result
    KBS->>TEE: Release image key and secrets
    TEE->>Reg: Pull encrypted or signed image
    TEE-->>K8s: Run workload and report status

Kata Containers는 일반 컨테이너 런타임과 달리 Pod를 경량 VM 안에서 실행하는 격리 계층이다. CoCo는 이 VM이 TEE 하드웨어에서 실행되도록 하고, 게스트 내부에 기밀 데이터 허브와 증명 에이전트 같은 구성요소를 추가한다. Kata Agent는 게스트 안에서 컨테이너 생명주기를 관리하므로, 호스트가 임의로 게스트의 컨테이너 작업을 결정하지 않도록 게스트 정책과 함께 보호해야 한다.

Attestation Agent는 하드웨어와 게스트 실행 상태를 증명하기 위한 evidence를 생성한다. evidence에는 TEE 종류, 게스트 이미지 측정값, 초기화 데이터, 런타임 구성 등 정책 판단에 필요한 값이 포함될 수 있다. 검증자는 단순히 “증명 메시지가 있다”는 이유로 신뢰하지 않고, 하드웨어 서명·인증서 체인·허용 측정값·TCB 보안 수준을 검토해야 한다.

Trustee 계열 구성에서는 Attestation Service가 증거를 검증하고, Key Broker Service(KBS)가 어떤 워크로드에 어떤 비밀을 내줄지 판단한다. Confidential Data Hub는 게스트 안에서 비밀 자원 요청을 중개하고, 게스트의 애플리케이션이 KBS 프로토콜을 직접 구현하지 않게 한다. 결정과 집행을 분리하면 KBS는 정책을 바꾸면서도 워크로드 이미지를 다시 빌드하지 않을 수 있지만, 정책 버전과 결정 로그를 반드시 추적해야 한다.

나. 원격 증명과 조건부 키 릴리스

증명 절차는 보통 다음의 순서를 따른다. 먼저 게스트가 nonce가 포함된 challenge를 받고, TEE 하드웨어가 현재 실행 환경의 측정 증거를 생성한다. 그 다음 Attestation Service가 증거의 서명과 인증서 체인을 확인하고, 조직의 appraisal policy와 reference value를 비교한다. 검증 결과가 통과하면 KBS는 요청한 이미지 키나 시크릿을 정책 조건에 따라 전달한다. 실패하면 키를 내리지 않으므로, 암호화된 이미지가 있어도 승인되지 않은 게스트는 업무를 시작할 수 없다.

키 릴리스 정책은 “TEE이면 허용”처럼 단순해서는 안 된다. TEE 종류, 게스트 이미지 다이제스트, Kata Agent 정책, 컨테이너 이미지 다이제스트, 네임스페이스, 워크로드 신원, 만료 시간과 목적을 함께 조건으로 삼는다. 예를 들어 운영 모델 가중치 키는 승인된 GPU TEE와 특정 이미지 다이제스트가 동시에 일치할 때만 허용하고, 개발 데이터 키는 별도의 낮은 등급 정책으로 제한할 수 있다.

증명은 한 번 통과하면 영원히 신뢰하는 인증서 발급이 아니다. 게스트 재부팅, 이미지 변경, TCB 보안 패치, 키 만료, 정책 변경 시 재검증해야 하며, 서비스가 장시간 실행되는 경우에도 세션 키와 lease를 갱신하는 설계가 필요하다. 또한 증거와 로그에 개인정보나 비밀을 그대로 기록하지 않고, 검증에 필요한 측정값·정책 버전·결정 결과를 최소화해야 한다.

다. 이미지와 시크릿 보호

서명 이미지는 이미지가 승인된 공급자에 의해 만들어졌고 변조되지 않았는지 확인하는 데 적합하다. 그러나 서명만으로는 레지스트리 운영자나 호스트가 이미지 내용을 읽는 것을 막지 못한다. 모델 가중치나 영업 데이터처럼 이미지 자체의 기밀성이 필요한 경우에는 이미지 레이어를 암호화하고, 증명 성공 이후에만 복호화 키를 가져오도록 구성한다.

암호화 이미지의 guest pull 방식에서는 호스트 런타임이 평문 레이어를 대신 풀지 않는다. 게스트가 증명을 통과한 뒤 KBS에서 키를 받고, 게스트 내부에서 레지스트리로부터 이미지를 가져와 복호화·검증·실행한다. 이때 레지스트리 자격증명이 호스트에 노출되는 구조라면 보호 목표가 약화되므로, 인증 토큰의 범위와 보관 위치도 기밀 영역에 맞춰야 한다.

Kubernetes Secret을 그대로 Pod 환경변수로 주입하면 로그, 코어 덤프, 디버깅 도구로 다시 노출될 수 있다. 따라서 시크릿은 KBS 리소스 정책과 워크로드 신원을 묶고, 런타임에 필요한 최소 시점에 단기 자격증명으로 전달한다. 애플리케이션이 시크릿을 오래 보관해야 하는지, 메모리에서 즉시 폐기할 수 있는지까지 데이터 분류 정책과 함께 결정해야 한다.

라. Kubernetes 연계

CoCo는 RuntimeClass로 보호 실행 프로파일을 선택하는 방식을 사용한다. 예를 들어 일반 Pod는 기본 런타임을 사용하고, 민감한 Pod만 kata-qemu-snp 또는 kata-qemu-tdx와 같은 클래스에 배치할 수 있다. 스케줄러는 TEE가 가능한 노드의 라벨과 자원 조건을 고려해야 하며, 잘못된 노드에 배치되면 배포 실패 또는 의도하지 않은 비기밀 실행이 발생할 수 있다.

Admission 정책은 허용된 이미지, 필수 RuntimeClass, 금지된 디버깅 옵션, 노드 라벨, 네임스페이스, 서비스 계정을 점검해야 한다. CoCo의 기밀성은 애플리케이션 Pod만 TEE에 넣고 사이드카·init container는 일반 런타임에 두는 식으로 분리하면 쉽게 깨진다. Pod 전체의 컨테이너와 초기화 단계를 동일한 보호 경계로 검토하고, 예외는 승인자·기간·사유를 가진 정책 객체로 남겨야 한다.

4. 배포 방식과 비교

가. 로컬 Pod VM과 Peer Pods

로컬 Pod VM 방식은 클러스터 노드에서 Kata VM을 생성하고, TEE 지원 CPU가 있는 베어메탈 또는 적합한 가상화 환경을 사용한다. 노드 자원을 직접 관리할 수 있다는 장점이 있지만, 중첩 가상화·장치 패스스루·노드 교체·TEE 펌웨어 호환성을 운영해야 한다.

Peer Pods 방식에서는 Cloud API Adaptor가 기존 클러스터 노드의 일반 하이퍼바이저 대신 클라우드 API를 호출하여 TEE가 활성화된 외부 VM을 만든다. 따라서 클러스터 노드가 TEE 베어메탈일 필요가 줄어들고, 클라우드의 confidential VM 서비스를 활용할 수 있다. 반면 Pod 생성 지연, 클라우드 API 의존성, 외부 VM의 네트워크·스토리지 연결, 비용과 장애 도메인을 추가로 관리해야 한다.

비교 항목 로컬 Pod VM Peer Pods
VM 생성 위치 Kubernetes worker node 클라우드 API가 만든 외부 VM
장점 낮은 외부 의존성, 세밀한 노드 제어 기존 클러스터에 도입, CSP TEE 활용
주요 부담 TEE 노드·펌웨어·장치 관리 API 지연·네트워크·외부 VM 비용
적합 환경 통제된 온프레미스·엣지 퍼블릭 클라우드·멀티테넌트
공통 위험 증명 정책, 키 릴리스, 이미지 보호를 별도 설계해야 함 증명 정책, 키 릴리스, 이미지 보호를 별도 설계해야 함

나. 기존 컨테이너·Kata·CoCo 비교

기존 컨테이너는 호스트 커널을 공유하므로 시작 속도와 밀도가 높지만, 호스트 관리자에 대한 기밀성은 보장하지 않는다. 일반 Kata Containers는 VM 격리로 호스트와 컨테이너를 분리하지만, 이미지와 게스트 구성요소가 항상 원격 증명과 키 릴리스에 결합되는 것은 아니다. CoCo는 Kata의 VM 경계에 하드웨어 TEE와 조건부 비밀 전달을 더해 “실행 중인 코드와 환경을 검증하지 못하면 비밀을 얻을 수 없다”는 정책을 구현한다.

대신 CoCo는 일반 컨테이너보다 VM 부팅·증명·키 교환 비용과 운영 복잡도가 높다. 고성능 네트워크, GPU, CSI 스토리지, 디버깅·관측 도구가 TEE 경계와 충돌할 수 있으므로, 모든 업무를 무조건 CoCo로 옮기는 것은 합리적이지 않다. 데이터의 민감도와 제공자 위협 수준을 기준으로 보호 프로파일을 선택하고, 일반·Kata·CoCo를 혼합 운영하는 것이 비용과 보안의 균형에 맞다.

5. 적용 사례

금융기관이 여러 기관의 거래 특징량을 공동 분석한다고 가정하자. 각 기관은 원천 데이터를 외부 클라우드 운영자에게 노출하고 싶지 않지만, 분석 결과는 공유하고자 한다. 기관별 암호화 입력과 승인된 분석 이미지를 CoCo에 배치하고, KBS는 TEE 측정값·이미지 다이제스트·분석 목적이 모두 맞을 때만 데이터 복호화 키를 제공한다. 분석 결과에는 출력 범위·재식별 방지·쿼리 빈도 제한을 적용하여, TEE가 있다고 해서 결과 단계의 개인정보 위험이 사라지지 않도록 한다.

두 번째 사례는 제조기업의 AI 모델 보호다. 추론 서비스는 외부 클라우드 GPU를 사용하지만, 모델 가중치는 경쟁사의 핵심 자산이므로 노드 운영자가 읽을 수 없어야 한다. CoCo와 GPU TEE를 함께 사용하면 모델 이미지와 입력 데이터를 암호화하고, GPU·CPU 측정값이 모두 승인된 경우에만 모델 키를 릴리스하는 composite attestation 구성을 고려할 수 있다. 다만 GPU 패스스루, 드라이버, CUDA 버전, 모델 로더가 TCB와 증명 기준에 포함되므로, 지원 매트릭스와 재현 가능한 빌드가 선행되어야 한다.

세 번째 사례는 SaaS 사업자의 테넌트 격리다. 테넌트별 민감 문서를 처리하는 공통 분석 Pod를 CoCo에서 실행하고, 테넌트 키는 테넌트 신원·처리 목적·단기 lease와 묶는다. 운영자가 Pod에 exec하는 기능은 일반 운영 환경처럼 허용하지 않고, 승인된 디버깅 이미지와 마스킹된 진단 채널만 제공한다. 이 구조는 인프라 제공자에 대한 신뢰를 낮추지만, SaaS 애플리케이션 자체의 권한 검증과 테넌트 간 논리 격리를 대체하지는 않는다.

6. 심화 — 성숙도와 답안 구성 전략

CoCo는 하드웨어별 TEE 구현 차이를 Kubernetes 워크로드 모델로 추상화하려는 오픈소스 프로젝트다. 실제 적용 시에는 사용하는 CPU·GPU, 클라우드 제공자, Kata 런타임, Trustee 구성, CSI와 네트워크 지원 여부가 버전별로 다를 수 있으므로 공식 릴리스 노트와 하드웨어 지원표를 기준으로 검증해야 한다. 문서의 “선택적 기능”을 운영 보장으로 오해하지 말고, 암호화 이미지·서명 검증·원격 증명·Peer Pods를 각각 PoC와 장애 테스트로 확인해야 한다.

기술사 답안에서는 먼저 “저장·전송 암호화만으로는 data in use를 보호할 수 없다”는 문제를 제시하는 것이 좋다. 다음으로 Pod-centric 신뢰 경계와 TEE를 설명하고, Kata runtime → attestation → KBS → encrypted image 순서의 처리 흐름을 개념도로 제시한다. 그 후 기존 컨테이너·Kata·CoCo를 기밀성, 무결성, 성능, 운영 난이도 기준으로 비교한다. 마지막에는 키 릴리스 정책, 공급망, 관측성, 예외 승인, 성능 검증을 기술사 관점의 고려사항으로 연결해야 논술의 완결성이 높아진다.

특히 “TEE가 모든 공격을 막는다”는 표현은 피한다. TEE는 호스트로부터 메모리와 실행 상태를 보호하는 강력한 하드웨어 경계를 제공하지만, 애플리케이션 취약점·악성 이미지·부적절한 키 정책·부주의한 로그·서비스 거부까지 자동으로 해결하지 않는다. 보호 보장은 하드웨어, 게스트 이미지, 런타임 정책, 이미지 공급망, KBS 정책이 하나의 검증 가능한 체인으로 연결될 때 성립한다.

7. 고려사항 및 시사점

가. TCB 최소화와 측정 기준

TCB에 포함되는 게스트 커널, Kata Agent, 초기화 데이터, 드라이버, GPU 구성요소를 최소화하고 각각의 버전과 빌드 해시를 관리한다. 측정값이 바뀔 때마다 무조건 배포를 중단하면 패치가 어려워지고, 반대로 모든 측정값을 허용하면 증명의 의미가 사라진다. 허용 목록의 변경은 보안 리뷰와 롤백 절차를 거치며, 긴급 패치와 일반 릴리스를 구분한 appraisal policy를 운영해야 한다.

나. 키 관리와 정책 분리

KBS는 단순한 비밀 저장소가 아니라 증거를 평가하는 정책 집행 지점이다. 키를 이미지 다이제스트·워크로드 신원·목적·환경·만료 시간과 결합하고, 관리자도 평문 키를 볼 수 없는 키 계층을 설계한다. 정책 작성자와 키 운영자를 분리하고, 정책 변경·키 릴리스·실패 사유를 감사 로그로 남기되 로그 자체에 비밀이 섞이지 않게 한다.

다. 공급망과 재현성

게스트 이미지와 컨테이너 이미지를 재현 가능하게 빌드하고, SBOM·서명·취약점 점검·출처 증명을 CI/CD에 연결한다. 서명은 무결성과 출처를 보완하지만 기밀성을 제공하지 않으므로, 필요한 경우 암호화 이미지와 함께 사용한다. KBS가 허용하는 이미지 다이제스트와 배포 파이프라인의 승인 기록이 불일치하면 키를 내리지 않는 fail-closed 정책을 기본값으로 검토한다.

라. 성능·가용성과 장애 모드

증명과 키 교환은 Pod 시작 시간에 추가 지연을 만든다. 부팅 지연, 레지스트리 왕복, KBS 장애, TEE 자원 부족을 SLO에 반영하고, 키 캐시를 쓰더라도 캐시된 키의 범위와 만료를 제한한다. KBS나 Attestation Service가 일시적으로 실패했을 때 기존 Pod의 계속 실행과 신규 Pod의 시작을 다르게 처리할지, 장애 시 fail-open을 허용할지 사전에 결정한다.

마. 관측성과 디버깅

기밀성을 이유로 운영 데이터를 전혀 기록하지 않으면 장애 대응이 불가능해진다. 증명 성공·실패, 정책 버전, 이미지 다이제스트, 런타임 클래스, 키 릴리스 결과를 민감정보 없이 구조화하여 기록하고, 로그 접근도 최소 권한으로 제한한다. 메모리 덤프와 원격 exec는 기본 거부하고, 재현용 비기밀 환경과 승인된 진단 이미지를 별도로 제공하는 것이 안전하다.

바. 규제와 책임 경계

CoCo는 개인정보·금융·의료 데이터의 기술적 보호 수단을 강화하지만, 법적 처리 근거와 목적 제한을 대신하지 않는다. 누가 증명 정책을 소유하는지, 누가 reference value를 승인하는지, 하드웨어 공급자와 클라우드 사업자의 책임이 어디까지인지 계약과 운영 절차에 명시한다. 감사에서는 TEE 사용 여부보다 데이터 분류, 키 릴리스 근거, 예외 승인, 폐기와 복구 기록을 연결해 통제의 실효성을 설명해야 한다.

한 줄 요약: Confidential Containers는 Kata 기반 Pod 격리와 하드웨어 TEE·원격 증명·조건부 키 릴리스를 연결하여 신뢰하지 않는 인프라에서도 Kubernetes의 사용 중 데이터와 워크로드를 보호하는 실행형 기밀 컴퓨팅 방식이다.

참고자료