1. Manage Security
  2. Control Access
  3. Role-Based Access Control

Manage Role Bindings on StreamNative Cloud

Note

This documentation covers RBAC Version 2. For information about the previous version (RBAC Version 1), see RBAC (V1).

Role Bindings

Role bindings are used to bind roles to principals. They are defined as RoleBinding resources in the Cloud API. The schema is as follows:

apiVersion: cloud.streamnative.io/v1alpha1
kind: RoleBinding
metadata:
  name: <name>
  namespace: <namespace>
spec:
  roleRef:
    apiGroup: cloud.streamnative.io
    kind: <role type> # Role type:  ClusterRole(predefined), Role(customized)
    name: <roleName>
  subjects:
    - apiGroup: cloud.streamnative.io
      kind: <subject type> # User, ServiceAccount, Identity Pool
      name: <subject name>
  • roleRef: Reference to the role to be bound. It can be a Predefined Role (ClusterRole) or a Custom Role (Role).
  • subjects: List of subjects (also known as principals) to be bound to the role. It can be a User, a ServiceAccount, or an IdentityPool.

Manage Role Bindings

Currently, you can manage role bindings by using snctl or StreamNative Terraform Provider. Support for the Cloud Console will be available soon.

Create Role Bindings

You can create a role binding by using the following methods:

You can create a role binding by running the following command to bind a predefined role <predefined-role-name> to a service account <service-account-name>.

snctl create rolebinding <role-binding-name> \
  --clusterrole <predefined-role-name> \
  --serviceaccount <service-account-name>

Alternatively, you can prepare the manifest file rolebinding.yaml to bind a predefined role to a service account.

apiVersion: cloud.streamnative.io/v1alpha1
kind: RoleBinding
metadata:
  name: <name>
  namespace: <namespace>
spec:
  roleRef:
    apiGroup: cloud.streamnative.io
    kind: ClusterRole
    name: <predefined-role-name>
  subjects:
    - apiGroup: cloud.streamnative.io
      kind: ServiceAccount
      name: <service-account-name>

Then apply it using snctl apply.

snctl apply -f rolebinding.yaml

After creating the role binding, you can verify it by running the following command:

snctl get rolebinding <name>

You should be able to see the role binding is in the Ready state.

Update Role Bindings

You can update a role binding by using the following methods:

You can use snctl edit to update a role binding directly.

snctl edit rolebinding <name>

Alternatively, you can update the manfiest file rolebinding.yaml and apply it using snctl apply.

snctl apply -f rolebinding.yaml

Delete Role Bindings

You can delete a role binding by using the following methods:

Delete a role binding:

snctl delete rolebinding <name>

Conditional Role Bindings

While basic role bindings simply associate a role with a user or service account, conditional role bindings provide more granular control by scoping permissions based on resource attributes.

For example, you may want to restrict a topic-producer role to only work within a specific namespace. StreamNative Cloud allows you to express these conditions using Common Expression Language (CEL).

The following example shows how to bind the topic-producer role to a service account named service-account-1 with conditions that limit its access to:

  • Instance: ins-a
  • Cluster: cluster-a
  • Tenant: tenant-a
  • Namespace: ns-a

With these conditions, service-account-1 can only produce messages to topics within the specified namespace (tenant-a/ns-a) on that particular instance and cluster.

snctl create rolebinding <role-binding-name> \
   --clusterrole topic-producer \
   --serviceaccount service-account-1 \
   --cel "srn.instance == 'ins-a' && srn.cluster == 'cluster-a' && srn.tenant == 'tenant-a' && srn.namespace == 'ns-a'"

The CEL expression supports accessing resources through the following variable:

  • StreamNative Resource Name (SRN): Provides access to all resources within the hierarchy, from instance and cluster down to individual resources like tenants, namespaces, topics, and subscriptions.

StreamNative Resource Name (SRN)

A StreamNative Resource Name (SRN) uniquely identifies resources in StreamNative Cloud using a hierarchical structure. The SRN is accessed through the srn variable in CEL expressions and contains the following fields:

  • instance: The StreamNative Cloud instance
  • cluster: The Pulsar cluster
  • tenant: The tenant
  • namespace: The namespace
  • topic_domain: The topic domain (persistent or non-persistent)
  • topic_name: The name of the topic
  • subscription: The subscription name

For example, to scope a role binding to specific resources, you can reference these fields in your CEL expression:

srn.instance == 'ins-a' && srn.cluster == 'cluster-a' && srn.tenant == 'tenant-a' && srn.namespace == 'ns-a'

Complex Conditional Role Bindings

CEL supports complex conditional role bindings that allow for more sophisticated access control patterns.

Some predefined roles inherit describe permissions for resources higher in the hierarchy. For example, when binding a user account as a tenant-admin for tenant tenant-a, they get:

  • Full access to all resources under that tenant
  • describe permissions for the parent cluster and instance containing the tenant

To properly handle these inherited permissions, the CEL expression needs to account for cases where higher-level resource attributes may be empty. This is done using the || operator to match either an empty string or the specific resource value.

For example, to bind a user as tenant-admin for:

  • Tenant: tenant-a
  • Cluster: cluster-a
  • Instance: ins-1

The CEL expression would be:

"(srn.instance == '' || srn.instance == 'ins-1') && (srn.cluster == '' || srn.cluster == 'cluster-a') && (srn.tenant == '' || srn.tenant == 'tenant-a')"
Previous
Manage Roles