Reference: Environment variables

If specified, anjuna-nitro-cli will use this path instead of /opt/anjuna/license.yaml. This is for running AWS Nitro EC2 Enclaves and not for use with Anjuna Nitro Kubernetes Toolset, because the webhook will automatically place the license secret at the correct location. ANJUNA_LICENSE_PATH is applicable for both build-enclave and run-enclave.

For more information on licensing, see Licensing the Anjuna Nitro Runtime.

If set to yes on a Pod with the Anjuna Nitro Kubernetes Toolset, ANJ_ENCLAVE_DEBUG_MODE creates a debug enclave. If not defined or set, the Anjuna Nitro Kubernetes Toolset will start the AWS Nitro Enclave in production mode.

anjuna-nitro-cli build-enclave will use temporary files in the $ANJ_NITRO_CLI_ARTIFACTS directory. If you run multiple builds in parallel, these files may conflict and cause corrupted EIFs to be produced. It is recommended to set $ANJ_NITRO_CLI_ARTIFACTS to a different path for each parallel build-enclave command.

When an application’s EIF is configured with an encrypted config, the Anjuna Nitro Runtime communicates directly with AWS KMS to leverage its Cryptographic Attestation capabilities. The Anjuna Nitro Runtime decrypts the encrypted config and injects the enclave’s application configuration at runtime.

This is secured by configuring an AWS KMS key’s policy to allow the kms:Decrypt operation for an application that has specific enclave measurements (PCR values). In this scenario, when a new version of the application is built, some of the enclave’s measurements (PCR values) will change. If the KMS policy to access a key includes PCRs with a changed value, you need to update the KMS policy for accessing the key in order to accommodate the new value.

As a global distributed service, AWS KMS has eventually-consistent updates for KMS key policies, meaning changes to a key policy may not be immediately available.

For this reason, an AccessDeniedException error might be thrown by the Anjuna Nitro Runtime when an updated version of an application’s EIF is launched soon after updating the encrypted config’s KMS key policy.

In order to work around this issue, the Anjuna Nitro Runtime exposes the environment variable ANJ_ENCLAVE_KMS_DECRYPT_RETRY_TIMEOUT_SECONDS. When this variable is set, the Anjuna Nitro Runtime will retry the kms:Decrypt operation until the timeout duration has elapsed. This enables the application’s CI/CD to launch the enclave with a custom timeout to account for any delays with AWS KMS in propagating changes to a key’s policy.

Since these delays might vary based on the region where the enclave is being deployed, this environment variable is allowed, by default, to be defined via the parent instance or your Pod yaml manifest. It can also be defined in the environment section of the EIF configuration file. If defined in both places, the value defined by either the parent instance or the Pod yaml precedes the value from the enclave configuration file.

If the environment variable is not set, the Anjuna Nitro Runtime will attempt to decrypt the encrypted config using KMS with up to three tries, as defined by the default AWS SDK retry configuration. If it is set, the Anjuna Nitro Runtime will retry until it succeeds or it reaches the defined timeout.