Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 31 million developers.Sign up
Big change for this release is the switch to per-key encrypted values.
("Keys" as in "object key/value", not as in "encryption key". English is hard.)
- Previously we generated a single big encrypted blob for each Secret, now we encrypt each value in the Secret separately, with the keys in plain text.
- This allows:
- Existing keys can now be renamed and deleted without re-encrypting the value(s).
- New keys/values can be added to the SealedSecret without re-encrypting (or even having access to!) the existing values.
- Note that (as before) the encrypted values are still tied to the namespace/name of the enclosing Secret/SealedSecret, so can't be moved to another Secret.
(The cluster-wide annotation does allow this, with the corresponding caveats, as before)
kubesealtool does not yet have an option to output just a single value, but you can safely mix+match the individual values from
kubesealoutput with an existing SealedSecret. Improving
kubesealsupport for this feature is still an open action item.
- Existing/older "all-in-one" SealedSecrets are declared deprecated, but will continue to be supported by the controller for the foreseeable future. New invocations of the
kubesealtool now produce per-key encrypted output - if you need to produce the older format, just use an older
kubeseal. Please raise a github issue if you have a use-case that requires supporting "all-in-one" SealedSecrets going forward.
- Note the CRD schema used for server-side validation in k8s >=1.9 has been temporarily removed, because it was unable to support the new per-key structure correctly (see kubernetes/kubernetes#59485).
- Huge thanks to @sullerandras for the code and his persistence in getting this merged!
- Support "cluster wide" secrets, that are not restricted to the original namespace
- Warning: cluster-wide SealedSecrets can be decrypted by anyone who can create a SealedSecret in your cluster
- Move to client-go v5.0
- Move to bitnami-labs github org
- Fix bug in schema validation for k8s 1.9
Note: this version moves TPR/CRD definition into a separate file. To install, you need
controller.yaml and either
- Add CRD definition and TPR->CRD migration documentation
kubeseal --fetch-certto dump server cert to stdout, for later offline use with
- Better sanitisation of input object to
(v0.5.1 fixes a travis/github release issue with v0.5.0)
- controller: deployment security hardening: non-root uid and read-only rootfs
kubeseal: Include oidc and gcp auth provider plugins
kubeseal: Add support for YAML output
controller-norbac.yamlto the release build. This is
controller.yamlwithout RBAC rules and related service account - for environments where RBAC is not yet supported, like Azure.
- Fix missing controller RBAC ClusterRoleBinding in v0.3.0
Rename everything to better represent project scope. Better to do this early (now) and apologies for the disruption.
- Rename repo and golang import path ->
- Rename cli tool ->
- Fix invalid field
resourceNamein v0.2.0 controller.yaml (thanks @Globegitter)
- Client tool has better defaults, and can fetch the certificate automatically from the controller.
- Improve release process to include pre-built Linux and OSX x86-64 binaries.