kube-apiserver 参数

kube-apiserver对外暴露了Kubernetes API。它是的 Kubernetes 前端控制层。

参数分类解释

审计参数：

详见： https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

• 审计提供了一组与安全相关的按时间顺序排列的记录，记录了各个用户，管理员或系统其他组件影响系统的活动顺序。
• 每个请求在每个阶段都会生成一个事件，然后根据某个策略对其进行预处理并写入后端。策略确定记录的内容，后端保留记录。
• 审计后端将审计事件持久保存到外部存储。
• Kube-apiserver提供三个后端：记录后端，将事件写入磁盘;Webhook后端，它将事件发送到外部API;动态后端，通过AuditSink API对象配置webhook后端。
• 每个请求都可以用相关的“阶段”记录。
  1、RequestReceived ：审计处理程序收到请求后立即生成的事件的阶段，以及在处理程序链下委托之前生成事件的阶段。
  2、ResponseStarted：一旦发送响应头，但在发送响应主体之前。此阶段仅针对长时间运行的请求（例如监视）生成。
  3、ResponseComplete： 响应正文已完成，不再发送字节。
  4、Panic：发生异常时产生的事件。

审核日志记录功能会增加API服务器的内存消耗，因为为每个请求存储了审核所需的某些上下文。此外，内存消耗取决于审计日志记录配置。

认证参数：

详见 https://kubernetes.io/docs/reference/access-authn-authz/authentication/

• 建立TLS后，HTTP请求将移至“身份验证”步骤。认证器的输入是整个HTTP请求，认证步骤通常只检查 headers 或客户端证书。
• 身份验证模块包括客户端证书，密码和普通token，bootstrap token和 JWT token（用于 service accounts）。
• 当启用了多个认证模块时，一个认证模块成功认证后将短路请求，不会进行剩余模块的认证。API server 不能保证认证的顺序。
• 如果请求无法通过身份验证，则会被HTTP状态码 401 拒绝。
• 如果请求通过身份验证，插件会尝试将以下属性关联到请求上：
  1、用户名：标识最终用户的字符串。常用值可能是 kube-admin 或 jane@example.com。
  2、UID：标识最终用户的字符串，比用户名更加一致且唯一。
  3、组：一组将用户和常规用户组相关联的字符串。system:authenticated 组包含在所有已验证用户的组列表中。
  4、额外字段：包含其他有用认证信息的字符串列表的映射。
• Kubernetes usernames 用于访问控制决策和日志记录，但它不是 user 对象，也不会在其对象库中存储用户名或有关用户的其他信息。

认证器分类：

（1）509 客户端证书：
启用方法：--client-ca-file=SOMEFILE

验证方法：引用的文件必须包含一个或多个证书颁发机构，用于验证提交给 API server 的客户端证书。

验证后：使用 subject 的 Common Name（CN）作为请求的用户名。客户端证书还可以使用证书的 organization 字段来指示用户的组成员身份。

（2）静态 Token 文件：
启用方法：--token-auth-file=SOMEFILE 。(token 文件是一个 csv 文件，每行至少包含三列：token、用户名、用户 uid，其次是可选的组名。token 会无限期地持续下去，并且不重新启动 API server 的话就无法更改token列表。)

验证方法：
API server 从文件读取 bearer token，期望请求的 Authorization header 中包含 Bearer token 的值。

（3）Bootstrap Token Authenticator：
启用方法： --enable-bootstrap-token-auth;Controller Manager 的 --controllers 参数启用 TokenCleaner 。

验证方法：Kubernetes 中包含了一个名为 Bootstrap Token 的动态管理的 bearer token。这些 token 使用 Secret 存储在 kube-system namespace 中，在那里它们可以被动态管理和创建。Controller Manager 中包含了 TokenCleaner 控制器，用于在 bootstrap token 过期时将其删除。这些 token 的形式是 [a-z0-9]{6}.[a-z0-9]{16}。第一部分是 Token ID，第二部分是 Token Secret。

验证后：请求将被认证为 system:bootstrap:<Token ID> 。被包含在 system:bootstrappers 组中。
详细可参考
https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/

(4)静态密码文件
启用方法：--basic-auth-file=SOMEFILE。基本身份验证凭证将无限期地保留，不重启API服务器无法更改密码。目前仅支持基本身份验证。基本身份认证是一个 csv 文件，至少包含3列：密码、用户名、用户 ID、组名（可选）。

验证方法：需要Authorization header 中包含 Basic BASE64ENCODED(USER:PASSWORD) 的值。

(5)Service Account Token
Service account 是一个自动启用的验证器，它使用签名的 bearer token 来验证请求。该插件包括两个可选参数：

• --service-account-key-file 一个包含签名 bearer token 的 PEM 编码文件。如果未指定，将使用 API server 的 TLS 私钥。
• service-account-lookup 如果启用，从 API 中删除掉的 token 将被撤销。
  Service account 通常由 API server 自动创建，并通过 ServiceAccount 注入控制器，关联到集群中运行的 Pod 上。Bearer token 挂载到 pod 中，并允许集群进程与 API server 通信。 帐户可以使用 PodSpec 的 serviceAccountName 字段显式地与Pod关联。

# 使用 kubectl create serviceaccount (NAME) 命令。这将在当前的 namespace 和相关连的 secret 中创建一个 service account。
$ kubectl create serviceaccount jenkins
# 创建出的 secret 中拥有 API server 的公共 CA 和前面的 JSON Web Token（JWT），secret 基于 base64 编码。
$ kubectl get secret jenkins-token-1yvwg -o yaml
apiVersion: v1
data:
  ca.crt: (APISERVER'S CA BASE64 ENCODED)
  namespace: ZGVmYXVsdA==
  token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
  # ...
type: kubernetes.io/service-account-token

经过签名的 JWT 可以用作 bearer token 与给定的 service account 进行身份验证，在请求中放置 bearer token。

验证后：用户名 system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)，组 system:serviceaccounts 和 system:serviceaccounts:(NAMESPACE)。

(6)OpenID Connect Token
OpenID Connect 是由 OAuth2 供应商提供的 OAuth2，特别是 Azure Active Directory、Salesforce 和 Google。
https://jimmysong.io/kubernetes-handbook/guide/authentication.html#openid-connect-token

(7)Webhook Token 认证
Webhook 认证是用来认证 bearer token 的 hook。
https://jimmysong.io/kubernetes-handbook/guide/authentication.html#webhook-token-%E8%AE%A4%E8%AF%81

(8)认证代理
可以配置 API server 从请求 header 的值中识别用户，例如 X-Remote-User。这样的设计是用来与请求 header 值的验证代理结合使用。
https://jimmysong.io/kubernetes-handbook/guide/authentication.html#%E8%AE%A4%E8%AF%81%E4%BB%A3%E7%90%86

(9)匿名请求
未被其他已配置身份验证方法拒绝的请求将被视为匿名请求，用户名：system:anonymous 、组名：system:unuthenticated
ABAC 和 RBAC 授权人需要明确授权 system:annoymous 或 system:unauthenticated 组，因此授予对 * 用户或 * 组访问权的传统策略规则不包括匿名用户。

授权参数：

RBAC模式: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

ABAC模式: https://kubernetes.io/docs/reference/access-authn-authz/abac/

Node模式: https://kubernetes.io/docs/reference/access-authn-authz/node/

Node模式：

• 为了获得Node授权者的授权，kubelet必须使用凭证说明它在system:nodes组中，用户名为system:node:<nodeName>，该格式应该与为 kubelet 作为 kubelet TLS 引导的创建的标识相匹配。
• Node 授权者可以允许 kubelet 执行 以下 API 操作：
  1、读操作：服务、端点、节点、Pod、Secret、ConfigMap、persistent volume claims、绑定到kubelet节点的pod相关的持久卷
  2、写操作：节点和节点状态、pod和pod状态、事件
  3、与认证相关的操作：对TLS引导的certificationsigningrequests API的读/写访问权限、能够为委派的身份验证/授权检查创建tokenreviews和subjectaccessreviews

API启用参数：

https://kubernetes.io/docs/reference/using-api/api-overview/

准入参数：

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
准入控制器在请求经过身份验证和授权之后、对象持久化之前，拦截对Kubernetes API服务器的请求。控制器被编译为 kube-apiserver二进制文件，只能由集群管理员配置。
准入控制器可以是“validating”，“mutating”或两者。变异控制器可以修改他们 admit 的对象; 验证控制器不会。
准入控制过程分两个阶段进行。在第一阶段，运行 mutating admission controllers。在第二阶段，运行 validating admission controllers。有些控制器会运行两次。如果任一阶段中的任何控制器拒绝请求，则立即拒绝整个请求，并向最终用户返回错误。
准入控制器有时可能具有副作用，即，作为请求处理的一部分来改变相关资源。比如增加配额使用量。任何副作用都需要相应的回收或协调过程。

NodeRestriction：

• 限制 kubelet 修改 node 和 pod 对象的权限。 为了启用该功能，kubelet 要使用 system: nodes 组中的证书。用户名如下 system:node:<nodeName>。这种 kubelet只允许修改自己节点的 API 对象 和 绑定在该节点上的 POD API 对象。
• 对于 Kubernetes 1.11+, kubelet 不能修改其NodeAPI对象中的污点。
• 对于 Kubernetes 1.13+, kubelet 不能删除其NodeAPI对象，并强制对其前缀kubernetes.io/或k8s.io/前缀下的标签进行修改。
• 未来版本可能会添加其他限制，以确保kubelet具有正确操作所需的最小权限集。