From a905be0ceb1233a28af7fb84b6c8b0eee0411693 Mon Sep 17 00:00:00 2001 From: Maya Kaczorowski <15946341+mayakacz@users.noreply.github.com> Date: Mon, 10 Jun 2019 19:30:16 -0700 Subject: [PATCH] Add recommendation to use kms provider (#13264) * Add recommendation to use kms provider Add a warning to encrypting secrets documentation that if using a provider with secrets encryption, kms provider is preferred as it materially changes the threat model. * Update encrypt-data.md * Update encrypt-data.md Updated to include kms provider is Beta sice 1.12 * Update encrypt-data.md --- .../en/docs/tasks/administer-cluster/encrypt-data.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index 8605ec7885..988c5b630e 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -92,6 +92,16 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider is the first provider, the first key is used for encryption. +__Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption. +Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which +provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key. +Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise. +Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and +extract the encryption keys. This was a stepping stone in development to the `kms` provider, introduced in 1.10, and beta since 1.12. Envelope encryption +creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the +kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than +locally-stored encryption keys. + ## Encrypting your data Create a new encryption config file: