广告

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

  • 浏览(89)
  • 评论(0)
  • 译者:k8s

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

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

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

虽然DevOps团队通常负责集群的设置和维护,但我们也不能忽视应用程序开发人员所扮演的角色,这些开发人员可能对Kubernetes没有很好的了解。一旦集群建立并准备就绪,有时正是开发人员容器化和部署应用程序导致了pod和容器级别的错误配置。因此,虽然我们无法涵盖本文中的所有配置,但笔者想介绍一些团队从集群部署开始就可以制定的初始策略,这些策略将大大提高安全状况。通过在集群设置后实施这六个解决方案,团队可以大大提高安全性。

1.etcd安全

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

在保护etcd安全时,需要检查三件事:

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

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

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

2.网络策略

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

为了防止这种情况发生,应制定网络策略。在网络和传输层,可以使用Weave NetKube-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身份运行的镜像。我们可以将runAsNonRoottruesecurityContext条目添加到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 DirectoryOkta等)管理普通用户帐户。Teleport这样的开源应用程序通过短期的kubeconfig文件(和证书)单点登录提供对Kubernetes集群的安全访问。此外,Teleport还提供了其他工具,如内置RBAC系统和kubectl事件的审核和会话记录,不仅适用于集群,还适用于一个图形用户界面中的数十、数百、数千个集群。可以设置角色和策略,让用户轻松安全地访问集群。事实上,用户从不直接访问集群,集群可以隔离在专用网络或防火墙后面。直接交互仅与Teleport的代理服务进行。

结论

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

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头