使用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 访问，但更易于管理。

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

权限管控可以通俗的理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。

Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。

原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。

例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

Discretionary Access Control，DAC是ACL的一种拓展。

原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。

例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。

缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。

Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。

原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。

例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

(Attribute-Based Access Control)，能很好地解决RBAC的缺点，在新增资源时容易维护。

原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。

属性通常有四类：

例如：早上9:00 11:00期间A、B两个部门一起以考生的身份考试，下午14:00 17:00期间A、B两个部门相互阅卷。

缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。

RBAC的核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。

RBAC三要素：

在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。

RBAC模型可以分为：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相当于底层逻辑，后三者都是在RBAC 0模型上的拔高。

我先简单介绍下这四个RBAC模型：

RBAC 0模型： 用户和角色、角色和权限多对多关系。

简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。

RBAC 0模型如下图：没有画太多线，但是已经能够看出多对多关系。

RBAC 1模型： 相对于RBAC 0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点。

角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC 0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。

而RBAC 1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。

RBAC 1模型如下图：多对多关系仍旧没有改变，只增加角色分级逻辑。

[图片上传中...(-95cc0-1640060170347-0)]

RBAC 2模型： 基于RBAC 0模型，对角色增加了更多约束条件。

如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。

如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？

这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。

RBAC 2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。

RBAC 3模型： 同样是基于RBAC0模型，但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述，读者返回去看RBAC 1和RBAC 2模型的描述即可。

RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。

用户管理中的用户，是企业里每一位员工，他们本身就有自己的组织架构，我们可以直接使用企业部门架构或者业务线架构来作为线索，构建用户管理系统。

需要特殊注意：

实际业务中的组织架构可能与企业部门架构、业务线架构不同，需要考虑数据共享机制，一般的做法为授权某个人、某个角色组共享某个组织层级的某个对象组数据。

在设计系统角色时，我们应该深入理解公司架构、业务架构后，再根据需求设计角色及角色内的等级。一般角色相对于用户来说是固定不变的，每个角色都有自己明确的权限和限制，这些权限在系统设计之处就确定了，之后也轻易不会再变动。

（1）自动获得基础角色

当员工入职到某部门时，该名员工的账号应该自动被加入该部门对应的基础角色中，并拥有对应的基础权限。这种操作是为了保证系统安全的前提下，减少了管理员大量手动操作。使新入职员工能快速使用系统，提高工作效率。

（2）临时角色与失效时间

公司业务有时需要外援来支持，他们并不属于公司员工，也只是在某个时段在公司做支持。此时我们需要设置临时角色，来应对这种可能跨多部门协作的临时员工。

如果公司安全级别较高，此类账号默认有固定失效时间，到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善，遗忘在系统中，引起安全隐患。

（3）虚拟角色

部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。

（4）黑白名单

白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。

黑名单：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。

权限管理一般从三个方面来做限制。页面/菜单权限，操作权限，数据权限。

（1）页面/菜单权限

对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。

（2）操作权限

操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。

（3）数据权限

对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。

数据权限如何管控

数据权限可以分为行权限和列权限。行权限控制：看多少条数据。列权限控制：看一条数据的多少个字段

简单系统中可以通过组织架构来管控行权限，按照角色来配置列权限，但是遇到复杂情况，组织架构是承载不了复杂行权限管控，角色也更不能承载列的特殊化展示。

目前行业的做法是提供行列级数据权规则配置，把规则当成类似权限点配置赋予某个角色或者某个用户。

网易有数做法：

https://youdata.163.com/index/manual/o/6System_management/data_role.html

1.超级管理员

超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。

2.互斥角色如何处理

当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。

3.用户管理权限系统设计一定要简单清晰

在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。

4.无权提示页

有时员工 A 会直接给员工 B 分享他当下正在操作的页面，但有可能员工 B 无权查看。此时我们应该在这里考虑添加「无权提示页」，避免粗暴的 404 页面让员工 B 以为是系统出错了。

---