-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decrypt base64 encoded SOPS encrypted secrets #328
Comments
Kustomize-controller can currently decrypt SOPS encrypted files - but whole files only. Kubernetes Secrets are base64 encoded, therefore when a SOPS encrypted file, is added as base64 encoded data to a Kubernetes Secret, it is not decrypted.
Kustomize-controller can currently decrypt SOPS encrypted files - but whole files only. Kubernetes Secrets are base64 encoded, therefore when a SOPS encrypted file, is added as base64 encoded data to a Kubernetes Secret, it is not decrypted. Signed-off-by: Bob Rohan <bob.rohan@hodge.co.uk>
Can you say more about this solution and what it looks like in practice? Eg. from my current understanding, the secret presents as a regular secret when opened as YAML in an editor, but if you decode the base64 data, it is a SOPS-encrypted (original plaintext) file? I appreciate that you've done some work and are presenting an implementation approach! This makes it much easier to talk about what it does and how it might need to change, in order to be accepted for merge. Can you present some minimal usage examples too? (Ideally in the form of documentation, but it would help my understanding of what you've tried to do, just to see an example secret and explanation of how you're using it.) |
invert execution to avoid decoding secrets - when kustomizse decrpytion provider not provided - when inline SOPS metadata available (i.e not part of the base64 encoded secret data)
invert execution to avoid decoding secrets - when kustomizse decrpytion provider not provided - when inline SOPS metadata available (i.e not part of the base64 encoded secret data) Signed-off-by: Bob Rohan <bob.rohan@hodge.co.uk>
adding tests for sops encrypted data, encoded as a k8 secret
adding tests for sops encrypted data, encoded as a k8 secret Signed-off-by: Bob Rohan <bob.rohan@hodge.co.uk>
@kingdonb I was also confused about this, but now that @bob-rohan has added tests to the PR, I can understand what it does. Thanks @bob-rohan for adding those tests 🏅 |
add Kustomize secretGenerator steps to docs
add Kustomize secretGenerator steps to docs Signed-off-by: Bob Rohan <bob.rohan@hodge.co.uk>
Kustomize-controller can currently decrypt SOPS encrypted files - but whole files only. It does this by, among other things, string matching "sops" and "ENC".
Kubernetes Secrets are base64 encoded, therefore when a SOPS encrypted file is added as base64 encoded data to a Kubernetes Secret, it is not decrypted.
I tried to explain this here fluxcd/flux2#745 (reply in thread)
You may well ask yourself, why someone would want to base64 encode a SOPS encrypted file. We, and I believe others, would and have (using fluxv1 workaround not available in v2) been using Kustomize secretGenerator. It is a useful feature in that it appends a hash of the content of the secret, and propagates that suffixed name to pods that need that secret. This enables that if the underlying secret should change, appropriate deployment/pod rollouts are scheduled.
I will submit a very rough PR, showing a functional solution. This is my first foray into Go development, with such a complicated project I'm surprised it worked - credit to the CONTRIBUTING instructions on getting a local version running so easily. If there is appetite to accept the idea, then I and hopefully others can work to improve the quality of the code and tests etc..
The text was updated successfully, but these errors were encountered: