这是一篇针对service accounts(服务账户)的集群管理员指南。 它呈现了 User Guide to Service Accounts中的信息。
对授权和用户账户的支持已在规划中,当前并不完备,为了更好地描述service accounts,有时这些不完善的特性也会被提及。
Kubernetes 区分用户账户和服务账户的概念主要基于以下原因:
三个独立组件协作完成服务账户相关的自动化:
对pod的改动通过一个被称为Admission Controller的插件来实现。它是apiserver的一部分。 当pod被创建或更新时,它会同步地修改pod。 当该插件处于激活状态(在大多数发行版中都是默认的),当pod被创建或更新时它会进行以下动作:
ServiceAccount
设置,将其 ServiceAccount
设为 default
。ServiceAccount
存在,否则拒绝该pod。ImagePullSecrets
设置,那么 将 ServiceAccount
中的ImagePullSecrets
信息添加到pod中。volume
添加到pod中。/var/run/secrets/kubernetes.io/serviceaccount
的 volumeSource
添加到pod下的每个容器中。Token管理器是controller-manager的一部分。 以异步的形式工作:
你需要通过 --service-account-private-key-file
参数项传入一个服务账户私钥文件至Token管理器。 私钥用于为生成的服务账户token签名。
同样地,你需要通过 --service-account-key-file
参数将对应的公钥传入kube-apiserver。 公钥用于认证过程中的token校验。
控制器中有专门的循环来保证每个服务账户中都存在API token对应的Secret。 当需要为服务账户创建额外的API token时,创建一个类型为 ServiceAccountToken
的Secret,并在annotation中引用服务账户,控制器会生成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
服务账户管理器管理各命名空间下的服务账户,并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户
此页是否对您有帮助?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.