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. This frees 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 report, a piece of data which cryptographically proves that an enclave is running with particular code inside. AWS KMS integrates with AWS Nitro Enclaves using the attestation report to provide finer-grained controls over AWS KMS keys.

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 report, 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 report 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.

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.