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 will support these features starting with SCONE release 5.3.0.

aad-token

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.

Parameters

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

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

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.

Note

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 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 session contains exactly one aad-token secret, the parameter is optional, and this secret will be used by default. If the session contains multiple aad-token secrets, the parameter must be specified.

Note

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.

Note

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.