Import secrets from file using API about sealed-secrets HOT 5 CLOSED

Manipulating the SealedSecret resource via the k8s API is super-normal CRD stuff, so I strongly doubt my writing abilities will do any better than what the broader k8s community has already explained on this topic - and certainly not across the same breadth of client environments and levels of detail ;) I'm happy to help where I can, but I encourage you to look there and at other examples of code using client-gen-based clients as a starting point.

Also wanted to know if there secret name affects any salting or hashing of the value in the encrypted data?

Yes, the controller will only decrypt the SealedSecret if the namespace+name matches the one it was originally encrypted with (docs).

As you might have seen in the test suite, you can disable this with a sealedsecrets.bitnami.com/cluster-wide: true annotation on the original Secret (which then triggers kubeseal to encrypt it differently) - with the caveat that this allows anyone with the RBAC permissions to create a SealedSecret anywhere in your cluster to decrypt such a SealedSecret (since they can now copy your SealedSecret to their own namespace/name). This feature is supported by the controller, but new enough that it isn't documented beyond the release notes, nor exposed in kubeseal in a discoverable way yet (patches welcome!)

from sealed-secrets.

I'm a little unclear what you mean by "import via the API", so please re-ask if this isn't what you meant:

The sealing certificate can be fetched with kubeseal --fetch-cert > /some/file.crt (this step requires access to the k8s cluster), and is not secret (so can be stored/shared publicly if you want).
Once you have the certificate, you can encrypt a plain text Secret to an encrypted SealedSecret with kubeseal --cert $cert < /some/secret/file.yaml (this step does not require access to the k8s cluster).

So this allows you to create a SealedSecret ahead of time, and without access to the final cluster. The SealedSecret object can be stored in git, just like all your other k8s config.

At some point you want to push the git config (including SealedSecret) to the k8s cluster. You should be able to push the SealedSecret object using whatever tooling you're using for all your other k8s config objects. kubectl apply -f ..., kubecfg update ..., weave cloud deploy, openshift config pipeline, etc, etc.

If you're writing your own client code and making raw k8s API calls, then the SealedSecret is just a regular CRD with apiVersion bitnami.com/v1alpha1 and kind SealedSecret. If you're using go, then the sealed-secrets repo includes the usual k8s API type declaration in github.com/bitnami-labs/sealed-secrets/pkg/apis/sealed-secrets and auto-generated client code (including fakes for testing) in github.com/bitnami-labs/sealed-secrets/pkg/client/clientset/versioned

from sealed-secrets.

Hi Angus, it sounds like you're following what I wanted to get to. I want an example in the docs of how to import that SealedSecret via Go instead of kubectl apply. I think I've figured it out now after digging through the code and the integration test, but it'd be good if you could confirm this.

Also wanted to know if there secret name affects any salting or hashing of the value in the encrypted data? I.e. could I create a secret, seal it then import it with a different name?

Thanks for your assistance.

from sealed-secrets.

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

from sealed-secrets.

Due to the lack of activity in the last 7 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

from sealed-secrets.