Add support for Vault Password Policies in VaultStaticSecret

[vlaborie]

Is your feature request related to a problem? Please describe.

Hello, I use auto-generated passwords for some apps on Kubernetes, mostly for internal API tokens and session passwords. However, these passwords are not synchronized to or from Vault (i use mittwald/kubernetes-secret-generator).

I have two problems with theses password not synchronized to Vault:

• If I redeploy a cluster from scratch (e.g., after a disaster), my passwords and API tokens change.
• When I deploy two identical clusters on different sites, they do not have the same password/API token on both sides.

Describe the solution you'd like

I would like to have a passwordPolicy field on VaultStaticSecret that auto-generates a password and stores it back to Vault if the specified path is empty and the password policy exist. eg:

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: mysecret
spec:
  mount: kv2
  type: kv-v2
  path: mysecret
  passwordPolicy: mypolicy
  refreshAfter: 60s
  destination:
    create: true
    name: mysecret

If the path kv2/mysecret is empty and the password policy mypolicy exist, a password is generated from /sys/policies/password/mypolicy/generate and stored to kv2/mysecret.

Describe alternatives you've considered

I have considered to generate theses password from Terrafom (or other tools) and not directly from Kubernetes but that's broke my GitOps workflow and leak password to Terraform state.

Thank's,

[ChristianCiach]

We have the same use-case and just found this operator that supports this: https://github.com/redhat-cop/vault-config-operator/blob/main/docs/secret-management.md#randomsecret

But we would like to continue to use VSO because it's a lot more lightweight. It would be nice to have this feature directly in VSO.

[Justin-DynamicD]

Adding a scenario to this:

We use crossplane to allow resources such as RDS to be deployed. As we want to be able to maintain control of the password/rotation of all access including the initial SA staticsecret, this would allow us to generate the initial SA credentials and store them in vault to be managed separately from the XP solution.

Without the ability to generate the initial secret, the dev making the request would have to take 2 steps to deploy RDS instead of 1 (make secret, create claim), which is a poor experience. With this feature we could:

1. create a XP composition that includes the VaultStaticSecret
2. point the aws RDS resource at a k8s secret we know will exist when the VaultStaticSecret completes either fetching or generating a secret.

This way we are back to a simple experience for self-service as well as a credential managed outside of the specific XP solution (seperation of duties and all that).

We are also looking at VCO as an alternative due to this workflow need.