-
为每个命名空间自动创建一个默认服务帐户。
kubectl获取服务帐户
姓名和年龄
默认值1 1d
-
可以在需要时添加服务帐户。每个pod只与一个服务帐户关联,但多个pod可以使用同一个服务帐户。
-
-
通过在pod清单中指定帐户名称,服务帐户被分配给pod。如果您没有明确分配它,pod将使用默认的服务帐户。
-
列出或修改任何资源。默认服务帐户不允许查看群集状态,更不用说以任何方式修改它。
-
-
kubectl exec-it测试-n foo sh/#curl
“apiVersion”:“v1”,“元数据”:{
},“status”:“Failure”,“message”:“禁止服务:User”
"system:serviceaccount:foo:default“无法列出资源
命名空间“foo”“reason”中API组“”中的“services”:
“禁止”,“细节”:{
“kind”:“services”},“code”:403
但当给予适当的角色和角色绑定时,如下所示
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: foo-role
namespace: foo
rules:
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: null
name: test-foo
namespace: foo
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: foo-role
subjects:
- kind: ServiceAccount
name: default
namespace: foo
现在我可以列出复活服务
kubectl exec -it test -n foo sh
/ # curl localhost:8001/api/v1/namespaces/foo/services
{
"kind": "ServiceList",
"apiVersion": "v1",
"metadata": {
"selfLink": "/api/v1/namespaces/bar/services",
"resourceVersion": "457324"
},
"items": []
-
clusteradmin
ClusterRole是一个
坏主意。最好只给每个人完成工作所需的权限,而不是一个权限。
-
最好为每个pod创建一个特定的服务帐户
角色绑定。
-
如果一个pod只需要读取pod,而另一个也需要修改它们,那么创建两个不同的服务帐户,并通过指定
serviceaccountName
中的属性
吊舱规格。
您可以参考下面的链接以获得深入的解释。
Service account example with roles
你可以查一下
kubectl explain serviceaccount.automountServiceAccountToken
apiVersion: v1
automountServiceAccountToken: false
kind: ServiceAccount
metadata:
creationTimestamp: 2018-10-14T08:26:37Z
name: default
namespace: default
resourceVersion: "459688"
selfLink: /api/v1/namespaces/default/serviceaccounts/default
uid: de71e624-cf8a-11e8-abce-0642c77524e8
secrets:
- name: default-token-q66j4
完成此更改后,您生成的任何一个pod都没有serviceaccount令牌,如下所示。
kubectl exec tp -it bash
root@tp:/# cd /var/run/secrets/kubernetes.io/serviceaccount
bash: cd: /var/run/secrets/kubernetes.io/serviceaccount: No such file or directory
