Kubernetes 命名空间默认服务帐户

Question

如果未指定，则 Pod 在默认服务帐户下运行。

• 如何检查默认服务帐户有权执行的操作？
• 我们需要它与每个吊舱一起安装在那里吗？
• 如果没有，我们如何在命名空间级别或集群级别禁用此行为。
• 默认服务帐户应处理哪些其他用例？
• 我们可以将其用作服务帐户来创建和管理命名空间中的 Kubernetes 部署吗？例如，我们不会使用真实的用户帐户在集群中创建东西，因为用户来来去去。

环境：Kubernetes 1.12，带有RBAC

Answer 1

1. 为每个命名空间自动创建一个默认服务帐户。

Kubectl 获取服务帐户

名称 秘密 年龄

默认 1 1D

2. 可以在需要时添加服务帐户。每个容器只与一个服务帐户关联，但多个容器可以使用相同的服务帐户。

3. 一个 Pod 只能使用同一命名空间中的一个服务帐户。

4. 通过在容器清单中指定帐户名称，将服务帐户分配给容器。如果未显式分配，容器将使用默认服务帐户。

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

6. 默认情况下，命名空间中的默认服务帐户除了未经身份验证的用户的权限外，没有其他权限。

7. 因此，默认情况下，Pod 甚至无法查看集群状态。由您授予他们适当的权限来执行此操作。

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

}， "状态"： ">

失败"， "消息"： "禁止服务： 用户 "系统：服务帐户：foo：默认"无法列出资源 命名空间 "foo" 中的 API 组 " 中的"服务"， "原因"： "禁止"、"详细信息"：{ "种类"： "服务" }， "代码"： 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": []

8. 为您的所有服务帐户提供clusteradmin群集角色是一个 坏主意。最好只授予每个人完成工作所需的权限，而不是更多的单个权限。

最好

9. 为每个容器创建一个特定的服务帐户 然后通过 角色绑定。

10. 如果其中一个 Pod 只需要读取 Pod，而另一个还需要修改它们，请创建两个不同的服务帐户serviceaccountName，并通过在 容器规格

您可以参考以下链接以获取深入解释。

具有角色的服务帐户示例

您可以检查kubectl explain serviceaccount.automountServiceAccountToken并编辑服务帐户

kubectl 编辑服务帐户默认值 -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 都没有服务帐户令牌，如下所示。

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

Answer 2

应用程序/部署可以使用default以外的服务帐户运行，方法是在部署配置的serviceAccountName字段中指定该服务帐户。

我服务帐户或任何其他用户可以执行的操作由赋予(绑定到)的角色决定 - 请参阅 roleBindings 或 clusterRoleBindings;动词根据角色的apiGroups和rules定义resources。

默认情况下，default服务帐户似乎没有被赋予任何角色。可以向default服务帐户授予角色，如此处 #2 中所述。

据此，"...在版本 1.6+ 中，您可以通过在服务帐户上设置automountServiceAccountToken: false来选择退出服务帐户的自动挂载 API 凭据"。

呵呵

Answer 3

• 如何检查默认服务帐户有权执行的操作？

没有一个简单的方法，但auth can-i可能会有所帮助。例如

$ kubectl auth can-i get pods --as=system:serviceaccount:default:default
no

对于用户来说，有auth can-i --list但这似乎不适用于我怀疑是错误的--as。无论如何，您可以在几个动词上运行上述命令，在所有情况下答案都是否定的，但我只尝试了几个。结论：默认情况下，默认服务帐户似乎没有权限(因为在我检查的集群中，我们尚未对其进行配置，AFAICT)。

• 我们需要它与每个吊舱一起安装在那里吗？

不知道这个问题是什么意思。

• 如果没有，我们如何在命名空间级别或集群级别禁用此行为。

您可以在服务或单个容器上设置automountServiceAccountToken: false。服务帐户是按命名空间计算的，因此在服务帐户上完成此操作时，该命名空间中使用此帐户的任何 Pod 都将受到该设置的影响。

• 默认服务帐户应处理哪些其他用例？

默认服务帐户是回退，如果 Pod 未指定 SA，则使用 SA。因此，默认服务帐户不应具有任何权限。为什么 pod 默认情况下需要与 kube API 通信？

• 我们可以将其用作服务帐户来创建和管理命名空间中的 Kubernetes 部署吗？

我不建议这样做，请参阅之前的答案。相反，您应该按照最小权限原则，为需要访问 API 的每个 Pod 类型创建一个服务帐户(绑定到相应的角色/集群角色)。所有其他容器类型都可以使用默认服务帐户，该帐户不应自动挂载 SA 令牌，也不应绑定到任何角色。

Answer 4

kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<serviceaccount> -n <namespace>

作为一个简单的示例。 检查 Testns 命名空间中的默认服务帐户

kubectl auth can-i --list --as=system:serviceaccount:testns:default -n testns 
Resources                                       Non-Resource URLs                     Resource Names     Verbs
selfsubjectaccessreviews.authorization.k8s.io   []                                    []                 [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                    []                 [create]
[/.well-known/openid-configuration]   []                 [get]
[/api/*]                              []                 [get]
[/api]                                []                 [get]

[ ... ]

[/readyz]                             []                 [get]
[/version/]                           []                 [get]
[/version/]                           []                 [get]
[/version]                            []                 [get]
[/version]                            []                 [get]