Red Hat OpenShift sandboxed containers, built on Kata Containers, provide the additional capability to run confidential containers (CoCo). This article continues our previous one, Exploring the OpenShift confidential containers solution and looks at different CoCo use cases and the ecosystem around the confidential compute attestation operator.
Use cases for OpenShift confidential containers
Let’s go over a few CoCo use cases.
Secrets retrieval by the workload (pod)
A workload (pod) may require secrets to perform different operations. For example, assume your workload runs a fine-tuned large language model (LLM), your secret sauce. The LLM is encrypted, and the workload needs the decryption key to start using it. Before the workload gets the key, you want to ensure that the workload runs in a VM Trusted Execution Environments (TEE) to protect the plaintext LLM from unauthorized access by any admin. Similarly, if the workload needs private data, then the same can be encrypted and provided to the workload. The workload will decrypt the data inside the TEE using the decryption key received after attestation.
The following diagram shows how a workload (pod) obtains its secret after successful attestation:
The workload initiates an attestation sequence via the Trustee agents running in the VM TEE (CVM) to confirm the trustworthiness of the TEE and obtain the secret from the Key Broker Service (KBS). You can read more about the attestation process in our previous blog Understanding the Confidential Containers Attestation Flow.
Verifying signed container images
Verifying a container image's signature before launching is necessary to make sure the image has not been tampered with and contains the intended binaries. For example, it should not contain backdoors for accessing the secrets when running. After successful attestation, the VM TEE (CVM) retrieves the signing key from the KBS and uses it to verify the trustworthiness of the container image before running it inside the TEE.
The following diagram shows how the container image signing key is retrieved from KBS after successful attestation:
The Linux guest components initiate an attestation sequence via the Trustee agents in VM TEE (CVM) to confirm the trustworthiness of the TEE and obtain the container image signing key from the KBS before launching the container. Note that the image signature verification is inside the VM TEE and not on the worker node. This is a fundamental difference when doing signature verification at the worker node level as described in this documentation.
Running an encrypted container image
Suppose you have your secret data (e.g. your fine-tuned AI model) in the container image. You would want to use an encrypted container image to prevent unauthorized access to the image contents. In contrast to the previous signed image use case, the concerns shifted from someone tampering with our container image to someone viewing the content of the container's image. After successful attestation, the VM TEE (CVM) retrieves the decryption key from the KBS and uses it to decrypt the container image before running it inside the TEE.
The following diagram shows how the container image decryption key is retrieved from KBS after successful attestation:
The Linux guest components initiate an attestation sequence via the Trustee agents running in the VM TEE(CVM) to confirm the trustworthiness of the TEE and obtain the container image decryption key from the KBS before launching the container.
Ecosystem for attestation and key management solutions
A key benefit the Trustee solution brings is that it works with other attestation and key management solutions while exposing the same APIs towards the Trustee agents components inside the CVM.
Working with other key managers
The confidential compute attestation operator simplifies configuring keys and serving them to TEEs. You can set up the required TEE secrets as OpenShift Secret objects and have the operator make them accessible through Trustee. You can use the same mechanism to integrate with external secret managers. For instance, you can utilize the Secrets store CSI driver or the External Secrets Operator to sync secrets from external sources (such as HashiCorp Vault) and make them available to the remote TEEs.
The following diagram shows the connection between Trustee and third-party secret store solutions:
Working with other attestation solutions
The confidential compute attestation operator can also use external attestation services (AS) supported by Trustee. For example Trustee supports Intel Trust Authority (ITA) and the same can be configured via the operator.
The value that confidential compute attestation operator brings for such deployments is the abstraction of third-party attestation services from OpenShift confidential containers. The same interfaces are used between the Trustee agent and KBS regardless of the backend attestation service being used.
OpenShift confidential containers in action
This demo shows how a confidential container created with the Openshift Sandboxed containers operator can retrieve secrets from the Trustee operator by performing remote attestation.
Wrap up
We have described the ecosystem surrounding attestation and key management solutions provided by the confidential compute attestation operator. We have also described a few use cases for OpenShift confidential containers and will introduce additional use cases in the future. Future articles will offer detailed, hands-on instructions for using OpenShift confidential containers, as well as guidelines for deployment models.
저자 소개
Pradipta is working in the area of confidential containers to enhance the privacy and security of container workloads running in the public cloud. He is one of the project maintainers of the CNCF confidential containers project.
Jens Freimann is a Software Engineering Manager at Red Hat with a focus on OpenShift sandboxed containers and Confidential Containers. He has been with Red Hat for more than six years, during which he has made contributions to low-level virtualization features in QEMU, KVM and virtio(-net). Freimann is passionate about Confidential Computing and has a keen interest in helping organizations implement the technology. Freimann has over 15 years of experience in the tech industry and has held various technical roles throughout his career.
Emanuele Giuseppe Esposito is a Software Engineer at Red Hat, with focus on Confidential Computing, QEMU and KVM. He joined Red Hat in 2021, right after getting a Master Degree in CS at ETH Zürich. Emanuele is passionate about the whole virtualization stack, ranging from Openshift Sandboxed Containers to low-level features in QEMU and KVM.
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.