kubernetes需要默认的serviceaccount的原因解析,


目录
  • 什么是k8s的serviceAccount?
  • 为什么每一个ns下都有默认的sa?
    • default sa yaml
  • 默认的sa下都会挂一个secret,这个secret是从哪里来的?
    • 一道关于RBAC的CKA考题
      • 1、创建一个新的 ServiceAccount
      • 2、创建一个新的 Role
      • 3、创建一个新的 RoleBinding
      • 4、在 Pod 中使用 ServiceAccount
    • role和rolebinding的核心
      • 练习一
        • 练习二

          什么是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。

          在这里插入图片描述

          练习一

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

          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?的文章就介绍到这了,更多相关kubernetes serviceaccount内容请搜索PHP之友以前的文章或继续浏览下面的相关文章希望大家以后多多支持PHP之友!

          您可能感兴趣的文章:
          • kubernetes认证鉴权内容浅析

          相关内容