写在开篇

在之前的两篇文章中提到，有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 serviceaccountNAME      SECRETS   AGEdefault   0         16d[root@k8s-b-master ~]# kubectl get serviceaccount default -o yamlapiVersion: v1kind: ServiceAccountmetadata:  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 gowebnamespace/goweb created[root@k8s-b-master ~]# kubectl get serviceaccount -n gowebNAME      SECRETS   AGEdefault   0         8s[root@k8s-b-master ~]# kubectl get serviceaccount default -n goweb -o yamlapiVersion: v1kind: ServiceAccountmetadata:  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