Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
65 lines (43 sloc) 5.64 KB
title description
Learn about the different options for authenticating with Azure Key Vault.

By default both the Controller and the Env Injector will assume it is running on Azure (since Azure Key Vault is most commonly used in Azure) - and use the default AKS service principal for authentication - unless custom authentication is provided (see Custom Authentication below).

Default authentication is the AKS credentials that are available on all Nodes (hosts) at /etc/kubernetes/azure.json. These credentials are the same as the Kubernetes cluster use when interacting with Azure to create VM's, Load Balancers and other cloud infrastructure.

Note: The preferred solution would be to use Azure Managed Identities, but this is still in preview - so for now we rely on the default AKS service principal.

Situations where Default Authentication does not Work

Currently only one situations has been identified, where default authentication does not work inside Azure.

When a Pod Security Policy is configured in the cluster, preventing containers from reading from the host.

Two solutions exists:

  1. Change the Pod Security Policy to list /etc/kubernetes/azure.json under AllowedHostPaths
  2. Or use custom authentication.

Custom Authentication

It is possible to give the Controller and/or the Env Injector specific credentials to authenticate with Azure Key Vault. The authentication requirements for the Controller and Env Injector are covered below.

Custom Authentication for the Controller

The Controller will need Azure Key Vault credentials to get Secrets from Azure Key Vault and store them as Kubernetes Secrets. In order to provide custom credentials, pass inn the value keyVault.customAuth.enabled=true to the Controller Helm Chart together with one of the Authentication options described below.

Fore more details, see the Controller Helm Chart.

Custom Authentication for Env Injector

To use custom authentication for the Env Injector there are two options:

  1. Use Microsft's AAD Pod Identity (see Using Custom Authentication with AAD Pod Identity)
  2. Use custom credentials through credential injection (see Using Custom Authentication with Credential Injection Enabled)
  3. Provide credentials for each Pod using the Env Injector pattern using Authentication options below.

To avoid using option no. 3, support for a more convenient solution (no. 2) is supported where the Azure Key Vault credentials in the Env Injector (using Authentication options below) is "forwarded" to the the Pods. The Env Injector will create a Kubernetes Secret containing the credentials and mutate the Pod's env section to reference the credentials in the Secret.

Fore more details, see the Env Injector Helm Chart.

Custom Authentication Options

The following authentication options are available:

Authentication type Environment variable Description
Managed identities for Azure resources (used to be MSI) No credentials are needed for managed identity authentication. The Kubernetes cluster must be running in Azure and the aad-pod-identity controller must be installed. A AzureIdentity and AzureIdentityBinding must be defined. See for details.
Client credentials AZURE_TENANT_ID The ID for the Active Directory tenant that the service principal belongs to.
AZURE_CLIENT_ID The name or ID of the service principal.
AZURE_CLIENT_SECRET The secret associated with the service principal.
Certificate AZURE_TENANT_ID The ID for the Active Directory tenant that the certificate is registered with.
AZURE_CLIENT_ID The application client ID associated with the certificate.
AZURE_CERTIFICATE_PATH The path to the client certificate file.
AZURE_CERTIFICATE_PASSWORD The password for the client certificate.
Username/Password AZURE_TENANT_ID The ID for the Active Directory tenant that the user belongs to.
AZURE_CLIENT_ID The application client ID.
AZURE_USERNAME The username to sign in with.
AZURE_PASSWORD The password to sign in with.

Note: These env variables are sensitive and should be stored in a Kubernetes Secret resource, then referenced by Using Secrets as Environment Variables.

See official MS documentation for more details on how environment base authentication works for Azure:

You can’t perform that action at this time.