bitnami/sealed-secrets

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

オープン

#821 opened on 2022/04/20

 (1 件のコメント) (6 件のリアクション) (0 人の担当者)Go (771 件のフォーク)auto 404
backlogenhancementhelp wanted

Repository metrics

Stars
 (9,222 個のスター)
PR merge metrics
 (PR metrics pending)

説明

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

コントリビューターガイド