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 -oyamlapiVersion: v1data:  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVVFZZeWZ0VDFBdnQ1ZHlORmM4WUN...  HU4NkZ0bTNyRkNaNUY3N1FmTVpCNU9hYXE2TkRDRwp3ems9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K  namespace: ZGVmYXVsdA==  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltcEdjRkkwWlRSRU55MW1NeTF4YWt0U1pYQm9Sems0U1dJd2RHMTV。。。  xQUJsdVlnSGJva3ZBkind: Secretmetadata:  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-cdc94bcc697atype: 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/v1kind: Rolemetadata:  name: myapp-rolerules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "list"] # 注意只有get和list的权限，并不需要update的权限

3、创建一个新的 RoleBinding

将 ServiceAccount 和 Role 关联起来：

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: myapp-rolebindingsubjects:- kind: ServiceAccount  name: myapp-saroleRef:  kind: Role  name: myapp-role  apiGroup: rbac.authorization.k8s.io

4、在 Pod 中使用 ServiceAccount

apiVersion: v1kind: Podmetadata:  name: myapp-podspec:  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。

练习一

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

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/v1kind: Rolemetadata:  name: serviceaccount-creatorrules:- apiGroups: [""]  resources: ["serviceaccounts"]  verbs: ["create"]

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

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: serviceaccount-creator-bindingsubjects:- kind: User  name: aliceroleRef:  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。