参考

• 使用token访问k8s集群
• 关于 Kubernetes中API Server授权(RBAC)管理的一些笔记
• Kubernetes之ServiceAccount + Secret + RBAC实现访问APIServer

步骤

1. 建立 ClusterRole 或 Role
2. 在某个 namespace 下建立 ServiceAccount（会生成对应的 secret，其中就是 token）
3. 建立 ClusterRoleBinding 或 RoleBinding

1 找一个token

• 建立 ServiceAccount 会产生一个【同名+随机字符串】的 Secret
• 从 Secret 中可获得 Token
• 注意
  1. 只能这样直接 | base64 -d解码才能获得 Token，若先将 Secret 保存为 yaml，再提取 Token，就会出错，无法提取 Token
  2. 通过下面获取的 Token 保存到文件中后，可能会出现更改（保存在 txt 文件中不会更改），请注意

kubectl get secret kube-proxy-token-qvcp2  -n kube-system -o jsonpath={".data.token"} | base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlLXByb3h5LXRva2VuLXF2Y3AyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Imt1YmUtcHJveHkiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI5MmQxY2FlZC1hYjE2LTExZWEtYTUxNy01MjU0MmMzNDgzOGYiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06a3ViZS1wcm94eSJ9.Z3GPxRHkp8wuIkGDf8DcOM-ZpunXtifhI6Wcd92lghOjrAOU7b2yIe6M2ybT22GuWANKezbe85DPqxvkIhTOhaVNkfeOuyhbBs5FBi3wBcjGVH2QAge1bHNT2yL_gjhaFR-tuaJSwrZpYWV8ubYXEB3ydNRpDh7CrdGcB8uBbkZgtsvWlBdWqSG-w5qcsJCcUmA-dP8ClW24pXCXVtzQ5VspbUJNS2OI3CR1PWROZCKBshifdyxkpPZXDrpRpPUrRRaVeG5f3v-DOhl_zI3T604ThqDvr9pJHSG7UIioUF-F9AmJtHMX0SAZyrZV-e8cnskakk_vcrAZd1AEqQjfSA

2 访问测试

• 注意，其中 Token 两边是双引号，单引号可能出错
• 不行的话，再试试单引号

curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlLXByb3h5LXRva2VuLXF2Y3AyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Imt1YmUtcHJveHkiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI5MmQxY2FlZC1hYjE2LTExZWEtYTUxNy01MjU0MmMzNDgzOGYiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06a3ViZS1wcm94eSJ9.Z3GPxRHkp8wuIkGDf8DcOM-ZpunXtifhI6Wcd92lghOjrAOU7b2yIe6M2ybT22GuWANKezbe85DPqxvkIhTOhaVNkfeOuyhbBs5FBi3wBcjGVH2QAge1bHNT2yL_gjhaFR-tuaJSwrZpYWV8ubYXEB3ydNRpDh7CrdGcB8uBbkZgtsvWlBdWqSG-w5qcsJCcUmA-dP8ClW24pXCXVtzQ5VspbUJNS2OI3CR1PWROZCKBshifdyxkpPZXDrpRpPUrRRaVeG5f3v-DOhl_zI3T604ThqDvr9pJHSG7UIioUF-F9AmJtHMX0SAZyrZV-e8cnskakk_vcrAZd1AEqQjfSA" https://172.16.99.200:6443/api

3 查看输出

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "172.16.99.200:6443"
    }
  ]
}

理清关系

• 在 K8S 集群中使用单一 Token 访问可控制多个 Namespace ( Using one sa token access and control multi namespaces)
• kubernetes rabc 的sa创建并限制多个namespace

概念
api-resources	注意 api-resources 也是有类型的，分为 Namespace 级和非 Namespace 级 查看集群上 api resources 信息 （NAMESPACED 字段表示的就是 namespace 级还是非 namespace 级 ）
ServiceAccount	是 namespace 级别的（就是一个 sa 只能在 一个 ns 下，不能在多个 ns 下）
总结	RoleBinding 创建需要指定 ns，作用范围也就是所在 ns，权限依据绑定的 Role 或 ClusterRole ClusterRoleBinding 创建不需要指定 ns，因此作用范围是集群范围（所有ns），权限依据绑定的 ClusterRole **ns 权限控制：**Role【仅在ns内，无法被别的ns引用】+ RoleBinding【作用在ns内】 **ns 权限控制（多ns配置相同权限）：**CluterRole【多ns的共用权限】+ RoleBinding【作用在ns内】 **一个 sa token 管控多个 ns：**同一 ServiceAccount + CluterRole【不同权限】+ RoleBinding【创建在不同ns下】 集群权限控制： CluterRole【大权限或特定权限】+ ClusterRoleBinding【作用在集群范围】
RoleBinding	RoleBinding 可以绑定 Role 和 ClusterRole 在哪个ns下创建 RoleBinding 就可对该 ns 具有相应的处置权限（具体视 Role 或 ClusterRole 所配置的）
ClusterRoleBinding	ClusterRoleBinding 只能绑定 ClusterRole ClusterRoleBinding 没有 ns 的概念，管控就是集群级别资源
Role+RoleBinding（ns内权限控制）	1. Role 是 namespace 级别资源，只能在所在 namespace 起作用，【无法被别的 ns 引用】 2. RoleBinding 也是 namespace 级别资源 3. 所以这两个组合只能作用于【Role 所在的 ns】
ClusterRole+RoleBinding （ns内权限控制，多ns配置相同权限）	1. ClusterRole 是集群级别资源，不受 namespace 所显示，【所有 ns 都可引用】 2. 可以把 ClusterRole 视为【抽象出的公共部分】，可以通过 RoleBinding 作用在不同的 namespace 举例子，现在有3个ns，我需要每个 ns 下的 ServiceAccount 都具有对 pod 的 get 、list 权限，怎么实现？ 1. 若采用 Role+RoleBinding，那需要先【在每个 ns 下】创建【具有get、list权限的 Role】，之后 RoleBinding 绑定该 ns 下的 ServiceAccount 2. 若采用 Cluster+RoleBinding，那简单了，只需要建立【一个】【具有get、list权限的 ClusterRole】（相当于提取公共部分），之后 RoleBinding 绑定该 ns 下的 ServiceAccount
ClusterRole+RoleBinding （一个 SA 管控多个 ns）	下面例子就是同一个 ServiceAccount default:updateuser 可以管控两个ns（default 和 kube-sytem） 可以看出 default 的 sa 可控制 default ns ： RoleBinding 创建在 default ns 内，引用的sa 是 default 的 updateuser，所以该 sa 可控制 default ns，权限是 clusterrole 所指定的 kubectl create rolebinding updateuser --clusterrole=system:controller:deployment-controller --serviceaccount=default:updateuser --namespace=default 可以看出 default 的 sa 可控制 kube-system ns ： RoleBinding 创建在 kube-system ns 内，引用的sa 是 default 的 updateuser，所以该 sa 可控制 default ns，权限是 clusterrole 所指定的 kubectl create rolebinding updateuser --clusterrole=system:controller:deployment-controller --serviceaccount=default:updateuser --namespace=kube-system 上面ClusterRole 可以指定不同的，代表不同的权限限制
ClusterRole+ClusterRoleBinding	1. 这种情况，适用于【某个用户需要特别大权限或特定权限的场景】 2. 如 ClusterRole 为 cluster-admin（具有所有权限），通过 ClusterRoleBinding 绑定用户，是该用户具有【大权限】

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zXee3Bls-1666082485625)(/Users/dufengyang/Library/Application Support/typora-user-images/image-20220929164248903.png)]

• SA 通过 RoleBinding 绑定 Role ，具有 Role 权限，只能操作 Role 所在 namespace

• 可以实现 SA 具有操作别的 namespace 中资源的权限（例如 SA 在 ns1, Role 在 ns2，SA 可操作 ns2 资源）

• SA 通过 RoleBinding 绑定 ClusterRole, 具有 ClusterRole 权限，只能操作 SA 所在的 namespace

  • 可以实现 SA 在所在 namespace 具有高权限，但不能跨出当前 namespace

• SA 通过 ClusterRoleBinding 绑定 ClusterRole，具有 ClusterRole 权限，可操作所有 namespace 和集群资源

• 没有 ClusterRoleBinding 与 Role 的 组合

举例子

Role ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: role-liruilong
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - services
  verbs:
  - get
  - list
  - watch
  - create
  - delete
- apiGroups:
  - "apps"
  resources:
  - deployments
  - deployments/scale
  verbs:
  - get
  - list
  - watch
  - create
  - delete
  - patch
  
---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: example-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - nodes/proxy
  - nodes/metrics
  - services
  - endpoints
  - pods
  - ingress
  verbs:
  - get
  - list
  - watch
- nonResourceURLs:
  - /metrics
  verbs:
  - get