请保护好这6个被忽视但重要的Kubernetes功能

如果你用过Kubernetes，你就会知道，对于许多人来说，它相当复杂。所有移动部件、网络以及只是让集群正常启动和运行，并非易事。这里所说的“正常”是指安全的，有安全通信、适当的网络隔离、保护秘密等。

不幸的是，仅仅启动并运行集群是不够的。默认情况下，Kubernetes并不安全。它需要进一步调整，不仅要确保集群的高安全性，还要确保pod和容器的安全性。

红帽发布的《2022年Kubernetes安全报告》对300名DevOps工程师和安全专家进行了民意调查，据报道，受访者“最担心容器和Kubernetes环境中的错误配置导致的暴露（46%），几乎是对攻击的三倍（16%），而漏洞是第二大担心原因（28%）。”正确配置重要配置，如基于角色的访问控制（RBAC）和安全上下文，对集群的安全态势至关重要。DevOps团队需要全面考虑许多因素，以及在自己独特情况的范围内的事情。

虽然DevOps团队通常负责集群的设置和维护，但我们也不能忽视应用程序开发人员所扮演的角色，这些开发人员可能对Kubernetes没有很好的了解。一旦集群建立并准备就绪，有时正是开发人员容器化和部署应用程序导致了pod和容器级别的错误配置。

因此，虽然我们无法涵盖本文中的所有配置，但笔者想介绍一些团队从集群部署开始就可以制定的初始策略，这些策略将大大提高安全状况。通过在集群设置后实施这六个解决方案，团队可以大大提高安全性。

1.etcd安全

保护etcd对Kubernetes安全至关重要。所有集群数据，包括秘密，都保存在这个高度可用的键值存储中。获得对etcd的读写访问权基本上就是获得钥匙。因此，你需要从一开始就为这个重要的后端规划保护。应该注意的是，Kubernetes-as-a-Service（EKS、AKS等）的一个好处是，此安全措施是托管的。

在保护etcd安全时，需要检查三件事：

——加密静态数据。默认情况下，etcd数据不加密。需要创建一个EncryptionConfiguration对象，以便etcd数据在静止时加密。还支持并建议与第三方密钥管理服务协作进行此加密的密钥轮换。

——限制访问。建议分离etcd服务器并隔离在防火墙后面。从那里，只允许从API服务器访问。不应允许集群中的其他组件直接访问它。

——确保API服务器正在使用TLS。

2.网络策略

如果集群层在某个点被突破了怎么办？我们希望尽可能少的水平渗透，对吗？默认情况下，Kubernetes允许所有pod-to-pod流量。允许pod之间的所有入站和出站连接。如果攻击者进入一个pod，他们可以不受阻碍地移动到其他pod。

为了防止这种情况发生，应制定网络策略。在网络和传输层，可以使用Weave Net或Kube-router等网络插件通过命名空间和标签限制不必要的pod-to-pod访问。更好的是，可以通过像Istio这样的服务网格在应用层控制pod流量。

举一个简单的例子，如果我们有一个带有前端、后端和数据库的应用程序，那么理想情况下不应该允许前端直接与数据库对话，也不应该允许数据库与前端对话。相反，应该只允许前端与后端对话，然后，后端与数据库对话。如果攻击者访问前端应用程序，他们将无法在不经过后端的情况下直接接触数据库。

3.pod间通信

除了开放网络之外，默认情况下，pod-to-pod通信是不加密的。这意味着任何能够渗透集群的人都可以用纯文本收听通信。同样，引入像Istio这样的服务网格，可以通过将其配置设置为STRICT模式，禁止纯文本，从而在服务之间实施相互TLS。这可以局限于命名空间或整个网格，具体取决于用例。

4.秘密

应在早期制定保护秘密的解决方案。然而，通常情况并非如此。事实上，由于建立Kubernetes集群和运行应用程序的复杂性，秘密管理在许多情况下都被搁置一边，直到完成更重要的任务。

问题是，Kubernetes虽然为我们提供了一个秘密框架，但在保护它们方面帮不了多少忙。默认情况下，它们仅采用Base64编码，可以轻松转换为纯文本。当写入etcd时，此框架可以在静止状态下对秘密进行加密；当它与适当的RBAC限制和严格的etcd安全性相结合时，它可以变得更安全。然而，这对于生产环境来说仍然不理想。

因此，团队越早解决秘密管理的问题，安全状况就会越好。大多数团队最好使用第三方解决方案，无论是AWS Secrets Manager之类的云解决方案，还是HashiCorp Vault之类的开源工具。这些将为重要的Kubernetes秘密管理提供一个更加强大和安全的系统。

5.pod级安全/dirty YAML

同样的尽职调查需要在应用程序级别应用。如前所述，有些应用程序开发人员会在不了解Kubernetes集群的内部工作原理或理想设置的情况下，将其应用程序打包并部署。公共存储库或公共Docker镜像中的Helm图表可能包含根级访问或其他可能削弱安全性的潜在关键配置。

因此，审核进入生态系统的YAML配置和容器非常重要。无论是由安全团队手动执行，还是通过更自动化的方法（如漏洞扫描）执行，这都有助于在潜在漏洞出现之前捕获它们。

此外，我们应该在pod或容器级别使用Kubernetes安全上下文来阻止任何以root身份运行的镜像。我们可以将runAsNonRoot为true的securityContext条目添加到YAML中，Kubelet将拒绝启动默认为root用户的任何镜像。当然，退一步来看，应该为镜像分配一个用户和组UID，但如果没有，添加此安全上下文将添加另一层防御。

6.Kubernetes访问

最后，让我们讨论一下通过API服务器的访问本身。从技术上讲，使用有效证书访问API服务器的任何用户都被视为已通过身份验证。鉴于这一事实，这里有一些建议：

首先，在大多数情况下，应该通过为API服务器设置--anonymous auth=false来禁用匿名身份验证。应设置RBAC以处理特定用户。然而，如果必须使用匿名身份验证，RBAC应该大大限制匿名用户的操作。

其次，默认情况下，API服务器侦听两个端口：一个是安全端口，另一个是不安全的“localhost”端口。你应该通过将--insecure-port标志设置为“0”并确保未设置--insecure bind address来禁用不安全端口。这个不安全的端口实际上会绕过身份验证和授权检查，恶意用户可能会通过它访问主服务器。

接下来，应建立一个安全且维护良好的RBAC系统，并随时到位。

最后，管理员应该考虑通过OpenID Connect使用公司解决方案（如Active Directory、Okta等）管理普通用户帐户。

像Teleport这样的开源应用程序通过短期的kubeconfig文件（和证书）单点登录提供对Kubernetes集群的安全访问。此外，Teleport还提供了其他工具，如内置RBAC系统和kubectl事件的审核和会话记录，不仅适用于集群，还适用于一个图形用户界面中的数十、数百、数千个集群。可以设置角色和策略，让用户轻松安全地访问集群。事实上，用户从不直接访问集群，集群可以隔离在专用网络或防火墙后面。直接交互仅与Teleport的代理服务进行。

结论

如果你正在启用一个新集群，请记住，默认情况下它并不太安全。你需要做一些工作来进一步保护它。从一开始就实施上述六种策略来保护Kubernetes集群的这些功能，将有助于大大提高集群的安全性和应用程序的整体成功性。