/

AzureKeyVaultSecret

Reference of AzureKeyVaultSecret custom resource definition

The AzureKeyVaultSecret is defined using this schema:

apiVersion: spv.no/v2beta1 # custom resource definition version
kind: AzureKeyVaultSecret
metadata:
  name: < name for azure key vault secret>
  namespace: <namespace for azure key vault secret>
spec:
  vault:
    name: <name of azure key vault>
    object:
      name: <name of azure key vault object to sync>
      type: <object type in azure key vault to sync>
      version: <optional - version of object to sync>
      contentType: <only used when type is the special multi-key-value-secret - either application/x-json or application/x-yaml>
  output: # ignored by env injector, required by controller to output kubernetes secret
    transform: # optional transformers executed in listed order
      - trim # optional - trims empty space
      - base64encode # optional - encode to base64
      - base64decode # optional - decode from base64
    secret: 
      name: <name of the kubernetes secret to create>
      type: <optional - kubernetes secret type - defaults to opaque>
      dataKey: <required when type is opaque - name of the kubernetes secret data key to assign value to - ignored for all other types>
      chainOrder: <optional - used when server certificate is at the end of the chain - set to ensureserverfirst>
    configMap:
      name: <name of the kubernetes secret to create>
      dataKey: <name of the kubernetes config map data key to assign value to>

Note - the output is only used by the Controller to create the Azure Key Vault secret as a Kubernetes native Secret or ConfigMap - it is ignored and not needed by the Env Injector.

Kubernetes Secret Types

The default secret type (spec.output.secret.type) is opaque. Below is a list of supported Kubernetes secret types and which keys each secret type stores.

For a complete list, see core/v1/types.go in the Kubernetes GitHub repository.

Secret typeKeys
opaque (default)defined in spec.output.secret.dataKey
kubernetes.io/tlstls.key, tls.crt
kubernetes.io/dockerconfigjson.dockerconfigjson
kubernetes.io/dockercfg.dockercfg
kubernetes.io/basic-authusername, password
kubernetes.io/ssh-authssh-privatekey

With the exception of the opaque secret type, the Controller will make a best effort to export the Azure Key Vault object into the secret type defined.

kubernetes.io/tls

By pointing to a exportable Certificate object in Azure Key Vault AND setting the Kubernetes output secret type to kubernetes.io/tls, the controller will automatically format the Kubernetes secret accordingly both for pem and pfx certificates.

kubernetes.io/dockerconfigjson

Requires a well formatted docker config stored in a Secret object like this:

{
  "auths": {
    "some.azurecr.io": {
      "username": "someuser",
      "password": "somepassword",
      "email": "someuser@spv.no",
      "auth": "c29tZXVzZXI6c29tZXBhc3N3b3JkCg=="
    }
  }
}

If the "auth" property is not included, the controller will generate it.

kubernetes.io/basic-auth

The controller support two formats. Either username:password or pre-encoded with base64: dXNlcm5hbWU6cGFzc3dvcmQ= stored in a Secret object.

kubernetes.io/ssh-auth

This must be a properly formatted Private SSH Key stored in a Secret object.

Vault Object Types

Object typeDescription
secretAzure Key Vault Secret - can contain any secret data
certificateAzure Key Vault Certificate - A TLS certificate with just the public key or both public and private key if exportable
keyAzure Key Vault Key - A RSA or EC key used for signing
multi-key-value-secretA special kind of Azure Key Vault Secret only understood by the Controller and the Env Injector. For cases where a secret contains json or yaml key/value items that will be directly exported as key/value items in the Kubernetes secret, or access with queries in the Evn Injector. When multi-key-value-secret type is used, the contentType property MUST also be set to either application/x-json or application/x-yaml.

Chain Order

When exporting a PFX certificate from Key Vault the server certificate sometimes end up at the end of the chain instead of the beginning. If this is used together with, for example, ingress-nginx the certificate won't be loaded and it will revert back to default. By setting chainOrder to ensureserverfirst the server certificate will be moved first in the chain.

Output Transformation

Three common transformers exists - trim, base64encode and base64decode. Below is an example where a secret extracted from Azure Key Vault, which is base64 encoded, gets decoded by the transformer before added to a Kubernetes Secret.

apiVersion: spv.no/v2beta1
kind: AzureKeyVaultSecret
metadata:
  name: base64decoded-binary-file
  namespace: my-kw
spec:
  vault:
    name: my-kv
    object:
      name: my-kv-secret
      type: secret
  output:
    transform:
      - base64decode
      - trim
    secret:
      name: not-base64encoded-anymore
      dataKey: myKey
Edit on GitHub