当今，企业在加速应用现代化的同时，往往将 Kubernetes 安全置于次要地位。尽管这样的风险越来越高，但我们仍需谨慎对待那些能够缓解容器化环境威胁的安全策略。
一方面，安全措施必须足够精准，才能满足严格的合规要求，并通过审计这一关。组织必须遵守的各种法规包括 SOC 2、PCI DSS、GPDR、HIPAA 等等。与此同时，无论采用哪种安全流程，都要确保 DevOps 和开发人员的生产力不会受到影响。这是一种微妙的平衡法，容错率极低。
为了确保在容器化环境中持续合规，而不影响生产力，请遵循以下 6 个实践。
1. 实现自动化
市面上有许多出色的、完全开源的工具可供选择，合适的工具能够帮助企业实现实时威胁响应和持续在线监控，从而确保持续合规。例如，企业应将自动化漏洞扫描和安全策略即代码集成到流水线中。通过自动化 Kubernetes 审计日志分析工具处理日志和事件。基于机器学习的 SIEM 技术能够快速自动识别攻击模式。企业还应利用 CIS 基准和自定义合规核查来持续检查 Kubernetes 配置。
2. 对 Kubernetes 本身进行保护
将 Kubernetes 本身视为攻击面至关重要，因为攻击者一定会这样做。威胁越来越复杂，企业需要主动保护容器环境背后的全栈，以实现持续合规。保护措施包括：启用自动监控、强化反攻击手段、执行配置审计以及准备自动化缓解。除了 Kubernetes，企业对任何可能受到攻击的服务网格、托管 VM、插件或其他目标也应采取相同措施。
3. 发现攻击就能防止攻击
攻击杀伤的链条通常从启动无法识别的容器网络连接或进程开始，通过写入或更改现有文件，或者利用未受到保护的入口点，来提升其访问级别。然后，此类恶意手段会利用网络流量，将捕获到的数据发送到外部 IP 地址，造成数据泄露。杀伤链可能会以类似的方式将 Kubernetes API 服务作为中间人攻击的目标，通常会发起零日攻击、内部攻击和加密货币挖矿攻击。利用 Apache Log4j 进行的攻击也日益增多。
数据丢失防护 (DLP) 和 Web 应用程序防火墙 (WAF) 相结合的策略能够提供检测活跃杀伤链所需的可见性以及自动响应能力，在可疑的进程和流量造成破坏之前将其终止。事实上，目前许多法规的合规框架都专门要求组织具备 DLP 和 WAF 能力，以保护其容器和 Kubernetes 环境，这些框架包括 PCI DSS、SOC 2 和 GDPR。（HIPAA 也强烈建议采用 DLP。）
4. 专注于零信任
通过实施零信任模型，企业不再被动地处理在日志分析或基于签名的检测中发现的威胁。零信任策略只允许经过批准的进程和流量在企业环境中活动，从而阻止所有攻击。整个云原生技术栈，以及 RBAC 等访问控制，都必须采取这些零信任防护措施。这样一来，企业就确保能够实现持续合规。
5. 利用Kubernetes 内置安全措施
Kubernetes 内置的安全功能包括日志审计、RBAC 以及由 Kubernetes API 服务器集中进行的系统日志收集。利用这些功能来收集并分析所有活动日志，从而识别攻击或错误配置。然后，通过安全补丁或者基于策略的新防护措施，来解决各种事件或不合规的运行时活动。
在大多数情况下，企业会希望进一步通过能够实现容器应用程序安全和持续合规审计的工具来支持现有的 Kubernetes 安全措施。企业应使用内置的 Kubernetes 准入控制器，紧密协调 Kubernetes 与外部注册请求和资源请求。这种方法可以更有效地防止应用程序部署中的漏洞和未经授权的行为。
6. 验证云主机的安全性
托管 Kubernetes 的云平台能够把控自己的系统，必须确保其持续合规。然而，如果不检查这些云托管实践是否真正得到了充分保护，是否履行了企业自身的合规责任，那风险就太高了。事实上，许多云提供商所提供的责任共担模式会将保护应用程序访问权限、网络行为和云上其他资产的重任直接留给客户。
实时环境中的持续合规
Kubernetes 和容器化环境极其活跃，容器创建和删除的速度之快，让手动安全检查无法对其进行保护。此外，许多合规法规要求的传统安全技术，例如，网络分段和防火墙，在容器网络中不起作用。
在构建、迁移和在生产环境中运行应用程序时，现代的持续开发流程会定期引入新的代码和容器。因此，法规要求组织采用自动化实时安全防护和审计措施，以实现真正的持续合规。
