这是一个关于 service accounts 的集群管理指南,它假设您了解 Service Accounts 用户指南。
计划支持授权和用户帐户,但并不完整。有时会引用不完整的功能以便更好地描述 service accounts。
Kubernetes 区分用户帐户和 service account 的概念有以下几个原因:
三个独立的组件合作实现 service accounts 的自动化:
pod 的修改是通过一个名为准入控制器的插件实现的。它是 apiserver 的一部分。它可以同步操作,以便在创建或更新 pod 时对其进行修改。 当此插件处于活动状态时(默认情况下在大多数发行版中),则在创建或修改 pod 时执行以下操作:
ServiceAccount
,它将 ServiceAccount
设置为 default
。ServiceAccount
存在,否则拒绝它。ImagePullSecrets
,则将 ServiceAccount
的 ImagePullSecrets
添加到 pod 中。volume
。volumeSource
,该 volume 被挂载到 /var/run/secrets/kubernetes.io/serviceaccount
。TokenController 作为控制器-管理器的一部分异步运行。它用于:
您必须使用 --service-account-private-key-file
选项将 service account 私钥文件传递给控制器-管理器中的令牌控制器。
私钥将用于签署生成的 service account 令牌。同样,您必须使用 --service-account-key-file
选项将相应的公钥传递给
kube-apiserver。公钥将用于在身份验证期间验证令牌。
控制器循环确保每个 service account 都存在具有 API 令牌的 secret。要为 service account 创建其他 API 令牌, 请使用 ServiceAccountToken 引用 service account 的注解创建类型的 secret,控制器将使用生成的令牌更新它:
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 控制器在命名空间中管理 ServiceAccount,并确保每个活动命名空间中都存在一个名为 default
的 ServiceAccount。
此页是否对您有帮助?
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.