Kubernetes学习笔记-kubernetes API服务器的安全防护（1）了解认证机制20220813

回顾

api服务器可以配置一个到多个认证插件。api服务器接收到的请求会经过一个认证插件的列表，列表中的每个插件都可以检查这个请求和尝试确定谁在发送这个请求。列表中的第一个插件可以提取请求中的客户端的用户名、用户id和组信息，并返回给api服务器。api服务器会停止调用剩余的认证插件并继续进入授权阶段。 目前有几个认证插件是直接可用。它们使用下列方法获取客户端的身份认证： 客户端证书 传入在http头中的认证token 基础的http认证 其他 启动api服务器时，通过命令行选项可以开启认证插件。

1.用户和组

认证插件会返回已经认证过用户的用户名和组（多个组）。kunernetes不会在任何地方存储器这些信息，这些信息被用来验证用户是否授权执行某个操作.

了解用户

kubernetes区分两种连接到apu服务器的客户端

• 真是的人（用户）
• pod（运行在pod的应用）

这两种类型的客户端都使用了认证插件进行认证。用户应该被管理在外部系统中，如单点登陆系统，但是pod使用一种称为service accounts的机制，该机制被创建和存储在集群中作为serviceaccount资源。相反，没有资源代表用户账户，这意味意味着不能通过api服务器来创建、更新或者删除用户

了解组

正常用户和serviceaccount都可以属于一个或多个组。认证插件会连同用户名和用户id返回组。组可以一次给多个用户赋予权限，而不是必须单独给用户赋予权限。 由插件返回的组仅仅是表示组的名称的字符串，但是系统内置的组会有一些特殊的含义

• system：unauthenticated组用户所有认证插件都不会认证客户端身份的请求
• system：authenticated组就自动分配给一个成功通过认证的用户
• system：serviceaccounts组包含所有在系统中的serviceaccount
• system：serviceaccounts：<namespace>组包含了所有在特定命名空间中的serviceaccount

2.ServiceAccount介绍

pod是通过发送/var/run/secrets/kubernetes.io/serviceaccount/token文件内容进行身份认证的。这个文件通过加密卷挂载进每个容器的文件系统中。token文件持有serviceaccount的认证token。应用程序使用这个token连接api服务器时，身份认证插件会对serviceaccount进行身份认证，并对serviceaccount的用户名传回api服务器内部。serviceaccount用户名的格式像下面这样：

system：serviceaccount：<namespace>:<service account name>

api服务器将这个用户名传给已配置好的授权插件，这决定该应用程序所尝试执行的操作是否被serviceaccount允许执行

serviceaccount只不过是一种运行在pod中应用程序和api服务器身份认证的一种方式，应用程序通过在请求中传递serviceaccountbtoken来实现这一点。

了解ServiceAccount资源

serviceaccount作用在单独的命名空间，为每个命名空间自动创建一个默认的serviceaccount 查看方式： $kubectl get sa

注意：sa是serviceaccount缩写

每个pod都与一个seeviceaccount相关联，但多个pod可以使用同一个serviceaccount。pod只能使用同一个命名空间中的serviceaccount

ServiceAccount如何和授权进行绑定

在pod的manifest文件中，可以用指定账户名称的方式将一个serviceaccount赋值给一个pod。如果不显式的指定serviceaccount的账户名称，pos会使用在这个命名空间中的默认serviceaccount 可以通过将不同的serviceaccount赋值给pod来控制每个pod可以访问的资源。当api服务器接收到一个带有认证token的请求事情，服务器会用这个token来验证发送请求的客户端所关联的serviceaccount是否允许执行请求的操作。api服务器通过管理员配置好的系统级别认证插件来获取这些信息。其中一个现成的授权插件是基于角色控制的插件（RBAC）

3.创建ServiceAccount

每个命名空间都拥有一个默认的serviceaccount，为了集群安全也可以在需要时创建额外的serviceaccount。 不需要读取任何集群元数据的pod应该运行在一个受限制的账户下，这个账户不允许它们检索或修改部署在集群中的任何资源。需要检索资源元数据的pod应该运行在只允许读取这些对象元数据的serviceaccount下。

创建serviceaccount

$kubectl create serviceaccount foo

了解ServiceAccount上的可挂载密钥

查看serviceaccount，在默认情况下，pod可以挂载任何它需要的密钥。但是我们可以通过对serviceaccount进行配置，让pod只允许挂载serviceaccount中列出的可挂载密钥，为了开启这个功能，serviceaccount必须包含以下注解：

kunernetes.io/enforce-mountable-secrets=“true”

如果serviceaccount被加上这个注解，任何使用这个serviceaccount的pod只能挂载serviceaccount的可挂载密钥--这些pod不能使用其他密钥

了解serviceaccount的镜像拉取密钥

serviceaccount的镜像拉取密钥和它的可挂载密钥表现有些轻微不同。和可挂载密钥不同的是，serviceaccount中的镜像拉取密钥不是用来确定一个pod可以使用哪些镜像拉取密钥的。添加到serviceaccount中的镜像拉取密钥会自动添加到所有使用这个serviceaccount的pod中。向serviceaccount中添加镜像拉取密钥可以不必对每个pod都单独进行镜像拉取密钥的添加操作。

4.将ServiceAccount分配给pod

在创建为另外的serviceaccount之后，需要将它们赋值给pod。通过pod定义文件中的spec.serviceaccountname字段设置serviceaccount的名称来进行分配 注意：pod的serviceaccount必须在pod创建时进行设置，后续不能修改