【Kubernetes】认证授权RBAC （一）

一、k8s安全管理：认证、授权、准入控制概述

1.1、简介

【1】认证基本介绍

kubernetes主要通过APIserver对外提供服务，那么就需要对访问apiserver的用户做认证。
如果任何人都能访问apiserver，那么就可以随意在k8s集群部署资源，这是非常危险的，也容易被黑客攻击渗透。所以需要我们对访问的k8s系统apiserver的用户进行认证，确保是合法的、符合要求的用户

【2】授权基本介绍

认证通过后仅代表它是一个被apiserver信任的用户，能访问apierver，但是用户是否拥有删除资源的权限，需要进行授权操作，常见的授权方式有rbac授权。

【3】准入控制基本介绍

当用户经过认证和授权后，最后一步就是准入控制了。
k8s提供了多重准入控制机制，它有点类似“插件”，为apiserver提供了很好的“可扩展性”。
请求apiserver时，通过认证鉴权后、持久化（“api对象”保存到etcd）前，会经过“准入控制器”，让它可以做“变更和认证”。

为什么需要准入控制器呢？
如果我们创建pod时定义了资源上下限，但不满足LimitRange规则中定义的资源上下限，此时LimitRanger就会拒绝我们创建此pod。

假如我们定义了一个名称空间叫做test-aa，这个名称空间做下资源限制：限制最多可以使用10vCPU、10Gi内存，在这个名称空间test-aa下创建的所有pod，定义limit的时候，所有pod的limit值不能超过test-aa这个名称空间设置的limit上线。

1.2、认证

k8s客户端访问apiserver的几种认证方式：

【1】客户端认证

客户端认证也成为双向TLS认证，kubectl在访问apiserver的时候，apiserver也要认证kubectl是否是合法的，他们都会通过ca根证书来进行验证：

【2】Bearertoken

Beartoken的方式，可以理解为apiserver将一个密码通过了非对称加密的方式告诉了kubectl，然后通过该密码进行相互访问：

kubectl访问k8s集群，要找一个kubeconfig文件，基于这个文件里的用户访问apiserver。

【3】Serviceaccount

上面的俩种认证方式，都是外部访问apiserver的时候使用的方式。
serviceaccount是内部访问pod和apiserver交互时候采用的一种方式。
serviceaccount包括namespace、token、ca，且通过目录挂载的方式给与pod，当pod运行起来的时候，就会读取到这些信息，从而使用该方式和apiserver进行通信。

【4】拓展：kubeconfig文件

官方地址：
https://kubernetes.io/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/

在k8s集群中，当我们使用kubectl操作k8s资源时，需要确定我们用哪个用户访问哪个k8s集群，kubectl操作k8s集群资源会去/root/.kube目录下找config文件，可以通过命令行查看配置文件：

[root@master ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.32.1.147:6443   # apiserver地址
  name: kubernetes                     # 集群的名字
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes   # 上下文的名字
current-context: kubernetes-admin@kubernetes  # 当前上下文
kind: Config 
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

在上面的配置文件当中，定义了集群、上下文以及用户。
其中config也是k8s的标准资源之一，在该配置文件中定义了一个集群列表，指定的集群可有多个，用户列表也可以有多个，指明集群中的用户。
而在上下文列表当中，是进行定义可以使用哪个用户对那个集群进行访问，以及当前使用的上下文是什么。

kubectl get pods --kubeconfig=/root/.kube/config

1.3、授权

用户通过认证之后，什么权限都没有，需要一些后续的授权操作，如对资源的增删该查等，
kubernetes1.6之后开始有RBAC（基于角色的访问控制机制）授权检查机制。

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

【1】什么是RBAC（基于角色的授权）

让一个用户(user)扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问。

在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是：把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。
如果通过rolebinding绑定role，只能对rolebinding所在的名称空间的资源有权限。
如上图，user1绑定到role1，只对role1这个名称空间的资源有权限，对其他ns的资源无权限，属于名称空间级别的；

另外，k8s还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有课操作的权限。
user可以通过ClusterRoleBinding绑定到ClusterRole，从而使user拥有集群的操作权限。

【2】用户基于rolebinding绑定到role

限定在rolebinding所在的名称空间

【3】用户基于rolebinding绑定到clusterrole

rolebinding绑定clusterrole的好处：
假如有6个ns，每个ns下的用户都需要对自己的名称空间有管理员权限，那么需要定义6个role和rolebinding，然后依次绑定，如果ns越来越多，就要定义更多的role和rolebinding，很麻烦，所以引入clusterrole。
定义一个clusterole，对其授予所有权限，然后用户通过rolebinding绑定到clusterrole，就会拥堵对自己名称的管理员权限了

注：RoleBinding仅仅对当前名称空间有对应的权限

【4】用户基于clusterrolebinding绑定到clusterrole

1.4、准入控制

在k8s上准入控制器的模块有很多，其中比较常用的有：LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy（k8s 1.25已废弃）等等，对于前三种准入控制器系统默认是启用的，我们只需要定义对应的规则即可；

对于PodSecurityPolicy(k8s1.25废弃了)这种准入控制器，系统默认没有启用，如果我们要使用，就必需启用以后，对应规则才会正常生效；这里需要注意一点，对应psp准入控制器，一定要先写好对应的规则，把规则和权限绑定好以后，在启用对应的准入控制器，否则先启用准入控制器，没有对应的规则，默认情况它是拒绝操作，这可能导致现有的k8s系统跑的系统级pod无法正常工作；所以对于psp准入控制器要慎用，如果规则和权限做的足够精细，它会给我们的k8s系统安全带来大幅度的提升，反之，可能导致整个k8s系统不可用。

查看apiserver启用的准入控制器有哪些？

[root@master ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.32.1.147:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.32.1.147
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
 ......

提示：

apiserver启用准入控制插件需要使用–enable-admission-plugins选项来指定，该选项可以使用多个值，用逗号隔开表示启用指定的准入控制插件；
这里配置文件中显式启用了NodeRestrication这个插件；
默认没有写在这上面的内置准入控制器，它也是启用了的，比如LimitRanger、ResourceQuota、ServiceAccount等等；
对于不同的k8s版本，内置的准入控制器和启用与否请查看相关版本的官方文档；
对于那些没有启动的准入控制器，我们可以在上面选项中直接启用，分别用逗号隔开即可。

对应的官网地址：
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/

二、k8s安全管理：账户

2.1、Useraccount和ServiceAccount介绍

kubernetes中账户分为：UserAccounts（用户账户） 和 ServiceAccounts（服务账户） 两种。

【1】UserAccount

UserAccount是给kubernetes集群外部用户使用的，如kubectl访问k8s集群要用useraccount用户， kubeadm安装的k8s，默认的useraccount用户是kubernetes-admin；

APIServer需要对客户端做认证，使用kubeadm安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

用户名称可以在kubeconfig中查看

[root@master ~]# cat  ~/.kube/config
...
users:
- name: kubernetes-admin
...

【2】ServiceAccount

• ServiceAccount是Pod使用的账号，Pod容器的进程需要访问API Server时用的就是ServiceAccount账户；
• ServiceAccount仅局限它所在的namespace，每个namespace创建时都会自动创建一个default service account；
• 创建Pod时，如果没有指定Service Account，Pod则会使用default Service Account。

2.2、ServiceAccount使用案例介绍

【1】创建sa，并绑定到pod

[root@master 16]# kubectl create sa sa-test
serviceaccount/sa-test created

[root@master 16]# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sa-test
  namespace: default
  labels:
    app: sa
spec:
  serviceAccountName: sa-test
  containers:
  - name:  sa-tomcat
    ports:
    - containerPort: 80
    image: nginx
    imagePullPolicy: IfNotPresent
[root@master 16]# kubectl apply -f pod.yaml
pod/sa-test created

【2】运行pod进行，验证sa是否可以访问apiserver

[root@master 16]# kubectl exec -it sa-test -- /bin/bash
root@sa-test:/#  cd /var/run/secrets/kubernetes.io/serviceaccount/

root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)"  https://kubernetes/api/v1/namespaces/kube-system
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "namespaces \"kube-system\" is forbidden: User \"system:serviceaccount:default:sa-test\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"kube-system\"",
  "reason": "Forbidden",
  "details": {
    "name": "kube-system",
    "kind": "namespaces"
  },
  "code": 403
}
# 上面结果能看到，sa能通过https方式成功认证API
# 但是没有权限访问k8s资源，所以code状态码是403，表示没有权限操作k8s资源

【3】对sa授权

[root@master 16]#  kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin  --serviceaccount=default:sa-test
clusterrolebinding.rbac.authorization.k8s.io/sa-test-admin created

【4】再次请求

# 请求指定ns空间下的资源
root@sa-tst:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)"  https://kubernetes/api/v1/namespaces/kube-system

{
  "kind": "Namespace",
  "apiVersion": "v1",
  "metadata": {
    "name": "kube-system",
    "uid": "1634946c-f5c2-4b67-ad3a-425107a83cd0",
    "resourceVersion": "26",
    "creationTimestamp": "2023-12-06T02:47:03Z",
    "labels": {
      "kubernetes.io/metadata.name": "kube-system"
    },
    "managedFields": [
      {
        "manager": "kube-apiserver",
        "operation": "Update",
        "apiVersion": "v1",
        "time": "2023-12-06T02:47:03Z",
        "fieldsType": "FieldsV1",
        "fieldsV1": {
          "f:metadata": {
            "f:labels": {
              ".": {},
              "f:kubernetes.io/metadata.name": {}
            }
          }
        }
      }
    ]
  },
  "spec": {
    "finalizers": [
      "kubernetes"
    ]
  },
  "status": {
    "phase": "Active"
  }
}root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount#
# 请求pod资源
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)"  https://kubernetes/apiv1/pods
......

三、RBAC认证授权策略

RBAC介绍

在Kubernetes中，所有资源对象都是通过API进行操作，他们保存在etcd里。
而对etcd的操作我们需要通过访问 kube-apiserver 来实现，上面的Service Account其实就是APIServer的认证过程，而授权的机制是通过RBAC：基于角色的访问控制实现。

3.1、Role角色

一组权限的集合，在一个命名空间中，可以用其来定义一个角色，只能对命名空间内的资源进行授权。如果是集群级别的资源，则需要使用ClusterRole。

例如：定义一个角色用来读取Pod的权限.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-read
rules:
- apiGroups: [""]
  resources: ["pods"]
  resourceNames: []
verbs: ["get","watch","list"]

rules中的参数说明：
1、apiGroups：支持的API组列表，例如："apiVersion: apps/v1"等
2、resources：支持的资源对象列表，例如pods、deployments、jobs等
3、resourceNames: 指定resource的名称
4、verbs：对资源对象的操作方法列表。

3.2、ClusterRole集群角色

具有和角色一致的命名空间资源的管理能力，还可用于以下特殊元素的授权.
1、集群范围的资源，例如Node
2、非资源型的路径，例如：/healthz
3、包含全部命名空间的资源，例如Pods

例如：定义一个集群角色可让用户访问任意secrets

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-clusterrole
rules:
- apiGroups: [""]
 resources: ["secrets"]
verbs: ["get","watch","list"]

3.3、RoleBinding角色绑定

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是User，Group，Service Account，使用RoleBinding为某个命名空间授权，使用ClusterRoleBinding为集群范围内授权。

例如：将在rbac命名空间中把pod-read角色授予用户es

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-bind
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
- kind: Role
  name: pod-read
  apiGroup: rbac.authorizatioin.k8s.io

3.4、ClusterRolebinding集群角色绑定

RoleBinding也可以引用ClusterRole，对属于同一命名空间内的ClusterRole定义的资源主体进行授权.
例如：es能获取到集群中所有的资源信息.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: es-allresource
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin