• Kubernetes的RBAC权限控制


    参考:

    1. https://blog.csdn.net/BigData_Mining/article/details/88849696
    2. https://cn-blogs.cn/archives/9078.html
    一、基本概念

    kubernetess的RBAC使用”rbac.authorization.k8s.io” API Group实现授权决策,允许管理员通过Kubernetes API动态配置策略,主要的概念有

    1. RBAC中资源有:Pods、PV、ConfigMaps、Deployments、Nodes、Secrets、Namespaces
    2. 资源api group关联:如pods属于core api group,deployments属于apps api group
    3. RBAC中操作有:get、create、list、delete、update、edit、watch、exe
    4. User:-
    5. Role :在一个namespace中的角色,其中rules规定一组可以在不同api group上的资源执行的规则(verbs
    6. ClusterRole:在整个集群中的角色,管理三种Subject:Service Account(针对pods运行的进程)、User Account(针对人)、Groups
    7. RoleBinding与ClusterRoleBinding:User与Role/ClusterRole的中间表绑定关系
    二、Role、ClusterRole、RoleBinding、ClusterRoleBinding

    Role与ClusterRole

    在RBAC API中,一个角色定义了一组特定权限的规则。namespace范围内的角色由Role对象定义,而整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。

    1、Role
    Role对象只能用于授予对某一namespace中资源的访问权限。
    以下示例表示在“default” namespace中定义一个Role对象,用于授予对资源pods的读访问权限,绑定到该Role的用户则具有get/watch/list pod资源的权限:

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      namespace: default
      name: pod-reader
    rules:
    - apiGroups: [""] # 空字符串""表明使用core API group,不是拥有了全区权限
      resources: ["pods"]
      verbs: ["get", "watch", "list"]

    为了更容易对API进行扩展,Kubemetes 使用API Groups (API组)进行标识。APIGroups 以及REST URL中的路径进行定义。当前支持两类API groups。

    Core Groups (核心组),也可以称为Legacy Groups,该组的REST路径位于/api/v1, 作为 Kubernetes 最核心的 API,
    它是没有“组”的概念,例如 ”v1“,在资源对象的定义中表示为”apiVersion: v1“。
    
    具有分组信息的API,以/apis/$GROUP_NAME/$VERSIONURL路径进行标识,在资源对象的定义中表示为
    apiVersion: $GROUP_NAME/$VERSION(例如,apiVersion: batch/v1)。已支持的 API 组详细列表请参阅
    Kubernetes API reference。

    2、ClusterRole
    ClusterRole对象可以授予整个集群范围内资源访问权限, 也可以对以下几种资源的授予访问权限:

    • 集群范围资源(例如节点,即node)
    • 非资源类型endpoint(例如”/healthz”)
    • 跨所有namespaces的范围资源(例如pod,需要运行命令kubectl get pods --all-namespaces来查询集群中所有的pod)

    以下示例中定义了一个名为pods-reader的ClusterRole,绑定到该ClusterRole的用户或对象具有用对集群中的资源pods的读访问权限:

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      # 鉴于ClusterRole是集群范围对象,所以这里不需要定义"namespace"字段
      name: pods-reader
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]

    RoleBinding与ClusterRoleBinding

    角色绑定将一个角色中定义的各种权限授予一个或者一组用户,则该用户或用户组则具有对应绑定的Role或ClusterRole定义的权限。
    角色绑定包含了一组相关主体(即subject, 包括用户——User、用户组——Group、或者服务账户——Service Account)以及对被授予角色的引用。 在某一namespace中可以通过RoleBinding对象授予权限,而集群范围的权限授予则通过ClusterRoleBinding对象完成。

    3、RoleBinding
    RoleBinding可以将同一namespace中的subject(用户)绑定到某个具有特定权限的Role下,则此subject即具有该Role定义的权限。
    下面示例中定义的RoleBinding对象在”default” namespace中将”pod-reader”角色授予用户”Caden”。 这一授权将允许用户”Caden”从”default” namespace中读取pod。

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: read-pods
      namespace: default
    subjects:
    - kind: User
      name: Caden
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io

    4、ClusterRoleBinding

    ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定,授予权限。
    下面示例中所定义的ClusterRoleBinding 允许在用户组”pods-reader”中的任何用户都可以读取集群中任何namespace中的pods。

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: read-pods-global
    subjects:
    - kind: Group
      name: pods-reader
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: pods-reader
      apiGroup: rbac.authorization.k8s.io

    此外,RoleBinding对象也可以引用一个ClusterRole对象用于在RoleBinding所在的namespace内授予用户对所引用的ClusterRole中 定义的namespace资源的访问权限。这一点允许管理员在整个集群范围内首先定义一组通用的角色,然后再在不同的名字空间中复用这些角色。
    例如,尽管下面示例中的RoleBinding引用的是一个ClusterRole对象,但是用serviceaccount ”reader-dev”(即角色绑定主体)还是只能读取”development” namespace中的pods(即RoleBinding所在的namespace)。

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: read-pods
      namespace: development # 这里表明仅授权读取"development" namespace中的资源,若不定义该字段,则表示整个集群的Pod资源都可访问
    subjects:
    - kind: ServiceAccount
      name: reader-dev
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: pod-reader
      namespace: kube-system
    三、相关命令行工具

    1.查看Role、ClusterRole、RoleBinding、ClusterRoleBinding

    kubectl get role -n kube-system

    查看kube-system namespace下的所有role

    kubectl get role <role-name> -n kube-system -o yaml

    查看某个role定义的资源权限

    kubectl get rolebinding -n kube-system

    查看kube-system namespace下所有的rolebinding

    kubectl get rolebinding <rolebind-name> -n kube-system -o yaml

    查看kube-system namespace下的某个rolebinding详细信息(绑定的Role和subject)

    kubectl get clusterrole

    查看集群所有的clusterrole

    kubectl get clusterrole <clusterrole-name> -o yaml

    查看某个clusterrole定义的资源权限详细信息

    kubectl get clusterrolebinding

    查看所有的clusterrolebinding

    kubectl get clusterrolebinding <clusterrolebinding-name> -o yaml

    查看某一clusterrolebinding的详细信息

    有两个kubectl命令可以用于在命名空间内或者整个集群内授予角色。

    kubectl create rolebinding

    2.在某一特定名字空间内授予Role或者ClusterRole

    a) 在名为”acme”的名字空间中将admin ClusterRole授予用户”bob”:

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

    b) 在名为”acme”的名字空间中将view ClusterRole授予服务账户”myapp”:

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

    3.在整个集群中授予ClusterRole,包括所有名字空间

    a) 在整个集群范围内将cluster-admin ClusterRole授予用户”root”:

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

    b) 在整个集群范围内将system:node ClusterRole授予用户”kubelet”:

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

    c) 在整个集群范围内将view ClusterRole授予名字空间”acme”内的服务账户”myapp”:

    kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
    四、apiVersion与apiGroup

     一、Kubernetes API版本的演进策略

    为了在兼容旧版本的同时不断升级新的API,Kubernetes提供了多版本API的支持能力,每个版本的API都通过一个版本号路径前缀进行区分,例如/api/v1beta3。

    在通常情况下,新旧几个不同的API版本都能涵盖所有的Kubernetes资源对象,在不同的版本之间,这些API接口存在一些细微差别。

    Kubernetes开发团队基于API级别选择版本而不是基于资源和域级别,是为了确保API能够清晰、连续地描述一个系统资源和行为的视图,能够控制访问的整个过程和控制实验性API的访问。

    API的版本号通常用于描述API的成熟阶段,例如:

    1. v1表示GA稳定版本;
    2. v1beta3表示Beta版本(预发布版本);
    3. v1alpha1表示Alpha版本(实验性的版本)。

    当某个API的实现达到一个新的GA稳定版本时(如v2),旧的GA 版本(如v1)和Beta版本(例如v2beta1)将逐渐被废弃,Kubernetes建议废弃的时间如下。

    1. 对于旧的GA版本(如v1),Kubernetes建议废弃的时间应不少于12个月或3个大版本Release的时间,选择最长的时间。
    2. 对旧的Beta版本(如v2beta1),Kubernetes建议废弃的时间应不少于9个月或3个大版本Release的时间,选择最长的时间。
    3. 对旧的Alpha版本,则无须等待,可以直接废弃。

    完整的API更新和废弃策略请参考官方网站 https://kubernetes.io/docs/reference/usingapi/deprecation-policy/的说明。

    二、API Groups(API组)
    为了更容易对API进行扩展,Kubernetes使用API Groups(API组)进行标识。API Groups以REST URL中的路径进行定义。
    当前支持两类 API groups。

    1. Core Groups(核心组),也可以称之为Legacy Groups,作为 Kubernetes最核心的API,其特点是没有“组”的概念,例如“v1”,在资源对象的定义中表示为“apiVersion:v1”。
    2. 具有分组信息的API,以/apis/$GROUP_NAME/$VERSION URL路径进行标识,在资源对象的定义中表示为“apiVersion: $GROUP_NAME/$VERSION”,例如:“apiVersion: batch/v1”“apiVersion: extensions:v1beta1”“apiVersion: apps/v1beta1”等

    详细的API列表请参见官网https://kubernetes.io/docs/reference,目前根据 Kubernetes的不同版本有不同的API说明页面。

    例如,由于Pod属于核心资源对象,所以不存在某个扩展API Group,其属于Core Groups,在Pod的定义中为“apiVersion: v1”。
    StatefulSet则属于名为apps的API组,版本号为v1,在StatefulSet的定义中为“apiVersion: apps/v1”。

    2.1、启动或者禁用特定API组
    如果要启用或禁用特定的API组,则需要在API Server的启动参数中 设置–runtime-config进行声明。
    例如,--runtime-config=batch/v2alpha1表示启用API组“batch/v2alpha1”;也可以设置--runtime- config=batch/v1=false表示禁用API组“batch/v1”。多个API组的设置以逗号分隔。
    在当前的API Server服务中,DaemonSets、Deployments、 HorizontalPodAutoscalers、Ingress、Jobs和ReplicaSets所属的API组是默认启用的。

    作者    :秋时

    本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。

  • 相关阅读:
    Codeforces 1005E1&2 Median on Segments (General Case & Permutations Edition)
    洛谷 P3952 时间复杂度 【模拟】【2017 noip d1t2】
    Codeforces 1000E We Need More Bosses 【无向图缩点】【树的直径】
    Codeforces 1003E Tree Constructing 【构造】【性质】
    2019年7月5日_实验室学术论文研讨
    2019年6月28日实验室学术讨论会议
    2019年6月12日实验室学术讨论
    2019年6月20日实验室学术讨论会议
    2019年5月31日实验室学术讨论会议
    2019年5月17日实验室学术讨论会议
  • 原文地址:https://www.cnblogs.com/Netsharp/p/15511882.html
Copyright © 2020-2023  润新知