一、概述

---

在Kubernetes（K8s）中，ServiceAccount是用于认证和授权集群内的Pod操作的身份标识。ServiceAccount与特定的命名空间相关联，提供了一种控制对Kubernetes API和其他资源访问权限的方式。

1.1 默认ServiceAccount

当前集群版本v1.26.2

​ 当我们创建一个命名空间时，集群会自动在该命名空间下创建一个默认的ServiceAccount服务账号default，当在该命名空间下创建pod资源时，如果没有指定ServiceAccount，那么将会自定挂载默认的ServiceAccount服务账号。

[root@k8s-master01 ~]# kubectl create ns dev
[root@k8s-master01 ~]# kubectl get sa -n dev
NAME      SECRETS   AGE
default   0         19s

1.2 作用级别

ServiceAccount同样是Kubernetes中的资源，与Pod、ConfigMap类似，且作用于独立的命名空间，也就是ServiceAccount是属于命名空间级别的。

注意

• 1.21以前版本的集群中，Pod中获取Token的形式是通过挂载ServiceAccount的Secret来获取Token，这种方式获得的Token是永久的。该方式在1.21及以上的版本中不再推荐使用，并且在1.25及以上版本的集群中，ServiceAccount将不会自动创建对应的Secret。
• 1.21及以上版本的集群中，直接使用TokenRequest (opens new window) API获得Token (opens new window)，并使用投射卷（Projected Volume）挂载到Pod中。使用这种方法获得的Token具有固定的生命周期，并且当挂载的Pod被删除时这些Token将自动失效。详情请参见Token安全性提升说明 (opens new window)。

二、ServiceAccount创建

---

2.1 yaml文件创建

• pod-reader-sa.yaml资源清单

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: dev

• 应用

kubectl apply -f pod-reader-sa.yaml 

2.2 命令行创建

kubectl create sa -n dev pod-reader

2.3 参数解读

• pod-reader： sa的名称，引用的时候使用。
• dev: sa作用于独立命名空间，这里指定dev。

说明

上面ServiceAccount(简称sa)创建后，其实是没有任何权限的，我们真正使用的时候，是会根据实际场景授权该sa有相应的权限来达到操作集群的资源的目的。

三、ServiceAccount 授权

---

​ 在 Kubernetes 中，我们可以使用 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 来授权 ServiceAccount 对不同资源的访问权限。

3.1 角色概念

• Role：用于在单个命名空间内定义权限。
• ClusterRole：用于在整个集群范围内定义权限。
• RoleBinding：将 Role 授予特定的 ServiceAccount，限定在单个命名空间内。
• ClusterRoleBinding：将 ClusterRole 授予特定的 ServiceAccount，允许在整个集群范围内生效。

3.2 创建 Role 或 ClusterRole

• 创建Role资源文件

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-role
  namespace: dev			# 作用命名空间
rules:
- apiGroups: [""]  	   		# 支持的API组列表，""空字符串，表示核心API群
  resources: ["pods"]  		# 支持的资源对象列表,这里只授权pod资源相关操作
  verbs: ["get", "list"]	# 权限条目，这里指可以执行的操作

• 创建ClusterRole资源文件

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-cluster-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

总结

上面Role 或 ClusterRole 定义中，规则中的resources和verbs对我们来说是比较重要的参数项，下面简单列举常用的资源及操作:

• resources
  • Pod
  • Service
  • Deployment
  • ConfigMap
  • Secret
  • Namespace
  • ServiceAccount
  • StatefulSet
• verbs
  • get：获取资源的信息。
  • list：列出资源的信息。
  • watch：监视资源的变化。
  • create：创建新资源。
  • update：更新现有资源的属性。
  • patch：对现有资源进行局部更新。
  • delete：删除现有资源。
  • exec：在容器中执行命令。

注: 不同的资源类型可能支持的 verbs 可能会有所不同。具体支持的操作取决于资源对象自身的定义和 Kubernetes 版本的特定实现

3.3 创建 RoleBinding 或 ClusterRoleBinding

• RoleBinding资源文件

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-role-binding
  namespace: dev
subjects:
- kind: ServiceAccount	# 指定 sa类型
  name: pod-reader		# 指定创建的sa名称
  namespace: dev		# 指定sa命名空间
roleRef:
  kind: Role
  name: pod-role
  apiGroup: rbac.authorization.k8s.io

• ClusterRoleBinding资源文件

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-cluster-role-binding
subjects:
- kind: ServiceAccount
  name: pod-reader
  namespace: dev
roleRef:
  kind: ClusterRole
  name: pod-cluster-role
  apiGroup: rbac.authorization.k8s.io

总结

RoleBinding与ClusterRoleBinding是 Kubernetes中用于将 Role和ClusterRole授予特定 Subject（如 ServiceAccount、User、Group）的授权机制,实现对集群级别资源和操作的授权和访问控制。

• subjects：指定授权主体（Subject），即要将 ClusterRole 授予的对象。

  • kind：指定主体类型，常见值包括 ServiceAccount、User 和 Group。

  • name：主体的名称。

  • namespace：如果主体是 ServiceAccount，则指定关联的命名空间。

• roleRef：指定要授予的 ClusterRole或者Role。

  • kind：指定要授予的角色类型， ClusterRole或者Role。
  • name：要授予的 ClusterRole或者Role 的名称。
  • apiGroup：指定 ClusterRole 或者Role所属的 API 组，默认为 rbac.authorization.k8s.io。

另外: rolebinding可以绑定role及clusterrole，clusterrolebing只能绑定clusterrole。

3.4 在pod中使用

在创建pod资源时可以通过serviceAccountName指定需要的sa名称

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
spec:
  serviceAccountName: pod-reader
  containers:
  - image: nginx:latest
    name: nginx
    ports:
      - containerPort: 80

3.5 查看pod状态

3.6 总结

在pod中使用，这种一般是我们部署的应用运行在pod中，调用集群api操作K8s集群资源时的应用场景,后续会出一个使用真实的使用场景。