이 글은 “컨테이너는 편한데, 클러스터 운영 주체(CSP/관리자)를 완전히 신뢰하기 어려운 상황”에서 현실적으로 선택할 수 있는 해법 중 하나인 **Confidential Containers(이하 CoCo)**를 정리하기 위해 작성했습니다. 읽고 나면 TEE 기반 신뢰 모델, 원격 검증(attestation), 시크릿 전달, Kubernetes에서의 배포 구성요소를 한 흐름으로 이해할 수 있습니다.
Confidential Containers란 무엇인가요?
Confidential Containers는 TEE(Trusted Execution Environment) 를 활용해 컨테이너 워크로드와 데이터를 보호하는 클라우드 네이티브 기밀 컴퓨팅(Confidential Computing) 오픈소스 커뮤니티/프로젝트입니다.
일반적으로 컨테이너 보안은 “호스트/커널을 신뢰한다”는 가정 위에 올라가는데, CoCo는 이 가정을 완화합니다. 핵심 목표는 다음처럼 요약할 수 있습니다.
- 수정 없는(unmodified) 컨테이너를 가능한 “그대로” 기밀 실행 환경에 올리고 싶습니다.
- 특정 벤더/하드웨어에 종속되지 않고 다양한 TEE를 지원하는 방향을 지향합니다.
- Kubernetes 운영 모델을 해치지 않으면서도 투명한 배포 경험을 제공하려 합니다.
왜 “신뢰 모델”이 핵심인가요?
CoCo를 이해하는 가장 좋은 출발점은 “누구를 신뢰하고, 누구를 신뢰하지 않느냐”입니다.
- 전통적 모델: 클러스터 관리자(혹은 CSP), 노드 OS, 하이퍼바이저까지 포함해 넓게 신뢰하는 경우가 많습니다.
- CoCo 지향 모델: CSP/인프라 운영 주체와 게스트 애플리케이션(워크로드)을 분리하고, 워크로드가 올라가는 실행 환경의 무결성을 TEE + attestation으로 확인하려 합니다.
이 관점은 Kubernetes 운영에서 특히 강력합니다. Kubernetes는 본질적으로 “관리 권한이 강력한 시스템”이라, 관리자가 마음먹으면 워크로드에 영향을 주기 쉽습니다. 그래서 CoCo 문맥에서는 최소권한(least privilege) 이 단순 모범사례가 아니라 “신뢰 모델을 성립시키는 전제 조건”에 가깝습니다.
구성요소를 한 줄로 연결하면: 배포(Operator) → Attestation → Secret Delivery
CoCo는 “TEE 위에서 컨테이너를 돌린다” 한 문장으로 끝나는 문제가 아니라, Kubernetes 배포/운영까지 포함한 체계를 제공합니다. 큰 흐름은 아래처럼 이해하면 편합니다.
1) Operator 기반 배포
Kubernetes에서 CoCo를 설치/관리하기 위해 Operator 기반 배포 방식을 제공합니다. 덕분에 클러스터 입장에선 “특수한 워크로드 런타임을 운영”하는 것이고, 개발자 입장에선 “컨테이너는 비슷하게 배포”하는 그림을 만들 수 있습니다.
2) Attestation(원격 검증): “내가 올라간 곳이 진짜 TEE인가?”
Attestation은 워크로드가 실행되기 전에/중에 다음을 확인하는 메커니즘입니다.
- 지금 실행 환경이 정상적인 TEE 설정을 갖췄는지
- 초기 부팅/런타임 구성 요소가 변조되지 않았는지
- (확장하면) 정책에서 요구하는 측정값/구성(예: 이미지 서명, 런타임 버전 등)을 만족하는지
이 단계가 있어야 “클러스터 운영자도 신뢰하지 않는다”는 모델이 현실적으로 굴러갑니다. 즉, 보호의 출발점은 암호화 자체가 아니라 검증(attestation) 입니다.
3) Secret Delivery(시크릿 전달): “검증된 워크로드에게만 비밀을 준다”
Attestation이 “신뢰할 수 있는 실행 환경인지”를 증명해 주면, 그 다음은 자연스럽게 이렇게 됩니다.
- “그 환경에서 돌아가는 워크로드에게만 시크릿을 전달하자”
- “검증 실패 시에는 시크릿을 주지 말자”
CoCo가 말하는 시크릿 전달은 단순히 Kubernetes Secret을 마운트하는 문제가 아니라, attestation 결과를 기준으로 시크릿을 조건부로 해제(release) 하는 패턴과 잘 맞물립니다.
Peer Pods / Cloud API Adapter: 컨테이너를 “VM급 격리”로 가져가는 방식
CoCo 생태계에서 자주 언급되는 구성요소로 Cloud API Adapter(일명 peer-pods) 계열이 있습니다. 이는 컨테이너를 실행할 때 “노드 위에서만 돌리는 컨테이너”가 아니라, 클라우드 API를 통해 격리된 실행 단위(예: VM/Pod VM 형태) 로 분리하는 모델과 연결됩니다.
요지는 이겁니다.
- 컨테이너는 가볍지만, “멀티테넌시/운영자 신뢰” 관점에서는 격리가 부족할 수 있습니다.
- TEE와 결합하면 “격리 + 기밀성”을 더 강하게 가져갈 수 있습니다.
- Kubernetes 경험은 유지하면서도, 실행 경계를 더 강하게 만들 수 있습니다.
(현실) 운영 복잡도와 보안 강화를 어떻게 균형 잡을까?
정리하면 CoCo의 방향성은 일관됩니다. 보안 요구 충족과 운영/배포의 투명성을 동시에 잡겠다는 것입니다. 다만 제가 보기에 “현장에서 진짜 어려운 지점”은 아래의 균형입니다.
- 디버깅/관측성: TEE 특성상 내부를 들여다보기 어렵거나 제한되는 순간이 생깁니다. 운영팀 입장에선 장애 대응 비용이 증가할 수 있습니다.
- 성능/비용: TEE 사용에 따른 오버헤드, 격리 단위가 커질 때(예: Pod VM) 늘어나는 비용이 있습니다.
- 거버넌스/권한 모델: “관리자가 할 수 있는 일”을 줄이는 설계는 좋지만, Kubernetes는 원래 강력한 관리 시스템이라 정책/권한을 촘촘히 설계해야 합니다.
여기서 제가 중요하게 보는 인사이트는, CoCo가 단순 기능이 아니라 거버넌스 변화를 요구한다는 점입니다. 예를 들어 “누가 무엇을 승인할 수 있는가”, “attestation 실패 시 어떤 예외 절차가 가능한가” 같은 운영 규칙이 기술과 함께 설계되어야 합니다.
(확장 생각) AI가 만든 IaC와도 연결됩니다: “최소권한”을 어디까지 강제할 것인가?
대화에서 나왔던 주제인 AI로 생성된 IaC(Infrastructure as Code) 거버넌스는 CoCo의 메시지와도 묘하게 맞닿아 있습니다. 결국 둘 다 “운영 주체(사람/도구/플랫폼)를 완전히 신뢰할 수 없을 때 무엇으로 통제할 것인가”의 문제입니다.
특히 IAM은 CoCo 환경에서도 여전히 가장 위험한 축입니다.
- IAM이 잘못 열리면, TEE로 보호하려던 데이터/워크로드도 “주변 권한”으로 우회 공격이 가능해질 수 있습니다.
- 그래서 “IAM은 AI 생성 금지”처럼 단순 룰로 갈 수도 있지만,
- 현실적으로는
AdministratorAccess, 와일드카드*, 조건 없는 AssumeRole, 외부 Principal 신뢰 같은 고위험 패턴을 정책-as-code로 차단하는 쪽이 운영 친화적일 때가 많습니다.
즉, CoCo가 제공하는 기술(TEE/attestation/secret delivery)만큼이나, 권한과 변경을 다루는 거버넌스가 함께 성숙해야 “보안이 실제로 강해졌다”라고 말할 수 있습니다.
마무리
Confidential Containers는 “컨테이너를 더 안전하게” 수준을 넘어, Kubernetes에서 신뢰 경계를 다시 그리는 방법을 제시합니다. TEE, attestation, 시크릿 전달, 그리고 최소권한 운영 원칙을 한 세트로 이해하고 도입 전략을 세우는 것이 현실적인 출발점입니다.