参考

步骤

  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"
    }
  ]
}

理清关系

概念
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【作用在集群范围】
RoleBindingRoleBinding 可以绑定 Role 和 ClusterRole
在哪个ns下创建 RoleBinding 就可对该 ns 具有相应的处置权限(具体视 Role 或 ClusterRole 所配置的)
ClusterRoleBindingClusterRoleBinding 只能绑定 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 nsRoleBinding 创建在 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 nsRoleBinding 创建在 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+ClusterRoleBinding1. 这种情况,适用于【某个用户需要特别大权限或特定权限的场景】
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
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐