ServiceAccount介绍
了解用户 Kubernetes 区分了两种连接到 API 服务器的客户端。
- 真实的人 (用户)
- pod (更准确地说是运行在 pod 中的应用)
这两种类型的客户端都使用了上述的认证插件进行认证。用户应该被管理在外 部系统中,例如单点登录系统(SSO),但是 pod 使用一种称为service accounts 的机制, 该机制被创建和存储在集群中作为 ServiceAccount 资源。 相反, 没有资源代表用户账户,这也就意味着不能通过 API 服务器来创建、更新或删除用户。
正常用户和 ServiceAccount 都可以属于一个或多个组。 认证插件会连同用户名和用户 ID 返回组。组可以一次给多个用户赋予权限,而不是必须单独给用户赋予权限。 由插件返回的组仅仅是表示组名称的字符串,但是系统内置的组会有一些特殊 的含义。
- system : unauthenticated 组用于所有认证插件都不会认证客户端身份的请求。
- system : authenticated 组会自动分配给一个成功通过认证的用户。
- system : serviceaccounts 组包含所有在系统中的 ServiceAccount。
- system : serviceaccounts : <namespace>组包含了所有在特定命名空间中的 ServiceAccount。
ServiceAccount 就像 Pod、 Secret、 ConfigMap等一样都是资源,它们作用在单独的命名空间, 为每个命名空间 自动创建一个默认的 ServiceAccount (你的 pod 会 一直使用)。 可以像其他资源那样查看 ServiceAccount 列表:
kubectl get sa --all-namespaces

每个 pod 都与一个 ServiceAccount 相关联,但是多个 pod 可以使用同一个ServiceAccount。pod 只能使用同一个命名空间中的ServiceAccount。
创建ServiceAccount
每个命名空间都拥有一个默认的 ServiceAccount, 也可以在需要 时创建额外的 ServiceAccount。 但是为什么应该费力去创建新的 ServiceAccount 而不是对所有的 pod 都使用默认的 ServiceAccount ? 显而易见的原因是集群安全性。不需要读取任何集群元数据的 pod 应该运行在一个受限制的账户下, 这个账户不允许它们检索或修改部署在集群中的任何资源。 需要检索资源元数据的 pod 应该运行在只允许读取这些对象元数据的 ServiceAccount 下。 反之,需要修改这些对象的 pod 应该在它们 自 己的 ServiceAccount 下运行, 这 些 ServiceAccount 允许修改 API 对象。
kubectl create serviceaccount foo


kubectl describe secrets foo-token-pdqnc
将 ServiceAccount 分配给 pod
在创建另外的 ServiceAccount 之后,需要将它们赋值给pod。 通过在 pod 定义文件中spec.serviceAccountName 字段上设置 ServiceAccount 的名称来进行分配。
注意 pod 的 ServiceAccount 必须在 pod 创建时进行设直,后续不能被修改。
cat > sa-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: curl-custom-sa
spec:
serviceAccountName: foo
containers:
- name: main
image: tutum/curl
command: ["sleep", "9999999"]
- name: ambassador
image: luksa/kubectl-proxy:1.6.2
EOF

发现这个 token 来自 foo ServiceAccount 的 token
kubectl exec -it curl-custom-sa -c main cat /var/run/secrets/kubernetes.io/serviceaccount/token

kubectl exec -it curl-custom-sa -c main curl localhost:8001/api/v1/pods

