Version 1.8.2 / 2020-10-28

Allow Namespaced Deployment (#51 by @bartmeuris)

The RBAC options of the Helm chart were adjusted as follows:

• rbac.createclusterrole toggles the creation of the (global) cluster role. This is only necessary once, and only enable this on an internal "management" namespace, where all helm deploys are owner of all CRD's and cluster roles. Note that this will only create the cluster role if rbac.create is also set.
• rbac.namespaced: this does a few things:
  • a RoleBinding is created instead of a ClusterRoleBinding
  • The WATCH_NAMESPACE env var is overridden to be the .Release.Namespace, so only this namespace (where the operator has permissions) is watched.

Thanks to @bartmeuris for his PR #51.

Version 1.8.1 / 2020-09-28

Fix the renew function for the Kubernetes auth method, by using the VAULT_TOKEN_RENEWAL_INTERVAL and VAULT_TOKEN_RENEWAL_RETRY_INTERVAL environment variable.

Version 1.8.0 / 2020-09-28

Reduce token renewal interval in case of errors (#49)

By default, token renewals take place after 50% of the token TTL have passed. In certain scenarios this would lead to only having a single chance to renew the token successfully before it would expire. In case of an error we will retry to renew the token after 30 seconds.

Parameterize token renewal intervals (#50)

For particular Vault setups, the default values for token renewals might not be a good fit. So that the time between a successful or failed token renewal and the next renewal attempt can be controlled via optional environment variables.

• VAULT_TOKEN_RENEWAL_INTERVAL: The time (in seconds) between a successful token renewal and the next renewal attempt. Default: 50% of the token lease duration
• VAULT_TOKEN_RENEWAL_RETRY_INTERVAL: The time (in seconds) between a failed token renewal and the next renewal attempt. Default: 30 seconds

Thanks to @moertel for her contribution.

Version 1.7.1 / 2020-06-22

Fix ClusterRole

During the update of the Operator SDK a bug with the ClusterRole was introduced, which should be fixed now.

Version 1.7.0 / 2020-06-20

Update the Operator SDK

Update the used Operator SDK to version 0.18.0

Add new field reconcileStrategy to the CRD

It is also possible to change the default reconciliation strategy from Replace to Merge via the reconcileStrategy key in the CRD. For the default Replace strategy the complete secret is replaced. If you have an existing secret you can choose the Merge strategy to add the keys from Vault to the existing secret.

Example:

• You have an existing secret merge with a key foo
• You create a vault secret with the same name and the key hello
• The resulting secret contains both keys foo and hello with the Merge strategy

apiVersion: v1
kind: Secret
metadata:
  name: merge
data:
  foo: YmFyCg==
type: Opaque

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: merge
spec:
  reconcileStrategy: Merge
  keys:
    - hello
  path: kubernetes/merge
  type: Opaque

apiVersion: v1
kind: Secret
metadata:
  name: merge
data:
  foo: YmFyCg==
  hello: d29ybGQ=
type: Opaque

Version 1.6.0 / 2020-05-08

• Remove the creation of the Service and ServiceMonitor from the code of the operator.
• Instead provide an option to create the ServiceMonitor via Helm chart.

The following values can be set via the Helm chart:

serviceMonitor:
  enabled: false
  labels: {}
  interval: 10s
  scrapeTimeout: 10s
  honorLabels: true
  relabelings: []

Version 1.5.0 / 2020-05-05

• FIX: Configuration of custom CA. The VAULT_CACERT, VAULT_CLIENT_CERT and VAULT_CLIENT_KEY environment variables must be the path to the corresponding certificate/key.

image:
  volumeMounts:
    - name: ca
      mountPath: "/etc/vault-secrets-operator"

environmentVars:
  - name: VAULT_CACERT
    value: "/etc/vault-secrets-operator/ca.pem"

volumes:
  - name: ca
    secret:
      secretName: vault-secrets-operator-ca
      items:
        - key: ca.pem
          path: ca.pem

• BREAKING CHANGE: Change handling of the environmentVars field in the Helm chart.

environmentVars:
-  - envName: VAULT_TOKEN
-    secretName: vault-secrets-operator
-    secretKey: VAULT_TOKEN
+  - name: VAULT_TOKEN
+    valueFrom:
+      secretKeyRef:
+        name: vault-secrets-operator
+        key: VAULT_TOKEN
+  - name: VAULT_TOKEN_LEASE_DURATION
+    value: "300"

Version 1.4.7 / 2020-02-26

Fix log level

When the service monitor could not be created, the corresponding log messages where using the info level. Thanks to @ilyas28 for his PR, which changes the log level to error.

Version 1.4.6 / 2020-02-06

Add additional annotations and labels

It's now possible to set additional annotations and labels for the vault-secrets-operator pod(s):

# Annotations for vault-secrets-operator pod(s).
podAnnotations:
  myannotation: myannotationvalue

# Additional labels for the vault-secrets-operator pod(s).
podLabels:
  mylabel: mylabelvalue

Version 1.4.5 / 2020-01-06

Adding support for label and annotation inheritance

This release adds support for label and annotation inheritance. Thanks to @s4mur4i for his PR #29. The following CR:

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: kvv1-example-vaultsecret
  annotations:
    myannotation: myvalue
  labels:
    mylabel: myvalue
spec:
  keys:
    - foo
  path: kvv1/example-vaultsecret
  type: Opaque

results now in the following secret:

apiVersion: v1
data:
  foo: YmFy
kind: Secret
metadata:
  annotations:
    myannotation: myvalue
  labels:
    created-by: vault-secrets-operator
    mylabel: myvalue
  name: kvv1-example-vaultsecret
type: Opaque