一文读懂 TKE 及 Kubernetes 访问权限控制 (3)

如需要开启此项功能，需要在APIServer的启动参数中指定oidc的配置参数，例如--oidc-issuer-url指定oidc身份提供方的地址，--oidc-client-id指定身份提供方侧的账户ID，--oidc-username-claim身份提供方的用户名。

具体可参考，目前公有云TKE没有使用此参数对接腾讯云账户，因为涉及用户需要主动登录授权后才可返回Id Token，和当前官网交互冲突，可以在后续CLI工具中实现。

5. Webhook Token Server

Webhook Token是一种hook的方式来校验是否认证通过。

APIServer启动参数--authentication-token-webhook-config-file及--authentication-token-webhook-cache-ttl来分别指定Webhook地址以及token的cache ttl。

若APiServer开启此方式进行认证校验，则在接受到用户的Request之后，会包装Bearer Token成一个TokenReview发送给WebHookServer，Server端接收到之后会进行校验，并返回TokenReview接口，在status字段中进行反馈是否通过校验通过和user.Info信息。

总结

以上即为Kubernetes APIServer认证的几种方式，TKE在每种认证方式都有支持。供用户灵活使用。

目前TKE正在推使用x509客户端证书方式来进行认证管理，以方便进行对接子账户的创建、授权管理、更新。

Kubernetes授权

Kubernetes的授权模式支持一下几种，和认证一样，参考开始说的RequestInfo context，可知用户Reqeust的context除了认证需要的userInfo，还有一些其他的字段例如Verb、APIGroup、APIVersion、Resource、Namespaces、Path……

授权就是判断user是否拥有操作资源的相应权限。

Kubernetes支持AlwaysAllow、AlwaysDeny、Node、ABAC、RBAC、Webhook授权Mode，和认证一样，只要有一种鉴权模块通过，即可返回资源。

在这里重点介绍下面两种方式

RBAC

RBAC（Role-Based Access Control)，Kubernetes提供ClusterRole、Role资源，分别对应集群维度、Namespace维度角色权限管控，用户可以自定义相应的ClusterRole、Role资源，绑定到已经认证的User之上。

如下tke:pod-reader ClusterRole，定义了该角色可以访问core apigroup下面对pods资源的get/watch/list操作

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: tke:pod-reader rules: - apiGroups: [""] # "" 指定核心 API 组 resources: ["pods"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 # 此角色绑定使得用户 "alex" 能够读取 "default" 命名空间中的 Pods kind: ClusterRoleBinding metadata: name: alex-ClusterRole subjects: - kind: User name: alex apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: tke:pod-reader # 这里的名称必须与你想要绑定的 Role 或 ClusterRole 名称一致 apiGroup: rbac.authorization.k8s.io

通过以上的yaml配置，通过认证模块到达授权模块的requestInfo中userInfo信息是alex的请求，在授权模块中走到RBAC授权模块时，则会进行查询集群的ClusterRole/ClusterRoleBinding信息。进行判断是否拥有context相应操作的权限。

TKE的对接子账户的权限授权策略就是使用的Kubernetes原生的RBAC进行对子账户资源访问控制，这样符合原生，符合有K8s使用习惯的用户。

WebHook

Webhook模式是一种基于HTTP回调的方式，通过配置好授权webhook server地址。当APIServer接收到request的时候，会进行包装SubjectAccessReview请求Webhook Server，Webhook Server会进行判断是否可以访问，然后返回allow信息。

以下是kubernetes社区一个例子，以供参考。

{ "apiVersion": "authorization.k8s.io/v1beta1", "kind": "SubjectAccessReview", "spec": { "resourceAttributes": { "namespace": "kittensandponies", "verb": "get", "group": "unicorn.example.org", "resource": "pods" }, "user": "alex", "group": [ "group1", "group2" ] } } { "apiVersion": "authorization.k8s.io/v1beta1", "kind": "SubjectAccessReview", "status": { "allowed": true } }

目前TKE没有考虑使用Webhook的模式，但是Webhook模式提供了强大的灵活性，比如对接CAM，实现K8s权限对接到平台侧，但是也有一定的风险和挑战，比如依赖CAM的稳定性；请求延迟、缓存/TTL的配置；CAM action配置与K8s权限对应关系。此项授权模式仍然在考虑中，有需求的用户可以反馈。

准入控制

什么是admission controller？

In a nutshell, Kubernetes admission controllers are plugins that govern and enforce how the cluster is used.

Admission controllers是K8s的插件，用来管理和强制用户如何来操作集群。