K8s中的RBAC认证授权之基于HTTPS证书给User授权认证


概述

本文主要介绍在K8s中如何使用证书给User进行授权认证。

在生产环境中,当你想给对应的人员分配不同的权限,则可以阅读这篇文章

阅读这篇文章之前,你应该有一些前置知识,应该知道K8s的授权认证

可以阅读这篇文章:一文搞懂K8s中的RBAC认证授权

实操

使用cfssl生成User的CA证书

cfssl可以阅读这篇文章:https://www.cnblogs.com/huangSir-devops/p/18876361


   
## 创建CA证书
[root@master ~/cfssl]# cat ca-config.json
{
"signing": {
"default": {
# 配置默认证书有效期为10年
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"expiry": "87600h",
"usages": ["signing", "key encipherment", "server auth", "client auth"]
}
}
}
}
# 创建CA证书请求
[root@master ~/cfssl]# cat ca-csr.json
{
# CN表示用户名称
"CN": "develop",
"hosts": [],
"key": {
# 加密算法
"algo": "rsa",
# 密钥长度
"size": 4096
},
"names": [
{
# 国家代码,CN代表是中国
"C": "CN",
# 省份
"ST": "Beijing",
# 城市或地区
"L": "Beijing",
# 这里O表示用户组
"O": "dev
# 组织单位(Organizational Unit),可以理解成公司部门
"OU": "ca"
}
]
}
# 创建证书存储目录
[root@master ~/cfssl]# mkdir -p develop
# 生成证书
[root@master ~/cfssl]# cfssl gencert \
-ca=/etc/kubernetes/pki/ca.crt \
-ca-key=/etc/kubernetes/pki/ca.key \
-config=ca-config.json \
-profile=kubernetes \
ca-csr.json | cfssljson -bare develop/develop
2025/06/07 13:52:37 [INFO] generate received request
2025/06/07 13:52:37 [INFO] received CSR
# 查看文件
[root@master ~/cfssl]# tree
.
├── ca-config.json
├── ca-csr.json
└── develop
├── develop-key.pem # 公钥
├── develop.csr
└── develop.pem # 私钥

生成kubeconfig文件

创建集群入口


   
# 配置集群,集群可以设置多套,此处只配置了一套
# --certificate-authority
# 指定K8s的ca根证书文件路径
# --embed-certs
# 如果设置为true,表示将根证书文件的内容写入到配置文件中,
# 如果设置为false,则只是引用配置文件,将kubeconfig
# --server
# 指定APIServer的地址。
# --kubeconfig
# 指定kubeconfig的配置文件名称
[root@master ~/cfssl]# kubectl config set-cluster dev \
--certificate-authority=/etc/kubernetes/pki/ca.crt \
--embed-certs=true \
--server=https://apiserver.cluster.local:6443 \
--kubeconfig=develop.kubeconfig
# 检查kubeconfig的配置文件
[root@master ~/cfssl]# ll develop.kubeconfig
-rw------- 1 root root 5336 Jun 4 11:27 develop.kubeconfig

设置客户端认证,客户端将来需要携带证书让服务端验证


   
[root@master ~/cfssl]# kubectl config set-credentials develop \
--client-key=/root/cfssl/develop/develop-key.pem \
--client-certificate=/root/cfssl/develop/develop.pem \
--embed-certs=true \
--kubeconfig=develop.kubeconfig

设置默认上下文,可以用于绑定多个客户端和服务端的对应关系。


   
[root@master ~/cfssl]# kubectl config set-context develop \
--cluster=dev \
--user=develop \
--kubeconfig=develop.kubeconfig

测试使用生成的kubeconfig文件访问K8s集群资源


   
# 设置当前使用的上下文
[root@master ~/cfssl]# kubectl config use-context develop --kubeconfig=/root/cfssl/develop.kubeconfig
Switched to context "develop"
# 访问测试,这里显示无权限
[root@master ~/cfssl]# kubectl get po --kubeconfig=/root/cfssl/develop.kubeconfig
Error from server (Forbidden): pods is forbidden: User "develop" cannot list resource "pods" in API group "" in the namespace "default"

为用户配置Role

上面的步骤,是认证没有问题了,但是对应的用户对集群没有权限操作


   
[root@master ~/role]# cat role-default.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: custom-role
rules:
# 规则1:操作核心组和 apps 组的 pods、deployments,仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["pods","deployments"]
verbs: ["get", "list"]
# 规则2:操作核心组和 apps 组的 configmaps、secrets、daemonsets,仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["configmaps","secrets","daemonsets"]
verbs: ["get", "list"]
# 规则3:操作核心组的 secrets,允许 delete 和 create
- apiGroups: [""]
resources: ["secrets"]
verbs: ["delete","create"]
[root@master ~/role]# kubectl apply -f role-default.yaml
[root@master ~/role]# kubectl get role custom-role
NAME CREATED AT
custom-role 2025-06-07T06:34:52Z
# 查看详情
[root@master ~/role]# kubectl describe role custom-role
Name: custom-role
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
secrets [] [] [get list delete create]
configmaps [] [] [get list]
daemonsets [] [] [get list]
deployments [] [] [get list]
pods [] [] [get list]
configmaps.apps [] [] [get list]
daemonsets.apps [] [] [get list]
deployments.apps [] [] [get list]
pods.apps [] [] [get list]
secrets.apps [] [] [get list]

使用RoleBinding关联Role


   
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
# RoleBinding 名称
name: develope-rolebinding
# 作用的命名空间
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
# 引用的角色类型(必须是 Role 或 ClusterRole)
kind: Role
# 引用的角色名称
name: custom-role
# 被授权的主体列表
subjects:
# 主体类型(User/ServiceAccount/Group)
- kind: User
# 主体名称,对应生成证书的CN字段
name: develop
#APIGroup 默认是 "rbac.authorization.k8s.io"。这意味着这些权限规则默认只适用于 #RBAC API 资源,例如 Role、RoleBinding、ClusterRole 和 ClusterRoleBinding。
apiGroup: "rbac.authorization.k8s.io"
[root@master ~/role]# cat rolebinding-develop.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
# RoleBinding 名称
name: develope-rolebinding
# 作用的命名空间
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
# 引用的角色类型(必须是 Role 或 ClusterRole)
kind: Role
# 引用的角色名称
name: custom-role
# 被授权的主体列表
subjects:
# 主体类型(User/ServiceAccount/Group)
- kind: User
# 主体名称,对应生成证书的CN字段
name: develop
#APIGroup 默认是 "rbac.authorization.k8s.io"。这意味着这些权限规则默认只适用于 #RBAC API 资源,例如 Role、RoleBinding、ClusterRole 和 ClusterRoleBinding。
apiGroup: "rbac.authorization.k8s.io"
# 创建RoleBinding
[root@master ~/role]# kubectl apply -f rolebinding-develop.yaml
# 查看RoleBinding
rolebinding.rbac.authorization.k8s.io/develope-rolebinding created
[root@master ~/role]# kubectl get rolebinding
NAME ROLE AGE
develope-rolebinding Role/custom-role 11s
# 查看详情
[root@master ~/role]# kubectl describe rolebinding develope-rolebinding
Name: develope-rolebinding
Labels: <none>
Annotations: <none>
Role:
Kind: Role
Name: custom-role
Subjects:
Kind Name Namespace
---- ---- ---------
User develop

再次使用User测试

查看Pod有权限


   
[root@master ~/role]# kubectl get po --kubeconfig=/root/cfssl/develop.kubeconfig
NAME READY STATUS RESTARTS AGE
alertmanager-prometheus-kube-prometheus-alertmanager-0 2/2 Running 0 21h
nginx-pod 0/1 Pending 0 6d16h
prometheus-grafana-55cbbf54b7-lmhnd 3/3 Running 0 20h
prometheus-kube-prometheus-operator-847fd659bc-scp4w 1/1 Running 0 21h
prometheus-kube-state-metrics-5fb66759db-nb242 1/1 Running 0 21h
prometheus-prometheus-kube-prometheus-prometheus-0 2/2 Running 0 16h
prometheus-prometheus-node-exporter-89xt7 1/1 Running 0 21h
prometheus-prometheus-node-exporter-cn8s4 1/1 Running 0 21h
prometheus-prometheus-node-exporter-llqgx 1/1 Running 0 21h

删除Pod无权限


   
[root@master ~/role]# kubectl delete po nginx-pod --kubeconfig=/root/cfssl/develop.kubeconfig
Error from server (Forbidden): pods "nginx-pod" is forbidden: User "develop" cannot delete resource "pods" in API group "" in the namespace "default"

删除Pod需要添加对应的权限


   
# 修改Role
[root@master ~/role]# cat role-default.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: custom-role
rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments"]
# 添加delete
verbs: ["get", "list","delete"]
- apiGroups: ["","apps"]
resources: ["configmaps","secrets","daemonsets"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["delete","create"]
# 重新应用
[root@master ~/role]# kubectl apply -f role-default.yaml
role.rbac.authorization.k8s.io/custom-role configured

重新测试删除Pod


   
[root@master ~/role]# kubectl delete po nginx-pod --kubeconfig=/root/cfssl/develop.kubeconfig
pod "nginx-pod" deleted # 这里显示正常
原创作者: huangSir-devops 转载于: https://www.cnblogs.com/huangSir-devops/p/18916651
### Kubernetes RBAC 用户授权机制 #### 角色定义 在Kubernetes中,RBAC(基于角色的访问控制)用于管理谁可以做什么以及在哪里做。一个角色是一组权限规则的集合[^5]。这些权限以累加的方式组合在一起,并不存在否定规则。 对于特定命名空间内的资源,权限可以通过`Role`对象来定义;而对于跨所有命名空间或集群级别的资源,则使用`ClusterRole`对象。 #### 绑定用户与角色 为了使普通用户获得对集群内资源的操作能力,必须先将其绑定至适当的角色上。这通常通过创建`RoleBinding`或`ClusterRoleBinding`资源完成。前者适用于单个命名空间范围内的角色分配,后者则是针对全局性的`ClusterRole`进行绑定[^3]。 例如,要授予某位开发者对其开发环境所在命名空间下的Pods完全读写权限: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: pod-editor rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "create", "update", "patch", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: developer-pod-access namespace: development subjects: - kind: User name: "developer@example.com" roleRef: kind: Role name: pod-editor apiGroup: rbac.authorization.k8s.io ``` 这段配置首先定义了一个名为`pod-editor`的角色,它允许执行一系列关于Pod的操作。接着,通过`RoleBinding`将这个角色赋予给指定邮箱地址对应的用户,在此案例中即为`developer@example.com`。 #### 特殊角色 值得注意的是存在一些预设好的特殊角色,比如`cluster-admin`,该角色拥有几乎不受限制的最大化权限(`verbs=*`),可用于管理和维护整个Kubernetes集群[^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值