Support for AWS KMS

[cknowles]

This is a feature request for KMS support like that of sops. Extracted from #63.

1. Get key rotation for almost free.
2. For those who wish to centralise their root keys and access to KMS + IAM rather than base it off those with access to kube-system secrets.
3. KMS together with IAM users/roles still provide the access control needed to restrict decryption to the cluster, the cluster controllers, admin users.

[anguslees]

Re (2):

The way sealedsecrets were intended to be used is that they deliberately don't provide an authentication mechanism. The public key is meant to be widely distributed and available for anyone who wants it - the only thing you can do with the public key is propose a valid SealedSecret object. From that point, the SealedSecret is just another piece of config, and it's up to your regular config approval mechanisms (RBAC, git review/approval, etc) to work out whether this particular change should be permitted - no different to the way you would authorise a change to (eg) the command line flags in a Deployment.

At one extreme, the key can even be committed to source control along with everything else for ease of use (eg: https://github.com/anguslees/k8s-home/blob/master/sealkey.crt).

Unfortunately, I think this point got lost somewhere thanks to a kubeseal convenience feature where it will fallback to querying the k8s server to find the encryption key, if none is given on the command line. This seems to be a really common misunderstanding, and if I had a time machine, I would go back and implement only --fetch-cert/--cert :(

With that in mind, the rest of this bug makes sense. The only real challenge is working out how to represent this in code/options in a pluggable fashion - I imagine once we support more than vanilla Secrets then suddenly we'll get me-too requests for every other system capable of storing the master key...

[cknowles]

Yeah sure, I agree on the goals and maybe it's less transparent than it could be. One of the current problems for review is it's tricky to see whether a secret looks valid. #63 should help a little bit.

I had a bit more of a look through RBAC and found resourceNames which can be used to restrict to a particular secret name. However, it only supports exact matches so no easy way to say an admin can view all secrets apart from the sealed-secrets one. I think KMS may actually improve the security in this regard.

[ayk33]

Has there been any progress made towards KMS support? I would like to have the sealed secret controller use a KMS key instead of generating a new key when it is loaded on the cluster. This is so that in the event of a system failure and my cluster gets wiped out, I do not have to go and regenerate all my sealed secrets again. As it is though I need to keep track of my un-encrypted secrets as a recovery procedure.

[anguslees]

@ayk33 I don't know what people have been working on privately, but no I haven't seen any PRs related to this.

[evq]

Has anyone proposed making use of the asymmetric key support of AWS KMS? There is currently a PR out on this repo for KMS support but it seems to rely on the use of symmetric CMKs. ( This is my assumption because AWS states the encryption context passed in that PR is incompatible with the RSA OAEP encryption used by asymmetric CMKs ). I wonder whether the use of asymmetric CMK(s) would fit better with the existing architecture. Essentially the RSA key could be created through the AWS KMS APIs, the private key stays in secure hardware and the public key can be exported and retrieved similar to the current scheme. Ephemeral symmetric key generation, encryption, decryption could all be done in a similar fashion to the current logic. This would allow new secrets to be sealed without having to grant every user doing so AWS KMS access.

If this path were to be pursued - would we want to grant the sealed-secrets operator permissions to create new CMKs? It seems like automatic "rotation" (seems more akin to "renewal" described in the README here, since the old key is not deleted) is not supported for asymmetric CMKs and that rotation has to be done "manually" - which amounts to creating a new CMK. This logic seems like it would be best handled by the sealed secrets operator.

---

Separately, on general integration direction - I saw one comment by @mkmik to the effect that direct integration should be avoided in favor of a more general plugin system. However there's another comment implying that current KMS PR of using interfaces is (possibly?) acceptable albeit not sufficiently abstracted. @mkmik can you advise on what direction you see being best here?

[github-actions]

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.

[crstian19]

I found this: https://github.com/EladLeev/kubeseal-convert#aws-secrets-manager