Azure Kubernetes Service (AKS) provides a variety of new features for confidential services like:
- Azure Key Vault (AKV) to manage secrets,
- aad-token to retrieve secrets from Azure Key Vault (AKV), and
- MAA (Microsoft Azure Attestation) to attest services
We will support these features starting with SCONE release 5.3.0.
CAS can retrieve access tokens for Microsoft Azure Active Directory (AAD). While they are primarily used to import secrets from Azure Key Vault (see below), they can also be consumed by application services.
tenant_id: The ID of an AAD tenant (required)
client_id: The ID of an AAD application of the referenced AAD tenant (required)
- Either of the following credentials are required:
application_secret: A shared secret that was registered with AAD
certificate_thumbprint: A PEM-encoded PKCS#8 RSA private key belonging to a certificate that was registered with AAD, and a thumbprint of this certificate that was returned during registration.
The AAD application must have application API permissions to access secrets of an Azure Key Vault. For information on how to set up an Azure application for API access, see https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-app. The Key Vault permissions for the application must then be configured using Azure access policies or Azure role-based access control.
In a CAS policy, one can define aad-tokens as follows:
secrets: - name: ad_token_1 kind: aad-token tenant_id: e7cac514-f1aa-4e0d-b207-50b1d9a89d21 client_id: 3f2c210e-83b4-4217-9eee-4f747d8aeeb3 application_secret: "dHmbyTBF4JNAN3JJobeD" - name: ad_token_2 kind: aad-token tenant_id: e7cac514-f1aa-4e0d-b207-50b1d9a89d21 client_id: 3f2c210e-83b4-4217-9eee-4f747d8aeeb3 private_key: | -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCbkIjwCh2zXbUs ... s5is0+EmTLXoWCqftUG5RQ== -----END PRIVATE KEY----- certificate_thumbprint: B033DB596639F3CA02D6537055E85B8EFE060756
Assuming a secret named
$$SCONE::ad_token_1$$ in program arguments, environment variables or secret injection files. AAD token secrets do not support any format suffix. The token can be used to authenticate directly for Microsoft Azure services.
Tokens are only valid for a limited amount of time (a couple of minutes), which means they can only be used successfully immediately after program start.
Azure Key Vault Integration
Existing secret values can be imported from a Microsoft Azure Key Vault (AKV). This requires:
- a new
import_akvmapping which specifies the vault to import from
aad-tokensecret authorized to access this vault
secrets: - name: db_encryption_key kind: binary import_akv: vault: myvaultname.vault.azure.net secret_name: abc token: $$SCONE::db-aad-token$$ - name: db-aad-token kind: aad-token ...
vault: The address of the key vault to use (required)
secret_name: The name of the secret that should be fetched from the vault (optional). If omitted, the
nameof the secret as defined in the session will be used
token: A reference to an
aad-tokensecret of the form
$$SCONE::<secret-name>$$. This token will be used to authenticate requests against the vault. If the session contains exactly one
aad-tokensecret, the parameter is optional, and this secret will be used by default. If the session contains multiple
aad-tokensecrets, the parameter must be specified.
import_akv are mutually exclusive.
kind is optional and will be inferred if omitted.
Assuming a secret named
$$SCONE::db_encryption_key$$ in program arguments, environment variables or secret injection files. These secrets support the specified CAS format suffixes. However, PKCS#12-encoded certificates are represented as strings.
PEM-encoded certificates imported from a key vault will be represented as X.509 secrets. These support format suffix.
PKCS#12-encoded certificates, on the other hand, will be represented as plain text secrets, i.e. suffixes such as
:privatekey cannot be used in secret placeholders.