RBAC Management
Role-based access control
Role-based access control (RBAC) is a method of regulating access to a computer or network resources based on the roles of individual users within your organization.
RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.
The RBAC API declares four kinds of Kubernetes object: Role, ClusterRole, RoleBinding and ClusterRoleBinding. You can describe objects, or amend them, using tools such as
kubectl, just like any other Kubernetes object.Caution: These objects, by design, impose access restrictions. If you are making changes to a cluster as you learn, see privilege escalation prevention and bootstrapping to understand how those restrictions can prevent you making some changes.
An RBAC Role or ClusterRole contains rules that represent a set of permissions. Permissions are purely additive (there are no "deny" rules).
A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in.
ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; it can't be both.
ClusterRoles have several uses. You can use a ClusterRole to:
- 1.define permissions on namespaced resources and be granted access within individual namespace(s)
- 2.define permissions on namespaced resources and be granted access across all namespaces
- 3.define permissions on cluster-scoped resources
If you want to define a role within a namespace, use a Role; if you want to define a role cluster-wide, use a ClusterRole.
A ClusterRole can be used to grant the same permissions as a Role. Because ClusterRoles are cluster-scoped, you can also use them to grant access to:
- non-resource endpoints (like
/healthz) - namespaced resources (like Pods), across all namespacesFor example: you can use a ClusterRole to allow a particular user to run
kubectl get pods --all-namespaces
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: digit-user
rules:
- apiGroups:
- "extensions"
resources:
- deployments
verbs:
- patch
- apiGroups:
- ""
resources:
- pods/portforward
- pods/proxy
verbs:
- create
- delete
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: digit-admin
rules:
- apiGroups:
- ""
resources:
- pods/portforward
- pods/proxy
- pods/exec
verbs:
- create
- delete
- apiGroups:
- "batch"
resources:
- jobs
verbs:
- create
- update
- patch
- list
- apiGroups:
- "apps"
- "extensions"
resources:
- deployments
verbs:
- patch
- get
- list
- update
A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.
A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding. If you want to bind a ClusterRole to all the namespaces in your cluster, you use a ClusterRoleBinding.
{{- with index .Values "cluster-configs" "rbac" }}
{{- range $idx, $v := . }} // These iteration values are defined in the environment file
{{- range $nsidx, $nsval := .namespaces }} // These iteration values are defined in the environment file
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: digit-{{ $v.role }}
namespace: {{ $nsval }}
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: digit-{{ $v.role }}
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: digit-user
---
{{- end }}
{{- end }}
{{- end }}
A RoleBinding can also reference a ClusterRole to grant the permissions defined in that ClusterRole to resources inside the RoleBinding's namespace. This kind of reference lets you define a set of common roles across your cluster, then reuse them within multiple namespaces.
For instance, even though the following RoleBinding refers to a ClusterRole, "dave" (the subject, case sensitive) will only be able to read Secrets in the "development" namespace, because the RoleBinding's namespace (in its metadata) is "development".
You must add a namespace to a role section to grant access to a group of a namespace.
cluster-configs:
rbac:
- role: user
namespaces: [egov] // digit-user ClusterRole would be granted to the playground and egov namespace.
- role: admin
namespaces: [playground,egov] // digit-admin ClusterRole would be granted to the playground and egov namespace.
Last modified 9mo ago