0

Is it possible to do SQL Server secret rotations?

Scenario:

  • CI/CD pipes with helm chart for SQL server

    • Including secret, persistent volume, persistent volume claim, deployment (persistent volume is a NFS is my case, and the k8s is bare metal, if it even matters)

  • Some time later, I probably want to upgrade SQL server version, preferable through the CI/CD pipe

I have tried this out a bit and it work pretty well, but the problem I'm facing is that when I do the deployment, SQL Server creates some sys-DB:s containing the SA password based on the initial secret.

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Values.name }}-secret
type: Opaque
data:
  sapassword: {{ randAlphaNum 64 | b64enc | quote }}

Now let's say I want to redeploy or do a version upgrade (or even a power failure, corrupt nodes or whatever else),
the sys-DB:s are mapped to a persistent storage and will be remapped.

However, the SA password "x" is inside the remapped sys-DB is and the newly generated secret SA password is is "y". Is it different for users/consumer-pods passwords (connection strings for Code First generated DBs)?

Any ideas? Or should I simply not generate the passwords in a DB secret?

Matt
  • 68,711
  • 7
  • 155
  • 158
Henkolicious
  • 1,273
  • 2
  • 17
  • 34

1 Answers1

2

I have been in your shoes and ended up removing the secret from the helm chart and made changes in the deployment to inject secrets as a env variable from a k8s secret which I created outside of the helm chart.

Other option I could think is to use external secret managers to dynamically inject secrets to the pod at runtime -> https://banzaicloud.com/blog/inject-secrets-into-pods-vault/

navinkbe7
  • 21
  • 3
  • Alright, option B for me was to remove the `secret` from the helm chart and store it outside of version control. We don't have to option to use e.g hashicorp or other external key-vaults. – Henkolicious Feb 03 '20 at 09:39