在 Kubernetes 中，Pod 是应用程序运行的最小单位。但是，如果 Pod 可以访问主机节点（Host Node）上的重要信息或影响其他 Pod，那将是一个巨大的安全威胁，对吗？ 💣
为了防止这些威胁，Kubernetes 定义了Pod 安全标准，强制 Pod 在创建时满足特定的安全要求。这有助于提高整个集群的安全级别。
Pod 安全标准的三个级别 🛡️
Pod 安全标准分为三个级别。每个级别允许的权限范围不同，其中privileged最宽松，restricted最严格。
- Privileged (特权): 这是最宽松的策略。它允许所有已知的权限提升，并且可以运行几乎所有 Pod。仅在特殊情况下使用，例如管理系统级工作负载。
- Baseline (基线): 这是中等程度的策略。它防止已知的权限提升，并推荐用于大多数常见的应用程序。可以将其视为一个合理默认值，它既严格又不过于限制。✅
- Restricted (受限): 这是最严格的策略。它遵循 Pod 强化（hardening）的最佳实践，适用于对安全性要求极高的工作负载。使用此级别可能会导致某些应用程序无法正常运行，因此在应用前需要进行充分的测试。🔒
应用于集群和命名空间 🚀
Pod 安全标准可以应用于整个集群，也可以选择性地应用于特定命名空间。
在命名空间级别应用
如果您只想将 Pod 安全标准应用于特定命名空间，可以使用命名空间的
标签(label)
。这真的非常简单！
例如，如果您想将 baseline 策略应用于名为 my-namespace 的命名空间，请运行以下命令：
kubectl label --overwrite ns my-namespace pod-security.kubernetes.io/enforce=baseline通过设置此标签，在 my-namespace 中创建的所有 Pod 都必须通过 baseline 策略。如果尝试创建违反策略的 Pod，API 服务器将拒绝其创建。🙅♀️
命名空间标签可以有以下三种模式（mode）：
- enforce: 阻止创建违反策略的 Pod。
- audit: 当创建违反策略的 Pod 时，留下警告日志。（允许创建）
- warn: 当创建违反策略的 Pod 时，向用户显示警告消息。（允许创建）
例如，您可以将 enforce 设置为 baseline，将 warn 设置为 restricted，从而逐步提高安全级别。
kubectl label --overwrite ns my-namespace pod-security.kubernetes.io/enforce=baseline pod-security.kubernetes.io/warn=restricted###
在集群级别应用
如果您想在整个集群中默认应用 Pod 安全标准，则需要修改 Admission Controller 设置。这主要是在首次设置或管理集群时使用的方法。
在 PodSecurity 准入控制器（Admission Controller）的配置文件中，您可以定义要在整个集群中应用的默认策略，如下所示：
# admission-configuration.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.k8s.io/v1beta1
kind: PodSecurityConfiguration
defaults:
enforce: "baseline"
enforce-version: "latest"
audit: "restricted"
audit-version: "latest"
warn: "restricted"
warn-version: "latest"
exemptions:
# 系统命名空间从策略中豁免
namespaces: ["kube-system"]此配置默认在集群的所有命名空间中强制执行 baseline 策略，并在违反 restricted 策略时显示警告。通常，像 kube-system 这样运行 Kubernetes 系统组件的命名空间会从策略执行中豁免（exemption）。
总结 ✨
至此，我们已经了解了如何在 Kubernetes 集群和命名空间级别应用 Pod 安全标准。请根据您的应用程序特性和安全要求，选择合适的策略级别和模式，以进一步保护您的集群！ 🛡️
Kubernetes 安全，并不难！ 😉
发表回复