16.5. 基于角色的安全性上下文约束访问权限


您可以将 SCC 指定为由 RBAC 处理的资源。这样,您可以将对 SCC 访问的范围限定为某一项目或整个集群。直接将用户、组或服务帐户分配给 SCC 可保留整个集群的范围。

注意

您无法将 SCC 分配给在以下某一默认命名空间中创建的 Pod: defaultkube-systemkube-publicopenshift-nodeopenshift-infraopenshift。这些命名空间不应用于运行 pod 或服务。

要使您的角色包含对 SCC 的访问,请在创建角色时指定 scc 资源。

$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>

这会生成以下角色定义:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
...
  name: role-name 1
  namespace: namespace 2
...
rules:
- apiGroups:
  - security.openshift.io 3
  resourceNames:
  - scc-name 4
  resources:
  - securitycontextconstraints 5
  verbs: 6
  - use
1
角色的名称。
2
所定义角色的命名空间。若未指定,则默认为 default
3
包括 SecurityContextConstraint 资源的 API 组。在 scc 指定为资源时自动定义。
4
要访问的 SCC 的示例名称。
5
允许用户在 resourceNames 字段中指定 SCC 名称的资源组名称。
6
应用到角色的操作动词列表。

当本地或集群角色具有这样的规则时,通过 RoleBinding 或 ClusterRoleBinding 与其绑定的主体可以使用用户定义的 SCC scc-name

注意

由于 RBAC 旨在防止升级,因此即使项目管理员也无法授予 SCC 访问权限。默认情况下,不允许他们对 SCC 资源使用操作动词 use,包括 restricted SCC。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.