乐趣区

关于kubernetes:关于ServiceAccount以及在集群内访问K8S-API

jiezi

写在开篇

在之前的两篇文章中提到，有 4 种形式应用 ConfigMap 配置 Pod 中的容器，对于之前的两篇可参考：

  • 《一文理解 K8S 的 ConfigMap》
  • 《下篇 1：将 ConfigMap 中的键值对作为容器的环境变量》

本篇的实战场景就以拜访 API 的形式读取 ConfigMap，也就是编写代码在 Pod 中运行，而后应用 K8S API 来读取 ConfigMap 的内容。然而，这个场景波及到服务账号、K8S 集群内身份验证的相干知识点。为了管制篇幅（次要是文章太长，放心没人看到最初），打算再拆分两篇。本篇尽力先把波及到的知识点搞清楚，下一篇再真正进入实战环节，例如写代码，制作镜像等等。

其实，这个实战场景，也刚好补救了在之前分享过的 下篇（开始写代码）：运维开发人员不得不看的 K8S API 实战》中短少的“集群内进行身份验证”的内容。

在持续之前，如果对 K8S API 的应用套路还无所不知，可联合参考：

  • 《上篇：运维人员不得不看的 K8S API 入门实战，醉生梦死整顿得又臭又长，有人看吗？》
  • 《下篇（开始写代码）：运维开发人员不得不看的 K8S API 实战》

K8S 的账号类型

在 K8S 中，次要有两种账号类型：

  1. User Accounts（用户账号）：用户账号用于标识和验证 Kubernetes 集群的用户。用户账号通常由集群管理员创立，并与相应的身份验证凭据（如用户名和明码、令牌等）关联。用户账号用于进行集群治理操作，如创立、删除和更新资源，以及拜访集群中的敏感信息。
  2. Service Accounts（服务账号）：服务账号是用于身份验证和受权 Pod 内的应用程序的一种机制。每个 Pod 都能够与一个 Service Account 相关联，并应用该 Service Account 进行与 Kubernetes API Server 的通信。服务账号通常用于在 Pod 内的应用程序与集群中的其余资源进行交互，如读取 ConfigMap、拜访 Secrets 等。

更多信息可参考官网文档：authentication

对于 ServiceAccount 和在 K8S 集群内身份验证

上次的实战场景《下篇（开始写代码）：运维开发人员不得不看的 K8S API 实战》次要是在 K8S 集群外进行身份验证，因为调用 K8S API 的代码是运行在集群内部。而这次的场景是：调用 K8S API 的代码运行在 POD 容器里，也就是要在 K8S 集群外部进行身份验证。

当调用 K8S API 的代码（利用程序代码）运行在 POD 里的容器时，Pod 中的应用程序能够应用其关联的 ServiceAccount 去拜访 API Server 中的 Kubernetes 资源（比方拜访 ConfigMap 资源）。在拜访资源时，ServiceAccount 会应用其所调配的 RBAC 角色来确定它有哪些权限。为了不便了解，我简略画了个图，如下：

  • 身份认证：应用程序能够应用与之关联的 ServiceAccount 进行身份认证，以证实其对 Kubernetes 集群中的资源的非法拜访权限。
  • 拜访受权：通过与拜访控制策略（如 Role、ClusterRole）联合应用，能够为 ServiceAccount 调配特定的角色和权限，从而限度应用程序对资源的拜访范畴和操作权限。

对于 ServiceAccount 的更多信息可参考官网文档：service-accounts

对于每个命名空间下默认的服务账号：default

官网文档提到：默认服务账户是 Kubernetes 在创立集群时主动为每个命名空间创立的一个 ServiceAccount 对象。每个命名空间中的服务账户默认状况下没有任何权限，除非启用了基于角色的访问控制（RBAC），此时 Kubernetes 会授予所有通过身份验证的主体默认的 API 发现权限。如果在一个命名空间中删除了 ServiceAccount 对象，管制立体会主动替换为一个新的 ServiceAccount 对象。如果在一个命名空间中部署一个 Pod，并且没有手动为 Pod 调配一个 ServiceAccount，Kubernetes 会将该命名空间的默认 ServiceAccount 调配给该 Pod。

接下来，查看一下默认命名空间（default）下的 serviceaccount：

[root@k8s-b-master ~]# kubectl get serviceaccount
NAME      SECRETS   AGE
default   0         16d
[root@k8s-b-master ~]# kubectl get serviceaccount default -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2023-04-30T03:24:16Z"
  name: default
  namespace: default
  resourceVersion: "359"
  uid: 47c8dccd-2d91-47cf-b0b7-ce4d02b610a8
[root@k8s-b-master ~]# 

创立一个名为 goweb 的自定义命名空间，创立后，在该命名空间下曾经主动创立了一个名为 default 的 serviceaccount 对象：

[root@k8s-b-master ~]# kubectl create ns goweb
namespace/goweb created
[root@k8s-b-master ~]# kubectl get serviceaccount -n goweb
NAME      SECRETS   AGE
default   0         8s
[root@k8s-b-master ~]# kubectl get serviceaccount default -n goweb -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2023-05-17T03:26:41Z"
  name: default
  namespace: goweb
  resourceVersion: "284809"
  uid: c0254d59-c625-4ef9-a619-1c51fdcfeef6
[root@k8s-b-master ~]# 

到了这里，可能会提出这样的问题： 创立自定义的命名空间后，为什么会主动创立一个名为 default 的 ServiceAccount？

这是因为 ServiceAccount 是用于身份验证和受权的一种机制，每个 Pod 都须要与一个 ServiceAccount 关联，以确定 Pod 在集群中的身份和权限。

默认的 ServiceAccount 是为了确保在创立 Pod 时不会产生谬误。如果没有显式地指定 Pod 要应用的 ServiceAccount，Kubernetes 会主动将命名空间的默认 ServiceAccount 调配给该 Pod。这样，Pod 就可能取得根本的权限和凭据，以便与集群中的其余组件进行通信。

默认的 ServiceAccount 通常没有具体的权限，除非通过其余形式为其调配了角色和权限。默认状况下，它只领有根本的 API 发现权限，容许 Pod 发现集群中的其余 API 资源。

能够通过为 Pod 显式指定不同的 ServiceAccount 来笼罩默认行为，以满足特定的平安需要和拜访控制策略，这也就是下篇要做的事件：为 Pod 配置 ServiceAccount。

为 Pod 配置 ServiceAccount 的步骤

为管制篇幅，为 Pod 配置 ServiceAccount，以及编写应用 Go 调用 K8S API 的代码、制作镜像等等均放到下篇分享。

为 Pod 配置 ServiceAccount 的步骤很简略，上面仅给出步骤，如下：

  1. 创立 ServiceAccount
  2. 创立 Role：定义所需的权限
  3. 创立 RoleBinding，将 ServiceAccount 和 Role 关联起来
  4. 将 ServiceAccount 对象调配给 Pod

更多信息可参考官网文档：configure-service-account

本文转载于 WX 公众号：不背锅运维（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/1BbBLr4E564b6OdIpXjMjw

退出移动版