learning/k8s-advanced/sec/sa-admin.md
本文面向集群管理员,阐述如何管理Service Account。假设您已经熟悉了 Configure Service Accounts for Pods。
<!-- FIXME -->Kubernetes 已经计划了要支持 user account,但是尚未完成。本文中引用了未完成的特性(user account)是为了更好地描述 service account。
[[TOC]]
Kubernetes 明确地区分了 user account 和 service account 的概念,原因如下:
三个组件共同实现了 service account 的 automation:
Admission Controller 是 apiserver 的一部分,它在 Pod 创建或者更新时,对 Pod 执行一些修改。此控制器激活时(默认处于激活状态),当 Pod 被创建或修改时,该控制器将执行如下动作:
ServiceAccount,将 ServiceAccount 设置为 defaultServiceAccount 存在,否则拒绝创建或者修改 PodImagePullSecrets,则 ServiceAccount 中的 ImagePullSecrets 将被添加到 Pod 上volume (其中包含了访问 APIServer 的 token)volumeSource,并挂载到路径 /var/run/secrets/kubernetes.io/serviceaccount自 v1.13 开始,当 BoundServiceAccountTokenVolume 特性被启用时,可以将 service account volume 迁移到一个 projected volume。Service account token 将在一小时后或者 Pod 被删除后过期。
TokenController 作为 controller-manager 的一部分运行。以异步的方式执行如下动作:
启动 controller-manager 时,必须通过 --service-account-private-key-file 参数,向 token controller 传递一个 service account private key 文件。该 private key 将用来为生成的 service account token 签名。类似的,也必须为通过 --service-account-key-file 将其对应的 public key 传递给 kube-apiserver。该 public key 将被用来在认证时验证 token。
控制器确保每个 Service account 都有一个包含 API token 的 Secret。如需为 Service Account 创建额外的 API token,可以创建一个类型为 ServiceAccountToken 的 Secret,并在注解中引用对应的 Service Account,此时,控制器将为其创建一个新的 token:
secret.json
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
kubectl create -f ./secret.json
kubectl describe secret mysecretname
kubectl delete secret mysecretname
Service Account Controller 管理了名称空间中的 ServiceAccount,并确保每一个当前有效的名称空间中都存在一个名为 default 的 ServiceAccount。