Configuration reference

The Anjuna Enclave Configuration file allows you to control and templatize parts of the container environment, such as the application command and environment variables, without needing to modify the container image. It is written in YAML.

When building Anjuna Confidential Pod disk images, you can set the Anjuna Enclave Configuration using the command anjuna-k8s-cli build with a --config <config_file> parameter. For example, if your enclave configuration file is called config.yaml, use the following command:

$ anjuna-k8s-cli build azure  \
    --docker-uri=docker.io/library/nginx:latest  \
    --config=config.yaml

Refer to the Anjuna SEV Configuration reference for a walkthrough of the Anjuna Enclave Configuration file syntax.

The features described in the document above are available to any Anjuna Confidential Container or Anjuna Confidential Pod. There is also a set of features that is exclusive to Anjuna Confidential Pods running in Kubernetes.

The sections below describe these features.

Untrusted configuration

The Anjuna Enclave Configuration provides the user a trusted and measured configuration that is attached to the disk at build time. However, there are cases where applications require data that cannot be known in advance, for example:

The IP address of a logging server
Values fetched from the Kubernetes Downward API
Values provided to the Anjuna Confidential Pod via Secrets or ConfigMaps.

The Anjuna Kubernetes Toolset provides a way to set this type of untrusted configuration via environment variables or volume mounts that can be allowed in the untrustedConfig section of the enclave configuration file.

Make sure to understand the consequences of allowing untrusted environment variables or volume mounts to be set from the Pod specification. Keep in mind that these environment variables or volume mounts can be manipulated by potential attackers to alter the behavior of your Anjuna Confidential Pod in undesirable ways.

Environment variables

By default, all the environment variables in a Pod specification are ignored since the cluster itself is considered to be untrusted. For instance, a malicious cluster administrator could set arbitrary environment variables by editing your Pod specification on the fly, thus affecting the behavior of the Pod.

Only environment variables that are previously measured as part of the container image or as part of the enclave configuration file are considered trusted and are effectively applied to the Anjuna Confidential Pod in Kubernetes. Environment variables that are injected from Anjuna Policy Manager secrets are also considered trusted, as they are only injected to trustworthy Anjuna Confidential Pods.

To allow an untrusted environment variable to be applied from the Anjuna Confidential Pod specification, you must explicitly allow it in the enclave configuration file via the untrustedConfig.envVars field.

For example:

version: 1.9

untrustedConfig:
  envVars:
    allow:
      - LOG_SERVER_ADDRESS
      - LOG_LEVEL
      - SERVICE_ADDRESS

Once you build your Anjuna Confidential Pod image with this configuration, the environment variables LOG_SERVER_ADDRESS, LOG_LEVEL, and SERVICE_ADDRESS will be applied if set in the Pod specification.

For instance, the Pod specification below would set the value of LOG_LEVEL directly in the Pod spec, the value of LOG_SERVER_ADDRESS from a ConfigMap, and fetch the value of SERVICE_ADDRESS from the Kubernetes Downward API.

apiVersion: v1
kind: Pod
# <snip>...
metadata:
  labels:
    io.anjuna/run-confidential: "yes"
spec:
  containers:
    # <snip>...
    env:
      - name: LOG_LEVEL
        value: "debug"
      - name: LOG_SERVER_ADDRESS
        valueFrom:
          configMapKeyRef:
            name: logging
            key: server_address
      - name: SERVICE_ADDRESS
        valueFrom:
          fieldRef:
            fieldPath: status.podIP
      # <snip>...

apiVersion: v1
kind: ConfigMap
metadata:
  name: logging
data:
  server_address: "my-log-server.anjuna.io"

If the enclave configuration file specified a trusted value for any of those variables through the field environment or via apmConfig.envs, they would have taken precedence over the untrusted value.

If you define the same environment variable in more than one place, the following describes the precedence used:

The environment variables defined in the apmConfig.envs field take highest precedence, overwriting any other definition of that same environment variable.
Then, the environment section in the enclave config file that is provided when building the enclave, is second in precedence.
The envVars in an untrustedConfig key is the second lowest in precedence, and is only applied if an environment variable is not already applied through environment or apmConfig.envs.
Finally, the environment variables set by the build-time container image are lowest in precedence.

Volume mounts

Similar to environment variables, all volume mounts defined in the Pod specification are considered untrusted and therefore ignored by default, unless explicitly allowed through the untrustedConfig.mountPaths field.

For example:

version: 1.9

untrustedConfig:
  mountPaths:
    allow:
      - /var/run/secrets/kubernetes.io/serviceaccount
      - /usr/share/nginx/html/index.html

The enclave configuration file above allows volume mounts for /var/run/secrets/kubernetes.io/serviceaccount (the Kubernetes service account token) and /usr/share/nginx/html/index.html.

For instance, the Pod specification below mounts a file at /usr/share/nginx/html/index.html from the ConfigMap custom-page. Kubernetes automatically mounts the service account token to all Pods by default.

apiVersion: v1
kind: Pod
# <snip>...
metadata:
  labels:
    io.anjuna/run-confidential: "yes"
spec:
  containers:
    # <snip>...
    volumeMounts:
      - name: custom-page
        mountPath: /usr/share/nginx/html/index.html
        subPath: index.html
      # <snip>...
  volumes:
    - name: custom-page
      configMap:
        name: custom-page

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-page
data:
  index.html: "This is my custom page!"

If the enclave configuration file specified a trusted file for any of the mount paths through the field files or via apmConfig.files, they would have taken precedence over the untrusted volume mount from the Pod specification.