Untrusted configuration

The Anjuna Enclave Configuration provides the user a configuration that is trusted, either through the configuration file attached at enclave-build-time or through an encrypted configuration file. However, there are cases where you need to provide data to the software running in an enclave that is only known at runtime and does not need to be trusted. For example, the IP address of a logging server. The Anjuna Nitro Runtime provides a way to set this type of untrusted configuration.

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

The environment of the encryptedConfig takes highest precedence, overwriting any other definition of that same environment variable.
Then, the environment variables defined in the parent instance or in the K8s Pod manifest are second in precedence. They are only applied if the environment variable is explicitly set as allowed in the envVars.allow field of the untrustedConfig key in the enclave configuration file.
Then, the values defined in the environment section of the enclave config file that is provided when building the enclave are considered.
Finally, the environment variables defined in the original Docker container image have the lowest precedence.

EKS example

Anjuna provides support for Kubernetes applications that run within AWS Nitro Enclaves. For a Kubernetes deployment with pre-built EIFs, the applications may need to obtain information about environment variables using a K8s ConfigMap.

For example, if your application determines the address of a log server and a log level to use through environment variables (LOG_SERVER_ADDRESS and LOG_LEVEL respectively), these values might change from time to time. You might not want to rebuild the enclave whenever these values change, and therefore you decide that these values will be considered "untrusted".

To make the Anjuna Nitro Runtime accept untrusted values for these environment variables, add an untrustedConfig section to your configuration file specifying the names of the environment variables.

untrustedConfig:
  envVars:
    allow:
      - LOG_SERVER_ADDRESS
      - LOG_LEVEL

As part of your Pod deployment, use a ConfigMap to set the untrusted values of the environment variables:

apiVersion: v1
kind: Pod
...
spec:
  containers:
    ...
    env:
      - name: LOG_SERVER_ADDRESS
        valueFrom:
          configMapKeyRef:
            name: logging
            key: server_address
      - name: LOG_LEVEL
        valueFrom:
          configMapKeyRef:
            name: logging
            key: level
      ...

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

You can also set the environment variables' values directly, without using a ConfigMap:

apiVersion: v1
kind: Pod
...
spec:
  containers:
    ...
    env:
      - name: LOG_SERVER_ADDRESS
        value: "my-log-server.anjuna.io"
      - name: LOG_LEVEL
        value: "info"
      ...

Direct EC2 example

For a direct EC2 AWS Nitro Enclave deployment, the enclave will obtain values for untrusted environment variables directly from the shell that created the enclave in the EC2 instance.

untrustedConfig:
  envVars:
    allow:
      - LOG_SERVER_ADDRESS
      - LOG_LEVEL

Prior to running the enclave, set the values of the desired environment variables in your terminal:

$ export LOG_SERVER_ADDRESS="my-log-server.anjuna.io"
$ export LOG_LEVEL="info"
$ anjuna-nitro-cli run-enclave ...

Default untrusted

The environment variable ANJ_ENCLAVE_KMS_DECRYPT_RETRY_TIMEOUT_SECONDS is allowed as untrusted by default.