技术分享|深入了解 Kubernetes Pod 安全标准
发布时间:
2024-03-29 19:26
1、特权(Privileged):提供完全不受限制的策略。
2、基线(Baseline):提供最小限制的保护,同时防止已知的权限升级。
3、限制(Restricted):遵循当前的 Pod 加固最佳实践,但可能会限制兼容性。
遵循这些标准有助于确保容器化应用程序在 Kubernetes 环境中满足行业标准的安全要求。为此,Kubernetes提供了一个内置的Pod安全控制器,用于检查 Pod 的隔离级别是否符合这些Pod安全标准。
01 使用 Pod 安全准入控制器
一旦我们启用了 Pod 安全准入控制器并安装了 Webhook,我们就可以在我们的命名空间中配置准入控制模式。
1、强制(Enforce):拒绝违反策略的Pod。
2、审计(Audit):允许存在策略违规的Pod,但在审计日志中记录违规行为。
3、警告(Warn):允许存在策略违规的Pod,并向用户发出警告。
4、配置Pod安全控制器涉及两个标签:
5、级别(Level):特权、基线或受限。
6、模式(Mode):强制、审计或警告。
同样,我们可以在任何命名空间上设置多个安全检查。我们还可以指定版本,并针对与特定 Kubernetes小版本一起提供的策略进行检查。例如,如果我们想知道命名空间“my-namespace”是否不符合Pod安全标准的最新基线版本,我们可以设置如下警告:
如果我们想强制执行“基线”级别的安全性,但希望在日志中收到通知以审计安全,以确定是否可以符合限制级别标准,我们可以进行如下设置:
02 使用特权安全配置文件
特权安全配置文件提供了管理敏感工作负载所需的无限制权限,以及在关键系统中执行复杂任务的灵活性。然而,由于特权安全配置文件允许已知的特权升级,因此应该仅在受信任的用户执行关键基础设施工作负载的有限用例中使用它。在使用特权安全配置文件时,重要的是包括Pod安全审批控制器的限制级警告和审计模式,以及实施其他最佳实践,如多因素身份验证(MFA),以减轻授予广泛权限的潜在风险。
03 使用基线安全配置文件
基线安全配置文件适用于非关键应用程序的应用程序操作者和开发人员,他们希望在保护环境的同时不使其过于复杂。基线策略允许用户管理典型的容器化工作负载,同时防止已知的特权升级。基线安全配置文件为具有标准工作负载的组织提供了灵活性,而无需额外的配置措施。重要的是,基线安全配置文件故意设计为涵盖广泛的工作负载,因此可能对于任何特定用例都包含不必要的限制。针对特定用例配置应用程序特定的控制措施可能是必要的。
04 使用受限安全配置文件
受限安全配置文件是最安全的选择,因为它遵循了当前的Pod加固最佳实践。受限安全配置文件强制执行沙箱化、限制用户帐户和控制网络权限等最佳实践,以帮助防止特权升级或其他恶意活动。该策略为处理易受攻击工作负载的组织提供了更大的透明度,并通过减少核心功能之外的不必要的应用程序特性以及采用高级威胁缓解功能等多种方式实现增加的安全性保护。
总结
Kubernetes Pod安全标准帮助开发人员在Kubernetes环境中保持其容器化应用程序的安全性。三种安全配置文件——特权、基线、受限,提供了从完全开放到严格限制的安全性选项。通过遵循这些标准并结合Pod安全准入控制器,客户织可以确保其容器化工作负载在安全性方面符合最佳实践,并降低受到恶意攻击的风险。