diff --git a/Overview.md b/Overview.md index 6f43059..2ad5b18 100644 --- a/Overview.md +++ b/Overview.md @@ -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. diff --git a/README.md b/README.md index 0552a03..97ad0c6 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/Roadmap.md b/Roadmap.md index ff1f2ab..a5512af 100644 --- a/Roadmap.md +++ b/Roadmap.md @@ -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