Architecture

This section introduces the architecture of the Anjuna Nitro Runtime and how it will improve your experience running applications in AWS Nitro Enclaves.

Anjuna workflow overview

The following diagram shows how you will use the Anjuna Nitro Runtime to take any Docker image and run it in a AWS Nitro Enclave. The remaining sections explain the different steps in more detail.

Diagram showing various components of the Anjuna architecture

Network and filesystem access

You can take an existing container image and run it in an AWS Nitro Enclave today. However, it will not work as expected, because there is no access to a network or filesystem. This diagram shows what happens when you run an existing container image in an AWS Nitro Enclave:

Your container is in the enclave, but it has no connectivity because it cannot use the vsock

Using Anjuna, you can run that same container image, and the Anjuna Nitro Runtime will seamlessly handle communication between your enclave and the outside world. In the simplified diagram shown below, the Anjuna Network Proxy automatically translates your container’s TCP requests over the vsock.

Your container communicates with the Anjuna Network Proxy to reach the internet

Anjuna provides similar capabilities for filesystem access. By default, the AWS Nitro Enclave has access to an ephemeral in-memory filesystem, which is lost when the enclave terminates or restarts. Anjuna adds support for the enclave to write files to the parent instance’s filesystem, enabling the use of persistent storage like Amazon Elastic Block Store (EBS) or PersistentVolumes in Kubernetes.

Although you could design a low-level protocol for networking over the vsock and change your container network code or operate proxies yourself, the Anjuna Nitro Runtime does the undifferentiated heavy lifting, freeing up more time for you to deliver business value.

You will learn more about the network and filesystem proxies in the Running Nginx in AWS Nitro and Persistent Storage sections.

Attestation and AWS KMS integration

Secure enclaves have the ability to generate an attestation document, a piece of data which cryptographically proves that an enclave is running with particular code inside. An attestation document consists of two main components: an attestation key signature from the secure enclave platform, and the measurements of the enclave.

Diagram mapping each component of the attestation document to its use

Attestation document components

Attestation key signature

The attestation document contains a signature created by the secure enclave hardware platform’s attestation key. This cryptographic signing key is a private key in the enclave platform, in this case AWS Nitro. The secure enclave hardware enforces that this key is only accessible from legitimate secure enclaves.

A client can validate the signature on the attestation document using the corresponding public key, which is provided by the enclave platform operator, AWS. An attestation document with a valid signature must originate from a secure enclave, because only secure enclaves have access to an attestation key. If any part of the attestation document has been modified, the signature will fail to validate because it was only valid for the original content.

Measurements

Conceptually, a measurement is a cryptographic hash of the contents of an enclave. Because the entire enclave contents are an input to the hash function, if any part of the enclave changes - even a single bit in your code - the measurement will completely change. You can think of the measurements as a set of “fingerprints” for the identity of the enclave.

AWS Nitro Enclaves generate measurements for different parts of the enclave, like the full enclave, the IAM role for the instance, or a user-provided signing key. These measurements are stored in platform configuration registers (PCRs). See AWS documentation for descriptions of the different PCRs available for AWS Nitro Enclaves.

How does the Anjuna Nitro Runtime use attestation?

In AWS KMS, you can create a KMS key with a policy to only allow usage by specific enclaves based on their attestation document and measurements.

Using KMS key policies with attestation is an improvement over regular IAM policies authorized to use IAM roles only. An attacker cannot generate a valid attestation document, even if they have access to an instance with the correct IAM role, so they will not be able to access a KMS key.

The Anjuna Nitro Runtime makes it easy to generate an attestation document and authenticate to AWS KMS to access a KMS key. In Providing Secrets to the AWS Nitro Enclave, you will see how the Anjuna Nitro Runtime builds upon these capabilities to securely deliver secrets to your application at boot time.

The following diagram shows three different applications trying to access a key in AWS KMS. After your cloud admin configures the key to require attestation, AWS KMS will only grant access to your specific application running in an AWS Nitro Enclave.

Your cloud admin configures a KMS key to require an enclave with XYZ measurements. Only an enclave with XYZ measurements can access the key; other enclaves or applications outside enclaves cannot access it.

Kubernetes and Amazon EKS integration

Deploying AWS Nitro Enclaves to an Amazon Elastic Kubernetes Service (EKS) cluster requires additional configuration. In a Kubernetes environment, the Anjuna Nitro Runtime provides the same networking, filesystem, and attestation support needed to run your application without modification.

The Anjuna Nitro K8s Toolset also provides necessary system configuration for AWS Nitro Enclaves to run on EKS nodes. With Anjuna, you can configure your EKS cluster to deploy your Docker image in an AWS Nitro Enclave by adding a single label to your Pod definition.

In Getting Started with the Anjuna Nitro Kubernetes toolset, you will learn how to install and use the toolset.