玩转 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:

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

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 是个啥的资料太多了，我就不过多啰嗦了。

贴一个 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.