Kubernetes Pod specification

This section describes the changes you need to make to a Kubernetes Pod specification in order to instruct the Anjuna Nitro Kubernetes software to run the specified application in an AWS Nitro Enclave.

On this page, some code blocks are shortened to emphasize only the relevant configuration. A line with <snip>… indicates that some lines have been removed from the full configuration.

Enabling running a Pod in an AWS Nitro Enclave

To indicate that a Pod should be running in an AWS Nitro Enclave, set the label nitro.k8s.anjuna.io/managed to yes in the Pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    name: nginx-pod
    nitro.k8s.anjuna.io/managed: "yes"
<snip>...

Setting this label to yes instructs the Anjuna Nitro Webhook to intercept the creation of that Pod, and automatically convert it into an AWS Nitro Enclave.

Other Kubernetes workload objects like Deployments

Kubernetes workload objects like Deployments are translated into Pods using the pod template field. So, add nitro.k8s.anjuna.io/managed: "yes" to the template of the Deployment. For example, if you have a Deployment with the following specification, line 16 defines the Anjuna label, and this label will be passed onto the created Pods:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
        nitro.k8s.anjuna.io/managed: "yes"
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Controlling the resources allocated to the AWS Nitro Enclave

Use the standard Kubernetes Pod specification attributes to control the vCPUs and memory reserved for the enclave:

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory

spec.containers[].resources.limits.cpu MUST be an integer when used in the context of an AWS Nitro Enclave (a regular Kubernetes Pod supports fractional vCPU values). The number of vCPU cores must be an even number due to hyperthreading.

This is an example Pod configuration that reserves 2GB of memory and 2 vCPUs for an AWS Nitro Enclave (see lines 14-16):

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    name: nginx-pod
    nitro.k8s.anjuna.io/managed: "yes"
spec:
  containers:
  - name: nginx-pod
    image: nginx:latest
    imagePullPolicy: Always
    resources:
      limits:
        memory: "2048Mi"
        cpu: "2"
    ports:
      - containerPort: 80
<snip>...

Passing parameters to the Anjuna Nitro Runtime

When a Pod is launched in an AWS Nitro Enclave, the Anjuna Nitro Runtime is used to build, configure and run the AWS Nitro Enclave.

The following environment variable is used to control how the Anjuna Nitro Runtime behaves:

ANJ_ENCLAVE_DEBUG_MODE: Set this variable to “yes” to create a debug enclave. If not defined or set, the Anjuna Nitro Kubernetes will start the AWS Nitro Enclave in production mode.

Downloading an EIF instead of building it on the fly

The Anjuna Nitro Kubernetes tools can create the Enclave Image File automatically from the Pod specification. However, you also have the option to pre-create an EIF and instruct the Anjuna Nitro Kubernetes to download the EIF from an S3 bucket by using the nitro.k8s.anjuna.io/imageLocation annotation:

apiVersion: v1
kind: Pod
metadata:
  name: secure-eif-pod
  labels:
    name: secure-eif-pod
    nitro.k8s.anjuna.io/managed: "yes"
  annotations:
    nitro.k8s.anjuna.io/imageLocation: "s3://your-eif-bucket/your-eif-file"
    <snip>...

When using this option, the container image in the Pod specification is ignored, although the Kubernetes Pod specification requires a value. You can simply leave the container image used in the original Pod specification.

Controlling the resources assigned to the Anjuna Nitro Pod

You have the ability to control the resources assigned to the Anjuna Nitro Pod by specifying the following annotations:

nitro.k8s.anjuna.io/launcherCPU: The limit for the number of vCPUs for the Pod.
nitro.k8s.anjuna.io/launcherMemory: The limit for the amount of memory for the Pod.

The values for these annotations are in the same format than the limits properties (memory/cpu) for a Pod specification:

<snip>
annotations:
  <snip>...
  nitro.k8s.anjuna.io/launcherMemory: "4Gi"
  nitro.k8s.anjuna.io/launcherCPU: "750m"
  <snip>...

If you don’t specify these annotations, no resource limits are set on the launcher Pod. This is particularly useful when creating Enclave Image Files (EIF) automatically, which is a memory-intensive process. Once the EIF has been created, the resource requirements for the launcher Pod are minimal.

Licensing the Anjuna Nitro Runtime for an Anjuna Nitro Pod

A license is required to run an Anjuna Nitro Pod. See the Licensing page for instructions on how to download the license from the Anjuna Resource Center.

This license file must be mounted to each Pod as a Kubernetes secret.

The Kubernetes secret must be named anjuna-license. The key license.yaml must contain the contents of the license file downloaded earlier. Run the following command to create the secret:

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

The Anjuna Nitro Webhook will automatically mount the license file to your Pod at /opt/anjuna/license.yaml.

Example

The following Pod specification creates an AWS Nitro Enclave for the Nginx web server.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    name: nginx-pod
    nitro.k8s.anjuna.io/managed: "yes"
spec:
  containers:
    - name: nginx-pod
      image: nginx:latest
      imagePullPolicy: Always
      env:
        - name: ANJ_ENCLAVE_DEBUG_MODE
          value: "yes"
      resources:
        limits:
          memory: "2048Mi"
          cpu: "2"
      ports:
        - containerPort: 80