Kubernetes(k8s)-RBAC用户账户(UserAccount)介绍&应用

作者介绍:简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

图片

我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。

我们上一小节介绍了使用RBAC给服务账户(ServiceAccount)添加权限,这个这个方式一般用于Pod内部,如果需要应用到Pod外部,比如我需要另外一个人来帮我维护我这个Kubernetes集群,但是我不能给他管理员权限,我需要给他创建一个相对较小的权限:比如我只允许他操作命名空间:user001;资源:pod,svc,权限:所有。

1.生成用户私钥

[root@master01 rbac]# openssl genrsa -out user001.key 2048
Generating RSA private key, 2048 bit long modulus
.....................+++
...........................+++
e is 65537 (0x10001)
[root@master01 rbac]# ls
user001.key

2.创建证书签名请求(csr) 

[root@master01 rbac]# openssl req -new -key user001.key -out user001.csr -subj "/CN=user001/O=k8s"
[root@master01 rbac]# ls
user001.csr  user001.key

3.给user001签发证书

这里需要经过集群的ca签发,也就是(/etc/kubernetes/pki/ca.crt文件),同一个ca签发的证书才会被认可(ca签发的集群证书和ca签发的kubectl证书)

[root@master01 rbac]# openssl x509 -req -in user001.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out user001.crt -days 3650
Signature ok
subject=/CN=user001/O=k8s
Getting CA Private Key
[root@master01 rbac]# ls
user001.crt  user001.csr  user001.key

4.创建集群证书

成功以后的配置文件具备了服务器地址和ca证书

[root@master01 rbac]# export KUBE_APISERVER="https://192.168.31.211:6443"
[root@master01 rbac]# 

[root@master01 rbac]# kubectl config set-cluster kubernetes \
>   --certificate-authority=/etc/kubernetes/pki/ca.crt \
>   --embed-certs=true \
>   --server=${KUBE_APISERVER} \
>   --kubeconfig=user001.kubeconfig
Cluster "kubernetes" set.
[root@master01 rbac]# ls
user001.crt  user001.csr  user001.key  user001.kubeconfig

5.添加用户信息

成功以后添加了用户user001,并添加了客户端证书和私钥

[root@master01 rbac]# kubectl config set-credentials user001 \
>   --client-certificate=/root/rbac/user001.crt \
>   --embed-certs=true \
>   --client-key=/root/rbac/user001.key \
>   --kubeconfig=user001.kubeconfig
User "user001" set.
[root@master01 rbac]# ls
user001.crt  user001.csr  user001.key  user001.kubeconfig

6.设置上下文(context)

成功以后会更新user001.kubeconfig,太抽象,我也不知道咋个解释。​​​​​​​

kubectl config set-context user001 \
  --cluster=kubernetes \
  --user=user001 \
  --kubeconfig=user001.kubeconfig

7.设置默认的上下文(context)

设置以后,就可以通过这个文件连接到kube-apiserver。​​​​​​​

kubectl config use-context user001 \
  --kubeconfig=user001.kubeconfig

图片

8.创建Role

这里实现的权限,就是我们需求里面的权限,如果需求是范围是是全集群则需要创建ClueterRole(也就是上个小节讲解的应用)。​​​​​​​

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: user001
  name: user001-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

9.创建RoleBinding

绑定以后,这个权限就和前面的用户绑定到一起,并可以正常连接到集群,同上如果是集群范围则是ClusterRoleBinding。​​​​​​​

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user001-rolebind
  namespace: user001
subjects:
- kind: User
  name: user001
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: user001-role
  apiGroup: rbac.authorization.k8s.io

10.验证权限

把这个文件放置到集群外,/root/.kube/config,在网络能通的情况下也可以直接使用kubectl命令。​​​​​​​

#有权限的资源,正常操作
kubectl get pod,svc -n user001  --kubeconfig=/root/rbac/user001.kubeconfig


​​​​​​​

图片

    #没权限的资源,提异常
    kubectl get cm,secret -n user001  --kubeconfig=/root/rbac/user001.kubeconfig 

    图片

    这个时候我们已经实现了我们的需求,把这个文件user001.kubeconfig提供给需要使用的人,他拿到这个文件放置到/root/.kube/config,然后客户端也安装了kubectl命令以后就可以在对应的节点操作集群权限范围内的资源。

    运维小路

    一个不会开发的运维!一个要学开发的运维!一个学不会开发的运维!欢迎大家骚扰的运维!

    关注微信公众号《运维小路》获取更多内容。

    <think>好的,我现在需要帮助用户理解KubernetesRBAC用户之前询问过如何让开发人员通过创建的用户访问集群查看Pod日志,现在他们想简单了解RBAC。首先,我应该回顾之前的对话,确保回答的一致性和连贯性。 用户当前的问题是“简单介绍k8srbac”,所以需要给出一个简明扼要的解释。但用户之前的问题涉及到具体的RBAC配置步骤,所以在回答时可能需要稍微展开,但保持简洁。 首先,RBAC的全称是Role-Based Access Control,也就是基于角色的访问控制。我需要解释清楚它的核心概念:Role、ClusterRole、RoleBinding、ClusterRoleBinding,以及它们之间的关系。要说明RBAC的作用是管理用户和服务账户对集群资源的访问权限。 接下来,需要区分Role和ClusterRole。Role是命名空间级别的,只能授权特定命名空间内的资源;而ClusterRole是集群范围的,可以授权所有命名空间的资源,或者非资源型端点如节点。例如,在之前的例子中,用户创建了一个Role来允许读取Pod日志,这个Role只作用于default命名空间。 然后是RoleBinding和ClusterRoleBinding。RoleBinding将角色绑定到主体(用户、组、服务账户),并且作用在特定的命名空间;而ClusterRoleBinding则是集群范围的绑定。例如,用户之前创建的RoleBinding将developer用户绑定到pod-logs-reader角色,限制在default命名空间。 需要提到主体可以是User、Group或ServiceAccount。这里的User通常指的是外部用户,比如通过证书认证的,如用户之前用X.509证书创建的developer用户。而ServiceAccount是集群内部的账户,用于Pod中的进程与API Server通信。 权限规则(Rules)由API组、资源、动词组成。例如,在用户之前的例子中,授权了core API组(空字符串)中的pods/log资源,允许get和list操作。需要说明如何组合这些元素来定义细粒度的权限。 还要强调RBAC的优势,比如细粒度控制、灵活授权、审计能力,以及如何帮助实现最小权限原则,提高安全性。可能还需要提到实际应用中的常见场景,比如开发人员只能查看特定命名空间的日志,管理员有更广泛的权限等。 在之前的回答中,用户已经接触过如何创建Role和RoleBinding,所以这里可以简要提及这些示例,但不需要详细展开步骤,因为用户现在需要的是概述而非操作指南。需要注意使用用户之前提到的例子来加强理解,比如pod-logs-reader角色。 此外,用户可能对RBAC的实际应用场景感兴趣,比如多团队环境中的权限隔离,或者CI/CD系统中的服务账户权限管理。虽然用户的问题只是简单介绍,但可能需要点到为止。 最后,要确保语言简洁,结构清晰,使用列表或小标题帮助用户快速抓住重点。避免使用过于专业的术语,但保持准确性。可能需要检查是否有必要提到其他访问控制机制,比如ABAC,但根据问题,重点在RBAC,所以可以忽略其他,除非对比有助于理解。 总结回答的结构应该是:定义RBAC,核心组件,Role与ClusterRole的区别,Binding的作用,主体类型,权限规则的结构,优势和应用场景。保持段落简短,使用项目符号或编号列表提高可读性。</think>### Kubernetes RBAC 简明指南 **RBAC(Role-Based Access Control)** 是 Kubernetes 的核心权限控制系统,通过 **角色关联权限** + **绑定关联主体** 的二级授权模式,实现精准的访问控制。 --- #### 🔑 **核心概念** | 对象 | 作用域 | 功能描述 | 示例场景 | |---------------------|-------------|-------------------------------------------|----------------------------| | **Role** | 命名空间级别 | 定义单个命名空间内的操作权限 | 允许读取 default 命名空间的 Pod 日志 | | **ClusterRole** | 集群级别 | 定义集群范围/跨命名空间的权限 | 允许查看所有节点的信息 | | **RoleBinding** | 命名空间级别 | 将 Role/ClusterRole 绑定到主体(用户/组) | 开发团队访问测试环境命名空间 | | **ClusterRoleBinding** | 集群级别 | 全局权限绑定 | 集群管理员全局访问权限 | --- #### 📜 **权限规则结构** 每个权限规则包含三个关键维度: ```yaml rules: - apiGroups: ["apps"] # API组 (核心API用空字符串"") resources: ["deployments"] # 资源类型 (pods, services等) verbs: ["get", "list"] # 操作动作 (create/delete/watch等) resourceNames: ["frontend"] # 可选:指定具体资源名称 ``` --- #### 👥 **授权主体类型** 1. **User**:外部用户(如通过证书认证的开发者) 2. **Group**:用户组(证书中的`O`字段,如`dev-group`) 3. **ServiceAccount**:服务账号(Pod内部使用的身份) --- #### ⚡ **典型操作流程**(以开发人员查看日志为例) 1. **创建角色**:定义允许访问`pods/log`的 Role 2. **绑定用户**:通过 RoleBinding 将 Role 关联到 User 3. **权限验证**:用户只能执行`kubectl logs <pod>`,其他操作被拒绝 --- #### 🌟 **核心优势** - **最小权限原则**:精确控制到`资源+操作`级别 - **权限组合复用**:ClusterRole 可被多个命名空间复用 - **动态生效**:权限修改实时生效,无需重启组件 - **审计追踪**:结合审计日志可追溯所有访问记录 --- #### 🛠️ **常用命令** ```bash # 检查用户权限 kubectl auth can-i list pods --as developer # 查看绑定关系 kubectl get rolebindings,clusterrolebindings -A # 诊断权限问题 kubectl describe role/pod-logs-reader ``` --- #### 📌 **特别注意** - **权限叠加**:用户最终权限是**所有绑定角色的并集** - **默认拒绝**:未明确允许的操作自动拒绝 - **服务账号**:Pod 自动挂载的 `default` SA 通常权限过高,建议显式配置
    评论
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

    当前余额3.43前往充值 >
    需支付:10.00
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明:

    1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

    余额充值