容器编排大王Kubernetes——认证与授权(7)

讲述了UserAccout与ServiceAcount的认证，主要讲述了UserAccout认证的授权，role授权与clusterrole授权

FJW020814

1039人浏览 · 2025-10-17 23:24:56

FJW020814 · 2025-10-17 23:24:56 发布

一 kubernetes API 访问控制

Authentication（认证）

认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。
Kubernetes集群有两类用户：由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts）普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。

Authorization（授权）

必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。默认集群强制开启RBAC。

Admission Control（准入控制）

用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验。

1.1 UserAccount与ServiceAccount

用户账户是针对人而言的。服务账户是针对运行在 pod 中的进程而言的。
用户账户是全局性的。其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，服务账户是 namespace 隔离的。
集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。

1.1.1 ServiceAccount

服务账户控制器（Service account controller）
- 服务账户管理器管理各命名空间下的服务账户
- 每个活跃的命名空间下存在一个名为 “default” 的服务账户
服务账户准入控制器（Service account admission controller）
- 相似pod中 ServiceAccount默认设为 default。
- 保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
- 如果pod不包含ImagePullSecrets设置那么ServiceAccount中的ImagePullSecrets 被添加到pod中
- 将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中
- 将一个包含用于 API 访问的 token 的 volume 添加到 pod 中

1.1.2 ServiceAccount示例：

建立名字为admin的ServiceAccount

[root@k8s-master ~]# kubectl create sa timinglee
serviceaccount/timinglee created
[root@k8s-master ~]# kubectl describe  sa timinglee
Name:                timinglee
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

建立secrets

[root@k8s-master ~]# kubectl create secret docker-registry docker-login --docker-username admin --docker-password lee --docker-server reg.timinglee.org --docker-email lee@timinglee.org
secret/docker-login created
[root@k8s-master ~]# kubectl describe secrets docker-login
Name:         docker-login
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/dockerconfigjson

Data
====
.dockerconfigjson:  119 bytes

将secrets注入到sa中

[root@k8s-master ~]# kubectl edit sa timinglee
apiVersion: v1
imagePullSecrets:
- name: docker-login
kind: ServiceAccount
metadata:
  creationTimestamp: "2024-09-08T15:44:04Z"
  name: timinglee
  namespace: default
  resourceVersion: "262259"
  uid: 7645a831-9ad1-4ae8-a8a1-aca7b267ea2d

[root@k8s-master ~]# kubectl describe sa timinglee
Name:                timinglee
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  docker-login
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

建立私有仓库并且利用pod访问私有仓库

[root@k8s-master auth]# vim example1.yml
[root@k8s-master auth]# kubectl apply -f example1.yml
pod/testpod created
[root@k8s-master auth]# kubectl describe pod testpod
 Warning  Failed     5s               kubelet            Failed to pull image "reg.timinglee.org/lee/nginx:latest": Error response from daemon: unauthorized: unauthorized to access repository: lee/nginx, action: pull: unauthorized to access repository: lee/nginx, action: pull
  Warning  Failed     5s               kubelet            Error: ErrImagePull
  Normal   BackOff    3s (x2 over 4s)  kubelet            Back-off pulling image "reg.timinglee.org/lee/nginx:latest"
  Warning  Failed     3s (x2 over 4s)  kubelet            Error: ImagePullBackOff

[!WARNING]

在创建pod时会镜像下载会受阻，因为docker私有仓库下载镜像需要认证

pod绑定sa

[root@k8s-master auth]# vim example1.yml
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  serviceAccountName: timinglee
  containers:
  - image: reg.timinglee.org/lee/nginx:latest
    name: testpod

[root@k8s-master auth]# kubectl apply -f example1.yml
pod/testpod created
[root@k8s-master auth]# kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
testpod   1/1     Running   0          2s

二 UserAccout认证与授权

2.1 创建UserAccount（认证）

1.生成私钥与证书文件

[root@master pki]# cd /etc/kubernetes/pki/

#生成私钥
[root@master pki]# openssl genrsa -out fjw.key 2048

#生成证书签名请求（CSR）
[root@master pki]# openssl req  -new -key fjw.key -out fjw.csr -subj "/CN=fjw"

#使用现有的CA证书和密钥签署CSR生成新的用户CA
[root@master pki]# openssl x509 -req  -in fjw.csr -CA ca.crt -CAkey ca.key -CAcreateserial  -out fjw.crt -days 365
Certificate request self-signature ok
subject=CN = fjw

#查看生成CA证书，用于查看证书文件 fjw.crt 的详细信息（以文本形式展示，不打印证书本身的编码内容）
[root@master pki]# openssl x509 -in fjw.crt -text -noout

2.创建用户

#使用创建的认证来创建用户
[root@master pki]# kubectl config set-credentials fjw --client-certificate /etc/kubernetes/pki/fjw.crt --client-key /etc/kubernetes/pki/fjw.key --embed-certs=true

#为用户创建集群的安全上下文
[root@master pki]# kubectl config set-context fjw@kubernetes --cluster kubernetes --user fjw
Context "fjw@kubernetes" created.

#查看当前 Kubernetes 集群的配置信息，包括集群、用户、上下文等详细内容
[root@master ~]# kubectl config view
......
users:
- name: fjw
......
#也可以通过查看这个文件来查看用户相当于系统用户的/etc/passwd
[root@master pki]# cat /etc/kubernetes/admin.conf



#切换用户，用户在集群中只有用户身份没有授权
[root@master pki]# kubectl config use-context fjw@kubernetes
Switched to context "fjw@kubernetes".
[root@master pki]# kubectl get pods		#由于没权限报错
Error from server (Forbidden): pods is forbidden: User "fjw" cannot list resource "pods" in API group "" in the namespace "default"

#切换回集群管理用户
[root@master pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

#如果需要删除用户
[root@master pki]# kubectl config delete-user fjw

2.2 RBAC（授权）

允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。
RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可
RBAC的三个基本概念
- Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount
- Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
- RoleBinding：定义了“被作用者”和“角色”的绑定关系
RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding
Role 和 ClusterRole
- Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。
- ClusterRole 跟 Role 类似，但是可以在集群中全局使用。
- Kubernetes 还提供了四个预先定义好的 ClusterRole 来供用户直接使用
- cluster-amdin、admin、edit、view

2.2.2 role授权实施

1.建立role

#创建工作目录
[root@master ~]# mkdir role
[root@master ~]# cd role/

#查看api资源
[root@master role]# kubectl api-resources | less

#生成role的yaml文件
[root@master role]# kubectl create role myrole --dry-run=client --verb=get --resource pods -o yaml > myrole.yml

[root@master role]# vim myrole.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myrole
rules:
- apiGroups:
  - ""				#为组时才需要添加，使用api-resources来查看资源
  resources:
  - pods			#对pods进行授权
  verbs:
  - get
  - watch
  - list
  - create
  - update
  - path
  - delete

- apiGroups:
  - ""
  resources:
  - services		#对服务进行授权
  verbs:
  - get
  - watch
  - list
  - create
  - update
  - path
  - delete

#部署并查看
[root@master role]# kubectl apply -f myrole.yml
role.rbac.authorization.k8s.io/myrole created
[root@master role]# kubectl describe role myrole
Name:         myrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get watch list create update path delete]
  services   []                 []              [get watch list create update path delete]

2.建立rolebind

#建立角色绑定
[root@master role]# kubectl create rolebinding bindfjw --role myrole --namespace default --user fjw --dry-run=client -o yaml  > rolebinding-myrole.yml

[root@master role]# cat rolebinding-myrole.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bindfjw
  namespace: default			#角色绑定必须指定namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myrole					#授权的权限
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: fjw						#要授权的用户

#部署并查看
[root@master role]# kubectl apply -f rolebinding-myrole.yml
rolebinding.rbac.authorization.k8s.io/bindfjw created
[root@master role]# kubectl describe rolebindings.rbac.authorization.k8s.io bindfjw
Name:         bindfjw
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  myrole
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  fjw

3.切换用户测试授权

[root@master role]# kubectl config use-context fjw@kubernetes
Switched to context "fjw@kubernetes".

[root@master role]# kubectl get pods
No resources found in default namespace.

[root@master role]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   6d5h
nginx-svc    ClusterIP   None         <none>        <none>    2d23h

[root@master role]# kubectl get namespaces	#只对了pods跟svc授权，所以不能操作其他
Error from server (Forbidden): namespaces is forbidden: User "fjw" cannot list resource "namespaces" in API group "" at the cluster scope

#切换回管理员
[root@master role]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

2.2.3 clusterrole授权实施

1.建立clusterrole

[root@master role]# kubectl create clusterrole myclusterrole --resource=deployment --verb get --dry-run=client -o yaml > myclusterrole.yml

[root@master role]# cat myclusterrole.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: myclusterrole
rules:
- apiGroups:
  - apps		#由于deployments是组  
  resources:
  - deployments
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - path
  - delete

- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - path
  - delete

- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - path
  - delete

[root@master role]# kubectl apply -f myclusterrole.yml
[root@master role]# kubectl describe clusterrole myclusterrole
Name:         myclusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
  pods              []                 []              [get list watch create update path delete]
  services          []                 []              [get list watch create update path delete]
  deployments.apps  []                 []              [get list watch create update path delete]

2.建立集群角色绑定

[root@master role]# kubectl create clusterrolebinding  clusterrolebindfjw --clusterrole myclusterrole  --user fjw --dry-run=client -o yaml > clusterrolebind-myclusterrole.yml

[root@master role]# vim clusterrolebind-myclusterrole.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: clusterrolebindfjw
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: fjw
  
[root@master role]# kubectl apply -f clusterrolebind-myclusterrole.yml
[root@master role]# kubectl describe clusterrolebindings.rbac.authorization.k8s.io clusterrolebindfjw
Name:         clusterrolebindfjw
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  myclusterrole
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  fjw

3.切换用户测试授权

[root@master role]# kubectl config use-context fjw@kubernetes
Switched to context "fjw@kubernetes".

[root@master role]# kubectl get pods -A
[root@master role]# kubectl get svc -A
[root@master role]# kubectl get deployments.apps -A

[root@master role]# kubectl get namespaces	#没有授权不能操作
Error from server (Forbidden): namespaces is forbidden: User "fjw" cannot list resource "namespaces" in API group "" at the cluster scope

#切换回管理员
[root@master role]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

服务账户的自动化

服务账户准入控制器（Service account admission controller）

如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。
保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
如果 pod 不包含 ImagePullSecrets 设置，那么将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。
将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。
将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中。

服务账户控制器（Service account controller）

服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户

rnetes".




## 服务账户的自动化

服务账户准入控制器（Service account admission controller）

- 如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。

- 保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。

- 如果 pod 不包含 ImagePullSecrets 设置，那么 将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。

- 将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。


- 将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中。


服务账户控制器（Service account controller）

服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户

开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

Flutter for OpenHarmony 技术博客阅读器APP

😩所以我决定用 Flutter for OpenHarmony 做一款程序员专属的技术博客阅读器，主打这些功能：✅ 聚合各大技术平台博客文章，一键下拉刷新✅ 应用内直接打开 WebView 阅读，支持 JS 交互✅ 安全加密存储你的书签和阅读进度，再也不怕丢✅ 响应式数据流，状态管理丝滑到飞起✅ 离线阅读功能，地铁上也能看技术文章这款 APP 完美适配 OpenHarmony 鸿蒙系统，利用四大

开源鸿蒙跨平台开发者社区

鸿潮万相：全品类OpenHarmony定制发行版全景详解

开源鸿蒙跨平台开发者社区

【maaath】Flutter for OpenHarmony 宠物社区应用实战开发

宠物社区应用是一款面向宠物爱好者的社交类应用，用户可以在平台上分享自家宠物的日常照片、参与宠物问答讨论、浏览萌宠内容等。该应用需要具备良好的用户体验，支持图片瀑布流展示、流畅的下拉刷新和上拉加载功能，以及直观的底部导航交互。1. 网络权限配置在2. 页面路由配置在"src": [3. 入口 Ability 配置在if (err!return;});