k8s-18 认证授权

Authentication (认证)
认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式
Kubernetes集群有两类用户:由Kubernetes管理的Service Accounts(服务账户)和普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在(Users Accounts) 它只是形式上存在
Authorization (授权)必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AIwaysAllow、ABAC、RBAC、Webhook.Node。默认集群强制开启RBAC。
Admission Control (准入控制)用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验。

UserAccount与serviceaccount:
用户账户是针对人而言的。服务账户是针对运行在 pod 中的进程而言的。用户账户是全局性的。其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做namespace 隔离，服务账户是 namespace 隔离的。通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并目涉及到复杂的业务流程。服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户(即权限最小化原则 )。

===================

pod绑定sa

认证

切换用户

默认用户没有任何权限，需要授权

切回admin

RBAC (Role Based Access Control) : 基于角色访问控制授权。允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可RBAC包括四种类型: Role、ClusterRole、RoleBinding、ClusterRoleBinding。

RBAC的三个基本概念
Subject: 被作用者，它表示k8s中的三类主体，user， group，serviceAccountRole:角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限RoleBinding:定义了被作用者”和“角色的绑定关系。
Role 和 ClusterRole
Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限ClusterRole 跟 Role 类似，但是可以在集群中全局使用。

切回admin

回收