简介
访问kubernetes集群的时候，需要经过安全机制的三个步骤才能访问，过程中都会经过apiserver的统一协调
机制如下
认证：判断用户是否为集群正常的合法用户【判断用户真伪】
鉴权：判断api调用是否合法【是否有权限】
准入控制：会有一个类似acl的列表进行校验，如果列表中有相关请求内容则通过，否则就不通过【能不能操作】
简单流程如下，主要需要理解的是认证和鉴权模块
主要关注的步骤
认证
认证策略包括四种：
匿名认证：
默认情况下匿名认证是关闭的
白名单认证：basicauth认证
一般情况下是服务器启动时加载的basic用户配置文件，并且通过没有更多配置的话basic的认证仅仅只能访问没有其他的操作权限，如今已经很少使用了
token认证：Webhooks、ServiceAccount Tokens、OpenID Connect Tokens等
token认证更多涉及到对集群和pod的操作
x509证书认证：clientCA认证，TLS bootstrapping等
是kubernetes集群组件间默认使用的认证方式，同事也说kubectl客户端对应kube config中经过使用的凭证
鉴权
当apiserver通过用户认证后就会到达鉴权的阶段，主要是判断api调用是否合法，主要包括四种
Always：
集群不需要鉴权
ABAC：
基于属性的访问控制
PBAC：
基于角色的访问控制，主流鉴权方式
Node:
对kubelet进行鉴权的特殊模式，限制每个Node只访问它自身运行的Pod及相关Service、Endpoints等信息
Webhook:
通过外部调用REST服务对用户鉴权，可自行编写鉴权逻辑通过webhook方式注册为k8s的鉴权服务，从而实现更加复杂的规则
RBAC
rolebased access control基于角色的访问控制，在RBAC中权限与角色相关关联，用户通过成为适当的角色然后才能获得到相关角色的权限。意思就是权限给予角色，而用户成为角色后，权限就又从角色给予的用户，此处用户可以是用户、用户组、服务账户
1.15版本中集群默认不开启RBAC，从1.16版本起默认启用RBAC访问控制策略，从1.18RBAC已作为稳定功能
角色用户相关
角色
role：普通角色，授权特定命名空间访问权限，用于日常分配给运行的容器
clusterrole：集群角色，授权所有命名空间访问权限，用于更多的管理工作
角色绑定
rolebinding：角色绑定到主体【同role对应】
clusterrolebinding：集群角色绑定到主体【同clusterrole对应】
主体
user：用户
group：用户组
serviceaccount：服务账号
namespace命名空间
namespace命名空间是多个用户之间划分集群资源的一种方式，kubernetes中每个资源都只能在一个namespace下
获取命名命名空间
如上图默认是有4个命名空间
default 默认使用
kube-node-lease 集群建的心跳维护
kube-public 能够被任何人访问包括匿名访问
kube-system kubernetes系统创建对象所使用的
主要关注的命名空间是default、kube-system
已知RBAC中的重点是角色，角色又细分为role、clusterrole
查看普通角色，没有设置的话默认是在default中，当前暂未设置
当然可以指定到其他的命名空间，查看普通角色
kubectl get role -n kube-system
查看集群角色，此处从default或kube-system命名空间查出来其实都是一样的
kubectl get clusterrole -n kube-system
集群角色中的最高权限是cluster-admin，具备集群所有资源的管控权限，如果给其他用户、用户组、服务账户绑定上该角色，也同样具备相关权限及更多的安全隐患
当然普通的admin用户权限也很大，比cluster-admin会少许多权限
基本创建绑定方法
kubectl create clusterrolebinding 名称 --clusterrole=给予的角色 --user=给予的用户 --group=给予的组
查看绑定情况
kubectl get clusterrolebinding -n kube-system | grep cluster-adminnew
kubectl describe clusterrolebinding -n 命名空间 绑定名字
serviceaccount服务账户
k8s为pod内部进程访问apiserver创建的用户，因为是pod内部的，所以也会有对应的命名空间
k8s有一种资源对象为secret，分为两种，一种是容器运行时的敏感配置如密码等，一种是用于记录serviceaccount的service-account-token
获取secrets
kubectl describe secrets -n kube-system
如上图所示service-account-token中包含了ca.crt、namespace、token
ca.crt：根证书，给apiserver发送时候使用
namespace：作用域空间
token：apiserver私钥签名的凭证，访问apiserver时进行认证
如上图账户名在-token前面的default，给这个服务账户绑定cluster-admin，也就意味着default这个serviceaccount将拥有集群最高权限，那么他创建的pod也会有集群最高权限的pod
kubectl create clusterrolebinding defaultadmin --clusterrole=cluster-admin --serviceaccount=kube-system:default
确认成功如下
kubectl describe clusterrolebinding -n 命名空间 绑定名字
准入控制
以插件形式运行在apiserver进程中，会在鉴权后对象被存储到etcd前拦截apiserver的请求， 对相关请求的资源进行校验、修改、拦截等操作
