Version 1.2.1 / 2019-09-07

Add support for nested secret values (#9, #10):

The Vault Secrets Operator supports nested secret values now. Therefor the operator checks the type for all returned keys from Vault and do not try to always use string as the type for the value. If the Vault secret contains nested values, the operator use the corresponding JSON string for the Kubernetes secret.

Example:

Create a file called values.json with the following content:

{
  "values.yaml": {
    "postgres": {
      "user:" "admin",
      "secret": "password"
    }
    "web": {
      "initialPassword": "password"
    }
  }
}

Then create a Vault secret from this file run:

cat values.json | vault kv put kv2/nested-secret -

When the Vault secret was created, create the corresponding CR:

cat <<EOF | kubectl apply -f -
apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: nested-secret
spec:
  path: kv2/nested-secret
  secretEngine: kv2
  type: Opaque
EOF

Version 1.2.0 / 2019-09-03

Add support for KV Secrets Engine - Version 2

The Vault Secrets Operator supports the KV Secrets Engine - Version 2 from now on. For this, the CRD has been expanded by two new fields. The spec.secretEngine and the version field.

• spec.secretEngine: Set the secret engine where the Vault secret is stored. This must be kv1 or kv2. kv1 is used for the KV Secrets Engine - Version 1 and kv2 for the KV Secrets Engine - Version 2. If the field is omitted, kv1 will be used.
• spec.version: If the KV Secrets Engine - Version 2 is used this field is used to set the Version of the Vault secret, which should be used. If the field is omitted the operator will use the latest version of the Vault secret.

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: kv2-example-vaultsecret
spec:
  keys:
    - foo
  path: kv2/example-vaultsecret
  secretEngine: kv2
  type: Opaque
  version: 4

Version 1.1.1 / 2019-09-01

Fix the versioning of the Helm chart.

Version 1.1.0 / 2019-09-01

• Add the Kubernetes Auth Method as second option for the authentication against Vault.
• More configurable options via the Helm chart values.
• Add description for all available Helm chart values
• Improve the readme

Version 1.0.0 / 2019-08-28

The Vault Secrets Operator creates a Kubernetes secret from a Vault. The idea behind the Vault Secrets Operator is to manage secrets in Kubernetes using a secure GitOps based workflow. The Vault Secrets Operator reads a Vault secret from the defined path in a CR and creates a Kubernetes secret from it.

• The Operator uses Token Auth Method for the authentication against Vault
• The Operator supports the KV Secrets Engine - Version 1
• To create a Kubernetes secret from Vault you can use a CR like the following:

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  # Name of the CR and the name of the Kubernetes secret to create
  name: example-vaultsecret
spec:
  # Optional: A list of keys which should be included in the Kubernetes Secret. If omitted the Kubernetes Secret will contain all keys from the Vault secret
  keys:
    - foo
  # Path of the Vault secret
  path: secrets/example-vaultsecret
  # Type of the Kubernetes secret to create
  type: Opaque

• Automatic build of a new Docker image and Helm chart on releases