kubernetes RBAC认证简介

你的名字 2022-05-26 01:15 281阅读 0赞

概述
RBAC是Role-Based Access Control的简称，中文为基于角色的访问控制
RBAC使用“rbac.authorization.k8s.io”API组来驱动授权决策，允许管理员通过Kubernetes API动态配置策略。

从1.8开始，RBAC模式处于稳定版本，并由rbac.authorization.k8s.io/v1 API提供支持。

要启用RBAC，请使用--authorization-mode = RBAC启动apiserver。

Role and ClusterRole

在RBAC API中，角色包含表示一组权限的规则。 权限纯粹是累加性的（没有“拒绝”规则）。 可以在某个空间指定角色Role或使用ClusterRole在集群范围内定义角色。

Role

Role只能用于授予对单个名称空间内资源的访问权限。 以下是可用于授予对Pod的读取权限的default名称空间中的角色示例：

  1. kind: Role
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4.   namespace: default
  5.   name: pod-reader
  6. rules:
  7. - apiGroups: [""] # "" indicates the core API group
  8.   resources: ["pods"]
  9.   verbs: ["get", "watch", "list"]

ClusterRole
ClusterRole除了拥有Role的权限之外，又因为它是集群内的，所以ClusterRole另外还有其他权限

  1. 访问集群内的资源如node的资源
  2. 非资源的endpoints 如/healthz

  3. 能访问集群内的所有的空间的资源，如kubectl get pods --all-namespaces

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:

    “namespace” omitted since ClusterRoles are not namespaced

    name: secret-reader
    rules:

    • apiGroups: [“”]
      resources: [“secrets”]
      verbs: [“get”, “watch”, “list”]
      这个ClusterRole可以访问集群内的所有空间的资源

RoleBinding and ClusterRoleBinding
RoleBinding 对应—> Role和ClusterRole
ClusterRoleBinding 对应—>ClusterRole
他们可以是针对某个用户或者某类用户或者是用户组以及service accounts

RoleBinding 对应—> Role

  1. # This role binding allows "jane" to read pods in the "default" namespace.
  2. kind: RoleBinding
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. metadata:
  5.   name: read-pods
  6.   namespace: default
  7. subjects:
  8. - kind: User
  9.   name: jane # Name is case sensitive
  10.   apiGroup: rbac.authorization.k8s.io
  11. roleRef:
  12.   kind: Role
  13.   name: pod-reader
  14.   apiGroup: rbac.authorization.k8s.io
  15.   这个表示用户jane可以访问空间default下所有pods的资源信息

RoleBinding 对应—> ClusterRole
RoleBinding还可以引用ClusterRole来授予RoleBinding命名空间中ClusterRole中定义的名称空间资源的权限。 这允许管理员为整个群集定义一组通用角色，然后在多个名称空间内重用它们。

  1. # This role binding allows "dave" to read secrets in the "development" namespace.
  2. kind: RoleBinding
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. metadata:
  5.   name: read-secrets
  6.   namespace: development # This only grants permissions within the "development" namespace.
  7. subjects:
  8. - kind: User
  9.   name: dave # Name is case sensitive
  10.   apiGroup: rbac.authorization.k8s.io
  11. roleRef:
  12.   kind: ClusterRole
  13.   name: secret-reader
  14.   apiGroup: rbac.authorization.k8s.io
  15.   这个表示用户dave可以访问集群内namespace为development下的所有的secret资源

ClusterRoleBinding 对应—>ClusterRole

  1. # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
  2. kind: ClusterRoleBinding
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. metadata:
  5.   name: read-secrets-global
  6. subjects:
  7. - kind: Group
  8.   name: manager # Name is case sensitive
  9.   apiGroup: rbac.authorization.k8s.io
  10. roleRef:
  11.   kind: ClusterRole
  12.   name: secret-reader
  13.   apiGroup: rbac.authorization.k8s.io
  14.   表示在group manager 中的成员都可以访问所有空间内的secret资源

Referring to Resources

大多数资源都以其名称的字符串表示形式表示，如“pods”，就像它出现在相关API的URL中一样。 但是，一些Kubernetes API涉及“子资源”，例如pods的日志。 pods日志的URL是：

  1. GET /api/v1/namespaces/{namespace}/pods/{name}/log

在这种情况下，“pods”是名称空间资源，“log”是pod的子资源。 要在RBAC角色中表示这种情况，请使用／来分隔资源和子资源。 要允许主题读取Pod和Pod日志，可以这么写：

  1. kind: Role
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4.   namespace: default
  5.   name: pod-and-pod-logs-reader
  6. rules:
  7. - apiGroups: [""]
  8.   resources: ["pods", "pods/log"]//用pods/log实现访问pod的日志的目的
  9.   verbs: ["get", "list"]

资源也可以通过resourceNames列表的某些请求的名称引用。 指定时，使用“get”，“delete”，“update”和“patch”动词的请求可以限制为资源的单个实例。
例如要限制对configmap只允许“get“,”update”操作权限，可以这么写

  1. kind: Role
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4.   namespace: default
  5.   name: configmap-updater
  6. rules:
  7. - apiGroups: [""]
  8.   resources: ["configmaps"]
  9.   resourceNames: ["my-configmap"]
  10.   verbs: ["update", "get"]

如果设置了 resourceNames 那 verb 就不能是 list, watch, create, deletecollection. 因为资源名resourceNames 不存在list, watch, create, deletecollection请求的URL中

Aggregated ClusterRoles
从kubernetes1.9开始，可以通过使用aggregationRule组合其他ClusterRoles来创建ClusterRoles。 聚集的ClusterRoles的权限由控制器管理，并通过联合与提供的标签选择器匹配的任何ClusterRole的规则来填充。 聚合ClusterRole示例：

  1. kind: ClusterRole
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4.   name: monitoring
  5. aggregationRule:
  6.   clusterRoleSelectors:
  7.   - matchLabels:
  8.       rbac.example.com/aggregate-to-monitoring: "true"
  9. rules: [] # Rules are automatically filled in by the controller manager.

创建拥有标签rbac.example.com/aggregate-to-monitoring：true的ClusterRole

  1. kind: ClusterRole
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4.   name: monitoring-endpoints
  5.   labels:
  6.     rbac.example.com/aggregate-to-monitoring: "true"
  7. # These rules will be added to the "monitoring" role.
  8. rules:
  9. - apiGroups: [""]
  10.   Resources: ["services", "endpoints", "pods"]
  11.   verbs: ["get", "list", "watch"]

Aggregated ClusterRoles例子，该例子表示 aggregate-cron-tabs-edit对crontabs拥有”get”, “list”, “watch”, “create”, “update”, “patch”, “delete”权限，而aggregate-cron-tabs-view只有”get”, “list”, “watch”操作权限

  1. kind: ClusterRole
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4.   name: aggregate-cron-tabs-edit
  5.   labels:
  6.     # Add these permissions to the "admin" and "edit" default roles.
  7.     rbac.authorization.k8s.io/aggregate-to-admin: "true"
  8.     rbac.authorization.k8s.io/aggregate-to-edit: "true"
  9. rules:
  10. - apiGroups: ["stable.example.com"]
  11.   resources: ["crontabs"]
  12.   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  13. ---
  14. kind: ClusterRole
  15. apiVersion: rbac.authorization.k8s.io/v1
  16. metadata:
  17.   name: aggregate-cron-tabs-view
  18.   labels:
  19.     # Add these permissions to the "view" default role.
  20.     rbac.authorization.k8s.io/aggregate-to-view: "true"
  21. rules:
  22. - apiGroups: ["stable.example.com"]
  23.   resources: ["crontabs"]
  24.   verbs: ["get", "list", "watch"]

Role Examples

只允许读的权限

  1. rules:
  2. - apiGroups: [""]
  3.   resources: ["pods"]
  4.   verbs: ["get", "list", "watch"]

允许读写的权限(对deployments的extensions或者apps的api)

  1. rules:
  2. - apiGroups: ["extensions", "apps"]
  3.   resources: ["deployments"]
  4.   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读pods，允许读写jobs

  1. rules:
  2. - apiGroups: [""]
  3.   resources: ["pods"]
  4.   verbs: ["get", "list", "watch"]
  5. - apiGroups: ["batch", "extensions"]
  6.   resources: ["jobs"]
  7.   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读名字为my-config的ConfigMap(必须与RoleBinding绑定，以限制单个命名空间中的单个ConfigMap)

  1. rules:
  2. - apiGroups: [""]
  3.   resources: ["configmaps"]
  4.   resourceNames: ["my-config"]
  5.   verbs: ["get"]

允许读node上的资源(因为节点是集群范围的，所以必须在ClusterRole中绑定一个ClusterRoleBinding才能生效)

  1. rules:
  2. - apiGroups: [""]
  3.   resources: ["nodes"]
  4.   verbs: ["get", "list", "watch"]

允许post get操作的例子

  1. rules:
  2. - nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  3.   verbs: ["get", "post"]

Referring to Subjects
RoleBinding 和 ClusterRoleBinding帮定某个具体的subjects，subjects可以是 groups, users或者 service accounts，例如可以是名字test或者邮箱，还有某类前缀等等，但是有些前缀是系统的保留的如system:就不能使用

Service Accounts 拥有 system:serviceaccount:前缀的用户属于拥有system:serviceaccounts:的groups.
例子
用户名为alice@example.com的用户

  1. subjects:
  2. - kind: User
  3.   name: "alice@example.com"
  4.   apiGroup: rbac.authorization.k8s.io

组名为frontend-admins

  1. subjects:
  2. - kind: Group
  3.   name: "frontend-admins"
  4.   apiGroup: rbac.authorization.k8s.io

名字为default空间是kube-system的service

  1. subjects:
  2. - kind: ServiceAccount
  3.   name: default
  4.   namespace: kube-system

service accounts 为qa

  1. subjects:
  2. - kind: Group
  3.   name: system:serviceaccounts:qa
  4.   apiGroup: rbac.authorization.k8s.io

任何服务service accounts都生效

  1. subjects:
  2. - kind: Group
  3.   name: system:serviceaccounts
  4.   apiGroup: rbac.authorization.k8s.io

所有经过认账的用户(kubernetes 1.5+)

  1. subjects:
  2. - kind: Group
  3.   name: system:authenticated
  4.   apiGroup: rbac.authorization.k8s.io

未认证的用户(kubernetes 1.5+)

  1. subjects:
  2. - kind: Group
  3.   name: system:unauthenticated
  4.   apiGroup: rbac.authorization.k8s.io

所有用户(kubernetes 1.5+)

  1. subjects:
  2. - kind: Group
  3.   name: system:authenticated
  4.   apiGroup: rbac.authorization.k8s.io
  5. - kind: Group
  6.   name: system:unauthenticated
  7.   apiGroup: rbac.authorization.k8s.io

default Roles and Role Bindings
API服务器创建一组默认的ClusterRole和ClusterRoleBinding对象。 其中很多是system:前缀，表示该资源由基础设施“拥有”。 对这些资源的修改可能会影响集群的功能。
例如 system:节点ClusterRole。 该角色定义了kubelets的权限。 如果角色被修改，它将会影响kubelets的正常运行。
默认的Roles and Role Bindings 都带有这个labelkubernetes.io/bootstrapping=rbac-defaults

禁用Auto-reconciliation功能

在annotation 添加 rbac.authorization.kubernetes.io/autoupdate:false就可以实现，不自动更新权限

Discovery Roles

role

User-facing Roles(本人能力有限)直接引用官方的
role01

核心组件角色
role02

其他组件角色
role03

Controller Roles

控制器角色的前缀为system:controller:，如果启用--use-service-account-credentials，将会在各自的权限下管理 否则必须授予所有的访问权限

  1. system:controller:attachdetach-controller
  2. system:controller:certificate-controller
  3. system:controller:cronjob-controller
  4. system:controller:daemon-set-controller
  5. system:controller:deployment-controller
  6. system:controller:disruption-controller
  7. system:controller:endpoint-controller
  8. system:controller:generic-garbage-collector
  9. system:controller:horizontal-pod-autoscaler
  10. system:controller:job-controller
  11. system:controller:namespace-controller
  12. system:controller:node-controller
  13. system:controller:persistent-volume-binder
  14. system:controller:pod-garbage-collector
  15. system:controller:pv-protection-controller
  16. system:controller:pvc-protection-controller
  17. system:controller:replicaset-controller
  18. system:controller:replication-controller
  19. system:controller:resourcequota-controller
  20. system:controller:route-controller
  21. system:controller:service-account-controller
  22. system:controller:service-controller
  23. system:controller:statefulset-controller
  24. system:controller:ttl-controller

权限升级

例如：授予用户user-1在user-1-namespace下admin, edit,以及 view的权限

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRole
  3. metadata:
  4.   name: role-grantor
  5. rules:
  6. - apiGroups: ["rbac.authorization.k8s.io"]
  7.   resources: ["rolebindings"]
  8.   verbs: ["create"]
  9. - apiGroups: ["rbac.authorization.k8s.io"]
  10.   resources: ["clusterroles"]
  11.   verbs: ["bind"]
  12.   resourceNames: ["admin","edit","view"]
  13. ---
  14. apiVersion: rbac.authorization.k8s.io/v1
  15. kind: RoleBinding
  16. metadata:
  17.   name: role-grantor-binding
  18.   namespace: user-1-namespace
  19. roleRef:
  20.   apiGroup: rbac.authorization.k8s.io
  21.   kind: ClusterRole
  22.   name: role-grantor
  23. subjects:
  24. - apiGroup: rbac.authorization.k8s.io
  25.   kind: User
  26.   name: user-1

使用命令行授予命名空间或整个集群内的角色。

kubectl create rolebinding

授予指定空间 Role 或者 ClusterRole 角色权限 :

授予用户为bob在空间acme下 admin ClusterRole 权限:

  1. kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

授予service account为myapp空间为acme的 view ClusterRole 权限:

  1. kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

kubectl create clusterrolebinding

授予用户root cluster-admin ClusterRole 集群权限:

  1. kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

授予用户kubelet system:node ClusterRole 集群权限:

  1. kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

授予 service account 为myapp空间为acme view ClusterRole 集群权限:

  1. kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

Service Account Permissions

kubernetes RBAC默认不授权给除了空间名为kube-system之外的Service Account权限，留给用户自主管理，这样就让用户自己管理好解决，更好地掌握权限的粒度

为特定于应用程序的服务帐户授予角色（最佳做法):

前提: pod spec指定serviceAccountName且创建了对应的serviceaccount
授予service account 为my-sa 在空间my-namespace下 read-only 权限

  1. kubectl create rolebinding my-sa-view \
  2.   --clusterrole=view \   --serviceaccount=my-namespace:my-sa \   --namespace=my-namespace

授予 service account 为default 在空间my-namespace下的read-only权限
注意k8s默认就生成了一个name为default的service account

  1. kubectl create rolebinding default-view \
  2.   --clusterrole=view \
  3.   --serviceaccount=my-namespace:default \
  4.   --namespace=my-namespace

许多插件都是在service account为default 空间为kube-system下，因此要赋予插件以super-user的权限就必须授予service account为default 空间为kube-system下cluster-admin的权限

  1. kubectl create clusterrolebinding add-on-cluster-admin \
  2.   --clusterrole=cluster-admin \
  3.   --serviceaccount=kube-system:default

授权my-namespace空间下所有service accounts的read-only权限

  1. kubectl create rolebinding serviceaccounts-view \
  2.   --clusterrole=view \   --group=system:serviceaccounts:my-namespace \   --namespace=my-namespace

授予所有空间下所有service accounts的 read-only权限

  1. kubectl create clusterrolebinding serviceaccounts-view \ --clusterrole=view \ --group=system:serviceaccounts

授予所有service accounts super-user 权限

  1. kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  2.   --clusterrole=cluster-admin \
  3.   --group=system:serviceaccounts

参考
rbac

发表评论

表情：
评论列表 （有 0 条评论，281人围观）

还没有评论，来说两句吧...

相关阅读

    相关 Kubernetes简介

    什么是Kubernetes？ Kubernetes是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。它提供了一组强大的API和工具，可以帮助开发人员和运

    短命女短命女/ 0 赞/ 105 阅读

    相关 Kubernetes简介

    Kubernetes 本文内容仅为个人理解，如有偏颇，欢迎指正。 一、传统的运维方式 在了解Kubernetes之前，我们有必要先简单了解一下传统的运维模式。在传

    超、凢脫俗超、凢脫俗/ 0 赞/ 76 阅读