1. 程式人生 > 其它 >|NO.Z.00222|——————————|CloudNative|——|KuberNetes&細粒度許可權控制.V06|------------------------------------------------|RBAC.v02|配置引數說明|

|NO.Z.00222|——————————|CloudNative|——|KuberNetes&細粒度許可權控制.V06|------------------------------------------------|RBAC.v02|配置引數說明|



[CloudNative:KuberNetes&細粒度許可權控制.V06]                                                    [Applications.KuberNetes] [|DevOps|k8s|細粒度許可權控制|RBAC|許可權管理應用|]








一、配置檔案說明
### --- Role example:角色許可權示例
~~~     注:就是在default名稱空間下下建立一個role,
~~~     這個role是對pods具有get,watch和list許可權

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default                // default的namepspace下
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]               // 管理的資源是pod
  verbs: ["get", "watch", "list"]   // 它的許可權是get,watch,list
二、ClusterRole example:整個叢集的許可權示例
### --- 建立了一個secret-reader的ClusterRole,
~~~     它的許可權是對secrets具有get、watch、list的許可權
~~~     針對於所有的namespace下的許可權

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader               // 建立了一個secret-reader的一個ClusterRole
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
三、RoleBinding examples
### --- 案例一:
~~~     注:建立了一個pod-reader
~~~     之前建立了一個pod-reader的一個role,它的許可權是對pod的檢視許可權,
~~~     然後使用RoleBinding把它到一個Jane的user使用者上

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default                    // RoleBinding是需要指定namespace的,若是ClusterRoleBinding是不需要指定namespace
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive // 把pod-reader的這個許可權繫結到Jane的這個user上
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io
### --- 案例二:
~~~     注:之前建立了一個ClusterRole,
~~~     把secret-reader的ClusterRole繫結到了development的namespace,繫結的使用者是Dave這個使用者

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # The namespace of the RoleBinding determines where the permissions are granted.
  # This only grants permissions within the "development" namespace.
  namespace: development
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io
四、ClusterRoleBinding example
~~~     # 注:之前建立的secret-reader的讀許可權,建立了一個ClusterRoleBinding,
~~~     ClusterRoleBinding是作用於整個叢集的,不用謝namespace

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:                           // subjects定義了繫結的物件是誰,是一個切片形式的,可以寫多個。
- kind: Group                       // 繫結到這個group下manager
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader               // 所以說這個group下的所有的使用者具有secret-reader的許可權
  apiGroup: rbac.authorization.k8s.io
五、Referring to resources:引用資源
### --- 案例一:為日誌檢視設定許可權

apiVersion: rbac.authorization.k8s.io/v1
kind: Role                          // 建立了一個role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader     // role的名字
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]   // 繫結到它的下級資源;這個role的pods,pods下的log具有了get和list許可權
  verbs: ["get", "list"]
### --- 案例二:設定configmap的許可權
~~~     注:這個role的名字是configmap-updater對my-configmap具有update和get的許可權
~~~     這個configmap指定了my-configmap這個,所以只對整一個configmap具有這個許可權

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater           // role的名字
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing ConfigMap
  # objects is "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]   // 指定某個configmap指定的資源進行update或get的許可權
  verbs: ["update", "get"]
~~~     # 在配置許可權的時候,resources不知道寫什麼的時候,可以檢視view下的resources,
~~~     它基本包含了所有的resources

[root@k8s-master01 ~]# kubectl get clusterrole view -oyaml
  resources:
  - daemonsets
  - daemonsets/status
  - deployments
  - deployments/scale
  - deployments/status
  - ingresses
  - ingresses/status
  - networkpolicies
  - replicasets
  - replicasets/scale
  - replicasets/status
  - replicationcontrollers/scale  
六、Aggregated ClusterRoles:聚合的clusterroles
### --- 案例一:
~~~     注:在建立這個ClusterRole的時候,可以寫一個label;可以可以過濾出來這個ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
  labels:
     self-cluster-role: test        // 這個label的是self-cluster-adminrole;values是test
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
### --- 案例二:
~~~     # 注:把這個matchLabels改成之前建立的ClusterRole,這個monitoring就有了方案一ClusterRole的所有的許可權
~~~     把所有的ClusterRole集合起來,這樣就可以直接使用monitoring去給一個使用者去賦予很多的許可權。
~~~     就可以直接寫一個ClusterRole或者ClusterRoleBinding就有很多許可權

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
     self-cluster-role: test 
rules: [] # The control plane automatically fills in the rules
七、以下ClusterRoles讓“ admin”和“ edit”預設角色管理名為CronTab的自定義資源
~~~     # 以下ClusterRoles讓“ admin”和“ edit”預設角色管理名為CronTab的自定義資源,

~~~     而“ view”角色只能對CronTab資源執行讀取操作。
~~~     您可以假定CronTab物件是"crontabs"在URL中命名的,如API伺服器所看到的那樣。
~~~     針對crontabs 進行授權的,
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Add these permissions to the "admin" and "edit" default roles.
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Add these permissions to the "view" default role.
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:      
- apiGroups: ["stable.example.com"]         // 這個apigroup一般是不寫的。
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]








===============================END===============================


Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart                                                                                                                                                    ——W.S.Landor



來自為知筆記(Wiz)