github/confidential-containers
1
0
Fork 0
mirror of https://github.com/confidential-containers/confidential-containers.git synced 2025-08-17 15:26:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add container isolation (#5)

Browse Source 
* Format markdown

Set column width to 100 characters to facilitate future PR reviews.

Signed-off-by: Dan Middleton <dan.middleton@intel.com>

* Add container isolation to Overview

Reflect community discussions from October 2021 recognizing prior work
with container isolation and future work to comprehensively address
the scope implied by Confidential Containers.

Signed-off-by: Dan Middleton <dan.middleton@intel.com>
This commit is contained in:
Dan 2021-11-10 08:30:03 -06:00 committed by GitHub
parent 84f25fe318
commit 21612c7656
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 59 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

99
Overview.md
View File

@ -1,42 +1,51 @@
# Confidential Containers # Confidential Containers
We are interested in integrating existing [Trusted Execution Environments](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE)
infrastructure support and technologies with the cloud native world. We are interested in integrating existing [Trusted Execution Environments](https://en.wikipedia.org/wiki/Trusted_execution_environment)
(TEE) infrastructure support and technologies with the cloud native world.
Key considerations are: Key considerations are:
- Allow cloud native application owners to enforce application security requirements
- Transparent deployment of unmodified containers - Transparent deployment of unmodified containers
- Support multiple TEE and hardware platforms - Support multiple TEE and hardware platforms
- Introduce a trust model which separates Cloud Service Providers (CSPs) from guest applications - Introduce a trust model which separates Cloud Service Providers (CSPs) from guest applications
- Apply least privilege principles to the Kubernetes Cluster administration capabilities which impact delivering Confidential - Apply least privilege principles to the Kubernetes Cluster administration capabilities which
Computing for guest application or data inside the TEE. impact delivering Confidential Computing for guest application or data inside the TEE.
TEE's can be used to encapsulate different levels of the architecture stack with three key levels being node v pod v container.
We have initially focused on the pod level support for confidential computing, node level introduces significant challenges around
least privilege for kubernetes cluster administration and container level introduces challenges around transparent deployment of unmodified containers.
This initial pod level focus does not preclude use of container focused confidential computing
technologies and that challenges explored will have relevance to the use of TEE's at both node and container level.
TEE's can be used to encapsulate different levels of the architecture stack with three key levels
being node v pod v container. Container isolation was initially
[provided in kata-containers](https://github.com/kata-containers/kata-containers/blob/main/docs/use-cases/using-Intel-SGX-and-kata.md).
As an outgrowth of that project we are now expanding to address pod level support for confidential
computing. Node level introduces significant challenges around least privilege for kubernetes
cluster administration. We will explore the combination of pod and container level isolation, and we
expect that challenges explored will have relevance to future understanding of the use of TEE's at
the node level.
## Why? ## Why?
Security has long been a significant concern with data encryption at rest and in flight assumed to be a key part of any offering. Security has long been a significant concern with data encryption at rest and in flight
Trusted Execution Environments look to address the data in use security concern. assumed to be a key part of any offering. Trusted Execution Environments look to address the data
in use security concern.
Cloud Computing adoption continues to accelerate whether it be Public, Private or increasingly common a Hybrid approach Cloud Computing adoption continues to accelerate whether it be Public, Private or increasingly
and with it the trust boundaries change. Consideration of Insider Threats needs to now consider the cloud provider, common a Hybrid approach and with it the trust boundaries change. Consideration of Insider Threats
infrastructure provider, managed service provider. needs to now consider the cloud provider, infrastructure provider, managed service provider.
Certain Industries are heavily focused on compliance to standards, governments too are concerned both [collectively](https://www.un.org/counterterrorism/cybersecurity) Certain Industries are heavily focused on compliance to standards, governments too are concerned
and [individually](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/). both [collectively](https://www.un.org/counterterrorism/cybersecurity) and
The standards expected to protect software solutions continue to evolve towards a concept of Confidential Computing [individually](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/).
The standards expected to protect software solutions continue to evolve towards a concept of
Confidential Computing
Confidential Containers look to address the growing conern and needs of these three areas combining and growing in the future. Confidential Containers look to address the growing conern and needs of these three areas combining
and growing in the future.
## How? ## How?
### Trusted Execution Environments ### Trusted Execution Environments
We are actively working to support multiple TEE Technologies We are actively working to support multiple TEE Technologies
- AMD Secure Encrypted Virtualization(SEV, SEV-ES) - AMD Secure Encrypted Virtualization(SEV, SEV-ES)
- Intel Software Guard Extensions (SGX)
- Intel Trusted Domain Extensions (TDX) - Intel Trusted Domain Extensions (TDX)
- IBM - IBM
- Protected Execution Facility (PEF) - Protected Execution Facility (PEF)
@ -45,36 +54,44 @@ We are actively working to support multiple TEE Technologies
![TEE Protects an application](./images/ApplicationTEEProtection.png) ![TEE Protects an application](./images/ApplicationTEEProtection.png)
The TEE seeks to protect the Application and Data from outside threats, with the Application owner having complete control The TEE seeks to protect the Application and Data from outside threats, with the Application owner
of all communication across the TEE boundary. The application is considered a single complete entity and once supplied with the having complete control of all communication across the TEE boundary. The application is considered
resources it requires, the TEE protects those resource (memory cpu) from the infrastructure and all communication across a single complete entity and once supplied with the resources it requires, the TEE protects those
the TEE boundary is under the control of the Application Owner. resources (memory and cpu) from the infrastructure and all communication across the TEE boundary is
under the control of the Application Owner.
### Cloud Native Execution Environments ### Cloud Native Execution Environments
![TEE protects an orchestrated pod](./images/CloudNativeTEEProtection.png) ![TEE protects an orchestrated pod](./images/CloudNativeTEEProtection.png)
However moving to a more cloud native approach, the application is now considered a group of one or more containers, However moving to a more cloud native approach, the application is now considered a group of one or
with shared storage and network resources (pod). This pod is also subject to an orchestration layer which needs to dynamically more containers, with shared storage and network resources (pod). This pod is also subject to an
interact with the pods and containers with respect to provisioning, deployment, networking, scaling, availability, and orchestration layer which needs to dynamically interact with the pods and containers with respect to
lifecycle management. provisioning, deployment, networking, scaling, availability, and lifecycle management.
How does the application owner trust the orchestration actions required to deliver on the Cloud Native promise, How does the application owner trust the orchestration actions required to deliver on the Cloud
take advantage of the TEE capabilities and deliver on their compliance/ security requirements? Native promise, take advantage of the TEE capabilities and deliver on their compliance/ security
requirements?
Our goal is to establish patterns using TEE's to lock out the Cloud Service Provider (CSP) , establish deprivileged Our goal is to establish patterns using TEE's to lock out the Cloud Service Provider (CSP) ,
orchestration (kubernetes admin) and still be able to build and deploy cloud native workloads. establish deprivileged orchestration (kubernetes admin) and still be able to build and deploy cloud
native workloads.
### Integration of Technologies ### Integration of Technologies
With many TEE technologies requiring a KVM boundary between the host and guest, [Kata Containers](https://katacontainers.io/) With many TEE technologies requiring a KVM boundary between the host
are the basis for our initial work. The Kata Containers project already supports a KVM boundary between a Kubernetes Node and Kubernetes Pod and guest, [Kata Containers](https://katacontainers.io/) are the basis for our initial work. The
and focuses on reducing the concern of a Guest attacking the Host, in this case a breakout from containers within the pod attacking the Kubernetes Node. Kata Containers project already supports a KVM boundary between a Kubernetes Node and Kubernetes Pod
and focuses on reducing the concern of a Guest attacking the Host, in this case a breakout from
containers within the pod attacking the Kubernetes Node.
Requests from TEE vendors to support their technology within Kata Containers project led to consideration of Requests from TEE vendors to support their technology within Kata Containers project led to
[Confidential Computing Enablement](https://github.com/kata-containers/kata-containers/issues/1332). How to protect consideration of
the guest from the host, in this case to protect the Containers and workload within a Pod from the Kubernetes Node. [Confidential Computing Enablement](https://github.com/kata-containers/kata-containers/issues/1332).
How to protect the guest from the host, in this case to protect the Containers and workload within a
Pod from the Kubernetes Node.
Initial exploration led to the realisation that this was not a problem possible to solve within the Kata Initial exploration led to the realisation that this was not a problem possible to solve within the
Containers Project alone, it raises considerations that need to be discussed and resolved in other areas of a cloud native stack, from Kata Containers Project alone, it raises considerations that need to be discussed and resolved in
container runtime to CSI to orchestration(kubelet) and brings in new projects or concerns such as attestation, reconsidering trust other areas of a cloud native stack, from container runtime to CSI to orchestration(kubelet) and
domains and least privilege capabilities for kubernetes admin. brings in new projects or concerns such as attestation, reconsidering trust domains and least
privilege capabilities for kubernetes admin.