Kubernetes kind : ClusterRoleBinding

Giriş

ClusterRole nesnesine atıfta bulunur. Açıklaması şöyle

Roles and RoleBindings are created in a namespace, and they grant access to resources in the current namespace.

What happens when you want to grant access to global resources, such as Nodes or Persistent Volumes?

It’d be great if there were a way to define a profile as global instead of being scoped to a namespace.

Well, you just invented the ClusterRole — a global role that applies to the entire cluster.

To link an identity to a global role, we use a ClusterRoleBinding.

What happens when you link a “standard” ClusterRole to a RoleBinding?

Is it even possible?

Yes.

The user will have all the permissions from the ClusterRole but scoped in the current namespace of the RoleBinding.

Açıklaması şöyle

What happens when you link a “standard” ClusterRole to a RoleBinding?

Is it even possible?

Yes.

The user will have all the permissions from the ClusterRole but scoped in the current namespace of the RoleBinding.

roleRef Alanı

- apiGroup olarak  rbac.authorization.k8s.io yazılır

- kind olarak ClusterRole 

- name olarak atıfta bulunduğumuz role yazılır

subjects Alanı

Örnek

Açıklaması şöyle. Burada default namespace içindeki default service account'a role veriliyor. 

To allow Hazelcast to use the service inside Kubernetes for the discovery, we also need to grant certain permissions. An example of RBAC configuration for default namespace you can find in Hazelcast documentation.

Şöyle yaparız. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: hazelcast-cluster-role
rules:
  - apiGroups:
      - ""
    resources:
      - endpoints
      - pods
      - nodes
      - services
    verbs:
      - get
      - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: hazelcast-cluster-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: hazelcast-cluster-role
subjects:
  - kind: ServiceAccount
    name: default
    namespace: default

Örnek

Şöyle yaparız. Burada helm chart kullanılıyor. Sadece vitess-operator isimli service account nesnesine hak vermek istiyoruz. 

Bu yüzden projenin namespace (isim alanı) içindeki vitess-operator isimli service account nesnesine vitess-operator isimli role'ün tanımladığı haklara erişimi veriliyor.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: vitess-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vitess-operator
subjects:
  - kind: ServiceAccount
    name: vitess-operator
    namespace: {{ .Release.Namespace }}

Örnek

Açıklaması şöyle

For instance, the Kubernetes External DNS project uses a ClusterRole to realize the mandatory permissions it has to work. The External DNS incubator will be accustomed to utilizing external DNS servers for Kubernetes service discovery. the appliance desires read-only access to Services and Ingresses on all namespaces, however, it should not be granted to any extent further privileges (like modifying or deleting resources). The ClusterRole for such associate account ought to look as follows

Şöyle yaparız. Burada external-dns isimli ServiceAccount nesnesine cluster çapında service ve Ingress nesnelerine salt okunur (get, watch ve list) haklar veriliyor.

apiVersion: v1
kind: ServiceAccount
metadata:
 name: external-dns
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
 name: external-dns
rules:
- apiGroups: [""]
 resources: ["services"]
 verbs: ["get","watch","list"]
- apiGroups: ["extensions"]
 resources: ["ingresses"]
 verbs: ["get","watch","list"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: external-dns-viewer
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: external-dns
subjects:
- kind: ServiceAccount
 name: external-dns