Access-Control

Overview Role and ClusterRole are both Kubernetes RBAC objects that define sets of permission rules (verbs on resources), but they differ in scope: a Role only applies within a single namespace, while a ClusterRole is defined once for the whole cluster and can be bound either cluster-wide or scoped down to one namespace. Understanding this distinction is essential for applying least-privilege access control in multi-tenant clusters. Comparison Diagram RoleClusterRoleNamespace: devRoleRoleBindingUserlimited to this namespaceCluster scopeClusterRoleRoleBindingClusterRoleBindingUserthis ns onlyUserall namespacesone definition, reused via either binding Comparison Table Aspect Role ClusterRole API object scope Namespaced object; exists only within one Namespace Cluster-scoped object; exists once for the entire cluster Resources it can grant access to Only namespaced resources (pods, configmaps, secrets, etc.) within its own namespace Namespaced resources cluster-wide plus cluster-scoped resources such as nodes, persistentvolumes, and namespaces Non-resource URLs (e.g. /healthz, /metrics) Cannot reference non-resource URLs Can include rules for non-resource URLs Binding object required RoleBinding only, created in the same namespace RoleBinding for a namespace-scoped grant, or ClusterRoleBinding for a cluster-wide grant Effective grant when bound Permissions always limited to the Role’s own namespace Spans every namespace when bound via ClusterRoleBinding, or just one namespace when bound via RoleBinding Reuse across namespaces Must be duplicated in each namespace that needs the same rules Defined once, reused across many namespaces or cluster-wide via separate bindings Aggregation support None; rules are static within the object Supports aggregationRule to auto-combine rules from other ClusterRoles by label selector Typical built-in examples None shipped by default; teams author their own per namespace cluster-admin, admin, edit, view, and system: component roles ship as default ClusterRoles Key Differences Role is namespace-scoped while ClusterRole is cluster-scoped by definition, regardless of how it’s later bound. Only ClusterRole can grant access to cluster-scoped resources like nodes or to non-resource URLs such as /metrics. A ClusterRole can still be restricted to one namespace by binding it with a RoleBinding instead of a ClusterRoleBinding. ClusterRole supports aggregation to compose permissions from labeled ClusterRoles; Role has no equivalent mechanism. Kubernetes ships default admin/edit/view permission sets as built-in ClusterRoles, never as Roles. When to Use Each Role ...

Overview RBAC and ABAC are two models for deciding whether a subject can perform an action on a resource. RBAC grants access based on a user’s assigned role and that role’s fixed permission set, while ABAC evaluates a policy against attributes of the user, resource, action, and environment at request time. The choice affects how fine-grained, dynamic, and auditable your authorization system can be. Comparison Diagram RBACABACUserRole: EditorPermissionsReadWritePublishFixed, regardless of contextUser attrsResource attrsEnv attrsPolicy EngineAllow / DenyEvaluated per request, in context Comparison Table Aspect RBAC ABAC Access decision basis A user’s assigned role Attributes of the user, resource, action, and environment Permission structure Static, predefined role-to-permission mappings Dynamic policies expressed as attribute-based rules Administration Admin assigns users to existing roles Policy author writes rules combining attribute conditions Runtime evaluation Check whether the user’s role includes the requested permission Policy engine evaluates rules against current attribute values Context sensitivity Same result regardless of time, location, or device Can factor in time, location, device, and other real-time signals Granularity Coarse-grained, applied per role Fine-grained, applied per request or condition Scalability with complexity Role explosion as requirements diversify Policy complexity grows, but avoids proliferating roles Auditability Easy to audit — list who holds a given role Harder to audit — requires tracing policy logic across attributes Key Differences RBAC ties access to roles; ABAC ties access to attributes RBAC decisions are static; ABAC decisions are context-aware ABAC enables fine-grained control at the cost of policy complexity RBAC suffers from role explosion as requirements grow RBAC is generally easier to audit than ABAC When to Use Each RBAC ...

Overview Authentication (AuthN) confirms who a user or system claims to be, typically through credentials like passwords, biometrics, or tokens. Authorization (AuthZ) determines what an already-authenticated identity is permitted to do or access. The two are sequential and often conflated, but security bugs frequently trace back to confusing one for the other — e.g., checking that a user is logged in without checking they’re allowed to see a specific resource. ...