Closed djds closed 1 week ago
I also have this requirement, and is blocking deployment, we cannot expect to not auto populate caCertSecret
when rolling out vso to clusters.
BTW, this can now be done using a template:
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultPKISecret
metadata:
name: example
spec:
...
destination:
name: pki1
transformation:
templates:
ca.crt:
text: |
{{- printf "%s" (get .Secrets "issuing_ca") -}}
BTW, this can now be done using a template:
apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultPKISecret metadata: name: example spec: ... destination: name: pki1 transformation: templates: ca.crt: text: | {{- printf "%s" (get .Secrets "issuing_ca") -}}
Indeed, secrets transformations should now be honoured for kuberntes.io/tls
Secret type. That requires v0.7.0 or greater.
Populate
ca.crt
from the vaultissuing_ca
field the Kubernetes secret created byVaultPKISecret
if the target secret is of typekuberntes.io/tls
. Many Kubernetes applications expect a CA to be located at that key and this would obviate the need for separate CAConfigMaps
orSecrets
in many cases. This is especially useful because Vault works great as a cluster CA, but would also simplify the rollout of new trust anchors when the CA is updated or rotated.