Skip to content

v0.7.0
Compare
Choose a tag to compare
@anguslees anguslees released this 22 Mar 00:20
v0.7.0
bda0af6

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)
  • The 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.
  • 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 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.
  • 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!
Assets 8