Kubernetes命名空间默认服务帐户 [英] Kubernetes namespace default service account

问题描述

如果没有另外指定，则该Pod使用命名空间中的默认服务帐户运行，我如何检查默认服务帐户被授权执行的操作，是否需要将每个Pod都安装在该服务中?我们如何在命名空间级别或集群级别禁用此行为.

If not specified otherwise, the pod is run with default service account in the namespace , how can I check what the default service account is authorized to do , and do we need it to be mounted there with every pod, if not, how can we disable this behavior on the namespace level or cluster level.

虽然仍在搜索文档.

环境:Kubernetes 1.12，带有RBAC

Environment: Kubernetes 1.12 , with RBAC

默认服务帐户应处理哪些其他用例?我们可以/应该将其用作服务帐户来创建和管理k8s部署吗? ，例如，我们不会使用真实的用户帐户在集群中创建事物，因为用户在team/org中进出.

What other use cases the default service account should be handling? Can/should we use it as a service account to create and manage the k8s deployments in a namsepace? , for example we will not use real user accounts to create things in the cluster becuase users come and leave in team/org.

推荐答案

1. 会自动为每个命名空间创建一个默认的Serviceaccount，每个名称空间将具有一个默认的sa

kubectl得到sa

kubectl get sa

姓名秘密年龄

默认1 1d

可以在需要时添加

1. serviceccounts.每个Pod都与 一个serviceAccount，但是多个Pod可以使用相同的serviceaccount.

1. serviceccounts can be added when required. Each pod is associated with exactly one serviceAccount but multiple pods can use the same serviceaccount.

pod只能使用来自相同名称空间的服务帐户.

a pod can only use a serviceaccount from the same namespace.

您可以通过在窗格中指定帐户名称来将服务帐户分配给窗格 显现.如果您未明确分配，则广告连播会使用默认的服务帐户 在命名空间中

You can assign a serviceaccount to a pod by specifying the account’s name in the pod manifest. If you don’t assign it explicitly the pod will use the default serviceaccount in the namespace

ServiceAccount的默认权限不允许它 列出或修改任何资源.默认服务- 不允许帐户查看群集状态，更不用说以任何方式对其进行修改

The default permissions for a ServiceAccount dont allow it to list or modify any resources. The default Service- Account isnt allowed to view cluster state let alone modify it in any way

默认情况下，名称空间中的默认serviceAccount除具有权限外没有其他权限 那些未经身份验证的用户.

By default, the default serviceAccount in a namespace has no permissions other than those of an unauthenticated user.

因此默认情况下，广告连播无法 甚至查看群集状态.您可以自行授予他们适当的权限.

Therefore pods by default can’t even view cluster state. Its up to you to grant them appropriate permissions to do that.

kubectl exec -it测试-n foo sh/#curl 本地主机:8001/api/v1/名称空间/foo/services {"kind":状态"，
"apiVersion":"v1"，元数据":{

kubectl exec -it test -n foo sh / # curl localhost:8001/api/v1/namespaces/foo/services { "kind": "Status",
"apiVersion": "v1", "metadata": {

}，状态":失败"，消息":禁止服务:用户 \"system:serviceaccount:foo:default \"无法列出资源 API组\"\"在命名空间\"foo \"，"原因中的\" services \: 禁止"，详细信息":{ "kind":"services"}，"code":403

}, "status": "Failure", "message": "services is forbidden: User \"system:serviceaccount:foo:default\" cannot list resource \"services\" in API group \"\" in the namespace \"foo\"", "reason": "Forbidden", "details": { "kind": "services" }, "code": 403

如上图所示，默认服务帐户无法列出服务

as can be seen above the default service account cannot list services

但是在被赋予适当的角色和角色绑定时，如下所示

but when given proper role and role binding like below

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

现在我可以列出中转服务了

now i am able to list the resurce service

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": []

1. 提供所有服务帐户clusteradmin clusterrole是一个 坏主意最好只给每个人权限 他们需要做自己的工作，而不是一个单独的权限

1. giving all your serviceAccounts the clusteradmin clusterrole is a bad idea its best to give everyone only the permissions they need to do their job and not a single permission more

为每个吊舱创建一个特定的服务帐户是一个好主意 然后通过一个 角色绑定

It’s a good idea to create a specific serviceAccount for each pod and then associate it with a tailor-made role or a clusterrole through a rolebinding

如果您的一个Pod只需要读取Pod 而另一个也需要修改它们，然后创建两个不同的服务帐户 并通过在 广告连播规范

If one of your pods only needs to read pods while the other also needs to modify them then create two different serviceaccounts and make those pods use them by specifying the serviceaccountName property in the pod spec

您可以参考以下链接进行详细说明

you can refer the below link for indepth explaination

具有角色的服务帐户示例

您可以检查

kubectl解释serviceaccount.automountServiceAccountToken并编辑服务帐户

kubectl explain serviceaccount.automountServiceAccountToken and edit the service account

kubectl edit serviceaccount default -o yaml

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没有服务帐户令牌，如下所示.

once this change is done whichever pod you spawn doesnt have a serviceaccount token as can be seen below.

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

这篇关于Kubernetes命名空间默认服务帐户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！