Version 1.14.2 / 2021-04-05

• Add support for access vault namespace root secrets by @Carles-Figuerola (#98)
• Fix Helm test by @tehlers320 (#99)
• Fix nil pointer exception, which caused a problem with tokens, which can not be renewed (#100)

Version 1.14.1 / 2021-03-30

• Add support for ARM (#93). Thanks to @ChipWolf for testing it.
• Fix Helm test by @tehlers320 (#95)

Version 1.14.0 / 2021-03-16

Add status to VaultSecret CR (#90)

The VaultSecret CR contains a new status field, which can be used to view the current reconciliation status of the CR. The current condition is shown via additional print columns:

NAME   SUCCEEDED   REASON    MESSAGE              LAST TRANSITION   AGE
test   True        Created   Secret was created   5s                5s
test   True        Updated   Secret was updated   0s                35s
test   True        Updated   Secret was updated   5m9s              5m44s

Thanks to @swarren83 for his input on this.

Allow setting a list of namespaces even when rbac.namespaced is true (#87)

It is now possible to set a list of namespaces, which should be watched by the operator, even when rbac.namespaced is set to true.

Thanks @mtougeron for his contribution.

Misc

• Update Operator SDK to v1.4.2 (#88)
• Do not create the corresponding Kubernetes Secret for a VaultSecret CR, when the templating fails (#85). Thanks @nikhiljha for reporting.

Version 1.13.0 / 2021-02-17

Add support for AppRole auth method for Vault (#82)

Adding a new Vault auth method approle that requires VAULT_ROLE_ID and VAULT_SECRET_ID instead of the token. Also added a new parameter VAULT_APP_ROLE_PATH, which is set to auth/approle in Helm chart by default. Also, tokens returned by AppRole auth method usually have a maximum TTL, by default 32 days, so the operator needs to request a new token periodically using AppRole id and secret id. To control the token maximum TTL, added a new parameter VAULT_TOKEN_MAX_TTL, which by default set to 1382400 seconds (16 days).

vault:
  authMethod: approle
environmentVars:
  - name: VAULT_ROLE_ID
    valueFrom:
      secretKeyRef:
        name: vault-secrets-operator
        key: VAULT_ROLE_ID
  - name: VAULT_SECRET_ID
    valueFrom:
      secretKeyRef:
        name: vault-secrets-operator
        key: VAULT_SECRET_ID

Thanks to @pbchekin for his contribution.

Fix RBAC Permissions for Namespaced Deployments using the Kubernetes Auth Method

Fix RBAC permissions for namespaced deployments, when the Kubernetes authentication method is used. When the Kubernetes auth method is used for the operator, we have to create an additional ClusterRole and ClusterRoleBinding for the TokenReview API.

⚠️ Breaking: ⚠️ createclusterrole was renamed to createrole in the Helm chart, because we are creating a Role instead of a ClusterRole, when the rbac.namespaced value is set to true. So that the (Cluster)Role is handle in the same way as the (Cluster)RoleBinding.

Thanks to @acornax for reporting and testing.

Version 1.12.0 / 2021-02-10

Support Vault Namespaces (#74)

Add support for Vault Namespaces via the VAULT_NAMESPACE environment variable and the vaultNamespace field in the VaultSecret CR.

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: kvv1-example-vaultsecret
spec:
  vaultNamespace: team1
  path: kvv1/example-vaultsecret
  type: Opaque

Thank you @swarren83 for testing this.

Remove whitespaces in watchNamespace (#77)

Thanks to @alexandra-tudor for her contribution, which allows to pass the namespaces as ns1, ns2, ns3 to the operator.

Improve Kustomize Files (#71, #72)

Thanks to @fernando-villalba for his ideas around the improvement of the kustomize files. The kustomize files are using the resources instead of the deprecated base field and the apiVersion and kind field was added to all files.

Version 1.11.0 / 2020-12-30

It is now possible to specify a vaultRole property for the VaultSecret CR, which defines the Vault Role which should be used to retrieve a secret from Vault.

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: kvv1-example-vaultsecret
spec:
  vaultRole: my-custom-vault-role
  path: kvv1/example-vaultsecret
  type: Opaque

We are creating a shared client for requests against the Vault API, when the VAULT_KUBERNETES_ROLE (vault.kubernetesRole) environment variable is set. This shared client is used to get the secrets from Vault.

When the vaultRole property for a secret is set, we will ignore the shared client and instead we create a new client to get the secret from Vault.

For that the operator will now also start when the VAULT_KUBERNETES_ROLE environment variable isn't set when the Kubernetes auth method is used. We only log a warning that no shared client was created. This means that each secret must have set the vaultRole property.

Version 1.10.2 / 2020-12-30

Added ability to specify priorityClassName (#66)

It is now possible to specify the priorityClassName in the Helm chart. Thanks to @null93 for his contribution.

Fix RBAC generation (#65, #67)

Add markers to generate RBAC rules and add finalizers to the RBAC rules, to fix the following error for OpenShift:

secrets "test-vault-secret" is forbidden: cannot set blockOwnerDeletion if an ownerReference refers to a resource you can't set finalizers on: , <nil>

Thanks to @bartmeuris for finding and fixing this bug.

Version 1.10.1 / 2020-12-01

Fix missing ownerReferences in the created secret

The ownerReferences metadata was missing in the created secret. Now we are setting the VaultSecret as owner of the secret again.

Version 1.10.0 / 2020-11-27

Breaking Change

• The Kustomize files are not compatible with older versions of the operator. Please check your Kustomize setup carefully before applying this to production.

Update Operator SDK

• The Operator SDK was updated to version 1.2.0.
• The args value was removed and the RBAC rules were adjusted in the Helm chart.
• Adding new e2e test using kind, which is run on every PR.

Version 1.9.0 / 2020-11-14

Templated Secrets (#53 by @bartmeuris)

This version add support for templated secrets to the Vault Secrets Operator. When you set the new value spec.templates in the CR, the secrets loaded from Vault are passed to the specified templates. The following values are passed to the template:

• .Secrets: Map with all the secrets fetched from vault. Key = secret name, Value = secret value
• .Vault: Contains misc info about the Vault setup
  • .Vault.Address: configured address of the Vault instance
  • .Vault.Path: path of the Vault secret that was fetched
• .Namespace: Namespace where the custom resource instance was deployed.
• .Labels: access to the labels of the custom resource instance
• .Annotations: access to the annotations of the custom resource instance

For the following example we are creating a new Vault secret containing a username and password, which are used for a database connection string:

vault kv put kvv2/mongodb-credentials username=foo password=bar

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: mongodb-connection-string
spec:
  path: kvv2/mongodb-credentials
  templates:
    mongodbConnectionString: "mongodb://{% .Secrets.username %}:{% .Secrets.password %}@mongodb.{% .Namespace %}.svc.cluster.local:27017"
  type: Opaque

More examples can be found in the readme under Using templated secrets.

Thanks to @bartmeuris for his PR #53.