kubernetes为什么需要默认的serviceaccount

本文讲解"kubernetes为什么需要默认的serviceaccount",希望能够解决相关问题。

什么是k8s的serviceAccount?

在 Kubernetes 中,ServiceAccount 是一种用于身份验证和授权的对象。它为 Pod 提供了一种身份,以便它们可以与 Kubernetes API 交互,并且可以通过 Role 和 RoleBinding 为它们分配特定的权限。

ServiceAccount 是 Kubernetes 中的一种重要概念,它的实际使用场景包括:

  • 访问 Kubernetes API:ServiceAccount 为 Pod 提供了访问 Kubernetes API 的凭据,使得它们可以查询和修改 Kubernetes 中的资源。例如,一个 Pod 可以使用 ServiceAccount 访问 Kubernetes API 获取其他 Pod 的信息,或者创建、更新、删除其他资源。

  • 认证和授权:ServiceAccount 为 Pod 提供了一种身份,使得 Kubernetes 可以对其进行认证和授权。例如,Kubernetes 可以使用 ServiceAccount 来验证 Pod 是否有权限访问某个资源,并根据 Role 和 RoleBinding 为其分配特定的权限。

  • 安全性:ServiceAccount 可以帮助提高 Kubernetes 集群的安全性。通过为每个 Pod 分配一个独立的 ServiceAccount,并为其分配最小特权的权限,可以降低潜在的安全风险。

  • 多租户:ServiceAccount 可以帮助实现 Kubernetes 中的多租户。通过为每个 Namespace 创建一个独立的 ServiceAccount,并为其分配特定的权限,可以实现不同 Namespace 之间的隔离和安全性。

认证和授权:ServiceAccount 为 Pod 提供了一种身份,使得 Kubernetes 可以对其进行认证和授权。例如,Kubernetes 可以使用 ServiceAccount 来验证 Pod 是否有权限访问某个资源,并根据 Role 和 RoleBinding 为其分配特定的权限。

安全性:ServiceAccount 可以帮助提高 Kubernetes 集群的安全性。通过为每个 Pod 分配一个独立的 ServiceAccount,并为其分配最小特权的权限,可以降低潜在的安全风险。

多租户:ServiceAccount 可以帮助实现 Kubernetes 中的多租户。通过为每个 Namespace 创建一个独立的 ServiceAccount,并为其分配特定的权限,可以实现不同 Namespace 之间的隔离和安全性。

为什么每一个ns下都有默认的sa?

在 Kubernetes 中,每个 namespace 下都有一个默认的 ServiceAccount,原因如下:

简化配置:默认的 ServiceAccount 使得用户无需为每个 Pod 创建一个新的 ServiceAccount,从而简化了配置。如果 Pod 没有指定 ServiceAccount,它将自动关联到默认的 ServiceAccount。

容器运行时身份:ServiceAccount 提供了一种将身份信息(如 API 访问凭据)与 Pod 关联的方法。默认的 ServiceAccount 为 Pod 提供了基本的身份信息,以便它们可以与 Kubernetes API 交互。

安全性:默认的 ServiceAccount 通常具有较少的权限,这有助于遵循最小特权原则。这意味着,如果 Pod 不需要访问 Kubernetes API 的特定资源,它可以使用默认的 ServiceAccount,从而降低潜在的安全风险。

易于管理:默认的 ServiceAccount 使得集群管理员可以更轻松地管理和控制对 Kubernetes API 的访问。例如,管理员可以通过修改默认 ServiceAccount 的权限来限制或扩展某个 namespace 下所有 Pod 的访问权限。

总之,默认的 ServiceAccount 是 Kubernetes 中的一种设计,旨在简化配置、提供基本的身份信息、增强安全性并便于管理。然而,在实际应用中,根据需要创建特定的 ServiceAccount 并为其分配适当的权限是一种更好的做法。

default sa yaml

k get secret default-token-lnzs9 -oyaml
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVVFZZeWZ0VDFBdnQ1ZHlORmM4WUN...
  HU4NkZ0bTNyRkNaNUY3N1FmTVpCNU9hYXE2TkRDRwp3ems9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  namespace: ZGVmYXVsdA==
  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltcEdjRkkwWlRSRU55MW1NeTF4YWt0U1pYQm9Sems0U1dJd2RHMTV
。。。
  xQUJsdVlnSGJva3ZB
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: b90818be-0587-4a7a-8abb-c0b214cdaba0
  creationTimestamp: "2022-06-26T07:04:38Z"
  name: default-token-lnzs9
  namespace: default
  resourceVersion: "11436"
  uid: 37c38aaa-bd9d-4beb-abf9-cdc94bcc697a
type: kubernetes.io/service-account-token

默认的sa下都会挂一个secret,这个secret是从哪里来的?

在 Kubernetes 中创建一个新的 Namespace 时,系统会自动为该 Namespace 下的默认 ServiceAccount 创建一个关联的 Secret。这个 Secret 是用于存储访问 Kubernetes API 的凭据的,通常包含一个 token 和一个 CA 证书。这个 Secret 的来源如下:

Kubernetes 控制平面的 Token Controller 自动创建并管理这个 Secret。当创建一个新的 ServiceAccount 时,Token Controller 会生成一个新的 token,并将其存储在一个新的 Secret 中。

该 Secret 会被自动关联到对应的 ServiceAccount。Secret 的类型为 kubernetes.io/service-account-token,并且在 Secret 的 annotations 字段中包含了关联的 ServiceAccount 信息。

当创建一个使用该 ServiceAccount 的 Pod 时,Kubernetes 会自动将这个 Secret 挂载到 Pod 的容器中。默认情况下,Secret 会被挂载到 /var/run/secrets/kubernetes.io/serviceaccount 目录下。容器内的应用程序可以使用这个 token 和 CA 证书与 Kubernetes API 交互。

要查看默认 ServiceAccount 关联的 Secret,可以使用以下命令:

kubectl get serviceaccounts default -o jsonpath='{.secrets[0``].name}' -n <namespace>

将 替换为实际的 Namespace 名称。然后,使用以下命令查看 Secret 的详细信息:

kubectl get secret <secret_name> -o yaml -n <namespace>

将 <secret_name> 替换为上一步获取到的 Secret 名称,将 替换为实际的 Namespace 名称。

一道关于RBAC的CKA考题

假设我们有一个运行在 Kubernetes 中的 Web 应用程序,它需要访问 Kubernetes API 来获取其他 Pod 的信息。

为了实现这个功能,我们可以创建一个 ServiceAccount,并为其分配访问 Kubernetes API 的权限。具体步骤如下:

1、创建一个新的 ServiceAccount

kubectl create serviceaccount myapp-sa

2、创建一个新的 Role

用于授予 ServiceAccount 访问 Kubernetes API 的权限:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myapp-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"] # 注意只有get和list的权限,并不需要update的权限

3、创建一个新的 RoleBinding

将 ServiceAccount 和 Role 关联起来:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myapp-rolebinding
subjects:
- kind: ServiceAccount
  name: myapp-sa
roleRef:
  kind: Role
  name: myapp-role
  apiGroup: rbac.authorization.k8s.io

4、在 Pod 中使用 ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  serviceAccountName: myapp-sa
  containers:
  - name: myapp-container
    image: myapp-image

在这个例子中,我们创建了一个名为 myapp-sa 的 ServiceAccount,并为其分配了访问 Kubernetes API 的权限。然后,我们创建了一个名为 myapp-role 的 Role,并将其与 ServiceAccount 关联起来。最后,我们在 Pod 中使用了这个 ServiceAccount。

这样,我们的 Web 应用程序就可以使用这个 ServiceAccount 访问 Kubernetes API,获取其他 Pod 的信息。同时,由于我们为 ServiceAccount 分配了最小特权的权限,可以降低潜在的安全风险。

role和rolebinding的核心

role是定义一组权限列表

rolebinding有两个obj:

  • roleRef : 绑定哪个role?

  • subjects: 给谁绑定的问题 可以是user、可以是sa也可以是group

如果遇到不懂怎么写就是explain。

kubernetes为什么需要默认的serviceaccount

练习一

只能使用官网的情况下,完成下面和这个需求:

Create a new ServiceAccount processor in Namespace project-hamster. Create a Role and RoleBinding, both named processor as well. These should allow the new SA to only create Secrets and ConfigMaps in that Namespace.

提示; 可以使用kubectl 命令create role、create rolebinding

练习二

让alice这个用户可以创建sa:

创建一个新的 Role,用于控制 ServiceAccount 的创建:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: serviceaccount-creator
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["create"]

创建一个新的 RoleBinding,将 Role 和用户或组关联起来:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: serviceaccount-creator-binding
subjects:
- kind: User
  name: alice
roleRef:
  kind: Role
  name: serviceaccount-creator
  apiGroup: rbac.authorization.k8s.io

在这个例子中,我们创建了一个名为 serviceaccount-creator 的 Role,用于控制 ServiceAccount 的创建。然后,我们创建了一个名为 serviceaccount-creator-binding 的 RoleBinding,将 Role 和用户 alice 关联起来。

这样,用户 alice 就可以使用 kubectl create serviceaccount 命令创建新的 ServiceAccount。其他用户或组如果没有被授权,将无法创建新的 ServiceAccount。

需要注意的是,RBAC 可以用于控制 ServiceAccount 的创建和使用,但不能直接控制 ServiceAccount 的访问权限。要为 ServiceAccount 分配访问权限,需要使用 Role 和 RoleBinding。

关于 "kubernetes为什么需要默认的serviceaccount" 就介绍到此。希望多多支持编程教程

下一章:linux如何创建用户,添加及修改shell

linux怎么创建用户,添加及修改shell:本文讲解"linux如何创建用户,添加及修改shell",希望能够解决相关问题。1、创建用户useradd -d /test -s /bin/bash -m test-d:指定用户的家目录-s: ...