Service Account 与 User Account 的区别
获取 Kubernetes 跨 Namespace 的 Service Account Token
在 Kubernetes 中，Service Account（服务账号）允许 Pod 或其他资源与 Kubernetes API 进行交互。获取跨 Namespace 的 Service Account 的 Token，可以通过配置 RBAC（基于角色的访问控制）来完成。下面是详细的步骤和解释，如何创建一个 Service Account，并绑定到具有集群权限的 ClusterRole，然后获取其 Token。
1. 创建一个 Service Account
首先，我们需要创建一个 Service Account，指定它将在默认的 Namespace 中。
# 创建 Service Account
kubectl create sa mmwei3-sa
可以使用以下命令查看创建的 Service Account：
kubectl get sa mmwei3-sa -n default
2. 查看集群中的 ClusterRoleBinding
在授予权限之前，首先检查集群中的 ClusterRoleBinding 是否已经存在 cluster-admin 角色。这个角色具有对集群内所有资源的完全访问权限。
# 查看当前的 cluster-admin 角色绑定
kubectl get clusterrolebinding | grep admin
输出应该类似于：
cluster-admin ClusterRole/cluster-admin 51d
3. 为 Service Account 创建 ClusterRoleBinding
接下来，我们需要为 Service Account 绑定一个具有集群级别权限的 ClusterRoleBinding，使其具有跨 Namespace 的操作权限。
# 为 mmwei3-sa 创建 ClusterRoleBinding，绑定 cluster-admin 角色
kubectl create clusterrolebinding mmwei3-cluster-role-binding \
--clusterrole=cluster-admin \
--serviceaccount=default:mmwei3-sa
这会创建一个新的 ClusterRoleBinding，为 mmwei3-sa 授予 cluster-admin 的权限。
4. 查看 ClusterRoleBinding 信息
使用以下命令可以查看刚创建的 ClusterRoleBinding 的详细信息，确保其正确配置。
# 查看 mmwei3-cluster-role-binding 的详细信息
kubectl describe clusterrolebinding mmwei3-cluster-role-binding
输出示例如下：
Name: mmwei3-cluster-role-binding
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount mmwei3-sa default
5. 查看 Service Account 的详细信息
接下来，我们需要获取 mmwei3-sa Service Account 相关的 Secret 信息。每个 Service Account 通常会自动生成一个包含认证 Token 的 Secret。
# 查看 mmwei3-sa 的详细信息
kubectl describe sa mmwei3-sa -n default
在输出中，您可以看到 Mountable secrets 和 Tokens 字段，显示了与此 Service Account 相关的 Secret 名称。
Name: mmwei3-sa
Namespace: default
Mountable secrets: mmwei3-sa-token-nm47k
Tokens: mmwei3-sa-token-nm47k
6. 获取 Service Account 的 Token
要获取 Token，可以通过 kubectl 命令获取 Service Account 对应的 Secret 内容，然后解码 Token 字段。执行以下命令：
# 获取并解码 Token
TOKEN=$(kubectl get secrets mmwei3-sa-token-nm47k -o jsonpath={
.data.token} | base64 --decode)
现在 TOKEN 变量中就包含了该 Service Account 的 Token。
7. 使用 Token 进行验证
使用 curl 命令可以验证获取到的 Token 是否可以正确用于跨 Namespace 的访问。以下命令会使用 Token 访问 Kubelet 的 cAdvisor metrics 接口：
curl https://<kubelet-host>:10250/metrics/cadvisor -k -H "Authorization: Bearer $TOKEN"
将 <kubelet-host> 替换为 Kubernetes Node 的实际 IP 地址。输出应该是一些关于容器资源使用情况的指标数据。
Service Account 与 User Account 的区别
- Service Account 是为 Pod 提供身份认证的账号，用于管理 Pod 和 Kubernetes API 的交互。
- User Account 是为用户设计的账号，是跨 Namespace 使用的；而 Service Account 则是局限于其所在的 Namespace。
- 每个 Namespace 默认会创建一个
default的 Service Account。 TokenController会监控 Service Account 的创建，并为其创建对应的 Secret。
Service Account 的应用实例
以下是通过 Role 和 RoleBinding 为 Service Account 赋予访问权限的简单示例：
1. 创建 Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
name: mysa
namespace: default
应用这个 YAML 文件：
kubectl apply -f mysa.yaml
2. 为 Service Account 绑定权限
创建一个 Role 和 RoleBinding 来限制 mysa 只能获取 Pod 的信息：
# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: mysa-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mysa-binding
namespace: default
subjects:
- kind: ServiceAccount
name: mysa
namespace: default
roleRef:
kind: Role
name: mysa-role
apiGroup: rbac.authorization.k8s.io
应用此配置：
kubectl apply -f role.yaml
3. 使用 Service Account 的权限运行 Pod
# mysa-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: mysa-pod
spec:
serviceAccountName: mysa
containers:
- name: app
image: busybox
command: ["sh", "-c", "sleep 3600"]
将 Pod 部署到集群中：
kubectl apply -f mysa-pod.yaml
进入该 Pod 并测试：
kubectl exec -it mysa-pod -- sh
尝试查看集群的 Pod 资源：
kubectl get pods
如果没有授予删除权限，尝试删除 Pod 时会失败：
kubectl delete pod <pod-name>
# Error: the server doesn't have a resource type "pod"
结论
通过以上步骤，可以创建一个具有跨 Namespace 权限的 Service Account，获取其 Token 并使用它进行 API 操作。通过 RoleBinding 或 ClusterRoleBinding 来管理 Service Account 的权限，可以为其提供精细化的访问控制，从而满足不同场景下的需求。