Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Encryption of shoot secrets in etcd #1066
What this PR does / why we need it:
The protection of shoot cluster secrets against eavesdropping and unauthorised access is of utmost importance. As of today, Gardener already protects the transmission of secrets by applying transport encryption via TLS between the API server and the kubelet(s). While encryption in transit is already addressed, this PR provides a data-at-rest protection of Kubernetes secrets. More clearly, shoot secrets that are stored in etcd need to be encrypted prior to storing them in etcd and need to be decrypted after retrieving them from etcd. From Kubernetes version 1.13.0 onward, the kube-apiserver process supports the encryption of secret data at rest.
This PR uses the Kubernetes feature automatically for shoots created by Gardener. Each shoot cluster with Kubernetes version 1.13.0 receives an EncryptionConfiguration with a random shoot-specific encryption key. The EncryptionConfiguration is realised itself as a Kubernetes secret which is created during the shoot reconciliation in the seed cluster (in the shoot namespace) and is mounted to the API server pods. All shoot secrets are rewritten to ensure that they are encrypted as specified in the EncryptionConfiguration.
More clearly, the EncryptionConfiguration is written during the first reconciliation run in a passive state (meaning that "identity" is the first entry in the list of encryption providers, and "aescbc" is the second entry). In this state, the key is already known to each apiserver process (and could be used for decrypting a secret that was encrypted with that key) but secrets are not yet actively encrypted. The next subsequent reconciliation run re-orders the encryption providers and thereby activates the encryption.
Which issue(s) this PR fixes:
Special notes for your reviewer:
adracus left a comment
Quick remark: Please don't reply 'Ok' to items you resolved - We get an email for each of these replies. Rather just resolve the conversation. We're still able to see what you've resolved and what not.
3 times, most recently
Jun 26, 2019
The EncryptionConfiguration is written as secret to the seed and additionally is synced to the Garden. Having the key stored in two separate places was done on purpose to alleviate the risk of loosing an EncryptionConfiguration key as long as no current backup of the seed's etcd has been done. This approach was recommended by @marwinski and discussed with @rfranzke .
I understand that you @adracus are thinking about removing this part ... and of course the code gets simpler if this functionality is removed again ... and of course it is absolutely your choice as Gardener code owner. But I would like to ask you to weigh this code simplification against a potentially higher risk of loosing an encryption key.