github/confidential-containers
1
0
Fork 0
mirror of https://github.com/confidential-containers/confidential-containers.git synced 2025-04-28 03:21:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix language in docs

Browse Source 
- Fix random capitalization of words.
- Fix whitespace issues.
- Improve phrasing to increase clarity.
- Fix punctuation.
- Fix typos.

Signed-off-by: Johanan Liebermann <jliebermann@microsoft.com>
This commit is contained in:
Johanan Liebermann 2022-05-30 16:09:46 +03:00 committed by Dan
parent 0d6ee2805b
commit bc0c64a849
3 changed files with 63 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
Overview.md
View File

@ -9,8 +9,8 @@ Key considerations are:
- Transparent deployment of unmodified containers
- Support multiple TEE and hardware platforms
- 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 Computing for guest application or data inside the TEE.
- Apply least privilege principles to the Kubernetes cluster administration capabilities which
impact delivering Confidential Computing for guest applications 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. Container isolation was initially
@ -24,27 +24,27 @@ the node level.
## 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. 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 and with it the trust boundaries change. Consideration of Insider Threats
needs to now consider the cloud provider, infrastructure provider, managed service provider.
common a Hybrid approach and with it the trust boundaries change. Consideration of insider threats
needs to now consider the cloud provider, infrastructure provider, and managed service provider.
Certain Industries are heavily focused on compliance to standards, governments too are concerned
Certain industries are heavily focused on compliance to standards. Governments, too, are concerned
both [collectively](https://www.un.org/counterterrorism/cybersecurity) and
[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 Computing.
Confidential Containers look to address the growing conern and needs of these three areas combining
and growing in the future.
Confidential Containers seek to address the growing concerns and needs of these three areas
combining and growing in the future.
## How?
### Trusted Execution Environments
### Trusted Execution Environments
We are actively working to support multiple TEE Technologies
- AMD Secure Encrypted Virtualization(SEV, SEV-ES)
We are actively working to support multiple TEE Technologies:
- AMD Secure Encrypted Virtualization (SEV, SEV-ES)
- Intel Software Guard Extensions (SGX)
- Intel Trusted Domain Extensions (TDX)
- IBM
@ -54,44 +54,43 @@ We are actively working to support multiple TEE Technologies
![TEE Protects an application](./images/ApplicationTEEProtection.png)
The TEE seeks to protect the Application and Data from outside threats, with the Application owner
The TEE seeks to protect the application and data from outside threats, with the application owner
having complete control of all communication across the TEE boundary. The application is considered
a single complete entity and once supplied with the resources it requires, the TEE protects those
resources (memory and cpu) from the infrastructure and all communication across 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)
However moving to a more cloud native approach, the application is now considered a group of one or
However, moving to a more cloud native approach, the application is now considered a group of one or
more containers, with shared storage and network resources (pod). This pod is also subject to an
orchestration layer which needs to dynamically interact with the pods and containers with respect to
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, take advantage of the TEE capabilities and deliver on their compliance/ security
How does the application owner trust the orchestration actions required to deliver on the cloud
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 orchestration (kubernetes admin) and still be able to build and deploy cloud
Our goal is to establish patterns using TEE's to lock out the Cloud Service Provider (CSP),
establish deprivileged orchestration (Kubernetes admin) and still be able to build and deploy cloud
native workloads.
### Integration of Technologies
With many TEE technologies requiring a KVM boundary between the host
and guest, [Kata Containers](https://katacontainers.io/) are the basis for our initial work. The
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
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
a consideration of
[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.
How to protect the guest from the host (in this case to protect the containers and workloads 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 Containers Project alone, it raises considerations that need to be discussed and resolved in
other areas of a cloud native stack, from container runtime to CSI to orchestration(kubelet) and
Kata Containers project alone. It raises considerations that need to be discussed and resolved in
other areas of the cloud native stack, from container runtime to CSI to orchestration (kubelet) and
brings in new projects or concerns such as attestation, reconsidering trust domains and least
privilege capabilities for kubernetes admin.
privilege capabilities for Kubernetes admins.

4
README.md
View File

@ -12,8 +12,8 @@ Our key considerations are:
- Transparent deployment of unmodified containers
- Support for multiple TEE and hardware platforms
- A trust model which separates Cloud Service Providers (CSPs) from guest applications
- Least privilege principles for the Kubernetes Cluster administration capabilities which impact
delivering Confidential Computing for guest application or data inside the TEE.
- Least privilege principles for the Kubernetes cluster administration capabilities which impact
delivering Confidential Computing for guest applications or data inside the TEE
## Further Detail

66
Roadmap.md
View File

@ -1,16 +1,15 @@
# Confidential containers roadmap
When looking at the project's roadmap we distinguish between short term roadmap (2-4 month) vs
the mid/long term roadmap (4-12 month):
- The **short term roadmap** is focused on achieving an end-to-end easy to deploy confidential
containers solution using at
least one HW encryption solution and integrated to k8s (with forked versions if needed)
- The **mid/long term solutions** focuses on maturing the components of the short term solution
and adding a number of
enhancements both to the solution and the project (such as CI, interoperability with other
projects etc...)
# Confidential Containers Roadmap
When looking at the project's roadmap we distinguish between the short-term roadmap (2-4 months) vs.
the mid/long-term roadmap (4-12 months):
- The **short-term roadmap** is focused on achieving an end-to-end, easy to deploy confidential
containers solution using at least one HW encryption solution and integrated to k8s (with forked
versions if needed)
- The **mid/long-term solutions** focuses on maturing the components of the short-term solution
and adding a number of enhancements both to the solution and the project (such as CI,
interoperability with other projects etc.)
# Short term roadmap
The short term roadmap aims to achieve the following:
# Short-Term Roadmap
The short-term roadmap aims to achieve the following:
- MVP stack for running confidential containers
- Based on and compatible with Kata Containers 2
- Based on at least one confidential computing implementation (SEV, TDX, SE, etc)
@ -35,55 +34,54 @@ The work is targeted to be completed by end of November 2021 and includes 3 mile
- Image is decrypted with a key obtained from a key brokering service (KBS)
- Integration with kubelet
For additional details on each milestone see [Confidential Containers v0](https://docs.google.com/presentation/d/1SIqLogbauLf6lG53cIBPMOFadRT23aXuTGC8q-Ernfw/edit#slide=id.p)
For additional details on each milestone see [Confidential Containers v0](https://docs.google.com/presentation/d/1SIqLogbauLf6lG53cIBPMOFadRT23aXuTGC8q-Ernfw/edit#slide=id.p).
Tasks are tracked on a weekly basis through a dedicated spreadsheet.
For more information see [Confidential Containers V0 Plan](https://docs.google.com/spreadsheets/d/1M_MijAutym4hMg8KtIye1jIDAUMUWsFCri9nq4dqGvA/edit#gid=0&fvid=1397558749).
# Mid term roadmap
# Mid-Term Roadmap
Continue our journey using knowledge and support of Subject Matter Experts (SME's) in other
projects to form stronger
opinions on what is needed from components which can be integrated to deliver the confidential
containers objectives.
projects to form stronger opinions on what is needed from components which can be integrated to
deliver the confidential containers objectives.
- Harden the code used for the demos,
- Improve CI/CD pipeline,
- Harden the code used for the demos
- Improve CI/CD pipeline
- Clarify the release process
- Establish processes and tools to support planning, prioritisation, and work in progress
- Simple process to get up and running regardless of underlying Trusted Execution
Environment technology.
- Simple process to get up and running regardless of underlying Trusted Execution Environment
technology
- Develop a small, simple, secure, lightweight and high performance OCI container image
management library [image-rs](https://github.com/confidential-containers/image-rs) for
confidential containers.
- Develop small, simple shim firmware ( [td-shim](https://github.com/confidential-containers/td-shim) )
- Develop small, simple shim firmware ([td-shim](https://github.com/confidential-containers/td-shim))
in support of trusted execution environment for use with cloud native confidential containers.
- Document threat model and trust model, what are we protecting, how are we achieving it.
- Identify technical convergence points with other confidential computing projects both inside
and outside CNCF.
# Longer term roadmap
# Longer-Term Roadmap
Focused meetings will be setup to discuss architecture and the priority of longer term objectives
in the process of being setup.
Focused meetings will be set up to discuss architecture and the priority of longer-term objectives
in the process of being set up.
Each meeting will have an agreed focus with people sharing material/thoughts ahead of time.
Topics under consideration:
- CI/CD + Repositories
- Community Structure and expectations
- 2 on Mid Term Architecture
- Attestation
- CI/CD + repositories
- Community structure and expectations
- 2 on Mid-Term Architecture
- Attestation
- Images
- Runtimes
- Runtimes
Proposed Topics to influence long term direction/architecture.
Proposed Topics to influence long-term direction/architecture:
- Baremetal / Peer Pod
- Composability of alternative technologies to deliver confidential containers.
- Performance
- Composability of alternative technologies to deliver confidential containers
- Performance
- Identity / Service Mesh
- Reproducible Builds/Demos
- Reproducible builds/demos
- Edge Computing
- Reduce footprint of image pull