Deploying a Pod as an AWS Nitro Enclave

The previous sections were all about setting up an AWS EKS cluster with the Anjuna Nitro Kubernetes tools installed in the cluster. You are now able to start a container in an AWS Nitro Enclave without changing the container, and verify that it is in fact running in an enclave. In this section you will load a simple nginx container in an enclave.

Refer to Kubernetes Pod specification in the Configuration reference section for more details including using pre-built Enclave Image Files (EIFs).

First, download the license from the Anjuna Resource Center. This license file will be mounted to your nginx Pod as a Kubernetes secret.

Run the following command to create a Kubernetes secret:

$ kubectl create secret generic anjuna-license --from-file=license.yaml=license.yaml

The Anjuna Nitro Webhook will automatically mount the license secret to the new Pod’s filesystem.

Run the following command to install the Helm chart:

$ helm install nitro-nginx helm-charts/nitro-nginx

Wait for the Pod to start by running the command until the Pod is running:

$ kubectl get pods

When the Pod is running, run the following command to see what the Pod did:

$ kubectl logs nitro-nginx-pod

Inspecting the logs, you will see that the Pod nitro-nginx-pod is:

  • downloading the nginx container,

  • converting it into an EIF using the Anjuna Nitro Runtime,

  • configuring the networking settings using the Anjuna Nitro Runtime,

  • starting the enclave in debug mode,

  • showing the AWS Nitro console output, which indicates that nginx should have started.

To confirm that nginx is in fact running, you can connect to the Pod, and issue a curl command to verify that nginx is responding to requests.

$ kubectl exec -it nitro-nginx-pod -- curl http://localhost:80

This command should display a welcome page from nginx.

How this works

To understand how the Anjuna Nitro Kubernetes tools are told to create an enclave, you have to inspect the Pod specification used for nginx. Open the file helm-charts/nitro-nginx/templates/nitro-nginx.yaml.

 1  ---
 2  apiVersion: v1
 3  kind: Service
 4  metadata:
 5    name: nitro-nginx
 6  spec:
 7    selector:
 8      name: nitro-nginx-pod
 9    ports:
10     - protocol: TCP
11       port: 80
12       targetPort: 80
13  ---
14  apiVersion: v1
15  kind: Pod
16  metadata:
17    name: nitro-nginx-pod
18    labels:
19      name: nitro-nginx-pod
20      nitro.k8s.anjuna.io/managed: "yes"
21  spec:
22    containers:
23    - name: nitro-nginx-pod
24      image: nginx:latest
25      imagePullPolicy: Always
26      resources:
27        limits:
28          memory: "2048Mi"
29          cpu: "2"
30      ports:
31        - containerPort: 80

  • Lines 14-19: Declare that a Pod nitro-nginx-pod will be created.

  • Line 20: Declares that this Pod should be running in an AWS Nitro Enclave by using the nitro.k8s.anjuna.io/managed label.

  • Line 24: The Pod should launch the container nginx:latest in the AWS Nitro Enclave.

  • Lines 26-29: Declare the resources that should be allocated to the enclave (number of vCPUs (must be even due to hyperthreading), RAM). If these resource limits are not defined, the webhook will default to using 2 GB of memory and 2 vCPUs.

All Pod configured volumes are automatically mounted into the enclave using a bind mount.

K8s probes with the Anjuna Nitro Runtime

The Anjuna Nitro Runtime supports liveness, readiness, and startup probes for network-based applications that export the appropriate ports.

Command-based liveness, readiness, and startup probes might not work since the cluster executes the commands on the launcher Pod, and not inside the AWS Nitro Enclave.

AWS Nitro Enclave Pods first build the EIF (when not using a pre-built EIF) and then run the AWS Nitro Enclave (no matter the EIF build strategy), and therefore require a significantly longer startup period before the application starts running.

Anjuna suggests setting your probes’ initialDelaySeconds to 180 to allow the AWS Nitro Enclave to start before probing the application.

The larger the enclave, the longer the initialDelaySeconds value should be. Large enclaves may require more than 180 seconds to start.

Example of a Pod spec file with a Liveness Probe:

 1  apiVersion: v1
 2  kind: Pod
 3  metadata:
 4    name: nitro-nginx-pod
 5    labels:
 6      name: nitro-nginx-pod
 7      nitro.k8s.anjuna.io/managed: "yes"
 8  spec:
 9    containers:
10    - name: nitro-nginx-pod
11      image: nginx:latest
12      imagePullPolicy: Always
13      resources:
14        limits:
15          memory: "2048Mi"
16          cpu: "2"
17      ports:
18        - containerPort: 80
19      livenessProbe:
20        httpGet:
21          path: /index.html
22          port: 80
23        initialDelaySeconds: 180
24        periodSeconds: 3

Deploying multiple enclaves per node

Anjuna Nitro K8s Toolset supports up to four Pods in separate enclaves (the current AWS Nitro limitation) on a single Node. When there are multiple Nodes in a cluster, it may be desirable to define how enclave Pods are scheduled. For example, you can use nodeSelector to choose a particular set of Nodes for a given Pod, or set podAntiAffinity to ensure that Pods for the same Deployment are placed on different Nodes.

For more information on managing Node labels and assigning Pods to Nodes in multi-node scenarios, please consult the Assigning Pods to Nodes Kubernetes documentation.