K8s记录-访问方式

认证

认证解决的是用户身份识别的问题，即用户是否是合法的用户

k8s中的用户

所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务账号和普通用户
Kubernetes 假定普通用户是由一个与集群无关的服务通过以下方式之一进行管理的：

负责分发私钥的管理员

类似 Keystone 或者 Google Accounts 这类用户数据库

包含用户名和密码列表的文件

有鉴于此，Kubernetes 并不包含用来代表普通用户账号的对象。普通用户的信息无法通过 API 调用添加到集群中。

普通用户账号和服务账号(service account)的面向场景是不一样的

普通用户账号是用于从外部访问k8s，从这两种账号的生成方式就可以知道，普通用户的创建需要生成自己的公钥和私钥，然后用K8s的ca证书签名，然后配置到kubeconfig中或者认证的时候带上就可以访问呢

普通用户的创建可以参考：https://blog.csdn.net/cbmljs/article/details/102953428 或者自行百度

服务账号是从k8s内部访问，和某个命名空间绑定（但不是说权限只在这个命名空间），每个命名空间都会有一个名为default的服务账号，而创建服务账号不需要自己去生成公钥和私钥，创建服务账号可以直接通过yaml或者kubectl创建。

ServiceAccount的创建可以通过诸如下面的yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-server-account
  namespace: test

ServiceAccount创建之后会生成一个Secret，可以使用这个Secret来访问k8s

个人理解服务账号和普通用户账号使用上区别并不是很大，只是他们面向的场景不一样而已

k8s目前支持的认证方式

X509 client certs
Static Token File
Bootstrap Tokens
Static Password File
Service Account Tokens
OpenId Connect Tokens
Webhook Token Authentication
Authticating Proxy
Anonymous requests
User impersonation
Client-go credential plugins

最常用的就是X509，这也是现在HTTPS中使用的方式，也是目前比较安全的方式

鉴权

鉴权解决的是用户的权限问题，即用户是合法的，但是没有权限一样不能够访问

K8s支持的鉴权模块

Node - 一个专用鉴权组件，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。了解有关使用节点鉴权模式的更多信息，请参阅节点鉴权。

ABAC - 基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 ABAC 模式。

RBAC

- 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看、创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅

RBAC 模式。

被启用之后，RBAC（基于角色的访问控制）使用 rbac.authorization.k8s.io API 组来驱动鉴权决策，从而允许管理员通过 Kubernetes API 动态配置权限策略。

要启用 RBAC，请使用 --authorization-mode = RBAC 启动 API 服务器。

Webhook - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 Webhook 模式。

准入控制

准入控制是作用于 kubernetes 中的对象，是访问控制的最后一环

准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求

准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。

个人理解准入控制器可以实现除了前面两个额外的权限验证，还可以实现诸如将所有的镜像拉取策略修改为always的功能，例如官方给出的例子AlwaysPullImages

AlwaysPullImages

该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always 。这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像的名称（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。

参考：

https://blog.csdn.net/weixin_45423952/article/details/103271097

https://kubernetes.io/zh/docs/reference/access-authn-authz/authentication/#users-in-kubernetes

https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/