Kubernetes EncryptionConfiguration中的`identity'提供者提供什么样的安全性?

问题描述

参考:https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers

根据文档

按原样编写的资源未加密。设置为第一个提供程序时,将在写入新值时对资源进行解密。

When set as the first provider,the resource will be decrypted as new values are written.听起来令人困惑。如果将资源按原样写入而未对etcd进行加密,那么decrypted as new values are written的含义是什么?

然后是

认情况下,身份提供者用于保护etcd中的机密,但不提供加密。

如果没有进行加密,identity提供者会提供什么样的安全性?如果进行加密,那是什么类型的加密?

解决方法

etcd关于security

所述

etcd是否加密磁盘驱动器上存储的数据?

不。 etcd不会加密存储在磁盘驱动器上的键/值数据。如果用户需要加密存储在etcd上的数据,则有一些选项:

  • 让客户端应用程序对数据进行加密和解密
  • 使用基础存储系统的功能来加密dm-crypt之类的存储数据

问题的第一部分:

默认情况下,identity provider用于保护etcd中的机密,但不提供加密。 这意味着默认情况下,k8s api在将机密存储在identity provider时使用etcd,并且不提供任何加密。

EncryptionConfiguration与唯一的提供者一起使用:identity的结果与根本不使用EncryptionConfiguration的结果相同(假设您根本没有任何加密机密)。 所有机密数据将以纯文本格式存储在etcd中。

示例:

    providers:
    - identity: {}

问题的第二部分:

按原样编写的资源未加密。 问题的第一部分对此进行了描述和解释

设置为第一个提供程序时,将在写入新值时解密资源。

看看这个例子:

    providers:
    - aescbc:
        keys:
        - name: key1
          secret: <BASE 64 ENCODED SECRET>
    - identity: {}

此配置对您意味着什么:

  • 您的EncryptionConfiguration中引入的新提供程序不会影响现有数据。
  • secrets中所有现有的etcd(在应用此配置之前)仍为纯文本。
  • 从此配置开始,将使用secrets加密保存所有新的aescbcsecrets中所有新的etcd都将带有前缀k8s:enc:aescbc:v1:key1
  • 在这种情况下,您将在etcd中混合使用加密数据和未加密数据。

所以问题是为什么我们要使用这两个提供程序?

  • 提供者:aescbc用于在写操作期间将新的secrets作为加密数据写入,并在读操作期间用于解密现有的secrets
  • 提供者:identity对于读取所有未加密的机密仍然是必需的。

现在我们要在EncryptionConfiguration中切换提供商:

    providers:
    - identity: {}
    - aescbc:
        keys:
        - name: key1
          secret: <BASE 64 ENCODED SECRET>
  • 在这种情况下,您将在etcd中混合使用加密数据和未加密数据。
  • 从此配置开始,所有新的secrets将以纯文本格式保存
  • 对于etcd中所有前缀为k8s:enc:aescbc:v1:key1 provider的现有机密,将使用aescbc配置来解密存储在etcd中的现有机密。

设置为第一个提供程序时,将在写入新值时解密资源

为了从mixture of encrypted and not encrypted data切换到只有“未加密”数据的情况,您应该对所有机密执行读/写操作:

$ kubectl get secrets --all-namespaces -o json | kubectl replace -f -

为什么它不提供加密,但是文档似乎在讨论解密及其保护方法。

如果混合使用加密数据和未加密数据,则必须使用identity的提供程序类型 或者您想解密由其他提供程序加密的所有现有secrets(存储在etcd中)。

以下命令读取所有机密,然后更新它们以应用服务器端加密。可以在this paragraph

中找到更多详细信息

$ kubectl get secrets --all-namespaces -o json | kubectl replace -f -

取决于您的EncryptionConfiguration,如果第一个提供者为secrets,则所有identity都将保存为未加密状态;如果第一个提供者为不同类型,则所有内容都将被加密。

另外

EncryptionConfig被禁用为默认设置。要使用它,您必须在--encryption-provider-config配置中添加kube-apiserverIdentity未加密任何数据,根据Encrypted Providers documentation,它具有3倍的N/A