Cluster Architecture, Installation & Configuration

A Role is namespaced — its rules grant permissions only within the single namespace it lives in. A ClusterRole is cluster-scoped: it can grant access to cluster-scoped resources (nodes, PVs), non-resource URLs (like /healthz), or be reused across namespaces via RoleBindings.

Each rule specifies apiGroups (the API group of the resource, "" for core), resources (e.g. pods, deployments), and verbs (e.g. get, list, watch, create, update, patch, delete). An optional resourceNames field restricts the rule to specific named objects.

The standard verbs are get, list, watch, create, update, patch, delete (and deletecollection). Read-only access is granted by get, list, and watch.

The core API group is represented by an empty string "". So a rule for pods uses apiGroups: [""]. Resources like deployments use apiGroups: ["apps"].

A RoleBinding grants the permissions defined in a Role (or ClusterRole) to subjects within a single namespace. Subjects can be a User, a Group, or a ServiceAccount.

Yes. A RoleBinding can reference a ClusterRole; this grants the ClusterRole's permissions but only within the RoleBinding's namespace. This pattern lets you define common roles (like 'view') once cluster-wide and apply them per namespace.