k8s--基础--23.3--认证-授权-准入控制--授权

k8s–基础–23.3–认证-授权-准入控制–授权

---

1、介绍

Kubernetes的授权是基于插件形式的，其常用的授权插件有以下几种
1. Node(节点认证)
2. ABAC(基于属性的访问控制)
3. RBAC(基于角色的访问控制)
4. Webhook(基于http回调机制的访问控制)

1.1、什么是RBAC(基于角色的访问控制)？

1. 就是给用户(Users)授予一个角色(Role)，那么这个用户就有这个角色的权限。
2. Role是有名称空间的限制的

1.1、RBAC工作逻辑

1. 给用户(Users)授予一个角色(Role)，那么这个用户就有这个角色的权限。
2. 授权方式有2种
   1. 名称空间级别 的授权
   2. 集群级别 的授权

1.1.1、名称空间级别 的授权

如果通过rolebinding绑定role，只能对rolebingding所在的名称空间的资源有权限,上图user1这个用户绑定到role1上，只对role1这个名称空间的资源有权限，对其他名称空间资源没有权限，这个属于名称空间级别的授权。

1.1.2、集群级别的授权机制

1. 集群角色(ClusterRole)：可以认为是角色组的概念，就是一组角色
2. 定义一个集群角色(ClusterRole)，对集群内的所有资源都有可操作的权限
   1. 将User2通过ClusterRoleBinding到ClusterRole，使User2拥有集群的操作权限
3. 对资源的访问，没有名称空间的限制

1.2、Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图：

1.2.1、通过上图可以看到,3种绑定

1. 用户通过 rolebinding绑定role
2. 用户通过 clusterrolebinding绑定clusterrole
3. 用户通过 rolebinding绑定clusterrole

1.4、ClusterRole的好处

1. 假如有6个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义6个role和rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的role，这个是很麻烦的，所以我们引入clusterrole，定义一个clusterrole，对clusterrole授予所有权限，然后用户通过rolebinding绑定到clusterrole，就会拥有自己名称空间的管理员权限了，这样就减少了很多工作量。
2. 注：RoleBinding仅仅对当前名称空间有对应的权限。

2、授权机制

1. k8s中的授权策略也支持开启多个授权插件，只要一个验证通过即可。
2. k8s授权处理主要是根据以下请求属性：
   1. user, group, extra
   2. API、请求方法(如get、post、update、patch和delete)和请求路径(如/api)
   3. 请求资源和子资源
   4. Namespace
   5. API Group
3. k8s支持的授权模式
   1. Node Authorization
   2. ABAC Authorization
   3. RBAC Authorization
   4. 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

1. 通过启动参数使用RBAC：–authorization-mode=RBAC
2. 使用kubeadm安装k8s默认会enabled。
3. BAC API定义了四个资源对象用于描述RBAC中用户和资源之间的连接权限
   1. Role
   2. ClusterRole
   3. RoleBinding
   4. ClusterRoleBinding
4. Role是定义在某个Namespace下的资源，在这个具体的Namespace下使用。
   1. ClusterRole与Role相似，只是ClusterRole是整个集群范围内使用的。
   2. RoleBinding把Role绑定到账户主体Subject，让Subject继承Role所在namespace下的权限。
   3. ClusterRoleBinding把ClusterRole绑定到Subject，让Subject集成ClusterRole在整个集群中的权限。
5. API Server已经创建一系列ClusterRole和ClusterRoleBinding。
   1. 这些资源对象中名称以system:开头的，表示这个资源对象属于Kubernetes系统基础设施，也就说RBAC默认的集群角色已经完成足够的覆盖，让集群可以完全在 RBAC的管理下运行。
   2. 修改这些资源对象可能会引起未知的后果，例如
      1. 对于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

1. 用户在外部提供 HTTPS 授权服务，然后配置 apiserver 调用该服务去进行授权。
2. 参考官方文档
   1. https://kubernetes.io/docs/reference/access-authn-authz/webhook/

2.4.1、apiserver配置参数：

–authorization-webhook-config-file=SOME_FILENAME

3、kubernetes 中的认证机制

1. kubernetes 支持多种认证机制，可以配置成多个认证体制共存，这样，只要有一个认证通过，这个request就认证通过了。下面介绍官网列举的几种常见认证机制
2. 参考资料：https://kubernetes.io/docs/reference/access-authn-authz/authentication/

3.1、Service Account Tokens

1. Service Account Token 是一种比较特殊的认证机制
2. 适用于上文中提到的pod内部服务需要访问apiserver的认证情况
3. 默认enabled。

3.1.1、启动参数文件

–service-account-key-file=/etc/kubernetes/pki/apiserver-key.pem

1. 有启动参数文件，就使用启动参数文件
2. 没有启动参数文件，默认使用–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资源包含的数据有三部分：

1. ca.crt：

   1. API Server的CA公钥证书
   2. 用于Pod中的Process对API Server的服务端数字证书进行校验时使用的；

2. namespace：

   1. Secret所在namespace的值的base64编码： echo -n “kube-system”|base64
   2. 

3. token：

   1. 该token就是由service-account-key-file的值签署(sign)生成。
   2. 这种认证方式主要由k8s集群自己管理，用户用到的情况比较少。
   3. 我们创建一个pod时，默认就会将该namespace对应的默认service account token mount到Pod中，所以无需我们操作便可以直接与apiserver通信

3.2、OpenID Connect Tokens

类似 OAuth2的认证方式，大致认证过程如下：