Skip to main content
Version: v1.0.x

ClusterAuthzRoleBinding

A ClusterAuthzRoleBinding connects a subject (identified by a JWT claim-value pair) to one or more ClusterAuthzRole resources, granting or denying the roles' permissions. Each role mapping can optionally be scoped to a specific namespace, project, or component within the resource hierarchy.

API Version

openchoreo.dev/v1alpha1

Resource Definition

Metadata

ClusterAuthzRoleBindings are cluster-scoped resources.

apiVersion: openchoreo.dev/v1alpha1
kind: ClusterAuthzRoleBinding
metadata:
name: <binding-name>

Spec Fields

FieldTypeRequiredDefaultDescription
entitlementEntitlementClaimYes-Subject identification from JWT claims
roleMappingsClusterRoleMapping[]Yes-List of role-scope pairs this binding applies to
effectstringNoallowallow or deny

EntitlementClaim

FieldTypeRequiredDescription
claimstringYesJWT claim name (e.g., groups, sub, email)
valuestringYesJWT claim value to match (e.g., platformEngineer)

ClusterRoleMapping

Each entry in the roleMappings array pairs a role reference with an optional scope.

FieldTypeRequiredDescription
roleRefRoleRefYesReference to the cluster role to bind
scopeClusterTargetScopeNoNarrows the mapping to a specific namespace, project, or component. Omit for cluster-wide

RoleRef

FieldTypeRequiredDescription
kindstringYesMust be ClusterAuthzRole
namestringYesName of the ClusterAuthzRole to bind

ClusterTargetScope

All fields are optional. Omitted fields mean "all" at that level.

FieldTypeRequiredDescription
namespacestringNoScope to a specific namespace
projectstringNoScope to a specific project (requires namespace)
componentstringNoScope to a specific component (requires namespace and project)
important
  • roleMappings[].roleRef.kind must be ClusterAuthzRole. ClusterAuthzRoleBindings cannot reference namespace-scoped AuthzRole resources. This is enforced by a validation rule on the resource.
  • scope.project requires scope.namespace, and scope.component requires scope.project.

Examples

Grant Admin Access Cluster-Wide

apiVersion: openchoreo.dev/v1alpha1
kind: ClusterAuthzRoleBinding
metadata:
name: platform-admins-binding
spec:
entitlement:
claim: groups
value: platformEngineer
roleMappings:
- roleRef:
kind: ClusterAuthzRole
name: platform-admin
effect: allow

Grant Viewer Access to a Service Account

apiVersion: openchoreo.dev/v1alpha1
kind: ClusterAuthzRoleBinding
metadata:
name: backstage-reader-binding
spec:
entitlement:
claim: sub
value: openchoreo-backstage-client
roleMappings:
- roleRef:
kind: ClusterAuthzRole
name: viewer
effect: allow

Namespace-Scoped Admin with Cluster-Wide Reader

Multiple role mappings can be combined in a single binding, each with an independent scope:

apiVersion: openchoreo.dev/v1alpha1
kind: ClusterAuthzRoleBinding
metadata:
name: acme-admins-binding
spec:
entitlement:
claim: groups
value: acme-admins
roleMappings:
- roleRef:
kind: ClusterAuthzRole
name: admin
scope:
namespace: acme
- roleRef:
kind: ClusterAuthzRole
name: cluster-reader
effect: allow

In this example, acme-admins gets full admin access scoped to the acme namespace and cluster-wide read-only visibility into cluster-level resources — all in a single CR.

Allow and Deny

Both ClusterAuthzRoleBinding and AuthzRoleBinding carry an effect field: either allow or deny. When multiple bindings match a request, the system follows a deny-overrides strategy:

  • If any matching binding has effect allow AND no matching binding has effect deny: ALLOW
  • If any matching binding has effect deny: DENY (deny always wins)
  • If no bindings match: DENY (default deny)

A single deny binding can override any number of allow bindings, making it straightforward to revoke specific permissions without restructuring the entire role hierarchy.