Kubernetes是一种宝贵的资源,也是全球开发流程中领先的容器管理系统,但它也不能免受恶意攻击。使用 Kubernetes 需要深入了解 Kubernetes 环境,包括在集群中创建、部署或运行应用程序时可能遇到的不同漏洞。
由于您的 Kubernetes 集群可能是最有价值的云资源之一,因此需要对其进行保护。Kubernetes 的安全性解决了云、应用程序集群、容器、应用程序和代码的安全问题。尽管 Kubernetes 提供了固有的安全优势,但加强防御策略对于保护您的系统免受黑客和其他网络安全威胁至关重要。
本综述涵盖了您的集群可能受到攻击的前6种方式,并为每种方式提供了相应的对策。
由于 Kubernetes 集群的分布式、动态特性,您需要实施在整个容器生命周期中遵循最佳安全实践的防御策略。
虽然 Kubernetes 在整个应用程序生命周期(构建、部署和运行时)中存在一些安全问题,但一些最关键的安全问题包括:
虽然 Kubernetes 默认启用一些基本的安全措施,但开发人员必须探索最佳安全实践以确保集群的安全。
本文中的防御策略是根据防止 Kubernetes 黑客攻击的行业标准最佳实践选择的。其中包括几位专家的评论,解释这些策略如何以及为何有助于保护 Kubernetes 工作负载并降低云环境风险。
虽然基于属性的访问控制 (ABAC) 是一种很好的访问控制方法,但理解和管理起来很复杂。除了其复杂性之外,ABAC还根据用户属性(例如主体属性、资源属性和环境属性)向用户授予访问权限。ABAC 允许用户在集群范围内执行任何他们想做的事情:在集群中创建资源、查看机密、删除代码等等。它不能确保最大程度的保护,并且可能会产生灾难性后果。
Kubernetes 于 2017 年 3 月 28 日宣布发布Kubernetes 1.6 ,并表示“基于角色的访问控制 (RBAC)、 kubefed、 kubeadm和其他调度功能正在进入测试版。” 将 RBAC 转至测试版是本次公告的一大亮点。Control Plane联合创始人、 Hacking Kubernetes合著者 Andrew Grant在一篇 文章中指出,ABAC 自 1.6 版本以来已被 RBAC 取代,并且不应该在 API 服务器上使用。
根据 Grant 的说法,禁用 ABAC 并以最小权限启用 RBAC 可以提供强大的保护,防止遭到黑客攻击。与 ABAC 不同,RBAC 根据用户的角色向用户授予访问权限。例如,虽然 DevOps 团队可能有权访问编程文件,但项目管理团队将有权访问所有项目文件。这是 RBAC 所做的一个示例——根据用户的功能启用权限。
您可以通过使用以下标志启动 kube-apiserver 来启用 RBAC --authorization-mode:
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
有关 RBAC 的更多详细信息,请参阅Kubernetes 文档和 Kubernetes API 访问强化。
防止集群被黑客攻击的另一种方法是确保监控日志并定期审核它们是否存在可疑活动,例如异常或不需要的 API 调用,尤其是身份验证失败。Armo 产品副总裁Amir Kaushansky 指出,尽管审计日志记录有助于分析和识别一段时间内的趋势,但组织最常使用它来监控 Kubernetes 集群性能和加强安全性。
例如,如果日志条目显示诸如“禁止”之类的消息状态(未经集群管理员授权),则可能意味着攻击者正在尝试使用被盗的凭据。Kubernetes 用户可以在控制台中访问这些数据,并设置授权失败通知。
审核日志记录支持可定制的事件日志记录。您可以设置四个 API 日志记录级别之一:
注意:将这些日志保留在集群内会带来安全威胁,因为任何集群的某个扇区的泄露都可能为黑客提供存储在该集群中的日志,并危及集群的整体安全。任何敏感日志都应传输到集群外部以降低风险。
要启用审核日志记录,您需要--audit-policy-file在启动 kube-apiserver 时使用该标志。策略文件包含规定将记录什么内容的规则。以下是策略模板文件示例:
apiVersion: audit.k8s.io/v1
kind: Policy
# Ignore all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
resources: ["pods"]
保护 Kubernetes 免受恶意行为者侵害的最佳安全实践之一是定期轮换加密密钥和证书。默认情况下,这些证书的有效期为一年,因此您无需频繁续订。但是,您也可以将它们自定义为更适合您的时间。
Kubernetes 支持加密密钥和证书轮换,以便在当前证书即将到期时自动生成新密钥并从 API 服务器请求新证书。新证书可用后,它将验证与 Kubernetes API 的连接。此过程可确保用户无需频繁轮换密钥和证书,从而节省时间。
此外,务必始终使用经过严格审查的备份加密解决方案来加密您的备份,并在可能的情况下考虑使用全磁盘加密。
定期轮换加密密钥和证书可以限制密钥泄露时造成的损害。值得庆幸的是,Kubernetes 更改密钥和证书的自动化过程消除了人为故障的可能性:敏感密钥泄漏。
虽然看起来很简单,但保持 Kubernetes 保持最新是确保集群免受攻击的绝佳方法。要了解当前版本的安全性,您可以在此CVE 列表中找到 Kubernetes 漏洞列表https://www.cvedetails.com/vulnerability-list/vendor_id-15867/product_id-34016/Kubernetes-Kubernetes.html
。
对于使用 AWS EKS 等托管提供商的开发人员,请检查您的供应商是否自动更新您的 Kubernetes 版本。
进程白名单有助于识别意外运行的进程。
使用进程白名单保护 Kubernetes 的第一步是观察和识别应用程序正常运行时运行的每个进程。接下来,使用此列表作为白名单来检查未来应用程序行为中是否存在任何异常情况。
如果黑客设法访问您的集群并运行有害进程,白名单可以帮助您快速识别并标记此类违规行为。
以 root 用户身份运行容器会让您面临安全漏洞。正如技术专栏作家 Raquel Campuzano Godoy在 Bitnami 上所说的那样,“任何访问正在运行的容器的人都root可以在其中启动不需要的进程,例如注入恶意代码”。以 root 用户身份运行 docker 容器也会使您的应用程序容易受到攻击,因为它允许用户在启动容器时更改用户 ID 或组 ID。
root从到重新配置您的容器为non-root可提供额外的保护层,确保您免受黑客攻击。Bitnami 的 GitHub 存储库上提供了一系列标记为non-root镜像容器。
要将容器作为 运行non-root,您需要设置该securitycontext字段以准确指定容器应具有的权限。在这种情况下,您需要设置securitycontext.runAsUser并securityContext.runAsGroup
以非 root 用户身份运行容器。
虽然许多 DevOps 团队启用了 Kubernetes 附带的默认安全措施,但这些措施不足以保护集群免受攻击。警惕的 DevOps 团队需要采取更多措施来建立必要的隔离墙,以阻止黑客渗透其系统。、