管理Kubernetes容器工作负载的安全性

这是题为《Securing Kubernetes for Cloud Native Applications》系列文章的最后一篇，这个系列文章中，我们讨论了构成Kubernetes集群每个层的安全性方面的内容。在终结篇中，我们将讨论容器工作负载本身的安全性。我们如何确保容器内容的完整性？我们如何知道容器内部实际上是什么？让我们从Secrets（秘钥）开始。
保护Secrets

通常，在Kubernetes集群上运行的云原生应用程序需要访问敏感信息，并且需要提供Secrets以响应来自托管该信息的系统的查询。Secrets可以是任何东西，但通常是密码，X.509证书，SSH密钥或OAuth令牌。我们可能想要采用简单的路径并将Secrets存储在容器的镜像中，以便在需要时可以随时使用它。然而，如果我们这样做，它可能会“泪流满面"。撇开这种方法的脆弱性，更重要的是，将Secrets暴露给不应该暴露的实体的可能性将是巨大的。镜像定义通常需要向广大受众提供，并且经常由源代码控制系统管理，这可能潜在地导致Secrets的无意暴露。有一个被广泛接受的格言，Secrets应始终保持在容器镜像之外。这也遵循将容器配置保留在容器之外的Twelve-Factor App方法，允许我们为不同的目标环境使用不同的Secrets，同时为每个环境使用相同的容器镜像。
这引出了一个问题：我们如何为在Kubernetes集群中运行的容器化应用程序提供Secrets？ 由于它们的敏感性，Kubernetes提供了一个专用的API资源对象来处理Secrets，称为（不出所料）Secret。然后，可以在需要访问它们的Pod的Spec中引用封装在Secret对象中的秘密数据：最好是通过卷装入，而不是通过环境变量。
重要的是要确保对Secret的访问严格限于那些需要使用它的实体（用户和Pod），它不是通过网络未加密传输的，并且当存储在磁盘上时（静止状态）它是不可访问或可读的。 在之前的文章中，我们了解了如何使用身份验证和授权（RBAC）控制对API对象（如Secrets）的访问，以及使用TLS加密集群组件之间的通信的需求。这满足了其中两个原则，包括配置节点授权和kubelet通过API访问Secret的场景，但是需要确保Secret在静止状态时无法访问或可读。