kubernetes专题：权限管理 + RBAC + secret kubeconfig
1. 先抛需求
当一个 K8s 集群需要被多个租户共享时，就涉及到了权限问题，比如你是管理员，这时候你会面临着“给每个用户分配一个 Namespace”类似的需求。
更进一步，可能你需要限制特定用户只能够对集群进行特定的操作，比如不能让“张三”有机会执行 kubectl delete node <NODE_NAME> 这种 sao 命令。
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
- ServiceAccount：以用户 user1 为例，来一个 user1-account
apiVersion:v1
kind:ServiceAccount
metadata:
name:user1-account
namespace:default
- 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 了，玩法类似，不赘述。
- 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
- 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,13Dec202315:28:46CST
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,13Dec202315:28:46CST
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
注意几个细节：
-
clusters 下面的 name 记得不要和你系统内默认 config 中的 clusters 重名；
-
server 地址可以抄你的默认 config 里的配置；
-
ca 配置其实也是一样的，你的系统内有，复用配置也行；我这里选择贴一个 base64 版本的内容，为了不引入“外部文件”，方便分发；
-
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 能被操作到：
