Kubernetes认证与授权
k8s集群搭建的认证以及授权
一、k8s的认证
1、kubernetes客户端证书认证(TLS双向认证)
外部kubectl访问k8s集群的apiServer,通过apiServer来控制集群里面的资源(etcd、scheduler、controllermanager等),在发送请求的时候,需要认证所访问的apiServer是否是所需要访问的apiServer,反过来apiServer在被kubectl访问的时候,也需要向kubectl进行认证。
TLS认证需要的CA证书机构,不再是使用的国际默认的CA证书机构,而是由k8s集群自己提供的CA证书,用来判断认证证书的合法性,k8s集群的CA会给所有需要的组件进行颁发证书,包括集群里面的apiServer及外部的kubectl。
2、BearerToken
k8s集群生成BearerToken,提供给需要访问集群的组件,组件在访问集群的时候,带上Token,集群中的组件在接收到请求的时候,对Token进行验证,验证通过就可以进行通信。
3、ServiceAccount(namespace、token、ca)
ServiceAccount会挂载到k8s集群中的pod的目录下,每个应用的pod可以用过读取目录下的ServiceAccount来获取集群的认证证书数据,从而可以与集群中的apiServer进行认证通信。
二、k8s授权
1、ABAC
2、WebHook
3、RBAC(Role Based Access Control)角色权限访问控制
角色访问控制主要由三个部分组成
1)User(用户)
用户分为普通的User用户以及ServiceAccount,普通用户一般为kubectl等等外部访问k8s集群的用户,ServiceAccount主要是k8s内部访问的用户。
2)Role(角色)
角色包含了name(名称)、resources(资源)、verbs(操作)几个属性。
k8s集群的资源由namespace来进行划分,所以在设计权限的时候,k8s集群将role角色也划分到了某个namespace里面,用户(User)绑定了该Role,就拥有了访问该namespace的该Role所拥有的资源以及操作。
k8s中如果要做跨namespace的权限如何来操作呢,虽然有一个方式就是让用户(User)来binding其它的namespace的Role来实现,这种当然也是可行的,但是k8s集群中的某些资源比如node(节点),它也是一种资源,它是不属于任何namespace的,所以k8s为了解决这种问题,提供了一个特殊的角色---ClusterRole(集群角色),它是不属于任何namespace的,它可以定义Role的所有属性之外,还可以定义不属于namespace的资源,它的绑定也有一个专属的ClusterRoleBinding。
3)Authoritiy(权限)
权限主要分为Resource(资源)以及Verbs(操作),verbs主要是对k8s的资源的一些操作,类似增删改查。
普通的权限系统都会由关联关系来将用户与角色进行绑定,由于k8s集群是没有表这种存储结构的,于是k8s将用户与角色使用RoleBinding来进行绑定。
三、准入控制(AdmissionControl)
做完了上面的认证以及授权之后,要执行对应的请求,还需要通过k8s集群中的AdmissionControl。对于熟悉后端开发的人来说,也可以将它理解成为过滤器,所有对k8s集群的操作指令,都是需要通过一层一层的过滤之后,才可以执行。k8s提供了十几个准入控制器,具体如何执行以及执行顺序,是在配置apiServer的时候进行配置的。
下面简单的介绍几个比较常见的准入控制器
AlwaysAdmit(总是允许进入)
AlwaysDeny(总是拒绝进入)
ServiceAccount
这里的ServiceAccount跟用户层面的ServiceAccount并不是同一个概念,它是辅助用户层面的ServiceAccount,将其做了一个自动化,假设某些pod没有ServiceAccount用户,它会给该pod添加一个当前pod命名空间默认的ServiceAccount给pod,确保每个pod都能存在ServiceAccount。
更多推荐
所有评论(0)