Skip to content

AKS Integration

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.

aad-token

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.

Parameters

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
  • private_key and 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.

Note

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.

Example

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

Granting Access

As we already mentioned above, one can limit who can retrieve a policy.

Secret Placeholders

Assuming a secret named ad_token_1, use $$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.

Token Lifetime

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_akv mapping which specifies the vault to import from
  • an aad-token secret authorized to access this vault

Example

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

import_akv Parameters:

  • 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 name of the secret as defined in the policy (a.k.a. session) will be used
  • token: A reference to an aad-token secret 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-token secret, the parameter is optional, and this secret will be used by default. If the policy (a.k.a. session) contains multiple aad-token secrets, the parameter must be specified.

import vs import_akv

import and import_akv are mutually exclusive. The secret's kind is optional and will be inferred if omitted.

Secret Placeholders

Assuming a secret named db_encryption_key, use $$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.

Certificate Representation

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.