bitnami/sealed-secrets

Encrypt with multiple public keys (disaster recovery, ...)

Open

#263 opened on Sep 17, 2019

 (19 comments) (19 reactions) (0 assignees)Go (771 forks)auto 404
enhancementhelp wanted

Repository metrics

Stars
 (9,222 stars)
PR merge metrics
 (PR metrics pending)

Description

Proposal

Teach kubeseal to emit multiple versions of the same encrypted item, each one encrypted with a different cert.

Rationale

There are two major use cases:

  1. disaster recovery
  2. multi-cluster / multi-env

Disaster recovery

Since the introduction of automatic key renewal in #137, the process around disaster recovery become more complex since now users have to back up the sealing keys matching the label sealedsecrets.bitnami.com/sealed-secrets-key=active relatively frequently. If the cluster blows up after a new key has been created and before a backup has happened, all recently sealed secrets will be effectively lost.

If kubeseal can seal with multiple certificates, users could have a "backup key pair", whose private key is securely stored in a (physical?) vault and used only during

Decoupling the disaster recovery procedure from the creation of new sealing keys will allow us to explore more interesting patterns. For example, we could create a new private key per namespace, or even a new private key for each sealed secret! The trade-off between online/offline sealing still remains, but removing the disaster recovery process makes it more palatable to explore operation modes that involve multiple secrets created at arbitrary cadences.

Multi-cluster / multi-env

Ideally secret should be as fine grained as possible in order to reduce the impact of a leak and subsequent secret revocation. E.g. if you need a slack API key in a bunch of applications, possibly running in different clusters, it's better to create a token for each application and seal it independently.

That said, in some cases that's not practical or perhaps not even possible and you end up sealing the same underlying secret into multiple sealed secrets (or using cluster-wide scope if applicable)

Instead of scattering around each of those sealed secrets in independent files, we could use the "multi-encryption" feature to have a single sealed secret that seals the same items for N target environments (either different namespaces of the same cluster or even different clusters altogether)

References

  • #120
  • #226

Contributor guide