You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The README should mention that using https://github.com/contentful-labs/kube-secret-syncer alone will result in external secrets being stored unencrypted in etcd and therefore open to attack (either via the etcd server or via backups of etcd data).
A solution, which should probably be recommended in the README, is to use a KMS plugin to encrypt the secrets prior to them being stored in etcd.
Hi Glyn, this is correct. There are different solutions to encrypt the secrets prior to storing them in etcd. My understanding though is that - if stored encrypted, the pods accessing the secrets would require a way to decrypt the secrets. Though some googling brought me here https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/ which seems to indicate that this is supported by Kubernetes through a plugin now? Is that what you are referring to?
Fun stuff. Probably not massively hard to implement in kube-secret-syncer either, though I admit right now this is not a priority for us. Definitely interested in pull requests though. I ll leave this ticket open while the documentation is not updated.
The README should mention that using https://github.com/contentful-labs/kube-secret-syncer alone will result in external secrets being stored unencrypted in etcd and therefore open to attack (either via the etcd server or via backups of etcd data).
A solution, which should probably be recommended in the README, is to use a KMS plugin to encrypt the secrets prior to them being stored in etcd.
(See external-secrets/kubernetes-external-secrets#538.)
The text was updated successfully, but these errors were encountered: