Kubernetes（K8s）中的权限认证涉及多个组件的安全交互。用户或程序通过 API Server 发送请求，这些请求由 API Server 进行验证和授权，然后将指令下发到对应组件（如 Kubelet）进行实际操作。以下是一个简化的流程图：

简单来说权限认证就是：ApiServer 允许 谁 对什么资源，执行什么操作的过程。

  RBAC（基于角色的访问控制）是 Kubernetes 中用于管理权限的机制。它通过Role和Roleding来控制 谁 对什么资源，执行什么操作。

Role 可以定义多种操作权限，包括但不限于：

3.1.1 场景说明

在生产环境中，TCF框架用到了 Pod 之间的长连接方式。Kubernetes 的 Service 默认采用轮询负载均衡，这可能导致负载不均衡。因此，我们需要自行做负载均衡。方法是先获取 被访问的所有Pod 的 IP 地址，并通过业务逻辑进行负载均衡。

如图， Pod A1 A2 A3需要获取Pod B1 B2 B3的IP地址，用于建立长连接实现访问，并且Pod B的IP地址发生变化时，Pod A需要及时更新。

3.1.2 权限需求

为了实现这一点，Pod A需要以下权限

• Get权限：用于获取 Pod B 的 IP 地址；

• List权限：用于列出所有需要的Pod B的IP地址；

• Watch权限：用于监听 Pod B的变动，以便在 Pod B被销毁和重建时更新 IP 地址。

3.1.3 实现步骤

1. 创建 ServiceAccount(SA)：供应用程序A使用，也可以直接使用默认的sa(default)，但不推荐，原因是其他所有使用default sa的pod都会具备权限，不符合最小权限原则。

2. 创建 Role：定义需要的权限(Get 、list 和 Watch)。

3. 创建 RoleBinding：将 Role 绑定到 SA。

4. 创建 ClusterRole 和 ClusterRoleBinding（如果需要集群范围的权限）：可选。

3.1.4 示例配置

以下是一个完整的 YAML 示例：

3.1.5 创建效果验证

在创建 RoleBinding 之前，可以使用以下命令验证权限：

此命令表示 我用my-app-sa这个服务账号能否执行get pod操作，如果输出yes,表示具有权限，如果输出no, 表示没有权限。

在创建 RoleBinding 之后，再次验证：

除了给程序授权，RBAC还可用控制对人的授权。当管理员需要执行kubectl命令的时候，也遵循RBAC权限。那管理员如何使用呢？

3.2.1 场景说明

由于管理员和程序不同，管理员无法直接使用SA，能使用的只有token。此时我们需要为SA创建一个secret，从secret中获取token。

管理员需要执行kubectl命令，那一定少不了 kubeconfig文件。这个文件一般在  ~/.kube/config，其中 client-key-data 这里填的内容就是来自于ServiceAccount的token。拥有这个token即代表拥有管理员权限。

3.2.2 权限需求

admin权限，也就是允许admin用户对 所有资源 可以执行 任何操作。

3.2.3 实现步骤

保存上述文件为 secret.yaml后，执行 kubectl apply -f secret.yaml即可创建secret

3.2.4 获取token

创建好之后，通过 kubectl get secrets -n kube-system admin-token -oyaml 获取token即可，拿到了token，填入前面kubeconfig中的 client-key-data 部分，即可以管理员的身份执行kubectl命令了。

通过以上两个生产环境的案例，介绍了RBAC权限的基本配置和应用。除此之外涉及到K8S中其他需要权限认证的场景也是类似的方式。这种权限管理方式较为灵活，并且也具有较强的系统安全性和可控性，遵循最小权限原则进行授权。

END