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 not known in advance 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 you define the same environment variable 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 section in the enclave config file that is provided when building the enclave, is second in precedence.
Finally, the envVars in an untrustedConfig key is lowest in precedence, and is only applied if an environment variable is not already applied through environment or encryptedConfig.

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 ...