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.
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:
- Change the Pod Security Policy to list
- Or use 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.
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.
To use custom authentication for the Env Injector there are two options:
- Use Microsft's AAD Pod Identity (see Using Custom Authentication with AAD Pod Identity)
- Use custom credentials through credential injection (see Using Custom Authentication with Credential Injection Enabled)
- 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.
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 |
|Client credentials||The ID for the Active Directory tenant that the service principal belongs to.|
|The name or ID of the service principal.|
|The secret associated with the service principal.|
|Certificate||The ID for the Active Directory tenant that the certificate is registered with.|
|The application client ID associated with the certificate.|
|The path to the client certificate file.|
|The password for the client certificate.|
|Username/Password||The ID for the Active Directory tenant that the user belongs to.|
|The application client ID.|
|The username to sign in with.|
|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: https://docs.microsoft.com/en-us/go/azure/azure-sdk-go-authorization#use-environment-based-authentication