zoukankan      html  css  js  c++  java
  • Kubernetes的RBAC权限控制

    role和roleBinding

    Role资源定义了哪些操作可以在哪些资源上执行。也可以直接控制访问的url的权限,下面的cluster也是这样。
    查询所有service的demo:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      # role的命名空间,如果没有则默认为当前命名空间
      namespace: foo
      name: service-reader
    rules:
      # service是核心apiGroup的资源,所以没有apiGroup的名,就是“”
      - apiGroups: [""]
        # 允许查询和返回所有允许的服务
        verbs:
          - "get"
          - "list"
        # 说明这条规则和服务有关
        resources:
          - "services"
    

    注意: 在指定资源时,必须采用复数形式!如:services

    角色定义了哪些操作可以执行,但没有指定谁可以执行这些操作。要做到这一
    点,必须将角色绑定到一个主体,它可以是一个user (用户)、 一个ServiceAccount或一个组(用户或 ServiceAccount 组)。
    也就是说RoleBinding就是一个中间表,主要负责维护"角色"和用户的关系。而这里的用户可以使user、serviceAccount或者serviceAccount group

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      namespace: foo
      name: test
    # 绑定的role  
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: service-reader
    # 绑定的用户 
    subjects:
      - kind: ServiceAccount
        name: foo
        namespace: default
    

    上面的配置中给service-reader的角色绑定了default命名空间中名称为foo的ServiceAccount,也就是说在foo命名空间中的pod,只要
    引用了foo的ServiceAccount,就拥有了service-reader的角色权限。
    同样的,如果将service-reader的角色绑定到其他的命名空间的ServiceAccount,那么其他命名空间的pod,也可以拥有service-reader的
    角色权限,也就是访问foo中的service资源。

    ClusterRole和ClusterRoleBinding

    上面通过Role我们可以获得了部分操作命名空间的权限。但是有些资源不属于命名空间自身,如:pv、role、或者namespace自身。
    这个时候就需要用到了ClusterRole和ClusterRoleBinding。
    集群级别的资源访问ClusterRole必须和ClusterRoleBinding绑定才会生效。因为这些资源本身就不属于命名空间之内的,而roleBinding
    都是针对命名空间内的资源生效的。
    可以查看k8s内置的一个clusterRole

    kubectl get clusterrole system:discovery -o yaml
    

    这个cluterRole提供了对一些公共的url访问的权限,如:healthz、version等

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      annotations:
        rbac.authorization.kubernetes.io/autoupdate: "true"
      creationTimestamp: "2020-04-29T06:32:17Z"
      labels:
        kubernetes.io/bootstrapping: rbac-defaults
      name: system:discovery
      resourceVersion: "42"
      selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
      uid: 406bba95-3344-4650-8b00-1afb55d7321f
    rules:
    - nonResourceURLs:
      - /api
      - /api/*
      - /apis
      - /apis/*
      - /healthz
      - /livez
      - /openapi
      - /openapi/*
      - /readyz
      - /version
      - /version/
      verbs:
      - get
    

    注意:对于URL权限的控制,要使用普通的HTTP动词,如:post、get、patch等,必须使用小写。而不是create或者update
    非资源型URL clusterRole和集群级别的资源一样,只能与clusterRoleBinding结合使用。
    查看官方中此clusterRole对应的clusterRoleBinding

    kubectl get clusterrolebinding system:discovery -o yaml
    
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      annotations:
        rbac.authorization.kubernetes.io/autoupdate: "true"
      creationTimestamp: "2020-04-29T06:32:17Z"
      labels:
        kubernetes.io/bootstrapping: rbac-defaults
      name: system:discovery
      resourceVersion: "93"
      selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
      uid: cc81c481-e70b-406b-bde8-c25c811102cd
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: system:discovery
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: system:authenticated
    

    可以看到上面的ClusterRoleBinding,赋予了所有已登录的用户system:discovery的ClusterRole的权限。

    ClusterRole与RoleBinding

    ClusterRole不是必须与ClusterRoleBinding结合使用。当需要访问命名空间级别的资源时,可以使用ClusterRole定义这些权限,
    然后使用RoleBinding与具体的命名空间中的serviceAccount绑定。然后这个命名空间下的pod,应用了这个serviceAccount后,就
    获得了访问所有命名空间中的资源的权限。如:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: view
    rules:
        apiGroups:
          - ""
        # 指定可以访问的资源的权限,注意:这里全部都是命名空间中的资源
        resources:
          - configmaps
          - endpoints
          - persistenvolumeclaims
          - pods
          - replicationcontrollers
          - replicationcontrollers/scale
          - serviceaccounts
          - services
        # 指定权限为查看
        verbs:
          - get
          - list
          - watch
    

    为了防止权限扩散,建议为每个pod或一组pod,创建一个特定的serviceAccount,并且把它和一个定制的role或者clusterRole通过roleBinding
    联系起来(不使用clusterRoleBinding是因为这样做会给其他命名空间的pod对资源的访问权限,只要他们指定这个命名,这样做是很危险的)

  • 相关阅读:
    不同等级数据源的多级缓冲环的生成
    从DataTable到List<Model>(C#.net)
    string与char之间的转换以及如何获得string所占位数
    AndroidKotlin
    Android高级POS开发
    IOS 应用开发
    Android切屏的处理
    Android POS开发
    Android深入理解JNI
    Android的IPC机制Binder
  • 原文地址:https://www.cnblogs.com/yechen2019/p/14680198.html
Copyright © 2011-2022 走看看