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 have started to support these features with SCONE release 5.4.0. You can read and watch at our tutorial to learn how to use these new features.
CAS can retrieve access tokens (aad-token) 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.
To retrieve an aad-token, one has to specify secrets:
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 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
Protecting the credentials to retrieve the AAD Token
To protect the credentials define within a policy P, policy P defines who can read P. In quite a few cases, one wants to permit that anybody can read policy P. However, one does not want to expose the credentials to retrieve, say, the aad-token
ad_token_1. Our recommendation is to define the credentials to retrieve
ad_token_1 in a second CAS policy, say, P2. Policy P2 specifies the credentials for
ad_token_1 and exports
ad_token_1 to policy P. One can define P2 such that nobody can read P2. Policy P imports
ad_token_1 from P2. Policy P2 could state that anybody can read P2: a reader would only learn the name
ad_token_1, but it would not be able to read token
ad_token_1 nor the credentials used to retrieve
As we already mentioned above, one can limit who can retrieve a policy.
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 policy (a.k.a. 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 policy (a.k.a. session) contains exactly one
aad-tokensecret, the parameter is optional, and this secret will be used by default. If the policy (a.k.a. session) contains multiple
aad-tokensecrets, the parameter must be specified.
import vs import_akv
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.