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 \
--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.
Apart from the features described in the document above, which are available to any Anjuna Confidential Container or Anjuna Confidential Pod, there is 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.8
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>...
spec:
runtimeClassName: anjuna-remote
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 If you define the same environment variable in more than one place, the following describes the precedence used:
|
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.8
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>...
spec:
runtimeClassName: anjuna-remote
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 |