RELEASE-NOTES.md
Latest release:
28efbe9 to 47b2d72 in /docker (#1919)d90359c to 28efbe9 in /docker (#1912)972618c to d90359c in /docker (#1884)4b2a093 to cd64bec in /docker (#1866)87bce11 to 4b2a093 in /docker (#1846)GOMAXPROCS and GOMEMLIMIT environment variables (#1528)Incomplete release
Incomplete release
Incomplete release
golang.org/x/text fixing CVE-2022-32149 (#1008).controller.yaml having no image reference (#977)kubeseal to its own package (#939)controller (#940 & #947)kubeseal in a container image (#921)Incomplete release
gopkg.in/yaml.v3 to avoid CVE-2022-28948 (#852)prometheus/client_golang and crypto dependencies to avoid CVE-2022-21698 and CVE-2022-27191 (#831)This release finally turns on the update-status feature flag that was introduced back in v0.12.0. The feature is considered stable (if it doesn't work for you, you can deactivate it by setting SEALED_SECRETS_UPDATE_STATUS=0 in the controller manifest).
rbac.authorization.k8s.io/v1 (#602)--update-status by default (#583)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/26?closed=1
This release contains a couple of fixes in the controller and manifests.
Notable mention: You can give the --update-status (also available as env var SEALED_SECRETS_UPDATE_STATUS=1) feature flag another try. We'll turn it on by default in the next release v0.17.0.
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/28?closed=1
condition_info prometheus metric disappearance (#504)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/27?closed=1
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/19?closed=1
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/17?closed=1
This release contains a fix for CVE-2020-14040, which could have opened the possibility for an attacker to cause a DoS on the sealed-secret controller (provided the attacker can cause the controller to process a malicious sealed secret resource).
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/24?closed=1
condition_info metric to expose SealedSecrets status (#421)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/23?closed=1
The binaries in this release have been rebuilt with the Go 1.14.3 toolchain. No other changes in binaries nor k8s manifests.
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/22?closed=1
This release contains only a change in the kubeseal binary since v0.12.2. No controller nor k8s manifest changes.
--merge-into file permissions on Windows (#407)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/21?closed=1
This release contains important changes in manifests since v0.12.1. It also contains a minor fix in kubeseal client.
Previously, users upgrading to v0.12.x from previous versions would experience:
The Deployment "sealed-secrets-controller" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/managed-by":"jsonnet", "app.kubernetes.io/name":"kubeseal", "app.kubernetes.io/part-of":"kubeseal", "app.kubernetes.io/version":"v0.12.1", "name":"sealed-secrets-controller"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable
This was caused by a bug in our official yaml manifests introduced in v0.12.0. Users of the Helm chart were unaffected.
By reverting this issue we're are going to cause the same bad experience for users who did perform a clean install of v0.12.x. However, we believe such users are a minority.
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/19?closed=1
This release contains changes in kubeseal and controller binaries but no changes in manifests since v0.12.0.
This release is a fixup release that turns off the status update feature introduced in v0.12.0. Several users have reported a severe bug (an infinite feedback loop where the controller kept updating SealedSecrets and consuming lots of CPU).
In order to turn it back on you need to manually pass the --update-status flag to the controller (or pass the SEALED_SECRETS_UPDATE_STATUS=1 env var)
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/18?closed=1
This release contains changes in kubeseal and controller binaries as well as a minor change to the k8s manifest (see #381); keep that in mind if you don't rely on the official k8s manifests, including the community-maintained Helm chart.
Now the Sealed Secrets controller updates the Status field of the SealedSecrets resources.
This makes it easier for automation like ArgoCD to detect whether (and when) the controller has reacted to changes in the SealedSecret resources and produced a Secret. It also shows an error message in case it fails (many users are not familiar with k8s events and they may find it easier to see the error message in the status).
The Sealed Secrets controller now exports prometheus metrics. See also contrib/prometheus-mixin and controller-podmonitor.yaml.
status: {} field (#383)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/16?closed=1
This release contains only changes in kubeseal binary (no k8s manifest changes required).
Creating secrets with namespace-wide and cluster-wide scopes is now easier as it no longer requires manually adding annotations in the input Secret before passing it to kubeseal. This was often the root cause of many support requests. Now all you need to do is to:
$ kubeseal --scope namespace-wide <input-secret.yaml >output-sealed-secret.json
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/15?closed=1
This release supports the ARM 32 bit and 64 bit architectures, both on the client and the controller sides.
We also end the silly streak of patch level releases that actually contained features. We'll try to bump the minor version on every release except true hotfixes.
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/2?closed=1
This release contains only changes in Linux kubeseal-arm and kubeseal-arm64 binaries. There are no changes in the docker images, nor in the x86_64 binaries for any of the supported OS.
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/14?closed=1
This release contains changes in kubeseal and controller binaries as well as a minor change to the k8s manifest (see #338); keep that in mind if you don't rely on the official k8s manifests, including the community-maintained Helm chart.
By default, the sealed-secrets controller doesn't unseal a SealedSecret over an existing Secret resource (i.e. a resource that has not been created by the sealed-secrets controller in the first place).
This is an important safeguard, not only to catch accidental overwrites due to typos etc, but also as a security measure: the sealed-secrets controller can create/update Secret resources even if the user who has the RBAC rights to create the SealedSecret resource doesn't have the right to create/update a Secret resource. We didn't want the sealed-secret controller to give its users more effective rights than what they would otherwise have without the sealed-secrets controller. A simple way to achieve that was permit only updates (overwrites) to Secret resources that were already owned by the sealed-secrets controller (which also seemed a sensible thing to do since it protects from accidental overwrites).
However, this behavior gets in the way when you're just starting to use SealedSecrets and want to migrate your existing Secrets into SealedSecrets.
You now can just annotate your Secrets with sealedsecrets.bitnami.com/managed: true thus indicating that they can be safely overwritten by the sealed-secrets controller. This doesn't loosen our security model since you'd have to have RBAC rights to annotate the existing secrets (e.g. with kubectl annotate) or you can ask your friendly admins to do it on your behalf.
fsGroup to nobody in order to support BoundServiceAccountTokenVolume (#338)--force-empty-data flag to allow (un)sealing an empty secret (#334)sealedsecrets.bitnami.com/managed: true annotation which controls overwriting existing secrets (#331)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/13?closed=1
This release contains only changes in kubeseal and controller binaries (no k8s manifest changes required).
It always been possible in theory to run multiple controller instance in multiple namespaces, each with their own sealing encryption keys and thus each able to unseal secrets intended for it. However, doing so created a lot of noise in the logs, since each controller wouldn't know which secrets are meant to be decryptable, but failed to decrypt, and which it ought to ignore.
Since v0.9.6 you can reduce this noise by setting the --all-namespaces flag to false (also via the env var SEALED_SECRETS_ALL_NAMESPACES=false).
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/12?closed=1
This release contains only changes in kubeseal binary (no k8s manifest changes required).
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/11?closed=1
This release contains only changes in kubeseal and controller binaries (no k8s manifest changes required).
--fetch-cert (regression caused by #303 released in v0.9.3) (#306)--recovery-unseal to help with disaster recovery (#307)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/10?closed=1
This release contains only changes in kubeseal and controller binaries (no k8s manifest changes required).
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/9?closed=1
This release contains only changes in kubeseal and controller binaries (no k8s manifest changes required).
A few people have raised concerns of how will automatic key+certificate renewal affect the offline signing workflow. First, a clarification: nothing changed. You can keep using your old certificates; it's just that if you do, you won't benefit from the additional security given from the periodic key renewal.
In order to simplify the workflow for those who do want to benefit from the key renewal, but at the same time
cannot access the target cluster (while not being completely offline), we offer a little feature that will help: --cert has learned to accept http(s) URLs. You can point it to a place where you serve up-to-date certificates for your clusters (tip/idea: you can expose the controller's cert.pem files with an Ingress).
--cert (#281)--merge-into (#286)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/8?closed=1
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/7?closed=1
This release turns on an important security feature: a new private key will be now created every 30 days by default. Existing sealed-secrets resources will still be decrypted until the keys are manually phased out.
You can read more about this feature and the problem of secret rotation and how it interacts with Sealed Secrets in this README section or in the original GH issue #137.
This feature alone is not technically a breaking change for people who use the offline workflow with kubeseal --cert, since old keys are not rotated out automatically. Users would be required to update their offline certs only when they purge old keys manually (we might introduce automatic purging in the future).
That said, to reap the benefits of key renewal, users of the offline workflow are encouraged to update their offline certificates every time a new key is generated (by default every 30 days).
If you are using kubeseal clients older than v0.7.0, please upgrade. Since this release the controller will no longer accept the "v1" format of the encrypted "data" field and instead it will only support the "encryptedData" field.
If you have old sealed secret resources lying around, you can easily upgrade them by invoking:
kubeseal --re-encrypt <old.yaml >new.yaml
Since version v0.7.0 it was possible to update individual items in the encryptedData field of the Sealed Secret resource, but you had to manually copy&paste the encrypted items into an existing resource file. The required steps were never spelled out in the documentation and to be fair it always felt quite awkward.
Now kubectl has learned how to update an existing secret, whilst preserving the same general operation principles, namely staying out of the business of actually crafting the secret itself (kubectl create secret ... and its various flags like --from-file, --from-literal, etc). Example:
$ kubectl create secret generic mysecret --dry-run -o json --from-file=foo=/tmp/foo \
| kubeseal >sealed.json
$ kubectl create secret generic mysecret --dry-run -o json --from-file=bar=/tmp/bar \
| kubeseal --merge-into sealed.json
-o alias for --format (#261)--raw command for only encrypting single items (#257)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/1?closed=1
This release contains a fix for a possible secret leak that can happen when sealing existing secrets that have been retrieved from a cluster (e.g. with kubectl get) where they have been created with kubectl apply (as opposed to kubectl create).
This potential problem has been introduced v0.8.0 when kubeseal learned how to preserve annotations and labels.
Please check your existing sealed secret sources for any annotation kubectl.kubernetes.io/last-applied-configuration, because that annotation would contain your original secrets in clear.
This release strips this annotation (and a similar annotation created by the kubecfg tool)
Fixes in this release:
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/6?closed=1
Fixes in this release:
--cert (#208,#166)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/5?closed=1
Fixes in this release:
client.authentication.k8s.io/v1beta1 config by upgrading to client-go v12.0.0 (#183)The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/4?closed=1
The main improvements in this release are:
The full Changelog is maintained in https://github.com/bitnami-labs/sealed-secrets/milestone/3?closed=1
Many thanks for all the folks who contributed to this release!
Big change for this release is the switch to per-key encrypted values.
kubeseal tool does not yet have an option to output just a single value, but you can safely mix+match the individual values from kubeseal output with an existing SealedSecret. Improving kubeseal support for this feature is still an open action item.kubeseal tool 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.sealedsecrets.bitnami.com/cluster-wide: "true" annotationNote: this version moves TPR/CRD definition into a separate file. To install, you need controller.yaml and either sealedsecret-tpr.yaml or sealedsecret-crd.yaml
kubeseal --fetch-cert to dump server cert to stdout, for later offline use with kubeseal --certkubeseal(v0.5.1 fixes a travis/github release issue with v0.5.0)
kubeseal: Include oidc and gcp auth provider pluginskubeseal: Add support for YAML outputcontroller-norbac.yaml to the release build. This is controller.yaml without RBAC rules and related service account - for environments where RBAC is not yet supported, like Azure.Rename everything to better represent project scope. Better to do this early (now) and apologies for the disruption.
bitnami/sealed-secretskubesealSealedSecret apiGroup -> bitnami.comresourceName in v0.2.0 controller.yaml (thanks @Globegitter)Basic functionality is complete.