Kubernetes 中 RBAC、ServiceAccount 的区别和联系

Author：rab

---

---

前言

首先，Kubernetes (K8s) RBAC (Role-Based Access Control) 和 ServiceAccount 都是 Kubernetes 中用于控制访问权限的两个重要概念，但是它们之间有一些区别和联系。

一、区别

1、RBAC

RBAC 是一种授权机制，用于定义和管理用户或组对 Kubernetes 资源的访问权限。它基于角色和角色绑定的概念，可以细粒度地控制用户对集群中的资源的操作权限。

2、ServiceAccount

ServiceAccount 是用于身份验证和授权的 Kubernetes 资源，它代表一个应用程序或服务在集群中的身份。每个 Pod 都会自动关联一个默认的 ServiceAccount，用于与 API 服务器进行通信。

二、联系

1、RBAC

RBAC 和 ServiceAccount 都是 Kubernetes 中的安全机制，用于确保集群中的资源只能被授权的实体访问。RBAC 提供了更细粒度的控制，而 ServiceAccount 则用于标识和认证应用程序或服务（如 Pod）。

2、ServiceAccount

ServiceAccount 是 RBAC 的一部分，RBAC 可以使用 ServiceAccount 来授权用户或组对资源的访问权限。通过为 ServiceAccount 分配适当的角色和角色绑定，可以限制应用程序或服务对资源的访问权限。

三、案例

接下来我们使用 RBAC 和 ServiceAccount 来控制对 Kubernetes 资源的访问权限。

1、创建 my-namespace 命名空间

进行资源隔离，形成一个好的习惯，要不然一堆资源集中在一起，乱七八糟的。

kubectl create namespace my-namespace

2、创建角色（Role）

vim role-test.yaml

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

kubectl apply -f role-test.yaml

3、角色绑定（RoleBinding）

vim role-bind.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-role-binding
  namespace: my-namespace
subjects:
- kind: ServiceAccount
  name: default
  namespace: my-namespace
roleRef:
  kind: Role
  name: my-role
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f role-bind.yaml

案例分析：

该案例中，我们创建了一个角色 my-role，并将其绑定到 default ServiceAccount。这意味着 default ServiceAccount 在 my-namespace 命名空间中具有对 pods 资源的 get 和 list 权限。其他用户或组如果没有被授予相应的角色和角色绑定，则无法访问这些资源。

请注意！这只是一个简单的示例，实际使用中可能需要更复杂的 RBAC 规则和更多的 ServiceAccount 来满足实际需求。

思考？

问：如果我们没有显示地指定 Pod 的 ServiceAccount，那 Pod 被创建后所属的 ServiceAccount 是什么？

答：是 default。每个 Pod 都有一个唯一的 ServiceAccount，用于与 Kubernetes API 服务器进行身份验证和授权。这样可以确保每个 Pod 在访问集群中的资源时都有自己的身份。而且要搞清楚的是：每个命名空间都会自动创建一个名为 default 的 ServiceAccount，如果没有指定其他的 ServiceAccount，Pod 将会自动关联到该默认的 ServiceAccount。如下图就是 Kubernetes 集群中 default 名称空间中默认的 ServiceAccount（且名为 default）。

但是，默认的 ServiceAccount 具有较低的权限，并且通常只能访问自己所在命名空间的资源。如果需要更细粒度的访问控制，可以创建自定义的 ServiceAccount，并为其分配适当的角色和角色绑定。

问：那我们如何在 Kubernetes 中创建自定义的 ServiceAccount 呢？

答：可通过以下两种方式来定义。

1、命令行方式

# 首先创建一个namespace
kubectl create namespace my-namespace

# 接着就开始创建ServiceAccount资源
kubectl create serviceaccount my-serviceaccount -n my-namespace

2、yaml 文件方式

# 首先创建一个namespace
kubectl create namespace my-namespace

# 接着就开始创建ServiceAccount资源
vim my-serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceaccount
  namespace: my-namespace

# 执行创建
kubectl apply -f my-serviceaccount.yaml

serviceaccount 创建完成之后，就可以创建角色并进行角色绑定应用了。

—END