Manage Role Bindings on StreamNative Cloud

​

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:

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

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>

snctl apply -f rolebinding.yaml

snctl get rolebinding <name>

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

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>

snctl apply -f rolebinding.yaml

snctl get rolebinding <name>

terraform {
  required_providers {
    streamnative = {
      source = "streamnative/streamnative"
    }
  }
}


provider "streamnative" {
    # Please replace path use your own key file path
    key_file_path = "/path/to/your/service/account/key.json"
}


resource "streamnative_service_account" "metrics-account" {
  organization = "<organization-id>"
  name = "<service-account-name>"
  admin = false
}


resource "streamnative_role_binding" "metrics-viewer" {
	organization = "<organization-id>"
  name         = "metrics-viewer"
  cluster_role_name = "<predefined-role-name>"
  service_account_names = ["<service-account-name>"]
}

terraform init
terraform validate
terraform plan
terraform apply

​

Update Role Bindings

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

snctl edit rolebinding <name>

snctl apply -f rolebinding.yaml

snctl edit rolebinding <name>

snctl apply -f rolebinding.yaml

​

Delete Role Bindings

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

snctl delete rolebinding <name>

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 below ways:

1. Resource Name.
2. Common Expression Language (CEL) for complex restriction.

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.

​

Using resource name:

snctl create rolebinding <role-binding-name> \
   --clusterrole topic-producer \
   --serviceaccount service-account-1 \
   --condition-instance ins-a --condition-cluster cluster-a --condition-tenant tenant-a --condition-namespace ns-a

snctl create rolebinding <role-binding-name> \
   --clusterrole topic-producer \
   --serviceaccount service-account-1 \
   --condition-instance ins-a --condition-cluster cluster-a --condition-tenant tenant-a --condition-namespace ns-a

resource "streamnative_role_binding" "user-a-topic-xxx-producer" {
   organization = "<organization-id>"
   name = "<role-binding-name>"
   cluster_role_name = "topic-producer"
   service_account_names = ["service-account-1"]
   condition_resource_names {
      instance  = "ins-a"
      cluster   = "cluster-a"
      tenant    = "tenant-a"
      namespace = "ns-a"
   }
}

​

Using CEL expression:

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

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

resource "streamnative_role_binding" "user-a-topic-xxx-producer" {
   organization = "<organization-id>"
   name = "<role-binding-name>"
   cluster_role_name = "topic-producer"
   service_account_names = ["service-account-1"]
   cel = "srn.instance == 'ins-a' && srn.cluster == 'cluster-a' && srn.tenant == 'tenant-a' && srn.namespace == 'ns-a'"
}

The Resource Name and 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
• servie_account: The service account name (used for “service-account-admin” role)
• secret: The secret name (used for “secret” role)

For example, to scope a role binding to specific resources, you can create it with below arguments:

--condition-instance ins-a --condition-cluster cluster-a --condition-tenant tenant-a --condition-namespace ns-a --condition-topic-domain persistent --condition-topic-name topic-a --condition-subscription sub-a

​

Complex Conditional Role Bindings

CEL supports complex conditional role bindings that allow for more sophisticated access control patterns than using the resource name.

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

• Tenant: tenant-a and tenant-b
• Cluster: cluster-a and cluster-b
• Instance: ins-1 and ins-2

The CEL expression would be:

"(srn.instance == '' || srn.instance == 'ins-1' || srn.instance == 'ins-2') && (srn.cluster == '' || srn.cluster == 'cluster-a' || srn.cluster == 'cluster-b') && (srn.tenant == '' || srn.tenant == 'tenant-a' || srn.tenant == 'tenant-b')"

​

Schema Registry Role Binding

The schema registry has its own resource name, use the schema.subject indicates schema subject name in the CEL compression.

For example, to bind a user as schema-writer for a specific schema subject with snctl create:

snctl create rolebinding <role-binding-name> \
--clusterrole schema-writer \
--serviceaccount service-account-1 \
--condition-cel "schema.subject == 'public/default/sr-subject-value' && srn.instance == 'rbac-ins'" \
-O sndev

The schema registry instance name srn.instance is necessary.

For the subject name, the subject resource name should include namespace prefix, here are some examples.

Or we can use the startWiths in CEL expression, then the user can access all schema subjects under the public/default namespace.

snctl create rolebinding <role-binding-name> \
--clusterrole schema-writer \
--serviceaccount service-account-1 \
--condition-cel "schema.subject.startsWith('public/default') && srn.instance == 'rbac-ins'" \
-O sndev