RBACアグリゲーション

達成したいことの例：クラスターのリソースのみを表示するようにユーザーを制限し、監視グラフを表示できるようにします（監視）

ロールファイル

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: aideveloper-role
  namespace: monitoring
rules:
- apiGroups:
  - ""
  resources:
  - pods/proxy
  - services/proxy
  verbs:
  - get
  - list
  - watch

roleBindingファイル

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: aideveloper-roleBinding
  namespace: monitoring
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: aideveloper-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: aideveloper

clusterRoleBindingファイル

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: aideveloper-view-roleBinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: aideveloper

次に、監視の読み取り専用の役割をビューに集約する方法を確認する必要がありますか？

ユーザーがクラスターのすべてのリソースとクラスターの監視情報を表示できることを認識したい場合は、ユーザーに対してroleBindingを2回実行する必要があります。したがって、問題は次のとおりです。たとえば、必要なアクセス許可がより複雑な場合、たとえば、数十のタイプがある場合、数十のroleBindingを作成する必要がありますか？それは確かにそれほど愚かなことではありません。k8s1.9以降、rbac-aggregateの集約メカニズムがあります。

集計方法は、matchLabels（rbac.example.com/aggregate-to-monitoring： "true"）を使用して、ラベルのClusterRoleに一致するすべてのメタデータを照合することです。AggregationRuleは、ルールセクションを構成する必要はありません。コントローラーが、一致するすべてのClusterRoleルールを収集した後に入力されます。

といった：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: roleTest001
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-roletest001: "true"
rules: [] # Rules are automatically filled in by the controller manager.

matchLabelに一致する新しいclusterRoleを作成すると、コントローラーは新しいルールをaggregationRuleに追加します。以下では、roleTest002のルールを上記のClusterRoleroleTest001に追加するため、ここでルールを入力する必要はありません。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: roleTest002
  labels:
    rbac.authorization.k8s.io/aggregate-to-roletest001: "true"
# These rules will be added to the "monitoring" role.
rules:
- apiGroups: [""]
  Resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

次に、前の記事で行ったRBACを改善できます。監視権限をビューに集約するだけで、ビューの役割をaideveloperユーザーに割り当てるだけで済みます。100の複雑な権限が背後にある場合でも、タグを追加するだけでよく、あまり多くのroleBindingを記述する必要はありません。

まず、ロールビューのプロパティを確認しましょう。

kubectl edit clusterrole view
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-view: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2021-01-06T10:11:00Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  managedFields:
  - apiVersion: rbac.authorization.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:aggregationRule:
        .: {}
        f:clusterRoleSelectors: {}
      f:metadata:
        f:annotations:
          .: {}
          f:rbac.authorization.kubernetes.io/autoupdate: {}
        f:labels:
          .: {}
          f:kubernetes.io/bootstrapping: {}
          f:rbac.authorization.k8s.io/aggregate-to-edit: {}
    manager: kube-apiserver
    operation: Update
    time: "2021-01-06T10:11:00Z"
  - apiVersion: rbac.authorization.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:rules: {}
    manager: kube-controller-manager
    operation: Update
    time: "2021-01-07T05:56:44Z"
  name: view

このビューが本質的に集約可能であることに気付いて嬉しく思いました-aggregationRuleを含みます。ここでは、rbac.authorization.k8s.io / Aggregate-to-view： "true"のaggregationRuleが表示されているため、以前に作成した監視ロールにrbac.authorization.k8s.io/aggregate-to-を追加します。ビュー：「true」タグで問題ありません。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: aideveloper-role
  namespace: monitoring
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups:
  - ""
  resources:
  - pods/proxy
  - services/proxy
  verbs:
  - get
  - list
  - watch

おすすめ