Kubernetes集群的安全框架主要由以下认证、鉴权和准入控制三个阶段组成。这三个阶段的关系如下图所示。

视频讲解如下：

认证（Authentication）

当客户端与Kubernetes集群建立HTTP通信时，首先HTTP请求会进入到认证阶段。由于API Server是操作集群资源的唯一入口，因此可以在API Server上配置一个或者多个认证模块。在这种情况下，API Server将逐个验证每一个认证模块，直到其中一个认证成功。如果认证失败，API Server将返回401的HTTP状态码给客户端，表示Kubernetes拒绝了客户端的连接请求。一般情况下认证模块只会检查HTTP的头部信息，因为这里包含了用户名、密码、客户端证书、令牌等信息，而不会检查整个HTTP请求。

鉴权（Authorization）

当客户端请求完成了认证阶段后，就会进入鉴权阶段。这个阶段会检查请求者是否拥有相应的权限来执行操作。因此，在鉴权阶段需要提供请求者的用户名、请求的权限或者行为以及操作的资源对象。如果请求者无权完成请求的操作，那么Kubernetes将拒绝该请求。

下面是Kubernetes鉴权的一个例子。

{  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "Jerry",
        "namespace": "project-dev",
        "resource": "pods",
        "readonly": true
    }
}

通过这里的策略指定了Jerry能够在命名空间“project-dev”中读取Pod。隐藏Jerry执行下面的操作时，就可以正常被鉴权允许他读取 project-dev名称空间中的Pod对象。

{ "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "project-dev",
      "verb": "get",
      "group": "dev.example.org",
      "resource": "pods"
    }
  }
}

提示：如果Jerry在命名空间project-dev中执行写操作，如create和update，则会被鉴权拒绝。另外，Jerry只对命名空间project-dev有读取Pod的权限，对于其他命名空间没有任何权限。

准入控制（Admission Control）

当客户端请求通过了认证阶段和鉴权阶段后，API Server此时还不会立即处理客户端的请求。因为这时候客户端请求还要通过最后一个阶段，即准入控制阶段。该阶段的本质其实是拦截客户端请求的一种方式，这样就可以修改客户端请求中的参数以完成一些特殊的任务。另外，Kubernetes为准入控制阶段维护了一个插件列表，发送给API Server的所有客户端请求都需要通过该列表中的每一个准入控制器插件的检查。如果某个准入控制插件拒绝了客户端请求，那么该请求将立即被拒绝，而不会继续检查后续的插件。

提示：Kubernetes允许用户自己开发每一个阶段的插件，并集成到相应的阶段中来实现用户的访问控制。每个插件都是通过APIServer来启用。