minikube Pod Security Policy 插件实战：启用 PSP 准入控制器与 pod-security-policy Addon

minikube Pod Security Policy 插件实战启用 PSP 准入控制器与 pod-security-policy Addon【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube导读本文讲解如何在 minikube 中启用 Kubernetes 的 Pod Security PolicyPSPPod 安全策略核心方案是将PodSecurityPolicy准入控制器admission controller与pod-security-policyaddon 同时启用并围绕仓库中随包分发的 PSP 清单逐项解读privileged与restricted两套策略的字段含义与 RBAC 授权设计。读完本文你将掌握一条命令完成 PSP 加固集群的方法、底层 addon 的实现机制以及针对 minikube 1.5.2 ~ 1.11.1 等历史版本的手动落地流程能够根据实际需求选用合适的 PSP 部署路径。Overview什么是 PSP为什么要与 Admission Controller 搭配Pod Security Policy 是 Kubernetes 提供的一种集群级安全控制机制它定义了一组 Pod 必须满足的安全约束例如是否允许以特权模式运行、是否允许使用宿主机网络命名空间、以什么 UID 运行、允许挂载哪些卷类型等。当PodSecurityPolicy准入控制器开启后API Server 会在 Pod 创建及更新时按策略逐一校验拒绝不符合任何可用策略的 Pod。minikube 中启用 PSP 的关键在于两点必须同时满足准入控制器开启通过--extra-configapiserver.enable-admission-pluginsPodSecurityPolicy让 kube-apiserver 在调度前强制校验addon 提供策略pod-security-policyaddon 将 PSP 对象及配套的 RBAC 授权清单部署进集群否则准入控制器开启后没有任何可用策略集群内几乎所有组件包括引导组件都会因校验失败而无法启动。官方文档特别强调pod-security-policyaddon 必须与准入控制器同时启用以避免集群 bootstrap 期间出现问题。从源码看该 addon 在 minikube 中并不是默认启用的。在 pkg/minikube/assets/addons.go 中pod-security-policy通过NewAddon注册第二个参数为false非默认启用其清单资源来自嵌入的 deploy/addons/pod-security-policy/pod-security-policy.yaml会被拷贝到 guest 节点的 addons 目录vmpath.GuestAddonsDir即/etc/kubernetes/addons下pod-security-policy: NewAddon([]*BinAsset{ MustBinAsset(addons.PodSecurityPolicyAssets, pod-security-policy/pod-security-policy.yaml, vmpath.GuestAddonsDir, pod-security-policy.yaml, 0640), }, false, pod-security-policy, 3rd party (unknown), , , nil, nil, nil),其中PodSecurityPolicyAssets由 Go 的embed.FS在 deploy/addons/assets.go 中声明也就是说这份 YAML 是编译进 minikube 二进制的内置资产无需用户另行准备文件。前提条件minikube 版本不低于1.11.1且 Kubernetes 版本不低于1.16.x。需要能正常执行minikube start与kubectl命令的环境。若使用低于 1.11.1 的 minikube请直接跳至本文「历史版本兼容方案」一节按对应版本处理。快速开始一条命令启用 PSP在满足前提条件的 minikube 上执行如下命令一次性完成准入控制器与 addon 的启用minikube start --extra-configapiserver.enable-admission-pluginsPodSecurityPolicy --addonspod-security-policy命令拆解参数作用--extra-configapiserver.enable-admission-pluginsPodSecurityPolicy向 kube-apiserver 追加PodSecurityPolicy准入插件使集群具备策略校验能力--addonspod-security-policy在集群启动后自动应用pod-security-policyaddon 的清单启动完成后可以用以下命令确认 addon 与策略已生效minikube addons list | grep pod-security-policy kubectl get pspkubectl get psp应能看到privileged与restricted两个 PodSecurityPolicy 对象。随包分发的 PSP 清单逐项解读pod-security-policyaddon 实际应用的清单与官方文档中给出的 YAML 完全一致其完整内容见 deploy/addons/pod-security-policy/pod-security-policy.yaml。整个清单由两套 PSP 策略和配套的 RBAC 对象组成采用「默认受限、特定主体放行特权」的安全模型。策略一privileged特权策略--- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: privileged annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: * labels: addonmanager.kubernetes.io/mode: EnsureExists spec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - * volumes: - * hostNetwork: true hostPorts: - min: 0 max: 65535 hostIPC: true hostPID: true runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny fsGroup: rule: RunAsAnyprivileged策略在各项约束上全面放开privileged: true允许 Pod 以特权模式运行allowPrivilegeEscalation: true允许进程提权如设置setuid位、提升 capabilitiesallowedCapabilities: [*]允许任意 Linux capabilitiesvolumes: [*]允许挂载所有卷类型包括hostPathhostNetwork / hostIPC / hostPID: true允许使用宿主机网络、IPC 与 PID 命名空间hostPorts开放 0~65535 全端口段runAsUser / seLinux / supplementalGroups / fsGroup均使用RunAsAny不做 UID、SELinux 或组限制注解seccomp.security.alpha.kubernetes.io/allowedProfileNames: *允许使用任意 seccomp profile。这套策略主要服务于 kube-system 等需要访问宿主机资源的基础组件如网络插件、存储插件、kube-proxy。策略二restricted受限策略--- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted labels: addonmanager.kubernetes.io/mode: EnsureExists spec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: - ALL volumes: - configMap - emptyDir - projected - secret - downwardAPI - persistentVolumeClaim hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: MustRunAsNonRoot seLinux: rule: RunAsAny supplementalGroups: rule: MustRunAs ranges: # Forbid adding the root group. - min: 1 max: 65535 fsGroup: rule: MustRunAs ranges: # Forbid adding the root group. - min: 1 max: 65535 readOnlyRootFilesystem: falserestricted策略则收紧了绝大多数权限是普通工作负载的默认策略privileged: false禁止特权模式allowPrivilegeEscalation: false禁止提权requiredDropCapabilities: [ALL]强制丢弃全部 capabilities之后可按需通过allowedCapabilities重新添加此处未添加即最终没有任何 capabilityvolumes白名单仅允许configMap、emptyDir、projected、secret、downwardAPI、persistentVolumeClaim六种安全卷类型不允许hostPathhostNetwork / hostIPC / hostPID: false禁止使用宿主机命名空间runAsUser采用MustRunAsNonRoot强制以非 root 用户运行supplementalGroups与fsGroup采用MustRunAs并限定范围1 ~ 65535其注释明确指出「Forbid adding the root group禁止添加 root 组」即不允许将 GID 0root 组注入容器seLinux使用RunAsAnyreadOnlyRootFilesystem为false默认可写根文件系统便于一般应用运行。RBAC 授权策略如何被使用PSP 的生效必须配合 RBAC只有被授权对podsecuritypolicies资源执行use动词的实体其创建的 Pod 才会受到对应策略的约束。清单中为此定义了四类 RBAC 对象--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: psp:privileged labels: addonmanager.kubernetes.io/mode: EnsureExists rules: - apiGroups: [policy] resources: [podsecuritypolicies] verbs: [use] resourceNames: - privileged --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: psp:restricted labels: addonmanager.kubernetes.io/mode: EnsureExists rules: - apiGroups: [policy] resources: [podsecuritypolicies] verbs: [use] resourceNames: - restricted --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: default:restricted labels: addonmanager.kubernetes.io/mode: EnsureExists roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp:restricted subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: default:privileged namespace: kube-system labels: addonmanager.kubernetes.io/mode: EnsureExists roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: psp:privileged subjects: - kind: Group name: system:masters apiGroup: rbac.authorization.k8s.io - kind: Group name: system:nodes apiGroup: rbac.authorization.k8s.io - kind: Group name: system:serviceaccounts:kube-system apiGroup: rbac.authorization.k8s.io授权关系可以归纳为RBAC 对象类型作用域授权内容绑定主体psp:privilegedClusterRole集群use名为privileged的 PSPdefault:privilegedRoleBinding仅 kube-system 命名空间psp:restrictedClusterRole集群use名为restricted的 PSPdefault:restrictedClusterRoleBinding所有已认证用户default:restrictedClusterRoleBinding集群将psp:restricted授予system:authenticated组全体已认证主体default:privilegedRoleBindingkube-system命名空间将psp:privileged授予system:masters、system:nodes、system:serviceaccounts:kube-system集群管理员、节点与 kube-system 服务账号这种设计的核心思想是默认所有已认证用户只能使用受限策略restricted而只有集群管理组件masters、nodes、kube-system 服务账号才被放行使用特权策略privileged从而在保证集群自身组件正常引导的同时约束普通工作负载的安全边界。所有对象都带有addonmanager.kubernetes.io/mode: EnsureExists标签表明这些资源由 addon-manager 以确保存在的模式管理——对象存在即视为合规不会被 addon-manager 反复覆盖。Addon 的注册与启停机制从仓库源码可以进一步确认该 addon 的完整管理链路资源定义嵌入式资产 deploy/addons/pod-security-policy/pod-security-policy.yaml通过 deploy/addons/assets.go 中的PodSecurityPolicyAssets编译进二进制addon 注册在 pkg/minikube/assets/addons.go 中注册属于非默认启用、来源标注为 3rd party (unknown) 的插件配置项在 pkg/addons/config.go 中注册为布尔开关SetBool启停回调为EnableOrDisableAddon即通过minikube addons enable/disable pod-security-policy即可在运行中的集群上动态开关另外可以注意到pkg/minikube/assets/addons.go 中存在LegacyPodSecurityPolicy标记其判定条件是 Kubernetes 版本低于 1.25v.LT(semver.Version{Major: 1, Minor: 25})这是为了适配 PSP 在 1.25 之后被 Pod Security AdmissionPSA取代的历史兼容逻辑使用新版本 Kubernetes 时需留意 PSP API 的弃用状态。验证效果受限与放行启用 PSP 后可以用一个简单的实验验证策略是否真正生效创建一个普通命名空间非 kube-system下的 Deployment其镜像以 root 用户运行例如busybox默认以 root 启动kubectl create deployment psp-test --imagebusybox -- sleep 3600观察 Pod 状态。由于restricted策略要求MustRunAsNonRoot且禁止提权未配置非 root 用户与相应 UID 的 Pod 会被准入控制器拒绝kubectl get pods中会看到创建失败kubectl describe pod的错误信息会指明违反的 PSP 约束。而 kube-system 中的系统组件因被显式授权use privileged策略可以正常以特权方式运行这正是上述 RBAC 设计的目的所在。历史版本兼容方案pod-security-policyaddon 是较新版本 minikube 才内置的旧版本并不随包提供该 addon需要手动将策略清单应用到集群。官方文档针对不同版本区间给出了两套处理流程以下 YAML 均与 deploy/addons/pod-security-policy/pod-security-policy.yaml 内容一致可直接复制使用完整内容见上文随包分发的 PSP 清单逐项解读一节此处不再重复。minikube 1.5.2 ~ 1.6.2引导前预置清单在该版本区间minikube 会把~/.minikube/files/etc/kubernetes/addons目录下的文件在引导阶段拷贝进集群的/etc/kubernetes/addons因此需要在启动之前把 PSP 清单放置到位否则准入控制器开启后集群无法完成 bootstrap。第一步创建目录mkdir -p ~/.minikube/files/etc/kubernetes/addons第二步将上文完整的 PSP YAML 保存为~/.minikube/files/etc/kubernetes/addons/psp.yaml文件名需为psp.yaml。第三步启动 minikube此处只需开启准入控制器无需--addons参数minikube start --extra-configapiserver.enable-admission-pluginsPodSecurityPolicyminikube 1.6.2 ~ 1.11.1启动后手动应用并重启对于大于 1.6.2 且小于 1.11.1 的版本预置目录机制不再自动把上述 YAML 应用到集群。如果直接开启PodSecurityPolicy准入控制器bootstrap 阶段可能出现错误。正确做法是分三步走不带准入控制器启动先得到一个策略空白的正常集群手动应用清单把 PSP 与 RBAC 对象部署进集群停止并携带准入控制器重启此时策略已存在组件可顺利通过校验。对应命令序列minikube start kubectl apply -f /path/to/psp.yaml minikube stop minikube start --extra-configapiserver.enable-admission-pluginsPodSecurityPolicy其中/path/to/psp.yaml指向你保存的清单文件路径。这套流程的核心逻辑是先有策略、再开闸门准入控制器是一个强制性的门禁一旦开启任何没有可用策略授权的 Pod 都会被拒绝因此必须保证策略与授权先于门禁存在。注意事项与限制PSP 的 API 演进本清单使用的apiVersion: policy/v1beta1是 PSP 引入时的版本。Kubernetes 1.21 起 PSP 进入弃用流程1.25 起已被 Pod Security AdmissionPSA取代新版本集群中该 API 不再提供服务。minikube 在 pkg/minikube/assets/addons.go 中通过LegacyPodSecurityPolicy标记对低于 1.25 的版本做兼容判断实际使用时请确认你的 Kubernetes 版本仍支持policy/v1beta1的PodSecurityPolicy。必须与准入控制器配合单独启用 addon 而没有开启PodSecurityPolicy准入插件时策略对象存在但不会被强制校验反过来只开准入插件而没有策略集群引导组件将全部失败。二者缺一不可。策略是最小权限设计默认所有已认证主体只能使用restricted普通工作负载若需要 hostPath、privileged 等能力需要另行创建并绑定更宽松的 PSP或使用 Pod Security Admission 等新机制不要直接修改随包清单的授权范围。若集群中已经运行了不受restricted约束的工作负载开启准入控制器前应逐一确认其是否符合策略要求避免存量 Pod 在滚动更新时被拒绝。参考资源本文档源文件site/content/en/docs/handbook/addons/pod-security-policy.mdaddon 随包清单deploy/addons/pod-security-policy/pod-security-policy.yamladdon 注册与资产嵌入pkg/minikube/assets/addons.go、deploy/addons/assets.goaddon 配置与启停回调pkg/addons/config.go【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考