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.

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 (enclave image file) using the Anjuna Nitro Runtime,

  • configuring the networking settings using the Anjuna Nitro Runtime,

  • stating 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 to verify that nginx is responding to requests.

$ kubectl exec -it nitro-nginx-pod -- /bin/bash

This command starts a bash interpreter on the nitro-nginx-pod. You should see a prompt like this:

bash-4.2#

Enter the following command to make a request to nginx:

# curl http://localhost:80

which should display a welcome page from nginx.

You can exit the bash session on the Pod:

# exit

How does this work?

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 the total memory and CPU cores that were reserved for AWS Nitro.

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