k8s--基础--23.3--认证-授权-准入控制--授权
就是给用户(Users)授予一个角色(Role),那么这个用户就有这个角色的权限。Role是有名称空间的限制的。
k8s–基础–23.3–认证-授权-准入控制–授权
1、介绍
Kubernetes的授权是基于插件形式的,其常用的授权插件有以下几种
1. Node(节点认证)
2. ABAC(基于属性的访问控制)
3. RBAC(基于角色的访问控制)
4. Webhook(基于http回调机制的访问控制)
1.1、什么是RBAC(基于角色的访问控制)?
- 就是给用户(Users)授予一个角色(Role),那么这个用户就有这个角色的权限。
- Role是有名称空间的限制的
1.1、RBAC工作逻辑
- 给用户(Users)授予一个角色(Role),那么这个用户就有这个角色的权限。
- 授权方式有2种
- 名称空间级别 的授权
- 集群级别 的授权
1.1.1、名称空间级别 的授权
如果通过rolebinding绑定role,只能对rolebingding所在的名称空间的资源有权限,上图user1这个用户绑定到role1上,只对role1这个名称空间的资源有权限,对其他名称空间资源没有权限,这个属于名称空间级别的授权。
1.1.2、集群级别的授权机制
- 集群角色(ClusterRole):可以认为是角色组的概念,就是一组角色
- 定义一个集群角色(ClusterRole),对集群内的所有资源都有可操作的权限
- 将User2通过ClusterRoleBinding到ClusterRole,使User2拥有集群的操作权限
- 对资源的访问,没有名称空间的限制
1.2、Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图:
1.2.1、通过上图可以看到,3种绑定
- 用户通过 rolebinding绑定role
- 用户通过 clusterrolebinding绑定clusterrole
- 用户通过 rolebinding绑定clusterrole
1.4、ClusterRole的好处
- 假如有6个名称空间,每个名称空间的用户都需要对自己的名称空间有管理员权限,那么需要定义6个role和rolebinding,然后依次绑定,如果名称空间更多,我们需要定义更多的role,这个是很麻烦的,所以我们引入clusterrole,定义一个clusterrole,对clusterrole授予所有权限,然后用户通过rolebinding绑定到clusterrole,就会拥有自己名称空间的管理员权限了,这样就减少了很多工作量。
- 注:RoleBinding仅仅对当前名称空间有对应的权限。
2、授权机制
- k8s中的授权策略也支持开启多个授权插件,只要一个验证通过即可。
- k8s授权处理主要是根据以下请求属性:
- user, group, extra
- API、请求方法(如get、post、update、patch和delete)和请求路径(如/api)
- 请求资源和子资源
- Namespace
- API Group
- k8s支持的授权模式
- Node Authorization
- ABAC Authorization
- RBAC Authorization
- Webhook Authorization
2.1、Node Authorization
通过配合NodeRestriction control准入控制插件来限制kubelet访问node,endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源。
2.1.1、配置方式
–authorization-mode=Node,RBAC –admission-control=…,NodeRestriction,…
2.2、ABAC Authorization
这种模式的实现相对比较生硬,就是在master node保存一份policy文件,指定不同用户(或用户组)对不同资源的访问权限,当修改该文件后,需要重启apiserver,跟openstack 的ABAC类似。policy文件的格式如下:
# Alice can do anything to all resources:
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "alice",
"namespace": "*",
"resource": "*",
"apiGroup": "*"
}
}
# Kubelet can read any pods:
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "kubelet",
"namespace": "*",
"resource": "pods",
"readonly": true
}
}
# Kubelet can read and write events:
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "kubelet",
"namespace": "*",
"resource": "events"
}
}
2.2.1、使用这种模式需要配置参数
–authorization-mode=ABAC –authorization-policy-file=SOME_FILENAME。
2.3、RBAC Authorization
- 通过启动参数使用RBAC:–authorization-mode=RBAC
- 使用kubeadm安装k8s默认会enabled。
- BAC API定义了四个资源对象用于描述RBAC中用户和资源之间的连接权限
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
- Role是定义在某个Namespace下的资源,在这个具体的Namespace下使用。
- ClusterRole与Role相似,只是ClusterRole是整个集群范围内使用的。
- RoleBinding把Role绑定到账户主体Subject,让Subject继承Role所在namespace下的权限。
- ClusterRoleBinding把ClusterRole绑定到Subject,让Subject集成ClusterRole在整个集群中的权限。
- API Server已经创建一系列ClusterRole和ClusterRoleBinding。
- 这些资源对象中名称以system:开头的,表示这个资源对象属于Kubernetes系统基础设施,也就说RBAC默认的集群角色已经完成足够的覆盖,让集群可以完全在 RBAC的管理下运行。
- 修改这些资源对象可能会引起未知的后果,例如
- 对于system:node这个ClusterRole定义了kubelet进程的权限,如果这个角色被修改,可能导致kubelet无法工作。
2.3.1、通过命令获取对应的Role相关资源进行增删改查
kubectl get roles --all-namespaces
kubectl get ClusterRoles
kubectl get rolebinding --all-namespaces
kubectl get clusterrolebinding
内容
[root@master1 test5]# kubectl get roles --all-namespaces
NAMESPACE NAME CREATED AT
kube-public kubeadm:bootstrap-signer-clusterinfo 2022-03-19T02:06:49Z
kube-public system:controller:bootstrap-signer 2022-03-19T02:06:47Z
kube-system extension-apiserver-authentication-reader 2022-03-19T02:06:47Z
kube-system kube-proxy 2022-03-19T02:06:49Z
kube-system kubeadm:kubelet-config-1.18 2022-03-19T02:06:47Z
kube-system kubeadm:nodes-kubeadm-config 2022-03-19T02:06:47Z
kube-system system::leader-locking-kube-controller-manager 2022-03-19T02:06:47Z
kube-system system::leader-locking-kube-scheduler 2022-03-19T02:06:47Z
kube-system system:controller:bootstrap-signer 2022-03-19T02:06:47Z
kube-system system:controller:cloud-provider 2022-03-19T02:06:47Z
kube-system system:controller:token-cleaner 2022-03-19T02:06:47Z
kubernetes-dashboard kubernetes-dashboard 2022-03-19T13:40:13Z
2.4、Webhook Authorization
- 用户在外部提供 HTTPS 授权服务,然后配置 apiserver 调用该服务去进行授权。
- 参考官方文档
- https://kubernetes.io/docs/reference/access-authn-authz/webhook/
2.4.1、apiserver配置参数:
–authorization-webhook-config-file=SOME_FILENAME
3、kubernetes 中的认证机制
- kubernetes 支持多种认证机制,可以配置成多个认证体制共存,这样,只要有一个认证通过,这个request就认证通过了。下面介绍官网列举的几种常见认证机制
- 参考资料:https://kubernetes.io/docs/reference/access-authn-authz/authentication/
3.1、Service Account Tokens
- Service Account Token 是一种比较特殊的认证机制
- 适用于上文中提到的pod内部服务需要访问apiserver的认证情况
- 默认enabled。
3.1.1、启动参数文件
–service-account-key-file=/etc/kubernetes/pki/apiserver-key.pem
- 有启动参数文件,就使用启动参数文件
- 没有启动参数文件,默认使用–tls-private-key-file的值,即API Server的私钥。
3.1.2、验证
# 获取所有名称空间的sa账号
kubectl get serviceaccount --all-namespaces
可以看到k8s集群为所有的namespace创建了一个默认的service account,利用命令describe会发现service account只是关联了一个secret作为token,也就是service-account-token。
kubectl describe serviceaccount/default -n kube-system
kubectl get secret default-token-7xqxg -o yaml -n kube-system
可以看到service-account-token的secret资源包含的数据有三部分:
-
ca.crt:
- API Server的CA公钥证书
- 用于Pod中的Process对API Server的服务端数字证书进行校验时使用的;
-
namespace:
- Secret所在namespace的值的base64编码: echo -n “kube-system”|base64
-
token:
- 该token就是由service-account-key-file的值签署(sign)生成。
- 这种认证方式主要由k8s集群自己管理,用户用到的情况比较少。
- 我们创建一个pod时,默认就会将该namespace对应的默认service account token mount到Pod中,所以无需我们操作便可以直接与apiserver通信
3.2、OpenID Connect Tokens
类似 OAuth2的认证方式,大致认证过程如下:
更多推荐
所有评论(0)