Authentication

By default both the Controller and the Env Injector will use the credentials found in Cloud Config on the host to authenticate with Azure Key Vault. This is the same credentials as the Kubernetes cluster use when interacting with Azure to create VM's, Load Balancers and other cloud infrastructure.

Cloud Config for Azure is located at /etc/kubernetes/azure.json. The Controller will map this as a read only volume and read the credentials. For the Env Injector it's a bit different. Since the Env Injector is not in full control over how the original container is setup, it will copy the azure.json to a local shared volume, chmod azure.json to 444 in case the original container is running under a less privileged user (which is a good practice) and not get access to the credentials.

Currently only one situations has been identified, where the above does not work:

For default authentication move to the next section about Authorization. To override default authentication, read on.

Override default authentication {#override}

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. See Authentication options below.

Custom Authentication for Env Injector

To use custom authentication for the Env Injector, set the environment variable CUSTOM_AUTH to true.

By default each Pod using the Env Injector pattern must provide their own credentials for Azure Key Vault using Authentication options below.

To avoid that, support for a more convenient solution is added where the Azure Key Vault credentials in the Env Injector (using Authentication options below) is "forwarded" to the the Pods. This is enabled by setting the environment variable CUSTOM_AUTH_INJECT to true. Env Injector will then create a Kubernetes Secret containing the credentials and modify the Pod's env section to reference the credentials in the Secret.

Custom Authentication Options

The following authentication options are available:

Authentication typeEnvironment variableDescription
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 https://github.com/Azure/aad-pod-identity for details.
Client credentialsAZURE_TENANT_IDThe ID for the Active Directory tenant that the service principal belongs to.
AZURE_CLIENT_IDThe name or ID of the service principal.
AZURE_CLIENT_SECRETThe secret associated with the service principal.
CertificateAZURE_TENANT_IDThe ID for the Active Directory tenant that the certificate is registered with.
AZURE_CLIENT_IDThe application client ID associated with the certificate.
AZURE_CERTIFICATE_PATHThe path to the client certificate file.
AZURE_CERTIFICATE_PASSWORDThe password for the client certificate.
Username/PasswordAZURE_TENANT_IDThe ID for the Active Directory tenant that the user belongs to.
AZURE_CLIENT_IDThe application client ID.
AZURE_USERNAMEThe username to sign in with.
AZURE_PASSWORDThe 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