search

intel / ACON

Apache License 2.0
57 stars 18 forks source link

readme

ACON - Attested Containers

ACON is an open source architecture and solution to create and manage small, purpose-built, Intel TDX-protected virtual machines (called Trust Domains, or TDs for short) for running container-like workloads. ACON aims at maximizing the security benefits of Intel TDX while retaining compatibility with existing applications/tools. It is designed and optimized for cloud native use cases (e.g., containers and FaaS (Function as a Service), etc.).

Goals

ACON is a container runtime.

From security perspective, ACON is designed to have

From functional perspective, ACON is designed to be

Architecture Overview

The diagram blow depicts ACON's architecture at a highlevel, with its key components (highlighted in yellow) and unique (comparing to OCI compliant runtimes) features (highlighted in blue).

Overview

In a nutshell, ACON runs containers in a small purpose-built TD (referred to as the ACON TD, or aTD). Below an introduction is provided to the numbered items in the diagram above.

  1. ACON Containers (referred to as Containers in italics hereon) are namespace-separated Linux processes similar to "containers" as defined in OCI Runtime spec.
  2. Containers are launched from ACON Images (referred to as just Images hereon), which are similar to OCI Images but with new elements designed specifically for cloud confidential compute usages.
    • Images are always digitally signed - This associates an Image with its vendor cryptographically, and is necessary to support Vendor FS Layers (described below).
    • 🧩Vendor FS layer refers to the mechanism that allows the vendor of an FS (File System) layer to update the layer on behalf of the Image owner. In the case of FaaS for example, this allows a CSP to update its FaaS framework on behalf of the function author. Details are available in the ACON Image spec.
    • 🔏Launch Policy (referred to as Policy for short hereon) is a part of an Image (hence is digitally signed) and governs aTD sharing - i.e., 2 Images can be loaded into the same aTD if and only if their Policies are mutually acceptable. In practice, this is usually used by Image authors for specifying dependencies among Images. Details are available in the ACON Image spec.
  3. aconcli is a command line utility. It is used to
    • Convert OCI images into Images and store them into a directory of a specific structure, called an ACON Image Repo (or just Repo for short).
    • Sign Images in a Repo.
    • Start aTDs.
    • Load Images from a Repo into an aTD and launch them as Containers (by sending commands to acond).
  4. acond accepts Images from aconcli via its gRPC interface (over VSOCK or TCP). Then, it measures each Image (using 📜RTMRs) and launches them as Containers. acond is launched as the init process (PID 1) at boot and is the only privileged process (in the aTD) in production.
    • 📜RTMR (RunTime Measurement Register) is a TDX specific feature - As of TDX v1.0, every TD is equipped with 4 RTMRs (namely, RTMR0..3) of 384 bits each. An RTMR cannot be set to any specific value but can be only extended by software (i.e., it works in the same way as a PCR does in a TPM).
  5. The Guest Kernel is an Intel TDX-enlightened Linux kernel specifically configured for minimal attack surface and TCB.
  6. Containers may communicate with the outside world through TCP or VSOCK. And in the latter case a proxy may be necessary to bridge VSOCK and other protocols to allow communication with remote hosts.

Getting Started

See README.md files of acond and aconcli for build instructions.

doc/TDGuest.md details how to build TD guest kernel and initrd images.

License

This project is released under Apache-2.0.