RBAC（Role-Based Access Control），即基于角色的访问控制，是一种广泛应用于信息安全领域的访问控制模型。RBAC的核心思想是将系统中的用户按照其角色进行分类，然后定义不同角色具有的权限，最后指定哪些用户属于哪些角色，从而实现权限管理。
- 用户（User）：用户代表系统中的实体，可以是个人用户或其他应用程序。用户通过被分配角色来获得相应的权限，从而决定其在系统中能够执行的操作。
- 角色（Role）：角色代表了一组相关权限的集合，通常与用户的职能、责任或角色相对应。每个角色拥有特定的权限，定义了该角色所能执行的操作。
- 权限（Permission）：权限是指用户对系统资源的访问能力。它可以是操作级别的，如读取、写入、删除等，也可以是对象级别的，如访问特定文件或数据库。
2.1.1 K8S中的Role角色分类
Role
作用范围： 的权限只在特定的命名空间内有效。也就是说， 只能控制该命名空间中的资源访问。
使用场景：适用于需要对单个命名空间中的资源（如 Pod、Service、ConfigMap 等）进行细粒度访问控制的场景。
ClusterRole
作用范围：ClusterRole 的权限在整个集群范围内有效，可以控制所有命名空间中的资源访问，或对集群级别的资源（如 Node、PersistentVolume 等）进行访问控制。
使用场景：适用于需要跨多个命名空间访问资源的场景，或者需要对集群级别的资源进行访问控制的情况。
K8S内置的集群角色
- cluster-admin：超级管理员，有集群所有权限。
- admin：主要用于授权命名空间所有读写权限。
- edit：允许对大多数对象读写操作，不允许查看或者修改角色，角色绑定。
- view：允许对命名空间大多数对象只读权限，不允许查看角色，角色绑定和secret。
2.1.2 RBAC具体实现
01 创建客户端证书
cfssl工具下载地址：
wget https://github.com/cloudflare/cfssl/releases/download/v1.6.5/cfssl-certinfo_1.6.5_linux_amd64
wget https://github.com/cloudflare/cfssl/releases/download/v1.6.5/cfssljson_1.6.5_linux_amd64
wget https://github.com/cloudflare/cfssl/releases/download/v1.6.5/cfssl_1.6.5_linux_amd64
下载完毕后，去掉文件后缀，加载到系统环境变量中即可。
1.设置客户端证书的有效期，此处设置的是10年
2.配置证书签发请求，注意CN字段是用户名。将来是这个用户去访问K8S集群。在后面的权限报错会有提示。
3.使用api-verver的CA证书进行签发。只用同一个CA签发的证书才有效。此CA证书为kubeadm初始化时自动生成的证书
查看证书有效期为10年
02 创建授权文件
1.创建一个名为 的集群配置
–certificate-authority=/etc/kubernetes/pki/ca.crt：
- 指定集群的 CA 证书路径，用于验证服务器的身份。
–embed-certs=true：
- 将 CA 证书嵌入到 kubeconfig 文件中，而不是只存储路径。这通常有助于简化配置文件的移动和分享，因为不需要依赖外部文件。
–server=：
- 指定 Kubernetes API 服务器的地址。所有与 Kubernetes 集群的交互都将通过这个地址进行。
注：生成的kubeconfig文件的字段和ca.crt内容不相同，是因为被base64编码过了
此时查看zhiyong18-wzy666.kubeconfig文件内容：
2.设置客户端证书，客户端将来需要携带证书让服务端验证
set-credentials wzy666：
- 创建或更新一个名为 的用户凭证配置。
–client-key=zhiyong18-key.pem：
- 指定用于身份验证的客户端私钥文件路径。这是之前使用cfssl手动生成的私钥
–client-certificate=zhiyong18.pem：
- 指定客户端证书文件路径。这个证书与私钥相对应，用于在与 Kubernetes API 服务器建立连接时进行身份验证。
此时查看zhiyong18-wzy666.kubeconfig文件内容：
3.设置上下文，可以用于绑定多个客户端和服务端的对应关系。
set-context xixi：
- 创建或更新一个名为 的上下文配置。
–cluster=zhiyong18-wzy666：
- 指定上下文所关联的集群名称。在这里， 是之前通过 创建的集群配置的名称。
–user=wzy666：
- 指定上下文所关联的用户凭证名称。在这里， 是之前通过 创建的用户凭证的名称。
此时查看上下文配置，并没有指定默认的上下文
4.设置要使用的上下文为xixi
再次查看文件已经更改为了xixi
总结步骤为：
- 设置集群
- 创建用户
- 集群和用户关联
- 设置默认上下文
03 创建RBAC授权策略
用户没有访问权限，因为还没有授权
1.创建RBAC授权，最后应用
2.查看创建的role角色，记录了详细的权限信息
3.可以查看默认名称空间pod的权限，但是没有查看svc资源和其他名称空间pod的权限。后续可以增加对svc资源的权限。
04 操作流程总结
- 因为访问K8S集群需要https证书，所以使用ca证书辅助创建一个让客户端访问的证书，并且把用户名嵌入到证书当中。
- 基于上一步创建好的证书生成kubeconfig文件，因为直接使用证书访问apiserver不方便，所以把证书内容嵌在kubeconfig文件当中。
- 定义一个角色，内容有用户名、对相应资源的权限；把角色和api组进行绑定。
5.1 ~/.kube/config文件
1.查看~/.kube/config文件内容：
2.把用base64解码后，使用查看
内容如下：，可以发现证书就是记录的K8S管理员
- 查看集群角色绑定，发现其基于system:masters组进行授权
3.用专有命令查看config文件内容
5.2 使用kubeconfig文件的四种方式
5.3 kubectl管理多套集群
方案1：使用不用的kubeconfig文件
手动指定kubeconfig文件位置，
方案2：切换上下文方式
基于变量使用
1.或者把多个集群信息写在一个config文件中
2.切换集群时就会多出2个选项
01 创建客户端证书
组授权：
- 用户组的好处是无需单独为某个用户创建权限，统一为这个组名进行授权，所有的用户都以组的身份访问资源。
- 在证书的.csr文件当中：
- CN：代表用户
- O：代表组
- 用户，用户组都是提取证书中的一个字段，不是在集群中创建的
1配置证书颁发机构（CA）的签名策略
配置了证书颁发机构（CA）的签名策略，包含以下内容：
-
- 定义证书签名的相关配置。 -
- 默认签名配置。
-
- 指定不同的签名配置档案。 -
- 定义适用于 Kubernetes 的签名配置。 -
- 指定证书的用途，包括：
- : 与默认签名配置相同，设置证书有效期为 10 年。
2定义证书签名请求（CSR）的相关信息
O字段指定为组，将来是对这个组授权。
定义了证书签名请求（CSR）的相关信息，包含以下内容：1. (Common Name)
：
- 该字段指定了证书的通用名称，通常表示持有者的身份。在这里，它是 ，表示这是为名为 的用户生成的证书。
-
：
- 这是一个空数组，表示没有指定特定的主机名或 IP 地址。通常，在需要为特定主机生成证书时，可以在这里列出主机名。
-
：
- 包含了关于生成密钥的信息。
- ：指定使用的加密算法为 RSA。
- ：指定密钥的大小为 2048 位，这在安全性和性能之间提供了良好的平衡。
-
：
- 这是一个数组，包含有关证书持有者的详细信息。
- 该数组中的对象定义了证书持有者的组织信息：
- ：国家，通常使用 ISO 3166-1 代码（如 代表中国）。
- ：省份或州，这里指定为北京。
- ：城市，这里也指定为北京。
- ：组织名称，指定为 。
- ：组织单位，指定为 ，通常表示部门或团队。
3生成访问Kubernetes的证书
通过指定 CA 证书和密钥，以及 CSR 文件和签名配置，生成一个适用于 Kubernetes 的证书。生成的证书和私钥将用于服务和客户端的身份验证
：
- 是 Cloudflare 的一个工具，用于管理证书。
- 是生成证书的命令。
：
- 指定 CA 证书的路径，用于签署生成的证书。
- 是 CA 证书的文件位置。
：
- 指定 CA 密钥的路径，用于验证 CA 的身份。
- 是 CA 密钥的文件位置。
：
- 指定配置文件，定义证书的签名策略和使用方式。
- 包含签名配置和使用用途的详细信息。
：
- 指定证书生成的配置文件中的配置档案。
- 是在 中定义的签名策略，适用于 Kubernetes 环境。
：
- 指定证书签名请求（CSR）文件的路径。
- 该文件定义了生成证书所需的基本信息，如通用名称（CN）、密钥类型和其他元数据。
：
- 管道将生成的证书输出传递给 ，用于格式化输出。
- 表示将输出的证书和密钥以无扩展名的文件格式保存，文件名前缀为 。
- 这将生成以下文件：
- ：证书签名请求文件。
- ：生成的证书文件。
- ：与证书对应的私钥文件。
查看生成的证书
02 创建kubeconfig文件
执行脚本后创建一个config文件
没有权限，后期在进行RBAC授权
提示：在默认的名称空间有权限，其他名称空间没有权限
03 创建RBAC授权策略
运行后，有了权限查看名称空间kube-system下的pod
ServiceAccount是一种特殊的资源，简称sa，用于在 Pod 内部提供身份验证和授权。用于管理和控制 Pod 与 K8SAPI 之间的访问。简单来说sa就是给pod使用的
sa的特点：
- 自动挂载：当 Pod 创建时，Kubernetes 会自动为其挂载对应的 ServiceAccount 的 Token
- Token：ServiceAccount 会生成一个访问 Token，通常以 Secrets 的形式存储。Token 用于 Pod 与 Kubernetes API 进行身份验证
- token位置：通常存储在 路径下
- 权限控制：依旧是通过 Role 和 RoleBinding 或 ClusterRole 和 ClusterRoleBinding 进行控制
- 便利性：无需配置额外的https证书
sa的创建和删除（响应式）：
参考创建好的sa，再创建一个sa
01 创建ServiceAccount
1.创建ServiceAccount账号
02 角色绑定
2.创建角色
3.角色绑定
03 pod部署
4.部署Python pod，并使用sa账号
04 Python pod访问K8S API
1.在Python pod里安装访问K8S资源的插件
2.编写访问的Python脚本
3.执行脚本可以看到可以访问pod资源，不能访问deploy资源
4.这时删掉授权绑定，什么资源都看不到了
01dashboard介绍
dashboard特点
- 以图形化的WebUI管理K8S集群，操作简单，简化操作
- 缺点就是不支持多套集群管理，功能相对来说比较单一
- 需要更好的功能可以考虑使用rancher，kuboard，kubesphere
- dashboard是K8S集群管理的一个GUI的WebUI实现，它是一个k8s附加组件，所以需要单独部署
不同版本的dashboard如何部署
- K8S 1.17版本前在K8S官网可以查看：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#unchanged
- K8S 1.17版本后，K8S官方再在维护，不过可以再dashboard官网上查看：https://github.com/kubernetes/dashboard/releases/tag/v2.5.1
02 快速部署dashboard
1.yam文件下载地址，下载下来
2.修改svc为NodePort方便对外访问
3.访问时，Chrome浏览器可能需要再空白处输入，才能打开
4.查看sa账号的token值。先查看到token名称，再查看token值。
5.登录之后出现权限报错，因为官方默认的sa账号权限不足
03 解决权限不足问题
1.编写K8S的yaml授权资源清单文件
2.查看token值
3.使用新token登录后可以看到集群所有的资源，右上角也不再报权限问题。
04 基于kubeconfig登录dashboard
在拿到管理员用户zhiyong18的secrets后，可以创建一个kubeconfig文件
1.指定一个要连接的集群名称
2.在kubeconfig中设置用户项
3.配置上下文，即绑定用户和集群的上下文关系，可以将多个集群和用户进行绑定
4.配置当前使用的上下文
5.把生成的kubeconfig文件导出到windows本机，在dashboard登录时选择使用kubeconfig登录就可以了
4.配置当前使用的上下文
5.把生成的kubeconfig文件导出到windows本机，在dashboard登录时选择使用kubeconfig登录就可以了
到此这篇rbac权限管理（rbac权限管理node如何实现）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-nodejs/22653.html