使用RBAC授权

基于角色的访问控制 (RBAC) 是一种根据组织内各个用户的角色来调节对计算机或网络资源的访问的方法。

RBAC 授权使用 rbac.authorization.k8s.io API 组 推动授权决策，允许您通过 Kubernetes API 动态配置策略。

要启用 RBAC，请启动 API 服务器 将 --authorization-mode 标志设置为逗号分隔的列表，其中包括 RBAC 例如：

RBAC API 声明了四种 Kubernetes 对象： Role 、 ClusterRole 、 RoleBinding 和 ClusterRoleBinding 。您可以 像任何其他 Kubernetes 对象一样使用工具来 描述 或修改对象。 kubectl,

警告： 这些对象在设计上会施加访问限制。如果您在学习过程中对集群进行更改，请参阅 权限提升预防和引导 以了解这些限制如何阻止您进行某些更改。

RBAC 角色 或 ClusterRole 包含表示一组权限的规则。权限纯粹是附加的（没有“拒绝”规则）。

角色总是在特定的范围内设置权限 命名空间 创建角色时，必须指定它所属的命名空间。

相反，ClusterRole 是一个非命名空间资源。资源具有不同的名称（Role 和 ClusterRole），因为 Kubernetes 对象总是必须具有命名空间或不具有命名空间；不可能两者兼而有之。

ClusterRoles 有多种用途。您可以使用 ClusterRole 来：

如果要在命名空间中定义角色，请使用角色；如果要在集群范围内定义角色，请使用 ClusterRole。

这是“默认”命名空间中的示例角色，可用于授予对 豆荚 ：

ClusterRole 可用于授予与角色相同的权限。由于 ClusterRoles 是集群范围的，您还可以使用它们来授予对以下内容的访问权限：

下面是一个 ClusterRole 示例，可用于授予对 秘密 在任何特定命名空间中，或跨所有命名空间（取决于它的 绑定 方式）：

Role 或 ClusterRole 对象的名称必须是有效的 路径段名称 。

角色绑定将角色中定义的权限授予一个用户或一组用户。它包含一个 主题 列表（用户、组或服务帐户），以及对被授予角色的引用。RoleBinding 授予特定命名空间内的权限，而 ClusterRoleBinding 授予访问集群范围的权限。

RoleBinding 可以引用同一命名空间中的任何角色。或者，RoleBinding 可以引用 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 的命名空间。如果要将 ClusterRole 绑定到集群中的所有命名空间，请使用 ClusterRoleBinding。

RoleBinding 或 ClusterRoleBinding 对象的名称必须是有效的 路径段名称 。

下面是一个 RoleBinding 示例，它将“pod-reader”角色授予“default”命名空间中的用户“jane”。这允许“jane”读取“default”命名空间中的 pod。

RoleBinding 还可以引用 ClusterRole 以将该 ClusterRole 中定义的权限授予 RoleBinding 命名空间内的资源。这种引用允许您在集群中定义一组通用角色，然后在多个命名空间中重用它们。

例如，即使以下 RoleBinding 引用 ClusterRole，“dave”（主题，区分大小写）也只能读取“development”命名空间中的 Secret，因为 RoleBinding 的命名空间（在其元数据中）是“development” .

要在整个集群中授予权限，您可以使用 ClusterRoleBinding。以下 ClusterRoleBinding 允许组“manager”中的任何用户读取任何命名空间中的机密。

创建绑定后，您无法更改它所引用的角色或集群角色。如果您尝试更改绑定 roleRef ，则会收到验证错误。如果确实要更改 roleRef 绑定，则需要删除绑定对象并创建替换。

这种限制有两个原因：

命令行实用程序创建或更新包含 RBAC 对象的 kubectl auth reconcile 清单文件，并在需要更改绑定对象引用的角色时处理删除和重新创建绑定对象。有关详细信息，请参阅 命令用法和示例 。

在 Kubernetes API 中，大多数资源都使用其对象名称的字符串表示形式来表示和访问，例如 pods Pod。RBAC 使用与相关 API 端点的 URL 中出现的完全相同的名称来引用资源。一些 Kubernetes API 涉及 子资源 ，例如 Pod 的日志。对 Pod 日志的请求如下所示：

在这种情况下， pods 是 Pod 资源的命名空间资源，并且 log 是 pods . 要在 RBAC 角色中表示这一点，请使用斜杠 ( / ) 来分隔资源和子资源。要允许主题读取 pods 并访问 log 每个 Pod 的子资源，请编写：

您还可以通过 resourceNames 列表为某些请求按名称引用资源。指定后，可以将请求限制为资源的单个实例。这是一个将其主题限制为 only get 或 update a 配置映射 命名 my-configmap ：

注意： 您不能通过资源名称来限制 create 或 deletecollection 请求。对于 create ，此限制是因为在授权时可能不知道新对象的名称。如果您限制 list 或 watch 通过资源名称，客户端必须在其或请求中包含与指定资源名称匹配的 metadata.name 字段选择器才能获得授权。例如， list``watch``kubectl get configmaps --field-selector=metadata.name=my-configmap

您可以将多个 ClusterRole 聚合为一个组合的 ClusterRole。 一个控制器，作为集群控制平面的一部分运行，用一个集合监视 ClusterRole 对象 aggregationRule 。定义一个 aggregationRule 标签 选择器 控制器用来匹配应该组合到这个 rules 字段中的其他 ClusterRole 对象。

这是一个聚合 ClusterRole 的示例：

如果您创建与现有聚合 ClusterRole 的标签选择器匹配的新 ClusterRole，则该更改会触发将新规则添加到聚合 ClusterRole 中。这是一个示例，通过创建另一个标记为 的 ClusterRole，将规则添加到“监控”ClusterRole rbac.example.com/aggregate-to-monitoring: true 。

默认的 面向用户的角色 使用 ClusterRole 聚合。这使您作为集群管理员可以包含自定义资源的规则，例如由 自定义资源定义 或聚合 API 服务器，以扩展默认角色。

例如：以下 ClusterRoles 让“admin”和“edit”默认角色管理名为 CronTab 的自定义资源，而“view”角色只能对 CronTab 资源执行读取 *** 作。您可以假设 CronTab 对象 "crontabs" 在 API 服务器看到的 URL 中命名。

以下示例是 Role 或 ClusterRole 对象的摘录，仅显示该 rules 部分。

允许 "pods" 在核心中读取资源 API 组 ：

允许在 API 组和API 组中读/写部署（在 HTTP 级别： "deployments" 在其 URL 的资源部分中的对象） ： "extensions"``"apps"

允许读取核心 API 组中的 Pod，以及读取或写入 API 组中的 Job "batch" 资源 "extensions" ：

允许读取名为“my-config”的 ConfigMap（必须与 RoleBinding 绑定以限制单个命名空间中的单个 ConfigMap）：

允许读取 "nodes" 核心组中的资源（因为节点是集群范围的，这必须在与 ClusterRoleBinding 绑定的 ClusterRole 中才能生效）：

允许对非资源端点 /healthz 和所有子路径的 GET 和 POST 请求（必须在与 ClusterRoleBinding 绑定的 ClusterRole 中才能生效）：

RoleBinding 或 ClusterRoleBinding 将角色绑定到主题。主题可以是组、用户或 服务帐户 .

Kubernetes 将用户名表示为字符串。这些可以是： 简单的名称，例如“alice”；电子邮件样式的名称，例如“ bob@example.com ”；或表示为字符串的数字用户 ID。作为集群管理员，您可以配置 身份验证模块 ，以便身份验证以您想要的格式生成用户名。

注意： 前缀 system: 是为 Kubernetes 系统保留的，因此您应该确保您没有名称 system: 以意外开头的用户或组。除了这个特殊的前缀，RBAC 授权系统不需要任何格式的用户名。

在 Kubernetes 中，Authenticator 模块提供组信息。组，如用户，表示为字符串，并且该字符串没有格式要求，除了 system: 保留前缀。

ServiceAccounts 的名称以 为前缀 system:serviceaccount: ，并且属于名称以 为前缀的组 system:serviceaccounts: 。

笔记：

以下示例是 RoleBinding 仅显示该 subjects 部分的摘录。

对于名为 的用户 alice@example.com ：

对于名为 的组 frontend-admins ：

对于“kube-system”命名空间中的默认服务帐户：

对于任何命名空间中“qa”组中的所有服务帐户：

对于“开发”命名空间中“开发”组中的所有服务帐户：

对于任何命名空间中的所有服务帐户：

对于所有经过身份验证的用户：

对于所有未经身份验证的用户：

对于所有用户：

API 服务器创建一组默认 ClusterRole 和 ClusterRoleBinding 对象。其中很多都是带 system: 前缀的，表示资源是由集群控制平面直接管理的。所有默认的 ClusterRoles 和 ClusterRoleBindings 都标有 kubernetes.io/bootstrapping=rbac-defaults 。

警告： 使用带有 system: 前缀的名称修改 ClusterRole 和 ClusterRoleBindings 时要小心。对这些资源的修改可能会导致集群无法正常工作。

在每次启动时，API 服务器会使用任何缺失的权限更新默认集群角色，并使用任何缺失的主题更新默认集群角色绑定。这允许集群修复意外修改，并有助于在新 Kubernetes 版本中权限和主题发生变化时保持角色和角色绑定是最新的。

要退出此协调，请将 rbac.authorization.kubernetes.io/autoupdate 默认集群角色或角色绑定上的注释设置为 false . 请注意，缺少默认权限和主题可能会导致集群无法正常工作。

如果 RBAC 授权方处于活动状态，则默认情况下会启用自动对帐。

默认角色绑定授权未经身份验证和经过身份验证的用户读取被认为安全且可公开访问的 API 信息（包括 CustomResourceDefinitions）。要禁用匿名未经身份验证的访问，请添加 --anonymous-auth=false 到 API 服务器配置。

通过 kubectl 运行查看这些角色的配置：

注意： 如果您编辑该 ClusterRole，您的更改将在 API 服务器重新启动时通过 auto-reconciliation 被覆盖。为避免覆盖，请不要手动编辑角色，或禁用自动协调。

<caption style="box-sizing: border-boxpadding-top: 0.75rempadding-bottom: 0.75remcolor: rgb(121, 118, 118)text-align: leftcaption-side: bottom">Kubernetes RBAC API 发现角色</caption><colgroup style="box-sizing: border-box"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-box"></colgroup>

一些默认 ClusterRoles 没有 system: 前缀。这些旨在成为面向用户的角色。它们包括超级用户角色 ( cluster-admin )、旨在使用 ClusterRoleBindings 在集群范围内授予的角色，以及旨在使用 RoleBindings ( admin 、 edit 、 view ) 在特定命名空间内授予的角色。

面向用户的 ClusterRoles 使用 ClusterRole 聚合 来允许管理员在这些 ClusterRoles 上包含自定义资源的规则。要将规则添加到 admin 、 edit 或 view 角色，请创建具有以下一个或多个标签的 ClusterRole：

<colgroup style="box-sizing: border-box"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-box"></colgroup>

如果在 RoleBinding 中使用，则允许对命名空间中的大多数资源进行读/写访问，包括在命名空间中创建角色和角色绑定的能力。此角色不允许对资源配额或命名空间本身进行写访问。此角色还不允许对使用 Kubernetes v1.22+ 创建的集群中的端点进行写访问。更多信息可在 “端点的写入访问”部分 中找到。

|

| 编辑 | 没有 | 允许对命名空间中的大多数对象进行读/写访问。

此角色不允许查看或修改角色或角色绑定。但是，该角色允许访问 Secrets 并作为命名空间中的任何 ServiceAccount 运行 Pod，因此它可以用于获取命名空间中任何 ServiceAccount 的 API 访问级别。此角色还不允许对使用 Kubernetes v1.22+ 创建的集群中的端点进行写访问。更多信息可在 “端点的写入访问”部分 中找到。

|

| 看法 | 没有 | 允许只读访问以查看命名空间中的大多数对象。它不允许查看角色或角色绑定。

此角色不允许查看 Secret，因为读取 Secret 的内容可以访问命名空间中的 ServiceAccount 凭证，这将允许 API 访问命名空间中的任何 ServiceAccount（一种权限提升形式）。

|

<colgroup style="box-sizing: border-box"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-box"></colgroup>

您应该使用 Node 授权 者和 NodeRestriction 准入插件 而不是<tt style="box-sizing: border-box">system:node</tt>角色，并允许根据计划在其上运行的 Pod 授予对 kubelet 的 API 访问权限。

<tt style="box-sizing: border-box">system:node</tt>角色的存在只是为了兼容从 v1.8 之前的版本升级的 Kubernetes 集群。

|

| 系统：节点代理 | 系统：kube-proxy 用户 | 允许访问所需的资源 kube-代理 零件。 |

<colgroup style="box-sizing: border-box"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-boxwidth: 296.406px"><col style="box-sizing: border-box"></colgroup>

Kubernetes 控制器管理器 运行 控制器 内置在 Kubernetes 控制平面中。当使用 调用时 --use-service-account-credentials ，kube-controller-manager 使用单独的服务帐户启动每个控制器。每个内置控制器都有对应的角色，前缀为 system:controller: . 如果控制器管理器不是以 启动的 --use-service-account-credentials ，它使用自己的凭据运行所有控制循环，必须授予所有相关角色。这些角色包括：

RBAC API 可防止用户通过编辑角色或角色绑定来提升权限。因为这是在 API 级别强制执行的，所以即使没有使用 RBAC 授权方，它也适用。

仅当以下至少一项为真时，您才能创建/更新角色：

例如，如果 user-1 无法在集群范围内列出 Secret，则无法创建包含该权限的 ClusterRole。允许用户创建/更新角色：

如果您已经拥有被引用角色中包含的所有权限（与角色绑定在同一范围内） ，或者 如果您已被授权 bind 对被引用角色执行谓词，则只能创建/更新角色绑定。例如，如果 user-1 无法在集群范围内列出 Secret，则它们无法创建 ClusterRoleBinding 到授予该权限的角色。允许用户创建/更新角色绑定：

例如，此 ClusterRole 和 RoleBinding 将允许 user-1 授予其他用户命名空间中的 admin 、 edit 和 view 角色 user-1-namespace ：

在引导第一个角色和角色绑定时，初始用户有必要授予他们尚未拥有的权限。引导初始角色和角色绑定：

在单个命名空间中创建定义权限的角色对象。例子：

创建一个 ClusterRole。例子：

授予特定命名空间内的角色或集群角色。例子：

在整个集群（所有命名空间）中授予 ClusterRole。例子：

rbac.authorization.k8s.io/v1 从清单文件创建或更新API 对象。

如果需要，将创建缺少的对象，并为命名空间的对象创建包含的命名空间。

现有角色已更新以包含输入对象中的权限，并在 --remove-extra-permissions 指定时删除额外权限。

更新现有绑定以将主题包括在输入对象中，如果 --remove-extra-subjects 指定，则删除额外的主题。

例子：

默认 RBAC 策略授予控制平面组件、节点和控制器的范围权限，但 不授予 命名空间之外的服务帐户 kube-system 权限（除了授予所有经过身份验证的用户的发现权限）。

这允许您根据需要将特定角色授予特定的 ServiceAccounts。细粒度的角色绑定提供了更高的安全性，但需要更多的管理工作。更广泛的授权可以为 ServiceAccounts 提供不必要的（并且可能会升级的）API 访问，但更易于管理。

按照从最安全到最不安全的顺序，这些方法是：

一、前言

随着互联网的快速发展，B端行业也逐渐崛起，很多企业管理中使用的软件我们通常称其为B端管理系统，而在B端系统中“权限管理”是必不可少的功能，不同的系统中权限的应用复杂程度不一样，都是根据实际产品以及需求情况而设置合理的权限。而我们现在对于权限的设置基本上都是建立在RBAC权限模型上的、扩展的，下面我会通过介绍RBAC权限模型的概念以及结合实际业务情况列举权限设置的应用。

二、什么是RBAC权限模型？

RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的 *** 作，也就是“主体”对“客体”的 *** 作。其中who是权限的拥有者或主体（例如：User、Role），what是资源或对象（Resource、Class)。

简单的理解其理念就是将“角色”这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。

RBAC其实是一种分析模型，主要分为：基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。

RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语：

用户：系统接口及访问的 *** 作者

权限：能够访问某接口或者做某 *** 作的授权资格

角色：具有一类相同 *** 作权限的用户的总称

1）RBAC0

RBAC0是RBAC权限模型的核心思想，RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成：用户、角色、会话、许可。用户和角色的含义很简单，通过字面意思即可明白，会话：指用户被赋予角色的过程，称之为会话或者是说激活角色；许可： 就是角色拥有的权限（ *** 作和和被控制的对象），简单的说就是用户可使用的功能或者可查看的数据。

用户与角色是多对多的关系，用户与会话是一对一的关系，会话与角色是一对多的关系，角色与许可是多对多的关系。

2）RBAC1

RBAC1是在RBAC0权限模型的基础上，在角色中加入了继承的概念，添加了继承发的概念后，角色就有了上下级或者等级关系。

举例：集团权责清单下包含的角色有：系统管理员、总部权责管理员、区域权责管理员、普通用户，当管理方式向下兼容时，就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限，且上层角色可拥有额外的权限

3）RBAC2

RBAC2是在RBAC0权限模型的基础上，在用户和角色以及会话和角色之间分别加入了约束的概念（职责分离），职责分离指的是同一个人不能拥有两种特定的权限（例如财务部的纳入和支出，或者运动员和裁判员等等）。

用户和角色的约束有以下几种形式:

互斥角色：同一个用户在两个互斥角色中只能选择一个（也会存在一个用户拥有多个角色情况，但是需要通过切换用户角色来实现对不同业务 *** 作）

基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的

先决条件约束：用户想要获得高级角色，首先必须拥有低级角色

会话和角色之间的约束，可以动态的约束用户拥有的角色，例如一个用户可以拥有两个角色，但是运行时只能激活一个角色。

例如：iconfont和蓝湖的用户与角色就采用了约束的概念，超级管理员只允许只有一个

4）RBAC3

RBAC3是RBAC1与RBAC2的合集，所以RBAC3包含继承和约束。

二、为什么要引用RBAC权限模型？

RBAC中具有角色的概念，如果没有角色这个概念，那么在系统中，每个用户都需要单独设置权限，而系统中所涉及到的功能权限和数据权限都非常多，每个用户都单独设置权限对于维护权限的管理员来说无疑是一件繁琐且工作量巨大的任务。

而引入角色这个概念后，我们只需要给系统设置不同的角色， 给角色赋予权限，再将用户与角色关联，这样用户所关联的角色就直接拥有了该角色下的所有权限。

例如：用户1~用户8分别拥有以下权限，，不同用户具有相同权限的我用不同的颜色做了区分，如下图：

在没有引入RBAC权限模型的情况下，用户与权限的关系图可采用下图的杨叔叔展示，每个用户分别设置对应的权限，即便是具有相同权限的用户也需要多次设置权限。

引入RBAC权限模型及引入了角色的概念，根据上面表格的统计，用户1、用户3、用户5、用户8拥有的权限相同，用户2、用户6、用户7拥有相同的权限，用户4是独立的权限，所以我们这里可以根据数据统计，以及实际的需求情况，可以建立三个不同的角色，角色A、角色B、角色C，三个角色分别对应三组用户不同的权限，如下图所示：

对应的上面的案例表格我们就可以调整为含有角色列的数据表，这样便可以清楚的知道每个用户所对应的角色及权限。

通过引用RBAC权限模型后，对于系统中大量的用户的权限设置可以更好的建立管理，角色的引入让具有相同权限的用户可以统一关联到相同的的角色中，这样只需要在系统中设置一次角色的权限，后续的用户便可以直接关联这些角色，这样就省去了重复设置权限的过程，对于大型平台的应用上，用户的数量成千上万，这样就可避免在设置权限这项工作上浪费大量的时间。

三、引入用户组的概念

我们依旧拿上面表格案例举例，虽然前面我们应用的RBAC权限模型的概念，但是对于大量用户拥有相同权限的用户，我们同样的也需要对每个用户设置对应的角色，如果一个部门上万人，那么我们就需要给这个部门上万人分别设置角色，而这上万其实是具有相同的权限的，如果直接采用基础的RBAC权限模型的话，那么面对这样的情况，无疑也是具有一个庞大的重复的工作量，并且也不利于后期用户变更的维护管理，那么针对相同用户具有相同的权限的情况，我们便可以引入用户组的概念。

什么是用户组呢？ 用户组：把具有相同角色的用户进行分类。

上面我们的数据表格案例中的用户1、用户3、用户5、用户8具有相同的角色A，用户2、用户6、用户7也拥有相同的角色B，那么我们就可以将这些具有相同角色的用户建立用户组的关系，拿上面的案例，我们分别对相同角色的用户建立组关系，如下：

用户1、用户3、用户5、用户8→建立用户组1

用户2、用户6、用户7→建立用户组2

因为用户4只有一个用户，所以直接还是单独建立用户与角色的关系，不需要建立用户组，当然尽管只有一个用户也是可以建立用户组的关系，这样有利于后期其他用户与用于4具有相同的角色时，就可以直接将其他用户添加到这个用户组下即可，根据业务的实际情况而选择适合的方案即可。

通过案例表格的变化我们就可以直观的看出权限设置变得清晰简洁了，通过第用户组赋予角色，可以减少大量的重复的工作，我们常见的企业组织、部门下经常会出现不同用户具有相同角色的情况，所以采用用户组的方式，便可以很好的解决这个问题，给具有相同权限的用户建立用户组，将用户组关联到对应的角色下，此用户组就拥有了此角色下的所有权限，而用户是属于用户组的，所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系。

四、引入权限组的概念

权限组与用户组的原理差不多，是将一些相对固定的功能或者权限建立组的关系，然后再给此权限组赋予角色，目前我所接触的B端项目中使用权限组的概念的比较少，可简单的看一下关系图

四、功能权限和数据权限

B端系统中一般产品的权限由页面、 *** 作和数据构成。页面与 *** 作相互关联，必须拥有页面权限，才能分配该页面下对应的 *** 作权限，数据可被增删改查。所以将权限管理分为 功能权限管理和数据权限管理。

功能权限管理：指的是用户可看到那些模块，能 *** 作那些按钮，因为企业中的用户拥有不同的角色，拥有的职责也是不同的。

数据权限管理：指的是用户可看到哪些模块的哪些数据。

例如：一个系统中包含多个权责清单（清单1、清单2、清单3），系统管理员能对整个系统 *** 作维护。。。。。

完整内容请查看公众号原文链接

原文链接：B端产品之权限设计（RBAC权限模型）

来源公众号《设计小余》

在我们生活中，每个组织都会有一个组织架构，例如一个公司，它会有财务部、技术部、行政部、后勤部等。而这些部门，之所以这样划分，就是因为他们的职责不同，所负责的业务不同，本质就是他们行使的职能不同。如果模糊部门的概念，引入一个新概念——角色，赋予同一部门的人同一的角色，他们在这个角色下，会行使相同的职能，这样同一部门的人就拥有了相同的权限，以后这个部门在人事上的变动，其实就是在给这个角色增减用户。于是，就引入RBAC模型。

RBAC的核心分为：用户、角色、权限这三个模块，在产品中的实际流程如下图所示：

下面我们将结合以下问题来一起深入了解下RBAC模型

如上图所示，在创建角色时，我们会给这个角色分配相应的权限，这里的权限是有前提的，就是它是基于已开发的功能来进行的，如果一个功能还没有开发，那无法对它进行权限控制的。如下图所示为常见的添加角色 *** 作：

可以，我们在创建角色时，可能会遇到不同的角色但有部分权限是相同的，这种情况是允许的

超级管理员，它是最大的权限，这个是必不可少的角色

---