기밀 컴퓨팅(Confidential computing)은 신뢰할 수 있는 실행 환경(Trusted Execution Environment, TEE)을 활용하여 사용 중인 메모리를 보호함으로써 유휴 데이터, 전송 중인 데이터, 사용 중인 데이터를 암호화합니다. 기밀 컨테이너(Confidential Container, CoCo)는 TEE와 쿠버네티스 배포를 결합합니다. 포드 수준에서 TEE를 배포하면 워크로드를 클러스터의 다른 워크로드뿐만 아니라 클러스터 관리자로부터 확실하게 격리할 수 있습니다.

기밀 컨테이너는 시작하는 것이 가장 어렵습니다. 포드를 기밀 컨테이너에 배포하려면 포드 매니페스트에서 한 줄만 변경하면 됩니다. 그러나 시작할 때는 여러 구성 요소를 함께 배포해야 하며, 이상적으로는 여러 클러스터에 배포해야 합니다. Red Hat은 최근 Red Hat OpenShift Sandboxed Container Operator v1.9 이상에서 Microsoft Azure 기반 기밀 컨테이너에 대한 지원과 Red Hat build of Trustee를 통한 원격 증명에 대한 지원을 릴리스했습니다.

이 블로그에서는 검증된 패턴을 사용하여 다음 세 가지 목표를 달성하는 방법을 설명합니다.

1. OpenShift Sandboxed Containers Operator와 Red Hat build of Trustee on Azure를 사용하여 기밀 컨테이너(CoCo) 시작을 간소화합니다.
2. 모범 사례 배포를 지원하기 위해 CoCo에 일관되고 선언적인 기반을 제공합니다.
3. CoCo를 사용하여 애플리케이션을 배포하는 방법을 확인합니다.

검증된 패턴의 개요 

검증된 패턴은 다양한 멀티클라우드 및 하이브리드 클라우드 활용 사례를 위한 현대적인 코드 아키텍처입니다. 각 패턴은 테스트를 거쳐 성숙해지면 Red Hat의 지속적 통합(CI) 시스템에 추가됩니다. Red Hat은 최신 버전의 오퍼레이터, OpenShift 릴리스, 그리고 여러 퍼블릭 클라우드 환경 전반에서 테스트를 수행합니다.

Red Hat의 각 검증된 패턴 리포지토리는 서비스에서 지원 인프라에 이르기까지 하이브리드 클라우드 스택을 선언적이고 포괄적으로 설명하는 쿠버네티스 리소스의 형태(helm 차트, kustomize, 원시 객체)로 비즈니스 활용 사례를 보여줍니다. 검증된 패턴은 복잡하고 재현 가능성이 높은 배포를 용이하게 하며, GitOps 운영 사례를 활용하여 이러한 배포를 규모에 맞게 운영하는 데 적합합니다.

검증된 패턴을 사용하는 이유 

복잡한 비즈니스 솔루션을 배포하려면 여러 단계를 거쳐야 합니다. 각 단계를 잘못 수행하면 잠재적인 오류나 비효율성이 발생할 수 있습니다. 검증된 패턴은 다음과 같이 사전 검증되고 자동화된 배포 프로세스를 제공하여 이 문제를 해결합니다.

• GitOps 모델을 사용하여 활용 사례를 코드로 제공합니다.
• 특정 요구 사항에 맞게 수정된 기술 검증(PoC)의 역할을 하며, 사용자는 이를 실제 배포로 발전시킬 수 있습니다.
• 재현 가능성이 높기 때문에 대규모 운영에 적합합니다.
• 검증된 패턴은 협업에 개방적입니다. 모든 Git 리포지토리가 업스트림이므로 누구나 개선 사항을 제안 또는 활용하거나, 개선 사항에 기여할 수 있습니다.
• 검증된 각 패턴은 특정 요구 사항에 맞게 수정할 수 있습니다. 구성 요소(component)를 교체하려는 경우(예: S3 대신 Ceph 스토리지 사용) 구성에서 섹션을 주석 처리하고 다른 리포지토리를 포함하는 것만큼 쉽습니다.
• 테스트는 완료되었습니다. 검증된 패턴이 생성되면 활용 사례가 Red Hat의 CI에 포함되며 패턴이 활성 상태를 유지하는 동안 제품 버전 전반에서 계속 테스트됩니다.

검증된 패턴은 “바로 사용할 수 있는(batteries included)” 솔루션입니다. 패턴 프레임워크로 시작할 때마다 코어와 구성 가능한 구성 요소 세트가 즉시 제공됩니다. 본 문서용으로는 검증된 패턴을 사용하여 기밀 컨테이너를 손쉽게 시작할 수 있는 방법을 만들었습니다.

패턴을 배포하는 방법

검증된 패턴 웹사이트에는 검증된 패턴을 사용하는 방법에 대한 광범위한 도큐멘테이션이 있습니다. 모범 사례에 필요한 사항은 다음과 같습니다.

1. 패턴의 Git 리포지토리(예: 패턴의 포크) 검증된 패턴은 GitOps를 사용하므로 사용 중인 리포지토리를 사용자가 제어
2. oc, Git, Podman이 설치된 개발자 노트북
3. 패턴 오퍼레이터가 클러스터를 '관리'하는 빈 OpenShift 클러스터

이러한 요구 사항이 상호작용하는 방식은 다음과 같습니다.

이 설정에서는 검증된 패턴이 클러스터의 항목을 '소유'하므로 사용자는 단일 위치에서 시작하면 됩니다.

기밀 컨테이너에 검증된 패턴 사용

Red Hat OpenShift 샌드박스 처리된 컨테이너는 Kata Containers를 기반으로 구축되며 기밀 컨테이너를 실행할 수 있는 추가 기능을 제공합니다. 기밀 컨테이너는 격리된 하드웨어 엔클레이브 내에 배포된 컨테이너로, 클라우드 또는 클러스터 관리자와 같은 권한 있는 사용자로부터 데이터와 코드를 보호하는 데 도움이 됩니다. CNCF Confidential Containers 프로젝트는 OpenShift CoCo 솔루션의 기반입니다.

기밀 컴퓨팅은 전용 하드웨어 기반 솔루션을 활용하여 사용 중인 데이터를 보호하는 데 도움이 됩니다. 하드웨어를 사용하면 자체 소유의 격리된 환경을 구축할 수 있으며, 워크로드의 데이터가 실행되는 동안(사용 중인 데이터) 무단 액세스 또는 변경으로부터 보호할 수 있습니다.

CoCo는 다양한 하드웨어 플랫폼과 지원 기술을 사용하여 클라우드 네이티브 기밀 컴퓨팅을 지원합니다. CoCo의 목표는 포드 레벨에서 기밀 컴퓨팅을 표준화하고 쿠버네티스 환경에서 기밀 컴퓨팅의 사용을 간소화하는 것입니다. 이를 통해 쿠버네티스 사용자는 기반 기밀 컴퓨팅 기술에 대한 심층적인 이해 없이도 익숙한 워크플로우와 툴을 사용하여 CoCo 워크로드를 배포할 수 있습니다.

자세한 내용은 OpenShift 기밀 컨테이너 솔루션 살펴보기를 참조하세요. 

기밀 컨테이너 아키텍처 

Red Hat 기밀 컨테이너 솔루션은 다음 두 가지 주요 오퍼레이터를 기반으로 합니다.

• Red Hat OpenShift 기밀 컨테이너: Red Hat OpenShift 샌드박스 컨테이너 오퍼레이터에 추가된 기능으로, 하드웨어에서 제공하는 TEE의 내부에서 실행되는 워크로드(포드)와 기밀 가상 머신(CVM)을 연결하기 위한 구성 요소를 배포합니다.
• 원격 증명: Red Hat build of Trustee는 Red Hat OpenShift 클러스터에서 Key Broker Service(KBS)를 배포하고 관리합니다.

자세한 내용은 Confidential Containers Trustee 소개: 증명 서비스 솔루션 개요 및 활용 사례를 참조하세요.

일반적으로 CoCo에는 신뢰할 수 있는 영역과 신뢰할 수 없는 영역이라는 두 가지 환경이 있습니다. 두 영역마다 Trustee와 샌드박스 컨테이너 오퍼레이터가 배포됩니다. 

그렇다면 어떤 점이 어려운 걸까요? 기밀 컨테이너를 배포하는 방법을 이해하려면 클라우드 또는 온프레미스 인프라에 대한 이해와 구체적인 세부 사항이 필요합니다. 그러려면 다음과 같은 몇 가지 질문을 생각해봐야 합니다. 예를 들면 다음과 같습니다. 어느 지역에 계신가요? 어떤 칩셋(Intel, AMD, IBM Power, s390)과 하이퍼바이저를 대상으로 하나요? 

CoCo 배포에 대한 자세한 내용은 Red Hat OpenShift 기밀 컨테이너 솔루션 배포 고려 사항을 참조하세요.

기밀 컨테이너 검증된 패턴 소개

기밀 컨테이너 검증된 패턴의 목표는 기밀 컨테이너를 손쉽게 시작하고 배포하는 방법을 이해하는 것입니다. 기밀 컨테이너 검증된 패턴은 검증된 패턴 아키텍처를 사용하여 다음을 수행합니다.

1. CoCo 실행에 필요한 오퍼레이터 배포
2. 인증서를 비롯한 주변 백그라운드 구성 요소를 설정(필요하다면 Let’s Encrypt 사용)
3. Red Hat Advanced Cluster Manager와 같은 툴을 사용하여 클라우드에서 클러스터로 CoCo를 배포하는 사용자 추상화
4. CoCo 조작을 포함한 기밀 컨테이너의 다양한 기능을 시연하기 위해 일련의 샘플 애플리케이션 배포

현재 패턴의 배포는 Microsoft Azure 단일 클러스터에서 이루어지며, 모든 구성 요소의 기반은 단일 검증된 패턴입니다 (추가 배포는 향후 예정).

작동 방식

검증된 패턴 오퍼레이터를 활용하여 Argo CD를 배포하고, Argo CD는 필요한 추가 오퍼레이터를 배포합니다. 

문제는 init-data와 kata-policy를 포함한 peer-pods 구성 맵을 Trustee Key Broker Service(KBS)를 가리키도록 구성해야 한다는 것입니다. 이 정보는 동적이며 사용자가 Azure CLI를 사용하거나 Azure Portal에 액세스해야 합니다. 보안 및 가시성 측면에서 init-data와 kata-policy가 구성 맵으로 푸시되기 전에 base64로 직렬화되므로 사용자가 상태를 확인하기 어렵게 되는 것도 문제가 됩니다.

이러한 문제는 검증된 패턴 오퍼레이터에서 주입한 메타데이터를 사용하여 해결되므로 애플리케이션에서 클러스터에 대한 정보에 손쉽게 액세스할 수 있습니다. 고급 클러스터 관리자 정책은 클라우드 컨트롤러 관리자에서 정의한 정보를 수집하고 샌드박스 처리된 컨테이너 오퍼레이터에 대한 적절한 구성 맵과 암호에 삽입하는 데 사용됩니다.

Hashicorp Vault는 검증된 패턴 암호 구성을 통해 클러스터 내에서 KMS로 사용되므로 사용자는 개발자 워크스테이션 환경에서 Vault를 일관되게 부트스트랩할 수 있습니다. 이를 사용하여 Trustee에 암호를 제공할 수 있으며, 이 암호는 외부 암호 오퍼레이터를 사용해 동기화됩니다.

이러한 기능들을 조합하면 단일 명령으로 설치할 수 있으며 다음과 같이 표시됩니다. 

요구 사항 

현재는 simple패턴 토폴로지가 단일 OpenShift 클러스터인 Azure 플랫폼으로 제한되어 있습니다.

사용자는 Azure Red Hat OpenShift 클러스터 또는 Azure 기반 자체 관리형 OpenShift 클러스터를 가져올 수 있습니다. 패턴에는 openshift-install을 사용하여 클러스터를 구축하는 방법에 관한 도큐멘테이션이 포함되어 있습니다. 클러스터 및 Azure 계정에는 지역 내 Azure CVM에 대한 액세스 권한과 가용성이 있어야 합니다. 현재 이 패턴은 기밀 컨테이너에 대해 DCasv5 클래스 가상 머신을 가정하지만 커스터마이징이 가능합니다.

Azure에 필요한 유일한 추가 구성은 작업자 노드 서브넷에 대한 NAT 게이트웨이를 배포하는 것입니다. 이 작업은 자동으로 수행됩니다.

개발자 워크스테이션의 경우 oc와 podman이 설치된 POSIX 워크스테이션(Mac OS 또는 Linux)이 필요합니다.

단계별 지침

세 단계만 수행하면 됩니다.

1. 포크 생성

먼저 조직 내에 검증된 패턴 GitHub 리포지토리의 포크를 생성합니다. Argo CD의 최종적 일관성으로 인해 검증된 패턴 리포지토리를 직접 사용하는 것은 안전하지 않습니다.

git clone https://github.com/(YOUR ORG}/coco-pattern.git

2. 임의의 키 생성

두 번째로, 기준 암호를 생성합니다. 패턴에는 임의의 키를 생성하는 스크립트가 포함됩니다.

sh scripts/gen-secrets.sh

3. 설치

oc login을 사용하여 클러스터에 로그인하고 install 패턴을 실행합니다.

./pattern.sh make install

이제 끝입니다. 이제 시스템이 온라인 상태가 될 때까지 기다린 다음 배포된 애플리케이션을 탐색하면 됩니다.

배포된 애플리케이션 탐색

패턴은 OpenShift 웹 콘솔의 9 상자 메뉴에 Simple ArgoCD라는 Argo CD 인스턴스를 배포합니다. 여러 애플리케이션이 배포되는 가운데 고려해야 할 두 가지 중요한 애플리케이션은 hello-openshift와 kbs-access입니다.

hello-openshift 애플리케이션은 웹 애플리케이션을 다음과 같이 세 차례에 걸쳐 배포합니다. 

• 표준 포드로 배포
• kata 포드로 배포. 사용자가 해당 포드에 실행할 수 있도록 에이전트 구성이 의도적으로 재정의
• CoCo 강화가 설정된 '보안' 애플리케이션으로 배포

kbs-access 애플리케이션은 init 컨테이너를 사용하여 Trustee에서 암호를 검색하는 방법을 간단하게 보여줍니다. KBS 액세스를 사용하면 웹 API를 통해 암호에 액세스할 수 있으므로 암호의 변경 사항이 시스템을 통해 전파되는 방식을 확인할 수 있습니다. 암호를 검색하는 이 init 컨테이너 메서드의 경우 기존 애플리케이션의 보안을 강화할 때 개발자가 코드를 개발하는 모든 위치에서 Trustee를 사용하지 않아도 되므로 편리한 방법입니다.

CoCo 패턴 배포 시 보안 고려 사항 

기밀 컨테이너의 핵심은 보안이므로 기밀 컨테이너 검증된 패턴의 보안 상태를 고려해야 합니다. 이 패턴에 대한 두 가지 주요 고려 사항은 다음과 같습니다.

• 현재 이 패턴은 간단한 참조 값을 사용합니다. RATS 증명 흐름에 대해 읽고 보안 요구 사항과 시스템의 리스크 프로필에 적합한 정책을 개발할 것을 권장합니다.
• Trustee 배포를 분리합니다. Trustee의 증명 서비스는 신뢰할 수 있는 다른 보안 영역에서 작동한다는 원칙에 따라 구축됩니다. 이는 첫 번째 고려 사항과도 관련이 있습니다. 환경이 다른 것이 가장 이상적입니다. 온프레미스나 다른 클라우드 공급업체를 사용하는 것이 그 예입니다.

아래 다이어그램은 기밀 컨테이너 검증된 패턴을 사용하여 별도의 환경에 Trustee를 배포하기 위한 아키텍처를 보여줍니다.

CoCo 패턴과 관련된 향후 작업 

처음 시작할 때는 CoCo 검증된 패턴만 있으면 됩니다. 이때 중요한 것은 단일 클러스터 및 환경으로도 충분하여 테스트를 시작할 수 있도록 하는 것입니다. 우선은 앞으로도 계속해서 기밀 컨테이너를 사용할 수 있도록 좀 더 실용적인 예시를 제공하여 검증된 패턴의 사용을 확장하는 데 집중하겠습니다.

Red Hat은 멀티 클러스터 허브 앤 스포크(hub-and-spoke) 배포를 지원하여 Red Hat Advanced Cluster Management를 통해 Trustee를 허브에 배포하고 스포크 클러스터를 기밀 워크로드가 실행되는 위치에 배포하고자 합니다.

또한 암호 관리를 위해 Trustee를 사용하는 실제 예를 제공하려고 합니다. 지금까지의 예시는 간단합니다. 향후 개발에 있어 Red Hat의 우선순위는 TEE 내에서 관리형 스토리지를 암호화하고, Trustee와 VPN 구성을 인식하지 못하는 애플리케이션에 대해 암호를 초기화하는 것입니다.

또한 온프레미스 또는 여러 클라우드 서비스 공급업체의 리소스 전반에 신뢰가 분산될 수 있도록 CoCo와 Trustee를 배포할 수 있는 다른 환경을 지원하고자 합니다.

요약 

기밀 컨테이너 검증된 패턴은 CoCo를 시작할 수 있는 간단한 메커니즘을 제공합니다. Argo CD를 통해 표준화된 app-of-apps GitOps 접근 방식을 활용하여 단일 리포지토리에서 독립적인 자체 애플리케이션을 배포하기 위해 실험과 포크를 시작할 수 있는 훌륭한 메커니즘입니다. 지금까지 살펴본 것처럼 git clone과 make install만큼이나 간단하게 시작할 수 있습니다.