SUSE：Kubernetes 安全防护终极指南（2022）（36页）.pdf

1、终极指南如何保护 Kubernetes 流水线Kubernetes 安全防护终极指南如何保护 Kubernetes 流水线Kubernetes 安全防护目录保护容器部署安全的重要意义.3Kubernetes 的运行机制.6Kubernetes 漏洞和攻击载体.9保护整个流水线.12CI/CD 生产线安全防护.13Kubernetes 节点生产准备.14Kubernetes 运行时容器安全防护.15Kubernetes 系统和资源安全防护.18Kubernetes 环境的审核与合规安全态势.20应用的运行时安全防护NEUVECTOR 容器安全平台.22Kubernetes 安全防护自动化这可能吗

2、？.28满足 PCI、GDPR、SOC 2、HIPAA、NIST 合规性要求.30开源 Kubernetes 安全防护工具.32运行时 Kubernetes 安全防护检查清单.342保护容器部署安全的重要意义借助容器和 Kubernetes 等工具，企业能够在应用程序部署的诸多方面实现自动化，继而获得巨大的业务收益。但这些新的部署环境与传统环境一样，容易受到黑客和内部攻击者的攻击和利用。私有云和公有云中基于容器的新型虚拟化环境仍会受到勒索软件、非法加密挖矿、数据窃取和服务中断等形式的攻击。更麻烦的是，公有云中的 Kubernetes 等新型工具和技术以及托管容器服务本身就将为攻击企业的重要资产

3、提供可乘之机。继近期 Kubernetes 的中间人漏洞和 Tesla 漏洞事件之后，许多攻击者都蠢蠢欲动，等待时机针对容器技术发起攻击，预计这类事件将在未来几个月乃至多年内频繁发生。容器高度动态化的特征带来了下列安全挑战：1.CI/CD 流水线引入的漏洞。开源组件的大量运用和不断涌现的严重漏洞都会在构建阶段、注册表和生产过程中对容器镜像产生影响。2.东西向流量激增。虽然可以通过传统的防火墙和主机安全防护工具来保护单片应用程序，但容器可能使东西向流量或内部流量持续增加，因此必须对这些流量进行攻击监控。33.攻击面扩大。每个容器中都含有可能被利用的不同攻击面和漏洞。此外，还必须将 Kuberne

4、tes 和 Docker 等编排工具引入的其他攻击面考虑在内。4.自动化安全防护才能满足发展需要。以往的安全防护模型和工具无法应对不断变化的容器环境。考虑到 Kubernetes 自动化的性质，容器和 Pod 从出现到消失可能只有几分钟甚至几秒的时间。可能包含新网络连接的应用程序行为必须即时纳入强制安全策略中。我们需要通过新一代自动化安全工具来保护容器安全，在流水线前期声明安全策略，并通过代码形式进行管理。KUBERNETES 团队的安全防护能力自查：团队是否具备能在流水线前期甚至构建阶段消除重大漏洞（具有可用修补程序）的相关流程？团队对正在部署的 Kubernetes Pod 是否具有可见性

5、？例如，是否了解应用程序 Pod 或集群之间如何通信？团队能否从容器间的东西向流量中检测出恶意行为？团队能否确定每个 Pod 的行为正常与否？当内部服务 Pod 或容器开始在内部扫描端口或尝试随机连接外部网络时，团队如何接收警报？有些人提出，由于功能和专用接口有限，默认情况下容器比传统应用程序更安全，但这种观点仅在以下情况中成立：网络攻击者和公共部门攻击者使用旧有手段攻击没有漏洞且已锁定所有潜在威胁载体的代码和基础设施。但我们清楚，这在现实中是不可能的。而且即便如此，也仍然需要实时对攻击进行监控。攻击事件屡次发生，时间和经验都表明，攻击者的手段总是能够击破乃至超越新的基础设施策略。恶意攻击者将

6、不断开发全新手段来攻击容器。4 团队如何确定攻击者是否已经在容器、Pod 或主机中找到了切入点？团队能否像对于非容器化部署一样全面查看和检查网络连接？例如 7 层网络？如果面临潜在攻击，团队能否监控 Pod 或容器内部的活动情况？团队是否曾通过检查 Kubernetes 集群的访问权限来确定潜在的内部攻击载体？团队是否拥有锁定 Kubernetes 服务、访问控制(RBAC)和容器主机的检查清单？如果具备合规策略，如何在运行时执行以确保合规性？例如，确保内部 Pod 通信加密，当 Pod 未使用加密通道时团队将如何得知？在对应用程序通信进行故障排除或记录取证数据时，如何定位相关 Pod 并抓取