尧图网页设计 
示例工程【免费下载链接】examplesKubernetes application example tutorials项目地址https://gitcode.com/gh_mirrors/examp/examples点击查看免费下载本篇技术指南以 Kubernetes 官方示例仓库中的 PSP RBAC 示例原文档为骨架完整演示如何通过PodSecurityPolicyPSP与RBAC协同工作按角色 用户组两个维度控制不同用户能否创建特权容器。读者学完后将掌握 PSP 准入控制的启用方式、use特殊动词的授权模型、privileged/restricted两类策略的配置方法以及如何用四组命令实测验证权限边界。PSP 与 RBAC 的协作模型策略管能不能建RBAC 管谁能用PodSecurityPolicy 是一种集群级别的准入控制资源admission controller它对 Pod 的创建请求做静态校验是否允许特权容器、是否允许 host 网络/IPC/PID、允许哪些卷类型、以什么身份运行runAsUser规则等。而 RBACRole-Based Access Control则回答谁有资格的问题——只有被授权的用户或 ServiceAccount才能使用某条 PSP。二者的结合点是一个特殊的use动词要在某个命名空间内创建 Pod创建该 Pod 的用户或 Pod 中显式指定的 ServiceAccount必须在该 Pod 所在的命名空间范围内对podsecuritypolicies资源拥有use权限use是一个专用动词它只授予使用某条策略的能力不附带对 PSP 资源的其他任何访问权限若某用户在命名空间内拥有超级用户权限对*资源有*动词则该用户可在该命名空间内使用任意 PodSecurityPolicy。从源码结构看示例仓库将这一场景的完整资源拆成了四份独立清单职责边界非常清晰文件角色policies.yaml定义privileged与restricted两条 PSProles.yaml定义两个 ClusterRole分别授予对单条 PSP 的use权限bindings.yaml定义 ClusterRoleBinding把角色绑定到用户组pod.yaml 与 pod_priv.yaml用于测试的非特权 / 特权 Pod 清单前置条件启用 PSP 所需的服务端开关要让 PSP 生效API Server 必须同时开启以下能力原文档列出的 5 项要求允许特权容器allow privileged containers允许安全上下文allow security contexts启用 RBAC启用 PodSecurityPolicies将 PodSecurityPolicy 加入准入控制器列表use the PodSecurityPolicy admission controller。如果使用 Kubernetes 仓库自带的hack/local-up-cluster.sh脚本本地拉起集群可以一次性打开全部开关PSP_ADMISSIONtrue ALLOW_PRIVILEGEDtrue ALLOW_SECURITY_CONTEXTtrue hack/local-up-cluster.sh注local-up-cluster.sh是 Kubernetes 主仓库的开发脚本不在本 examples 仓库内它已经预先创建了示例所需的策略、角色与绑定前提是 Kubernetes 仓库中存在指向本仓库staging子目录的examples软链接。若你同时克隆了 Kubernetes 与本 examples 仓库可在 Kubernetes 仓库根目录下执行ln -s ../examples/staging examples建立该链接。本仓库中对应资源实际位于_archived/podsecuritypolicy/rbac/目录。使用受保护端口测试 RBAC为了真实地触发 RBAC 鉴权示例中所有kubectl命令都刻意使用如下两个参数--serverhttps://127.0.0.1:6443强制走受保护端口secure port确保请求经过 RBAC 鉴权而不是绕过鉴权的本地端口--tokentoken允许在测试期间以不同用户的身份发起请求例如foo/system:masters超级用户或foo/restricted-psp-users受限用户组。第一步创建privileged与restricted两条策略本示例仅定义两条策略形成宽松与严格两个极端privileged允许任何类型的 Pod任意卷、任意 capability、host 网络/IPC/PID、任意端口范围、特权容器restricted只允许受限的用户、组与卷类型禁止 host 访问与特权容器。完整清单见 policies.yamlapiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: privileged spec: fsGroup: rule: RunAsAny privileged: true runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - * allowedCapabilities: - * hostPID: true hostIPC: true hostNetwork: true hostPorts: - min: 1 max: 65536 --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: privileged: false fsGroup: rule: RunAsAny runAsUser: rule: MustRunAsNonRoot seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - emptyDir - secret - downwardAPI - configMap - persistentVolumeClaim - projected hostPID: false hostIPC: false hostNetwork: false关键字段的约束语义逐项说明字段privilegedrestricted作用privilegedtruefalse是否允许创建特权容器securityContext.privileged: truerunAsUser.ruleRunAsAnyMustRunAsNonRoot前者允许任意 UID后者强制以非 root 用户运行volumes*白名单列表允许挂载的卷类型*表示全部受限策略仅放行emptyDir、secret、downwardAPI、configMap、persistentVolumeClaim、projectedallowedCapabilities*未设置默认拒绝允许附加的 Linux capabilitieshostPID/hostIPC/hostNetworktruefalse是否共享宿主机的 PID 命名空间、IPC 命名空间与网络命名空间hostPorts1–65536未设置允许容器绑定的宿主机端口范围fsGroup/seLinux/supplementalGroupsRunAsAnyRunAsAny文件系统组、SELinux 上下文、补充组的策略以超级用户身份创建这两条策略$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/system:masters create -f _archived/podsecuritypolicy/rbac/policies.yaml podsecuritypolicy privileged created podsecuritypolicy restricted created原文档中命令路径为staging/podsecuritypolicy/rbac/policies.yaml对应本仓库的实际相对路径即_archived/podsecuritypolicy/rbac/policies.yaml。第二步用 ClusterRole ClusterRoleBinding 授予use权限策略创建后并不会自动生效——还必须通过 RBAC 把使用某条策略的权限授出去。本示例先定义两个 ClusterRole见 roles.yaml# restricted-psp-user grants access to use the restricted PSP. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: restricted-psp-user rules: - apiGroups: - policy resources: - podsecuritypolicies resourceNames: - restricted verbs: - use --- # privileged-psp-user grants access to use the privileged PSP. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: privileged-psp-user rules: - apiGroups: - policy resources: - podsecuritypolicies resourceNames: - privileged verbs: - use注意两个角色的关键设计restricted-psp-user仅对名为restricted的策略拥有use权限privileged-psp-user仅对名为privileged的策略拥有use权限两者都通过resourceNames把授权精确锁定到单条策略且动词只有use符合最小权限原则。角色定义之后需要绑定才能把权限授予具体主体RoleBinding仅在某个特定命名空间内授予权限ClusterRoleBinding在全部命名空间内授予权限。本示例选择 ClusterRoleBinding 将角色按用户组做集群级绑定见 bindings.yaml# privileged-psp-users gives the privileged-psp-user role # to the group privileged-psp-users. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: privileged-psp-users subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: privileged-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: privileged-psp-user --- # restricted-psp-users grants the restricted-psp-user role to # the groups restricted-psp-users and privileged-psp-users. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: restricted-psp-users subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: restricted-psp-users - kind: Group apiGroup: rbac.authorization.k8s.io name: privileged-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: restricted-psp-user --- # edit grants edit role to the groups # restricted-psp-users and privileged-psp-users. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: edit subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: privileged-psp-users - kind: Group apiGroup: rbac.authorization.k8s.io name: restricted-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: edit三个绑定的授权效果privileged-psp-users组同时绑定privileged-psp-user与restricted-psp-user角色因此该组成员对两条策略都有use权限可以创建特权 Podrestricted-psp-users组仅绑定restricted-psp-user角色只能使用restricted策略system:authenticated这是任何已认证用户的系统组绑定到集群内置的edit角色——它提供常规的创建 Pod 等命名空间内编辑权限但不授予任何 PSP 的use权限edit角色不含use动词这正是能建普通 Pod、但不能越权建特权 Pod的关键。创建角色与绑定的命令$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/system:masters create -f _archived/podsecuritypolicy/rbac/roles.yaml clusterrole restricted-psp-user created clusterrole privileged-psp-user created $ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/system:masters create -f _archived/podsecuritypolicy/rbac/bindings.yaml clusterrolebinding privileged-psp-users created clusterrolebinding restricted-psp-users created clusterrolebinding edit created第三步四组实测验证权限边界测试用两个 Pod 清单非特权 pod.yaml普通 nginxcontainerPort: 80与特权 pod_priv.yaml在容器上追加securityContext.privileged: true。# pod.yaml —— 普通非特权 Pod apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 # pod_priv.yaml —— 特权 Pod核心差异在 securityContext spec: containers: - name: nginx image: nginx ports: - containerPort: 80 securityContext: privileged: true场景 1受限用户能创建非特权 Pod以foo/restricted-psp-users身份创建普通 Pod成功$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/restricted-psp-users create -f _archived/podsecuritypolicy/rbac/pod.yaml pod nginx created通过 Pod 的 annotation 反查准入时命中的策略$ kubectl get pod nginx -o yaml | grep psp kubernetes.io/psp: restrictedkubernetes.io/psp标注为restricted说明该 Pod 是通过受限策略完成准入校验的。场景 2受限用户无法创建特权 Pod删除已有 Pod 后尝试以同一身份创建特权 Pod被 API Server 拒绝$ kubectl delete pod nginx pod nginx deleted $ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/restricted-psp-users create -f _archived/podsecuritypolicy/rbac/pod_priv.yaml Error from server (Forbidden): error when creating _archived/podsecuritypolicy/rbac/pod_priv.yaml: pods nginx is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]错误信息分为两层值得逐句解读unable to validate against any pod security policy说明受限用户组可用的只有restricted策略spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed说明拒绝的具体原因是restricted策略中privileged: false特权容器不被允许。场景 3特权用户能创建非特权 Pod切换到foo/privileged-psp-users身份创建普通 Pod同样成功$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/privileged-psp-users create -f _archived/podsecuritypolicy/rbac/pod.yaml pod nginx created查看命中的策略与特权状态$ kubectl get pod nginx -o yaml | egrep psp|privileged kubernetes.io/psp: privileged注意这里命中的是privileged策略。原文档特别指出在 Kubernetes 1.9 之前的版本中restricted或privileged都可能被命中因为两条策略都允许创建非特权 Pod从 1.9 版本开始privileged策略会被始终使用——原因是它原样接受Pod即不做默认值填充/变更accepts the pod as-is, without defaulting/mutating在准入排序时优先命中。场景 4特权用户能创建特权 Pod$ kubectl delete pod nginx pod nginx deleted $ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/privileged-psp-users create -f _archived/podsecuritypolicy/rbac/pod_priv.yaml pod nginx created验证结果——PSP 标注与容器内privileged: true同时出现$ kubectl get pod nginx -o yaml | egrep psp|privileged kubernetes.io/psp: privileged privileged: true四组场景完整覆盖了权限矩阵的两个维度用户组 × Pod 特权任何未授权使用对应策略的组合都会被准入控制器拦截而授权组合则顺利创建且可以通过kubernetes.io/psp标注追溯准入决策。版本与演进说明本示例中的 PSP 使用policy/v1beta1API 版本配套的 RBAC 资源使用rbac.authorization.k8s.io/v1上述1.9 起 privileged 策略优先的行为差异仅影响非特权 Pod 命中哪条策略的观测结果不影响最终能否创建需要说明的是PodSecurityPolicy 在 Kubernetes 后续版本中已被官方逐步弃用并最终移除该示例目录也因此被归档在_archived/下。现代集群的安全基线建议采用其继任方案 Pod Security Standards / Pod Security Admission即restricted/baseline/privileged三档策略配合 RBAC 使用不过 PSP RBAC 的策略定义 use动词授权 分组绑定这一套权限建模思路仍然是理解 Kubernetes 准入控制与最小权限设计的经典教材也是本仓库中可直接复现的完整案例。赞分享示例工程【免费下载链接】examplesKubernetes application example tutorials项目地址https://gitcode.com/gh_mirrors/examp/examples点击查看免费下载相关推荐123云盘解锁脚本社区贡献指南如何参与开源项目开发123云盘解锁脚本社区贡献指南如何参与开源项目开发 想要为123云盘解锁脚本项目贡献代码但不知道从何开始 这篇完整的社区贡献指南将为你详细解答如何参与前端CANN/pypto泳道图性能报告查看查看性能报告 功能说明 支持查看汇总性能数据支持按全局时间范围、区域及任务节点查看。 前提条件 执行PyPTO程序生成泳道图文件。 操作步骤 1. 打开泳人工智能编译器模型编译深度学习高性能计算CANNAscendSuperTokens用户角色和权限管理精细化访问控制实现SuperTokens用户角色和权限管理精细化访问控制实现 SuperTokens作为开源的Auth0/Firebase Auth替代方案提供了强大的用户角认证鉴权身份认证后端上一篇LMCache 多对象组前缀缓存命中计算bitmap_ops 的 fold / unfold 设计与 C 加速实现下一篇如何3分钟搞定Beat Saber模组安装Mod Assistant终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes PSP + RBAC 实战：用 PodSecurityPolicy 与角色/用户组精细管控特权容器
示例工程【免费下载链接】examplesKubernetes application example tutorials项目地址https://gitcode.com/gh_mirrors/examp/examples点击查看免费下载本篇技术指南以 Kubernetes 官方示例仓库中的 PSP RBAC 示例原文档为骨架完整演示如何通过PodSecurityPolicyPSP与RBAC协同工作按角色 用户组两个维度控制不同用户能否创建特权容器。读者学完后将掌握 PSP 准入控制的启用方式、use特殊动词的授权模型、privileged/restricted两类策略的配置方法以及如何用四组命令实测验证权限边界。PSP 与 RBAC 的协作模型策略管能不能建RBAC 管谁能用PodSecurityPolicy 是一种集群级别的准入控制资源admission controller它对 Pod 的创建请求做静态校验是否允许特权容器、是否允许 host 网络/IPC/PID、允许哪些卷类型、以什么身份运行runAsUser规则等。而 RBACRole-Based Access Control则回答谁有资格的问题——只有被授权的用户或 ServiceAccount才能使用某条 PSP。二者的结合点是一个特殊的use动词要在某个命名空间内创建 Pod创建该 Pod 的用户或 Pod 中显式指定的 ServiceAccount必须在该 Pod 所在的命名空间范围内对podsecuritypolicies资源拥有use权限use是一个专用动词它只授予使用某条策略的能力不附带对 PSP 资源的其他任何访问权限若某用户在命名空间内拥有超级用户权限对*资源有*动词则该用户可在该命名空间内使用任意 PodSecurityPolicy。从源码结构看示例仓库将这一场景的完整资源拆成了四份独立清单职责边界非常清晰文件角色policies.yaml定义privileged与restricted两条 PSProles.yaml定义两个 ClusterRole分别授予对单条 PSP 的use权限bindings.yaml定义 ClusterRoleBinding把角色绑定到用户组pod.yaml 与 pod_priv.yaml用于测试的非特权 / 特权 Pod 清单前置条件启用 PSP 所需的服务端开关要让 PSP 生效API Server 必须同时开启以下能力原文档列出的 5 项要求允许特权容器allow privileged containers允许安全上下文allow security contexts启用 RBAC启用 PodSecurityPolicies将 PodSecurityPolicy 加入准入控制器列表use the PodSecurityPolicy admission controller。如果使用 Kubernetes 仓库自带的hack/local-up-cluster.sh脚本本地拉起集群可以一次性打开全部开关PSP_ADMISSIONtrue ALLOW_PRIVILEGEDtrue ALLOW_SECURITY_CONTEXTtrue hack/local-up-cluster.sh注local-up-cluster.sh是 Kubernetes 主仓库的开发脚本不在本 examples 仓库内它已经预先创建了示例所需的策略、角色与绑定前提是 Kubernetes 仓库中存在指向本仓库staging子目录的examples软链接。若你同时克隆了 Kubernetes 与本 examples 仓库可在 Kubernetes 仓库根目录下执行ln -s ../examples/staging examples建立该链接。本仓库中对应资源实际位于_archived/podsecuritypolicy/rbac/目录。使用受保护端口测试 RBAC为了真实地触发 RBAC 鉴权示例中所有kubectl命令都刻意使用如下两个参数--serverhttps://127.0.0.1:6443强制走受保护端口secure port确保请求经过 RBAC 鉴权而不是绕过鉴权的本地端口--tokentoken允许在测试期间以不同用户的身份发起请求例如foo/system:masters超级用户或foo/restricted-psp-users受限用户组。第一步创建privileged与restricted两条策略本示例仅定义两条策略形成宽松与严格两个极端privileged允许任何类型的 Pod任意卷、任意 capability、host 网络/IPC/PID、任意端口范围、特权容器restricted只允许受限的用户、组与卷类型禁止 host 访问与特权容器。完整清单见 policies.yamlapiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: privileged spec: fsGroup: rule: RunAsAny privileged: true runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - * allowedCapabilities: - * hostPID: true hostIPC: true hostNetwork: true hostPorts: - min: 1 max: 65536 --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: privileged: false fsGroup: rule: RunAsAny runAsUser: rule: MustRunAsNonRoot seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - emptyDir - secret - downwardAPI - configMap - persistentVolumeClaim - projected hostPID: false hostIPC: false hostNetwork: false关键字段的约束语义逐项说明字段privilegedrestricted作用privilegedtruefalse是否允许创建特权容器securityContext.privileged: truerunAsUser.ruleRunAsAnyMustRunAsNonRoot前者允许任意 UID后者强制以非 root 用户运行volumes*白名单列表允许挂载的卷类型*表示全部受限策略仅放行emptyDir、secret、downwardAPI、configMap、persistentVolumeClaim、projectedallowedCapabilities*未设置默认拒绝允许附加的 Linux capabilitieshostPID/hostIPC/hostNetworktruefalse是否共享宿主机的 PID 命名空间、IPC 命名空间与网络命名空间hostPorts1–65536未设置允许容器绑定的宿主机端口范围fsGroup/seLinux/supplementalGroupsRunAsAnyRunAsAny文件系统组、SELinux 上下文、补充组的策略以超级用户身份创建这两条策略$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/system:masters create -f _archived/podsecuritypolicy/rbac/policies.yaml podsecuritypolicy privileged created podsecuritypolicy restricted created原文档中命令路径为staging/podsecuritypolicy/rbac/policies.yaml对应本仓库的实际相对路径即_archived/podsecuritypolicy/rbac/policies.yaml。第二步用 ClusterRole ClusterRoleBinding 授予use权限策略创建后并不会自动生效——还必须通过 RBAC 把使用某条策略的权限授出去。本示例先定义两个 ClusterRole见 roles.yaml# restricted-psp-user grants access to use the restricted PSP. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: restricted-psp-user rules: - apiGroups: - policy resources: - podsecuritypolicies resourceNames: - restricted verbs: - use --- # privileged-psp-user grants access to use the privileged PSP. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: privileged-psp-user rules: - apiGroups: - policy resources: - podsecuritypolicies resourceNames: - privileged verbs: - use注意两个角色的关键设计restricted-psp-user仅对名为restricted的策略拥有use权限privileged-psp-user仅对名为privileged的策略拥有use权限两者都通过resourceNames把授权精确锁定到单条策略且动词只有use符合最小权限原则。角色定义之后需要绑定才能把权限授予具体主体RoleBinding仅在某个特定命名空间内授予权限ClusterRoleBinding在全部命名空间内授予权限。本示例选择 ClusterRoleBinding 将角色按用户组做集群级绑定见 bindings.yaml# privileged-psp-users gives the privileged-psp-user role # to the group privileged-psp-users. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: privileged-psp-users subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: privileged-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: privileged-psp-user --- # restricted-psp-users grants the restricted-psp-user role to # the groups restricted-psp-users and privileged-psp-users. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: restricted-psp-users subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: restricted-psp-users - kind: Group apiGroup: rbac.authorization.k8s.io name: privileged-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: restricted-psp-user --- # edit grants edit role to the groups # restricted-psp-users and privileged-psp-users. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: edit subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: privileged-psp-users - kind: Group apiGroup: rbac.authorization.k8s.io name: restricted-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: edit三个绑定的授权效果privileged-psp-users组同时绑定privileged-psp-user与restricted-psp-user角色因此该组成员对两条策略都有use权限可以创建特权 Podrestricted-psp-users组仅绑定restricted-psp-user角色只能使用restricted策略system:authenticated这是任何已认证用户的系统组绑定到集群内置的edit角色——它提供常规的创建 Pod 等命名空间内编辑权限但不授予任何 PSP 的use权限edit角色不含use动词这正是能建普通 Pod、但不能越权建特权 Pod的关键。创建角色与绑定的命令$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/system:masters create -f _archived/podsecuritypolicy/rbac/roles.yaml clusterrole restricted-psp-user created clusterrole privileged-psp-user created $ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/system:masters create -f _archived/podsecuritypolicy/rbac/bindings.yaml clusterrolebinding privileged-psp-users created clusterrolebinding restricted-psp-users created clusterrolebinding edit created第三步四组实测验证权限边界测试用两个 Pod 清单非特权 pod.yaml普通 nginxcontainerPort: 80与特权 pod_priv.yaml在容器上追加securityContext.privileged: true。# pod.yaml —— 普通非特权 Pod apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 # pod_priv.yaml —— 特权 Pod核心差异在 securityContext spec: containers: - name: nginx image: nginx ports: - containerPort: 80 securityContext: privileged: true场景 1受限用户能创建非特权 Pod以foo/restricted-psp-users身份创建普通 Pod成功$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/restricted-psp-users create -f _archived/podsecuritypolicy/rbac/pod.yaml pod nginx created通过 Pod 的 annotation 反查准入时命中的策略$ kubectl get pod nginx -o yaml | grep psp kubernetes.io/psp: restrictedkubernetes.io/psp标注为restricted说明该 Pod 是通过受限策略完成准入校验的。场景 2受限用户无法创建特权 Pod删除已有 Pod 后尝试以同一身份创建特权 Pod被 API Server 拒绝$ kubectl delete pod nginx pod nginx deleted $ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/restricted-psp-users create -f _archived/podsecuritypolicy/rbac/pod_priv.yaml Error from server (Forbidden): error when creating _archived/podsecuritypolicy/rbac/pod_priv.yaml: pods nginx is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]错误信息分为两层值得逐句解读unable to validate against any pod security policy说明受限用户组可用的只有restricted策略spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed说明拒绝的具体原因是restricted策略中privileged: false特权容器不被允许。场景 3特权用户能创建非特权 Pod切换到foo/privileged-psp-users身份创建普通 Pod同样成功$ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/privileged-psp-users create -f _archived/podsecuritypolicy/rbac/pod.yaml pod nginx created查看命中的策略与特权状态$ kubectl get pod nginx -o yaml | egrep psp|privileged kubernetes.io/psp: privileged注意这里命中的是privileged策略。原文档特别指出在 Kubernetes 1.9 之前的版本中restricted或privileged都可能被命中因为两条策略都允许创建非特权 Pod从 1.9 版本开始privileged策略会被始终使用——原因是它原样接受Pod即不做默认值填充/变更accepts the pod as-is, without defaulting/mutating在准入排序时优先命中。场景 4特权用户能创建特权 Pod$ kubectl delete pod nginx pod nginx deleted $ kubectl --serverhttps://127.0.0.1:6443 --tokenfoo/privileged-psp-users create -f _archived/podsecuritypolicy/rbac/pod_priv.yaml pod nginx created验证结果——PSP 标注与容器内privileged: true同时出现$ kubectl get pod nginx -o yaml | egrep psp|privileged kubernetes.io/psp: privileged privileged: true四组场景完整覆盖了权限矩阵的两个维度用户组 × Pod 特权任何未授权使用对应策略的组合都会被准入控制器拦截而授权组合则顺利创建且可以通过kubernetes.io/psp标注追溯准入决策。版本与演进说明本示例中的 PSP 使用policy/v1beta1API 版本配套的 RBAC 资源使用rbac.authorization.k8s.io/v1上述1.9 起 privileged 策略优先的行为差异仅影响非特权 Pod 命中哪条策略的观测结果不影响最终能否创建需要说明的是PodSecurityPolicy 在 Kubernetes 后续版本中已被官方逐步弃用并最终移除该示例目录也因此被归档在_archived/下。现代集群的安全基线建议采用其继任方案 Pod Security Standards / Pod Security Admission即restricted/baseline/privileged三档策略配合 RBAC 使用不过 PSP RBAC 的策略定义 use动词授权 分组绑定这一套权限建模思路仍然是理解 Kubernetes 准入控制与最小权限设计的经典教材也是本仓库中可直接复现的完整案例。赞分享示例工程【免费下载链接】examplesKubernetes application example tutorials项目地址https://gitcode.com/gh_mirrors/examp/examples点击查看免费下载相关推荐123云盘解锁脚本社区贡献指南如何参与开源项目开发123云盘解锁脚本社区贡献指南如何参与开源项目开发 想要为123云盘解锁脚本项目贡献代码但不知道从何开始 这篇完整的社区贡献指南将为你详细解答如何参与前端CANN/pypto泳道图性能报告查看查看性能报告 功能说明 支持查看汇总性能数据支持按全局时间范围、区域及任务节点查看。 前提条件 执行PyPTO程序生成泳道图文件。 操作步骤 1. 打开泳人工智能编译器模型编译深度学习高性能计算CANNAscendSuperTokens用户角色和权限管理精细化访问控制实现SuperTokens用户角色和权限管理精细化访问控制实现 SuperTokens作为开源的Auth0/Firebase Auth替代方案提供了强大的用户角认证鉴权身份认证后端上一篇LMCache 多对象组前缀缓存命中计算bitmap_ops 的 fold / unfold 设计与 C 加速实现下一篇如何3分钟搞定Beat Saber模组安装Mod Assistant终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考