玩转 K8s 权限控制：RBAC + kubeconfig 搞定 kubectl 权限管理那些事

1. 先抛需求

当一个 K8s 集群需要被多个租户共享时，就涉及到了权限问题，比如你是管理员，这时候你会面临着“给每个用户分配一个 Namespace”类似的需求。

更进一步，可能你需要限制特定用户只能够对集群进行特定的操作，比如不能让“张三”有机会执行 kubectl delete node <NODE_NAME> 这种 sao 命令。

在上一篇文章《通过 VS Code 优雅地编辑 Pod 内的代码（非 NodePort）》中我们讲到怎样在不暴露一堆 NodePort 的前提下，通过 VS Code 更新 Pod 内的代码。VS Code 里去 Attach Pod 其实也是用的本地 kubeconfig 来和 apiserver 通信，进而操作到 Pod。换言之，要实现“多租户通过 VS Code 连接自己的 Pod”这个需求，也涉及到给不同租户创建合适的“最小权限 kubeconfig”。行，今天就来解决这个问题。

2. RBAC 配置

整体就两步，先倒腾 RBAC，然后倒腾 kubeconfig。我们先来看 RBAC吧。

2.1. K8s 里的 RBAC 机制介绍

先复习下 K8s 里的 RBAC 机制。

(这时候需要用到 GPT 了。)

• 我：Hello ChatGPT，用中文总结下 K8s 里的 RBAC 是个啥。

• ChatGPT:

在 Kubernetes 中，RBAC 是一种强大的访问控制机制，用于管理对集群资源的访问权限。RBAC 可以帮助管理员精确地控制用户、ServiceAccount 或其他实体对 Kubernetes API 中资源的操作权限。RBAC 基于角色的授权模型使得管理员可以定义角色和角色绑定，从而实现对不同用户或实体的访问权限控制。

RBAC 由四个基本概念组成：

• 角色（Role）：角色定义了一组操作权限，例如对某个命名空间下资源的读取、创建或删除等操作。
• 角色绑定（RoleBinding）：角色绑定将特定的角色授予 User、Group 或者 ServiceAccount，从而赋予它们相应的权限。
• 集群角色（ClusterRole）：类似于角色，但作用范围更广，可以授权对整个集群中资源的操作权限。
• 集群角色绑定（ClusterRoleBinding）：将集群角色绑定给 User、Group 或者 ServiceAccount，授予它们在整个集群范围内的权限。

通过 RBAC，管理员可以根据需求精确控制不同用户或实体在集群中的权限范围，避免了不必要的权限泄露或误操作，提高了集群的安全性和管理灵活性。

行，就总结到这里，接着我们要实操了。

2.2 创建 ServiceAccount、Role、RoleBinding 和 Secret

1. ServiceAccount：以用户 user1 为例，来一个 user1-account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: user1-account
  namespace: default

1. Role：继续来一个 user1-role

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

这里就可以在 rules 下精细地控制这个角色所能够访问的资源、执行的操作了。如果需要集群维度资源的控制，比如 Node，那就得用到 ClusterRole 了，玩法类似，不赘述。

1. RoleBinding：把用户和角色绑起来

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

1. Secret：在 K8s 1.24 版本之后，ServiceAccount 对于的 Secret 就不会自动创建了。哎，手动搞吧

apiVersion: v1
kind: Secret
metadata:
  name: user1-account-secret
  annotations:
    kubernetes.io/service-account.name: "user1-account"
type: kubernetes.io/service-account-token

这个 Secret 创建出来之后，K8s 会自动将 ServiceAccount 对应的 token 写进这个 Secret。

一顿 apply 操作之后，RBAC 相关的几个资源就都有了。前几个没啥好说的，Secret 的关键字段贴一下，大家感受下 K8s 在背地里偷偷干了些啥：

• kgsec user1-account-secret -o yaml

apiVersion: v1
data:
  ca.crt: LS0t……==
  namespace: ZGVmYXVsdA==
  token: ZXlKa……=
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: user1-account
  name: user1-account-secret
  namespace: default
type: kubernetes.io/service-account-token

data 部分，发现了吗，ca.crt 和 token 信息被填进去了。这两段配置在后面要用到。

3. 配置 kubeconfig 文件

user1 的权限配置已经 OK 了，下一步就是将 token 搞到 kubeconfig 里。

3.1 kubeconfig 文件介绍

呵呵，老规矩，我这么懒的人，怎么可能自己总结。

• ChatGPT：

kubeconfig 是 Kubernetes 的一个配置文件，它包含了访问 Kubernetes 集群所需的所有信息。这些信息包括集群的地址、用户证书、用户名和命名空间等。kubeconfig 文件使得用户和 CI/CD 工具可以方便地与 Kubernetes 集群进行交互。

kubeconfig 文件通常位于用户的主目录下的 .kube 目录中，文件名为 config。然而，用户也可以通过设置 KUBECONFIG 环境变量来指定其他位置的 kubeconfig 文件。

kubeconfig 文件主要由以下三部分组成：

• 集群（clusters）：定义了要连接的 Kubernetes 集群的信息，包括集群的名称、服务器的地址和 CA 证书。

• 用户（users）：定义了用户的认证信息，包括用户的名称、客户端证书和密钥。

• 上下文（contexts）：定义了用户和集群之间的关系。一个上下文包含了一个用户和一个集群，以及用户在该集群中的默认命名空间。

通过在 kubeconfig 文件中定义不同的上下文，用户可以轻松地在不同的 Kubernetes 集群和命名空间之间切换。

稍显稚嫩，不过将就吧。关于 kubeconfig 是个啥的资料太多了，我就不过多啰嗦了。

贴一个 minikube 默认创建的 kubeconfig 文件：

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/danielhu/.minikube/ca.crt
    extensions:
    - extension:
        last-update: Wed, 13 Dec 2023 15:28:46 CST
        provider: minikube.sigs.k8s.io
        version: v1.32.0
      name: cluster_info
    server: https://127.0.0.1:60719
  name: minikube
contexts:
- context:
    cluster: minikube
    extensions:
    - extension:
        last-update: Wed, 13 Dec 2023 15:28:46 CST
        provider: minikube.sigs.k8s.io
        version: v1.32.0
      name: context_info
    namespace: default
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /Users/danielhu/.minikube/profiles/minikube/client.crt
    client-key: /Users/danielhu/.minikube/profiles/minikube/client.key

总之就是 clusters 里定义一堆可用的集群信息，users 里定义一堆用户信息，然后在 contexts 里将 user 和 cluster 关联起来；最后通过切换 context 就可以实现切换“用户/集群”了。

3.2 具体的 kubeconfig 配置

前面创建的 Secret 里有一个 token，将其复制出来备用。（这里要注意，别拿 base64 转码后的结果。kubectl get -o yaml 拿到的是 base64 编码的；kubectl describe 拿到的是原始的，你可以直接拿原始的，也可以拿编码后的自己 echo "xxx" | base64 -d 解码一下。

此外 Secret 里有一个 ca.crt，这个 ca 的内容是集群维度统一的，你在其他地方复制也行，不过这里有，顺手拿一个也不打紧。这里需要是 base64 编码后的内容，注意这个细节。

然后准备这样一个 kubeconfig 文件：

apiVersion: v1
kind: Config
clusters:
- name: minikube1
  cluster:
    server: https://127.0.0.1:60719
    certificate-authority-data: <ca.crt, base64>

users:
- name: user1-account
  user:
    token: <token>

contexts:
- name: user1-context
  context:
    cluster: minikube1
    namespace: default
    user: user1-account

注意几个细节：

1. clusters 下面的 name 记得不要和你系统内默认 config 中的 clusters 重名；
2. server 地址可以抄你的默认 config 里的配置；
3. ca 配置其实也是一样的，你的系统内有，复用配置也行；我这里选择贴一个 base64 版本的内容，为了不引入“外部文件”，方便分发；
4. token 填写前面准备的 token，非 base64。

3.3 kubeconfig 切换测试

最简单粗暴的办法，你可以直接备份 $HOME/.kube/config，然后将这个新文件替换进去，这样就能测试新的 kubeconfig 是不是正常工作了。

或者，你可以配置上 KUBECONFIG 环境变量，将新的 kubeconfig 保存路径追加进去。比如 mac 可以这样：

export KUBECONFIG=/Users/danielhu/.kube/config:/Users/danielhu/Work/test/kubeconfig

Windows 系统得用分号（；）。

这时候你再执行 kubectl config view 就可以看到一个 merge 之后的 kubeconfig 配置，也就是新的旧的 kubeconfig 都在一起了。

下一步，我推荐你用 kubectx 来切换 context：

• kubectx

minikube
user1-context

• kubectx user1-context

OK，这时候就能切换到新的 context 了。接着可以试下是不是只有 pods 能被操作到：

4. 总结

打完收工。没啥好总结的。See you next day.