Skip to content
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

Externally managed .data fields in generated Secrets (AKA preserve unknown .data fields on Secret Update) #821

Open
chrisob opened this issue Apr 20, 2022 · 1 comment
Labels
backlog Issues/PRs that will be included in the project roadmap enhancement help wanted Feature requests approved by maintainers that are not included in the project roadmap

Comments

@chrisob
Copy link

chrisob commented Apr 20, 2022

Which component:
Controller v0.17.2

Is your feature request related to a problem? Please describe.
I have an "operator"/controller separate from the SealedSecretsController which should manage (via Patch method) some .data keys in a Secret. The Secret itself is created from a SealedSecret.

In other words, I have this SealedSecret...

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: shared-secret
  namespace: default
spec:
  encryptedData:
    ss-key: <encrypted-value>
  template:
    data: null
    metadata:
      creationTimestamp: null
      name: shared-secret
      namespace: default
    type: Opaque

...which results in this Secret (redundant fields removed)...

apiVersion: v1
kind: Secret
metadata:
  name: shared-secret
  namespace: default
type: Opaque
data:
  ss-key: <value>

...and I want to separately Patch-in the field .data.non-ss-key like so:

apiVersion: v1
kind: Secret
metadata:
  name: shared-secret
  namespace: default
type: Opaque
data:
  ss-key: <value>
  non-ss-key: <value> # <------ This field is not part of the owning SealedSecret, but is added by a separate controller

Unfortunately, shortly after the separate controller Patches the .data.non-ss-key field in, the SealedSecretsController Updates the Secret and wipes out the extra key.

Describe the solution you'd like
I would like to see SealedSecretsController preserving data keys which are not part of the owning SealedSecret.

Even ignoring a separate controller, I would like to have the possibility of manually adding more .data fields to the generated Secret without them being deleted by the SealedSecretsController.

Describe alternatives you've considered
Right now we're looking into a workaround to "compile" a second Secret to be the one used by the end application, and the Secret owned by the SealedSecret is just used as input to compile this second Secret.

Additional context
none

@github-actions github-actions bot added the triage Issues/PRs that need to be reviewed label Apr 20, 2022
@alvneiayu alvneiayu added enhancement help wanted Feature requests approved by maintainers that are not included in the project roadmap backlog Issues/PRs that will be included in the project roadmap and removed triage Issues/PRs that need to be reviewed labels Apr 28, 2022
@alvneiayu alvneiayu added this to Inbox in Sealed Secrets via automation Apr 28, 2022
@yevhen-harmonizehr
Copy link

+1, i have same issue with ArgoCD when it always inject some auto-generated values to secret created by sealed-secrets, and controller wipes out everything after reboot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Issues/PRs that will be included in the project roadmap enhancement help wanted Feature requests approved by maintainers that are not included in the project roadmap
Projects
Sealed Secrets
  
Inbox
Development

No branches or pull requests

3 participants