使用RBAC授权
基于角色的访问控制 (RBAC) 是一种根据组织内各个用户的角色来调节对计算机或网络资源的访问的方法。
RBAC 授权使用 rbac.***thorization.k8s.io API 组 推动授权决策，允许您通过 Kubernetes API 动态配置策略。
要启用 RBAC，请启动 API 服务器 将 --***thorization-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”角色授予“def***lt”命名空间中的用户“jane”。这允许“jane”读取“def***lt”命名空间中的 pod。
RoleBinding 还可以引用 ClusterRole 以将该 ClusterRole 中定义的权限授予 RoleBinding 命名空间内的资源。这种引用允许您在集群中定义一组通用角色，然后在多个命名空间中重用它们。
例如，即使以下 RoleBinding 引用 ClusterRole，“dave”（主题，区分大小写）也只能读取“development”命名空间中的 Secret，因为 RoleBinding 的命名空间（在其元数据中）是“development” .
要在整个集群中授予权限，您可以使用 ClusterRoleBinding。以下 ClusterRoleBinding 允许组“manager”中的任何用户读取任何命名空间中的机密。
创建绑定后，您无法更改它所引用的角色或集群角色。如果您尝试更改绑定 roleRef ，则会收到验证错误。如果确实要更改 roleRef 绑定，则需要删除绑定对象并创建替换。
这种限制有两个原因：
命令行实用程序创建或更新包含 RBAC 对象的 kubectl ***th 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-def***lts 。
警告： 使用带有 system: 前缀的名称修改 ClusterRole 和 ClusterRoleBindings 时要小心。对这些资源的修改可能会导致集群无法正常工作。
在每次启动时，API 服务器会使用任何缺失的权限更新默认集群角色，并使用任何缺失的主题更新默认集群角色绑定。这允许集群修复意外修改，并有助于在新 Kubernetes 版本中权限和主题发生变化时保持角色和角色绑定是最新的。
要退出此协调，请将 rbac.***thorization.kubernetes.io/***toupdate 默认集群角色或角色绑定上的注释设置为 false . 请注意，缺少默认权限和主题可能会导致集群无法正常工作。
如果 RBAC 授权方处于活动状态，则默认情况下会启用自动对帐。
默认角色绑定授权未经身份验证和经过身份验证的用户读取被认为安全且可公开访问的 API 信息（包括 CustomResourceDefinitions）。要***用匿名未经身份验证的访问，请添加 --anonymous-***th=false 到 API 服务器配置。
通过 kubectl 运行查看这些角色的配置：
注意： 如果您编辑该 ClusterRole，您的更改将在 API 服务器重新启动时通过 ***to-reconciliation 被覆盖。为避免覆盖，请不要手动编辑角色，或***用自动协调。
captionKubernetes RBAC API 发现角色/captioncolgroupcolcolcol/colgroup
一些默认 ClusterRoles 没有 system: 前缀。这些旨在成为面向用户的角色。它们包括超级用户角色 ( cluster-admin )、旨在使用 ClusterRoleBindings 在集群范围内授予的角色，以及旨在使用 RoleBindings ( admin 、 edit 、 view ) 在特定命名空间内授予的角色。
面向用户的 ClusterRoles 使用 ClusterRole 聚合 来允许管理员在这些 ClusterRoles 上包含自定义资源的规则。要将规则添加到 admin 、 edit 或 view 角色，请创建具有以下一个或多个标签的 ClusterRole：
colgroupcolcolcol/colgroup
如果在 RoleBinding 中使用，则允许对命名空间中的大多数资源进行读/写访问，包括在命名空间中创建角色和角色绑定的能力。此角色不允许对资源配额或命名空间本身进行写访问。此角色还不允许对使用 Kubernetes v1.22+ 创建的集群中的端点进行写访问。更多信息可在 “端点的写入访问”部分 中找到。
|
| 编辑 | 没有 | 允许对命名空间中的大多数对象进行读/写访问。
此角色不允许查看或修改角色或角色绑定。但是，该角色允许访问 Secrets 并作为命名空间中的任何 ServiceAccount 运行 Pod，因此它可以用于获取命名空间中任何 ServiceAccount 的 API 访问级别。此角色还不允许对使用 Kubernetes v1.22+ 创建的集群中的端点进行写访问。更多信息可在 “端点的写入访问”部分 中找到。
|
| 看法 | 没有 | 允许只读访问以查看命名空间中的大多数对象。它不允许查看角色或角色绑定。
此角色不允许查看 Secret，因为读取 Secret 的内容可以访问命名空间中的 ServiceAccount 凭证，这将允许 API 访问命名空间中的任何 ServiceAccount（一种权限提升形式）。
|
colgroupcolcolcol/colgroup
您应该使用 Node 授权 者和 NodeRestriction 准入插件 而不是ttsystem:node/tt角色，并允许根据计划在其上运行的 Pod 授予对 kubelet 的 API 访问权限。
ttsystem:node/tt角色的存在只是为了兼容从 v1.8 之前的版本升级的 Kubernetes 集群。
|
| 系统：节点代理 | 系统：kube-proxy 用户 | 允许访问所需的资源 kube-代理 零件。 |
colgroupcolcolcol/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.***thorization.k8s.io/v1 从清单文件创建或更新API 对象。
如果需要，将创建缺少的对象，并为命名空间的对象创建包含的命名空间。
现有角色已更新以包含输入对象中的权限，并在 --remove-extra-permissions 指定时删除额外权限。
更新现有绑定以将主题包括在输入对象中，如果 --remove-extra-subjects 指定，则删除额外的主题。
例子：
默认 RBAC 策略授予控制平面组件、节点和控制器的范围权限，但 不授予 命名空间之外的服务帐户 kube-system 权限（除了授予所有经过身份验证的用户的发现权限）。
这允许您根据需要将特定角色授予特定的 ServiceAccounts。细粒度的角色绑定提供了更高的安全性，但需要更多的管理工作。更广泛的授权可以为 ServiceAccounts 提供不必要的（并且可能会升级的）API 访问，但更易于管理。
按照从最安全到最不安全的顺序，这些方法是：
RBAC原理
RBAC基于角色的权限访问控制（Role-based Access Control）
若要给某个用户添加单个权限 可新建 用户权限表
因此：
给用户赋予权限添加相应角色即可 ，权限不够的添加多个角色，角色包含权限太多的，直接添加权限
权限管理之RBAC模型
在我们生活中，每个组织都会有一个组织架构，例如一个公司，它会有财务部、技术部、行政部、后勤部等。而这些部门，之所以这样划分，就是因为他们的职责不同，所负责的业务不同，本质就是他们行使的职能不同。如果模糊部门的概念，引入一个新概念——角色，赋予同一部门的人同一的角色，他们在这个角色下，会行使相同的职能，这样同一部门的人就拥有了相同的权限，以后这个部门在人事上的变动，其实就是在给这个角色增减用户。于是，就引入RBAC模型。
RBAC的核心分为：用户、角色、权限这三个模块，在产品中的实际流程如下图所示：
下面我们将结合以下问题来一起深入了解下RBAC模型
如上图所示，在创建角色时，我们会给这个角色分配相应的权限，这里的权限是有前提的，就是它是基于已开发的功能来进行的，如果一个功能还没有开发，那无法对它进行权限控制的。如下图所示为常见的添加角色操作：
可以，我们在创建角色时，可能会遇到不同的角色但有部分权限是相同的，这种情况是允许的
超级管理员，它是***的权限，这个是必不可少的角色
权限管理（RBAC）
转自：（忘了）
RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。
RBAC的基本思想是：授权给用户的访问权限，通常由用户在一个组织中担当的角色来确定。
RBAC中许可被授权给角色，角色被授权给用户，用户不直接与许可关联。
RBAC对访问权限的授权由管理员统一管理，RBAC根据用户在组织内所处的角色作出访问授权与控制，授权规定是强加给用户的，用户不能自主地将访问权限传给他人，这是一种非自主型集中式访问控制方式。
例如，在医院里，医生这个角色可以开处方，但他无权将开处方的权力传给护士。在RBAC中，用户标识对于身份认证以及审计记录是十分有用的；但真正决定访问权限的是用户对应的角色标识。用户能够对一客体执行访问操作的必要条件是，该用户被授权了一定的角色，其中有一个在当前时刻处于活跃状态，而且这个角色对客体拥有相应的访问权限。即RBAC以角色作为访问控制的主体，用户以什么样的角色对资源进行访问，决定了用户可执行何种操作。
在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。
Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege,正向授权与负向授权）。
Operator：操作。表明对What的How操作。也就是Privilege+Resource
Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。
RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。
Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session.
权限控制RBAC模型
权限系统提的最多的就是RBAC（Role-base Access Control基于角色的访问控制）。所谓角色，其实就是权限的集合，某个角色就是某几个权限的结合。其目的是为了简化授权和鉴权的过程。
RBAC模型的核心是在用户和权限之间引入了角色的概念。取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限（如下图），从而达到用户和权限解耦的目的。
将用户直接绑定到权限上去，如下图：
一个用户只充当一种角色，一种角色可以有多个用户担当。
一个用户可同时充当好几种角色，一种角色可以有多个用户担当。
如上图：对于左边的用户-角色对应，每个人只能同时拥有一种角色，但是同一个角色里边，可能会含有多个用户（如：李四和王麻子都是业务员）；而右边的用户-角色对应，是在左边的基础上，增加了一个用户可拥有多种角色的情况（如：小马哥既是经理，也要负责财务的工作）。
一般公司的业务管理系统，都有数据私密性的要求：哪些人可以看到哪些数据，哪些人不可以看到哪些数据。这个时候，我们就需要把这些东西也考虑到你的权限体系内了。
假设上图是一家公司业务部门的组织架构图，公司要求你基于这个组织架构设计一个业务管理系统，并要求系统需要满足不同用户的数据私密性，比如：“张三”登录时，只能看到“张三”负责的数据；“张三”的领导登录时，能看到“团队A”的所有业务员负责的数据，但看不到其他团队业务员负责的数据等等。
在这种情况下，上一种权限体系就不适用了，但我们可以对其进行一些小改造后，即可达到数据管控的目的，如下图：
在“用户-角色-权限”的基础上，我们增加了用户与组织的关联关系，组织决定了用户的数据可视权限。但要想真正达到这个效果，我们还需要做2件事：
1、组织层级划分。如下图，我们需要对组织进行梳理，并划分层级。
2、数据可视权限规则制定。比如：上级组织职能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。
通过以上两点，系统就可以在用户登录时，自动判断要给用户展示哪些数据了！
第三种权限体系又是在第二种权限体系上进行优化的，增加了用户与岗位的关联关系，示意图如下：
增加岗位有以下几点好处：
1、识别用户的主要身份。一个人可能身兼多职（多个角色），但是他的主要职能是固定的，那怎么告诉系统用户的主要职能是什么呢？答案就是：通过岗位！拿上面的小马哥举例：小马哥虽然身兼经理和财务两种身份，但他的本职工作是“经理”，因此，他的系统岗位应该“经理”。当他登录时，系统会识别他的身份为“经理”，只不过这个“经理”刚好兼具了其他岗位的职能而已；
2、通过“组织-岗位”关联，快速甄别用户岗位。公司在不断地发展的过程中，系统的用户角色也会不断增加，当角色达到一定数量以后，管理员每新增一个用户都要花相当的时间去寻找角色。引入岗位后，可将组织和岗位、岗位和角色提前进行关联，配置账号时，管理员只要选定组织，系统就给出与该组织关联的岗位，而这些岗位，又是提前关联好角色的，选择起来，既方便又高效！
阿里云折扣快速入口
什么是RBAC？
什么是RBAC？
全称 ：role-based access control 基于角色的权限访问控制
作用 ：实现访问控制
RBAC模型概括
RBAC权限授权的过程可以概括为：W是否可以对Z进行H的访问操作，并对这个逻辑表达式进行判断是否为true的过程，也是将权限问题转换为Z、H的问题，W、Z、H构成了访问权限三元组。
权限与角色相关联，用户通过称为适当角色的成员而得到这些角色的权限，极大的简化了权限的管理。
RBAC的组成
3个基础组成部分
- 用户
- 角色
- 权限
RBAC通过定义角色的权限，并且对用户授予某个角色来控制用户的权限，从而实现了用户和权限的逻辑分离，方便了权限的管理
1. user（用户） ：每个用户都有不同且唯一的ID，用来进行识别，并被授予不同的角色
2. role（角色） ：不同的角色具有不同的权限
3. jurisdiction（权限） ：访问权限
关系 ：
- 用户 ---角色的映射：用户和角色之间的映射关系
- 角色 ---权限的映射：角色和权限之间的映射关系
例如：
用户的角色不同，看到的权限也就有所不同
RBAC的安全原则
- 最小权限原则 ：将角色配置成其完成所需的最小权限集合
- 责任分离原则 ：通过调用相互独立且互斥的角色来完成敏感任，例如：记账员和财务管理员共同参与过账操作
- 数据抽象原则 ：借助于抽象许可权这样的概念实现，例如：在账目管理活动中，可以使用信用，借方等抽象许可权，而不是使用典型的读、写、执行权限
RBAC的优缺点
优点：
1. 便于授权管理
2. 便于角色的划分
3. 便于赋予最小权限的原则
4. 便于职责的分离
5. 便于客体分类
缺点 ：
- 没有提供操作顺序的控制机制，这一缺陷使RBAC模型很难适应那些对操作顺序有严格要求的系统
RBAC的3种模型
1. RBAC0 ：最简单、最原始的实现方式，也是其他RBAC模型的基础
在该模型中，用户和角色之间可以是多对多的关系，一个用户在不同场景下是可以有不同的角色。
2. RBAC1 ：基于RBAC0模型，引入了角色间的继承关系，角色上有了上下级的区别
3. RBAC2 ：基于RBAC0模型的基础上，进行了角色的访问控制
RBAC的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于rbac和abac区别、RBAC的信息别忘了在本站进行查找喔。