Role-Based Access Control (RBAC) is the core mechanism for managing permissions in StreamNative Cloud. It allows administrators to grant specific permissions to principals to perform actions on specific resources. This feature is enabled by default for all cluster types (Serverless, Dedicated, and BYOC) and all organizations, offering a standardized way to secure your resources. Note the following:
  • Multiple Role Assignments: A principal can be assigned multiple roles. When a principal attempts to access a resource, the request is allowed if any of their assigned roles grant the necessary permission.
  • Resource Visibility: If a principal lacks read permission for a resource, that resource will not be visible to them in list commands or in the Cloud Console.
  • Console Access: To use the StreamNative Cloud Console, a user must be assigned at least one read-only role, such as org-readonly, cluster-readonly, or tenant-readonly.
  • Permissions are inherited down the resource hierarchy: Organization → Instance → Cluster → Tenant → Namespace → Topic. For example, a principal with the org-admin role can manage all resources within that organization, while a tenant-owner can only manage the specific tenant they are bound to and its sub-resources (like namespaces and topics).
  • A maximum of 10,000 role bindings are allowed per organization.
  • Currently, only principal with the org-admin or account-admin role can create and manage service accounts and binding a role to a principal.

​
Quick Reference

The following table summarizes all available predefined roles to help you quickly find the right one for your needs.
Role NameScopeSummary of Responsibilities
org-adminOrganizationFull administrative control over all resources in the organization.
org-readonlyOrganizationView all resources and settings in the organization without modification rights.
org-operatorOrganizationPerform organization-wide operational tasks like monitoring and basic troubleshooting.
metrics-viewerOrganizationAccess metrics endpoints for monitoring and observability.
account-adminOrganizationManage user and service accounts, including invitations, deletions, and role assignments.
billing-adminOrganizationView and manage billing and subscription information.
instance-ownerInstanceFull administrative control over one or more specified instances and all resources within them.
instance-readonlyInstanceView a specific instance and all its resources without modification rights.
instance-operatorInstancePerform operational tasks within a specific instance.
cluster-ownerClusterFull administrative control over one or more specified clusters and all resources within them.
cluster-readonlyClusterView specified clusters and all their resources without modification rights.
cluster-operatorClusterPerform operational tasks within specified clusters.
schema-ownerCluster/Schema RegistryFull administrative control over the Schema Registry for one or more specified subjects.
schema-managerCluster/Schema RegistryManage schema evolution and compatibility policies for the Schema Registry in one or more specified subjects.
schema-readerCluster/Schema RegistryRead schema definitions from the Schema Registry in one or more specified subjects.
schema-writerCluster/Schema RegistryCreate and update schemas in the Schema Registry for one or more specified subjects.
consumer-group-ownerCluster/Kafka Consumer GroupFull administrative control over one or more specified Kafka consumer groups.
consumer-group-readerCluster/Kafka Consumer GroupPerform operational tasks like resetting offsets on one or more specified Kafka consumer groups.
transactional-id-ownerCluster/Kafka TransactionIdFull administrative control over one or more specified Kafka transaction IDs.
tenant-ownerTenantFull administrative control over one or more specified tenants and their namespaces/topics.
tenant-readonlyTenantView one or more specified tenants and all their resources without modification rights.
tenant-operatorTenantPerform operational tasks within one or more specified tenants.
namespace-ownerNamespaceFull administrative control over one or more specified namespaces and their topics.
namespace-readonlyNamespaceView one or more specified namespaces and all their resources without modification rights.
namespace-operatorNamespacePerform operational tasks within one or more specified namespaces.
namespace-topic-producerNamespaceProduce messages to all topics within one or more specific namespace.
namespace-topic-consumerNamespaceConsume messages from all topics within one or more specific namespace.
topic-ownerTopicFull administrative control over one or more specified topics.
topic-readonlyTopicView the configuration and stats for one or more specified topics, without data access.
topic-producerTopicProduce messages to one or more specified topics.
topic-consumerTopicConsume messages from one or more specified topics.
You can use snctl to list and get predefined roles.
  • Get list of predefined roles: snctl get clusterroles
  • Get details of a predefined role: snctl get clusterrole <name> -o yaml
  • For human users: We recommend assigning roles with broader scopes (like org-operator or cluster-readonly) to [User Accounts]](/cloud/security/authentication/user-accounts). This is useful when inviting people to manage or view high-level resources.
  • For applications: It is best practice to use Service Accounts with more granular, task-specific roles (like namespace-topic-write or topic-read) to follow the principle of least privilege.
  • For fine-grained control: Combine roles to grant broad read-only access while restricting administrative rights to specific resources. For example, assign a user both cluster-readonly and a more specific tenant-owner role.

​
Organization

These are the highest-level roles, granting broad permissions across your entire StreamNative Cloud organization. The roles available at this scope are: Follow the instructions below to create a role binding for an organization role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the org-admin role. To bind a different organization role, replace org-admin in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding org-admin-user1 \
  --clusterrole org-admin \
  --user user1@example.com

​
org-admin

The Organization Administrator. Grants complete and unrestricted control over all StreamNative Cloud and Pulsar/Kafka resources within the organization. This role is equivalent to a superuser or root administrator.
  • Account Management: Manages all organization-level settings, including billing, subscriptions, users, service accounts, and security policies.
  • Identity Management: Full lifecycle management of users and service accounts: invite, delete, and assign any role to any principal.
  • Infrastructure Management: Full administrative control over all infrastructure, including creating, viewing, and deleting instances and clusters.
  • Data Plane Management: Complete control over all Pulsar and Kafka resources across all clusters, including tenants, namespaces, topics, schemas, Pulsar Functions, and Connectors.

​
org-readonly

The Organization Read-Only Observer. Provides comprehensive, read-only visibility across all resources and configurations in the organization, ideal for auditing and monitoring.
  • Global Visibility: Can view all organization-level settings, instances, clusters, tenants, namespaces, and topics.
  • Monitoring: Can view resource statistics and health metrics across the entire organization.
Limitations:
  • No Modification Rights: Cannot create, update, or delete any resource.
  • No Sensitive Data Access: Cannot view sensitive resources such as secrets or service account credentials.
  • No Data Access: Cannot produce and consume messages from any topic.

​
org-operator

The Organization Operator. Enables principals to perform organization-wide operational and troubleshooting tasks without granting full administrative or destructive permissions.
  • Operational Monitoring: Includes all permissions of the org-readonly role for comprehensive visibility.
  • Troubleshooting Actions: Can perform safe, non-destructive operational tasks such as unloading topics, change configuration, resetting subscription cursors, and restarting Pulsar Functions or Connector tasks across any cluster in the organization.
Limitations:
  • No Destructive Actions: Cannot delete critical resources like clusters, tenants, namespaces, or topics.
  • No Sensitive Data Access: Cannot view sensitive resources such as organization secrets or service account credentials.
  • No Data Access: Cannot produce and consume messages from any topic.
  • No Sensitive Configuration Changes: Cannot alter critical policies like data retention or manage user permissions.
  • No Account Management: Cannot manage users, service accounts, or billing information.
Assign to a central Site Reliability Engineering (SRE) or platform operations team responsible for maintaining the day-to-day health and stability of the entire StreamNative Cloud deployment.

​
metrics-viewer

The Metrics Viewer. This role is specifically designed to grant access to the metrics API, such as those compatible with Prometheus. Assign exclusively to a service account used by an external monitoring or observability platform (for example, Prometheus, Grafana, Datadog) to collect performance metrics, adhering to the principle of least privilege.

​
account-admin

The Account Administrator. Delegates the management of users and service accounts, separating identity management from infrastructure and data plane administration.
  • User Management: Can invite new users to the organization, remove existing users, and manage their role assignments.
  • Service Account Management: Full lifecycle control over service accounts, including creation, deletion, and API key management.
  • Role Assignment: Can bind any role to users or service accounts.
Assign to an IT security or identity management team responsible for controlling access to the platform, allowing them to manage principals without granting them permissions over the data infrastructure itself.

​
billing-admin

The Billing Administrator. A specialized role that provides exclusive access to manage the financial aspects of the organization’s account.
  • Payment Management: Can view and manage payment methods and billing information.
  • Invoice Access: Can view and download billing history and invoices.
Assign to members of the finance department or budget owners who need to manage the organization’s cloud spending without needing access to the underlying technical platform.

​
Instance

These roles are scoped to a specific StreamNative Cloud Instance. The roles available at this scope are: Follow the instructions below to create a role binding for an instance role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the instance-owner role. To bind a different instance role, replace instance-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding instance-owner-user1 \
  --clusterrole instance-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name}

​
instance-owner

The Instance Administrator. Grants full administrative control over all resources within a specific instance, including the clusters it contains.
  • Cluster Lifecycle Management: Can create, view, update, and delete Pulsar and Kafka clusters within the specified instance.
  • Inherited Permissions: Inherits all permissions of cluster-owner for every cluster within the instance.
  • Kafka Cluster Level Resource: Full permissions for Kafka cluster level resources, such as Schema Registry, Kafka Consumer Groups, and Kafka Transactional IDs.
Assign to an environment owner (for example dev-admin, prod-admin) who is responsible for managing all clusters and resources within a specific instance.

​
instance-readonly

The Instance Read-Only Observer. Provides read-only visibility into a specific instance and all of its resources.
  • View All Resources: Can view all clusters, tenants, namespaces, and topics within the specified instance.
  • Inspect Configuration: Can view the configuration of the instance and all its sub-resources.
Limitations:
  • No Data Access: Cannot produce and consume messages from any topic within the binding instance.

​
instance-operator

The Instance Operator. Permits operational tasks across all clusters within a specific instance.
  • Instance-Wide Operations: Includes all instance-readonly permissions, plus the ability to perform operational tasks (for example, unload topics, restart connectors) on any cluster within the instance.
Limitations:
  • No Destructive Actions: Cannot create or delete clusters or modify critical configurations within the instance.
  • No Data Access: Cannot produce and consume messages from any topic within the binding cluster.
Assign to an SRE team responsible for a specific environment (for example, the production instance) to enable troubleshooting and maintenance.

​
Cluster

These roles are scoped to a specific Pulsar or Kafka cluster within an cluster. The roles available at this scope are: Follow the instructions below to create a role binding for a cluster role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the cluster-owner role. To bind a different cluster role, replace cluster-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding cluster-owner-user1 \
  --clusterrole cluster-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id}
The --resource-common-cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
cluster-owner

The Cluster Administrator. Grants full administrative control over all resources within a specific cluster, enabling multi-tenancy management.
  • Tenant Lifecycle Management: Can create, view, update, and delete tenants within the specified cluster. This is the key permission that distinguishes it from tenant-owner.
  • Cluster-Level Policies: Manages cluster-wide configurations and policies.
  • Inherited Permissions: Inherits all permissions of tenant-owner for every tenant within the cluster.
  • Kafka Cluster Level Resource: Full permissions for Kafka cluster level resources, such as Schema Registry, Kafka Consumer Groups, and Kafka Transactional IDs.
Limitations:
  • Scoped to Cluster: Cannot manage other clusters or instance-level configurations.
  • No Org-Level Access: Cannot manage users, service accounts, or billing.
Assign to a platform administrator or team responsible for managing a shared, multi-tenant cluster and onboarding new teams by provisioning tenants for them.

​
cluster-readonly

The Cluster Read-Only Observer. Provides read-only visibility into a specific cluster and all of its tenants and resources.
  • View All Resources: Can view all tenants, namespaces, topics, and their configurations within the specified cluster.
Limitations:
  • No Modification Rights: Cannot make any changes to the cluster or any resources within it.
  • No Data Access: Cannot produce and consume messages from any topic within the binding cluster.
Assign to any user who needs to understand the structure and status of a specific cluster without having permission to alter it.

​
cluster-operator

The Cluster Operator. Permits operational tasks across all tenants within a specific cluster.
  • Cluster-Wide Operations: Includes all cluster-readonly permissions, plus the ability to perform operational tasks (for example, clear backlogs, reset subscriptions, manage function/connector) on any tenant or namespace within the cluster.
Limitations:
  • No Destructive Actions: Cannot create or delete tenants or modify critical cluster configurations.
  • No Data Access: Cannot produce and consume messages from any topic within the binding cluster.
Assign to an SRE or operations team focused on a single cluster, enabling them to perform maintenance and troubleshooting for all teams using that cluster.

​
Tenant

These roles are scoped to a specific Pulsar or Kafka cluster within a tenant. The roles available at this scope are: Follow the instructions below to create a role binding for a tenant role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the tenant-owner role. To bind a different tenant role, replace tenant-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding tenant-owner-user1 \
  --clusterrole tenant-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name}
You can use a startsWith macros to bind a role to multiple tenants. For example, grants the tenant-owner role to all tenants that start with the prefix ${tenant_prefix}.
snctl create rolebinding tenant-owner-user1 \
  --clusterrole tenant-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant "startsWith('${tenant_prefix}')"
You can remove --resource-common-tenant to bind the role to all tenants in the specified cluster:
snctl create rolebinding tenant-owner-user1 \
  --clusterrole tenant-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id}
The --resource-common-cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
tenant-owner

The Tenant Administrator. Grants full administrative control over a specific tenant and all its sub-resources, enabling self-service for application teams.
  • Namespace Management: Full lifecycle management (create, read, update, delete) of namespaces within the assigned tenant.
  • Topic and Policy Management: Manages all topics and namespace-level policies, such as retention, message TTL, and backlog quotas.
  • Functions and Connectors: Full lifecycle management of Pulsar Functions and Connectors (Sources/Sinks) within the tenant’s namespaces.
  • Allows creating tenants bound by the role. For example, if you bind resources prefixed with test-tenant_, you can create test-tenant_x
  • Data Access: Can produce and consume messages from any topic within the binding tenant.
Limitations:
  • Cannot Manage Other Tenants: Creating or deleting tenants that you haven’t bound is not allowed.
  • Cannot view and manage cluster-level resources, such as Schema Registry, Kafka Consumer Groups, and Kafka Transactional IDs. You need to grant a cluster-level role or set permissions for these resources individually.
Assign to a team lead or a team’s primary service account to give them full control over their application’s resources in a shared cluster, promoting a multi-tenant, self-service model.

​
tenant-readonly

The Tenant Read-Only Observer. Can view the configuration and status of a specific tenant and all its resources without modification rights.
  • View Tenant Resources: Can view all namespaces, topics, subscriptions, functions, and connectors within the tenant.
  • Inspect Policies: Can view namespace-level policies and topic configurations.
  • View Statistics: Can retrieve statistics for topics and subscriptions.
Limitations:
  • No Modification Rights: Cannot create, update, or delete any resource within the tenant.
  • No Data Access: Cannot produce and consume messages from any topic within the binding tenant.
Assign to developers who need to view the state and configuration of their team’s applications and resources without being able to modify them.

​
tenant-operator

The Tenant Operator. Can perform operational tasks within a specific tenant, such as troubleshooting and routine maintenance.
  • Operational Control: Includes all tenant-readonly permissions, plus the ability to perform tasks like clearing backlogs, resetting subscription cursors, unloading topics, and restarting functions/connectors within the tenant.
  • Policy Changes: Can alter namespace policies like data retention.
  • Allows creating tenants bound by the role. For example, if you bind resources prefixed with test-tenant_, you can create test-tenant_x
Limitations:
  • No Destructive Actions: Cannot delete namespaces, topics, or other critical resources.
  • No Data Access: Cannot produce and consume messages from any topic within the binding tenant.
Assign to a DevOps engineer or an automated operational tool responsible for maintaining the health of applications within a specific tenant.

​
Namespace

These roles are scoped to a specific Pulsar or Kafka cluster within a namespace. The roles available at this scope are: Follow the instructions below to create a role binding for a namespace role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the namespace-owner role. To bind a different namespace role, replace namespace-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding namespace-owner-user1 \
  --clusterrole namespace-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name} \
  --resource-common-namespace ${namespace_name}
You can use a startsWith macros to bind a role to multiple namespace. For example, grants the namespace-owner role to all namespaces that start with the prefix ${namespace_prefix}.
snctl create rolebinding namespace-owner-user1 \
  --clusterrole namespace-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name} \
  --resource-common-namespace "startsWith('${namespace_prefix}')"
You can remove --resource-common-namespace to bind the role to all namespaces in the specified tenant:
snctl create rolebinding tenant-owner-user1 \
  --clusterrole tenant-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name}
The --resource-common-cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
namespace-owner

The Namespace Administrator. Grants full administrative control over a specific namespace and all topics and functions within it.
  • Topic Management: Full lifecycle management of topics within the namespace.
  • Policy Control: Manages all policies for the namespace, such as retention and backlog quotas.
  • Functions and Connectors: Full lifecycle management of Pulsar Functions and Connectors deployed to the namespace.
  • Data Access: Can produce and consume messages from any topic within the binding tenant.
  • Allows creating namespaces bound by the role. For example, if you bind resources prefixed with test-namepsace_, you can create test-namespace_x
Limitations:
  • Cannot Manage Other Namespace: Creating or deleting namespace that you haven’t bound is not allowed.
  • Cannot view and manage cluster-level resources, such as Schema Registry, Kafka Consumer Groups, and Kafka Transactional IDs. You need to grant a cluster-level role or set permissions for these resources individually.
Assign to an application owner or lead developer to provide full control over all resources related to a specific microservice or application component.

​
namespace-readonly

The Namespace Read-Only Observer. Can view the configuration and status of a specific namespace and all its
  • View Namespace Resources: Can view all topics, subscriptions, functions, and connectors within the namespace.
  • Inspect Configuration: Can view namespace policies and topic configurations.
Limitations:
  • No Modification Rights: Cannot create, update, or delete any resource.
  • No Data Access: Cannot produce and consume messages from any topic within the binding namespace.
Assign to a developer who needs visibility into a specific application’s resources for debugging or understanding its configuration.

​
namespace-operator

The Namespace Operator. Can perform operational tasks within a specific namespace.
  • Operational Control: Includes all namespace-readonly permissions, plus the ability to perform operational tasks like clearing backlogs, resetting subscriptions, and restarting functions/connectors within the namespace.
  • Allows creating namespaces bound by the role. For example, if you bind resources prefixed with test-namepsace_, you can create test-namespace_x
Limitations:
  • No Destructive Actions: Cannot delete topics or other resources.
  • No Data Access: Cannot produce and consume messages from any topic within the binding namespace.
Assign to a service account for an automated CI/CD pipeline that needs to perform operational tasks like restarting a function after a deployment.

​
namespace-topic-producer

The Namespace Producer. Allows a principal to produce messages to all topics(kafka/pulsar) within a specific namespace. Limitations:
  • No Administrative Rights: Cannot manage topics, policies, or any other resources.
  • No Consume Rights: Cannot consume messages.
Assign to a service account for a producer application that needs to write to multiple topics within a single namespace, simplifying permission management.

​
namespace-topic-consumer

The Namespace Consumer. Allows a principal to consume messages from all topics(kafka/pulsar) within a specific namespace.
  • Consume Data: Can create subscriptions and consume messages from any existing or future topic within the specified namespace.
Limitations:
  • No Administrative Rights: Cannot manage topics, policies, or any other resources.
  • No Produce Rights: Cannot produce messages.
  • For kafka consumer, need grant consumer-group-reader role to the principal to consume messages from a kafka topic.
Assign to a service account for a consumer application or stream processing job that needs to read from all topics within a namespace.

​
Topic

These roles are scoped to a specific Pulsar or Kafka cluster within a topic. The roles available at this scope are: Follow the instructions below to create a role binding for a topic role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the topic-owner role. To bind a different topic role, replace topic-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding topic-owner-user1 \
  --clusterrole topic-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name} \
  --resource-common-namespace ${namespace_name} \
  --resource-common-topic "allPartition('${topic_name}')"
The allPartition macro applies the binding to all partitions of the specified topic. To bind to a single partition, provide the specific partition’s full name directly. For example: --resource-common-topic test-topic-partition-0
You can use a startsWith macros to bind a role to multipl topic. For example, grants the topic-owner role to all topics that start with the prefix ${topic_prefix}.
snctl create rolebinding topic-owner-user1 \
  --clusterrole topic-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name} \
  --resource-common-namespace ${namespace_name} \
  --resource-common-topic "startsWith('${topic_prefix}')"
You can remove --resource-common-namespace to bind the role to all topics in the specified namespace:
snctl create rolebinding topic-owner-user1 \
  --clusterrole topic-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-common-tenant ${tenant_name} \
  --resource-common-namespace ${namespace_name}
The --resource-common-cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
topic-owner

The Topic Administrator. Grants administrative control over a specific topic’s configuration and lifecycle. Limitations:

​
topic-readonly

The Topic Read-Only Observer. Allows viewing the configuration and statistics of a specific topic without modification rights or data access.

​
topic-producer

The Topic Producer. Allows a principal to produce messages to all topics(kafka/pulsar) within a specific topic. Limitations:
  • No Administrative Rights: Cannot manage topics, policies, or any other resources.
  • No Consume Rights: Cannot consume messages.
  • Grant appropriate Schema Registry permissions separately if needed.
Assign to a service account for a producer application that needs to write to multiple topics within a single namespace, simplifying permission management.

​
topic-consumer

The Topic Consumer. Allows a principal to consume messages from all topics(kafka/pulsar) within a specific topic.
  • Consume Data: Can create subscriptions and consume messages from any existing or future topic within the specified topic.
Limitations:
  • No Administrative Rights: Cannot manage topics, policies, or any other resources.
  • No Produce Rights: Cannot produce messages.
  • For kafka consumer, need grant consumer-group-reader role to the principal to consume messages from a kafka topic.
  • Grant appropriate Schema Registry permissions separately if needed.
Assign to a service account for a consumer application or stream processing job that needs to read from all topics within a namespace.

​
Schema Registry

These roles are used to manage Pulsar Schemas, ensuring data governance and type safety. The roles available at this scope are: The operational resource of the schema is subject, which are resources under the cluster. Follow the instructions below to create a role binding for a schema subject role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the schema-owner role. To bind a different schema role, replace schema-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding schema-owner-user1 \
  --clusterrole schema-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-schema-subject ${subject}
You can use a startsWith macros to bind a role to multiple subjects. For example, grants the schema-owner role to all subjects that start with the prefix ${subject_prefix}.
snctl create rolebinding schema-owner-user1 \
  --clusterrole schema-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-schema-subject "startsWith('${subject_prefix}')"
You can remove --resource-schema-subject to bind the role to all subjects in the specified cluster schema registry:
snctl create rolebinding topic-owner-user1 \
  --clusterrole topic-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
The --resource-common-cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
schema-owner

The Schema Administrator. Grants full administrative control over specified schema subjects, including destructive actions.
  • Full Lifecycle Management: Can create, update, and delete schemas and schema versions.
  • Destructive Actions: Can delete entire schema subjects, which is an irreversible action.
  • Policy Control: Includes all permissions of the schema-manager role, such as managing compatibility policies.
Limitations:
  • Scoped to Subject: Permissions are limited to the specified schema subjects.

​
schema-manager

The Schema Manager. Allows for the management of schema evolution and compatibility policies for specified subjects.
  • Compatibility Management: Can get and update the schema compatibility policy for a subject (for example, BACKWARD, FORWARD, FULL).
  • Schema Evolution: Can test the compatibility of new schema versions.
  • Includes Writer Permissions: Can create and update schemas, inheriting permissions from the schema-writer role.
Limitations:
  • No Deletion: Cannot delete schemas or entire schema subjects.

​
schema-reader

The Schema Reader. Provides read-only access to view schema definitions for specified subjects.
  • Read Schemas: Can fetch schema definitions and all their versions for a given subject.
  • Check Compatibility: Can check if a schema is compatible with the latest version for a subject.
Limitations:
  • No Modification Rights: Cannot post new schemas, update compatibility settings, or delete any schema information.

​
schema-writer

The Schema Writer. Allows for the creation and updating of schemas for specified subjects.
  • Create and Update Schemas: Can post new schema versions for a subject.
Limitations:
  • No Policy Management: Cannot change the compatibility mode for the subject.
  • No Deletion: Cannot delete schemas or subjects.

​
Kafka Consumer Group

These roles are designed for managing Kafka consumer group resources on StreamNative Cloud, applicable to Kafka-on-Pulsar (KoP) use cases. The roles available at this scope are: Follow the instructions below to create a role binding for a schema subject role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the consumer-group-owner role. To bind a different consumer group role, replace consumer-group-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding consumer-group-owner-user1 \
  --clusterrole consumer-group-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-kafka-consumerGroup-name ${group_name}
You can use a startsWith macros to bind a role to multiple consumer group. For example, grants the consumer-group-owner role to all consumer group that start with the prefix ${group_name_prefix}.
snctl create rolebinding consumer-group-owner-user1 \
  --clusterrole consumer-group-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-kafka-consumerGroup-name "startsWith('${group_name_prefix}')"
You can remove --resource-kafka-consumerGroup-name to bind the role to all consumer group in the specified cluster:
snctl create rolebinding consumer-group-owner-user1 \
  --clusterrole consumer-group-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
The --resource-common-cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
consumer-group-owner

The Consumer Group Administrator. Grants full administrative control over specific Kafka consumer groups, including the ability to delete them.
  • Delete Group: Can delete a consumer group, which removes its committed offsets.
  • Alter Offsets: Can alter committed offsets for any partition.
  • View Group: Can describe the consumer group, view its members, and monitor consumer lag.
  • Includes Reader Permissions: Inherits all permissions from the consumer-group-reader role.
Limitations:
  • Scoped to Group: Permissions are limited to the specified consumer groups.

​
consumer-group-reader

The Consumer Group Reader. Allows for monitoring and performing safe operational tasks on a specific Kafka consumer group.
  • Reset Offsets: Can perform the common operational task of resetting consumer offsets to a specific point in time (for example, earliest, latest) to reprocess or skip messages.
  • View Group: Can describe the consumer group, view its members, and monitor consumer lag.
Limitations:
  • No Deletion: Cannot delete the consumer group.

​
Kafka Transactional

These roles are designed for managing Kafka transactional ID resources on StreamNative Cloud, applicable to Kafka-on-Pulsar (KoP) use cases. The roles available at this scope are: Follow the instructions below to create a role binding for a schema subject role.
  • Ensure you have downloaded snctl and logged in to your StreamNative Cloud organization.
  • To bind a role to a different principal type
  • The example below binds the transactional-id-owner role. To bind a different transactional role, replace transactional-id-owner in the --clusterrole argument and in the role binding’s name.
snctl create rolebinding transactional-id-owner-user1 \
  --clusterrole transactional-id-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-kafka-transaction-id ${transactional_id}
You can use a startsWith macros to bind a role to multiple transactional ID. For example, grants the transactional-id-owner role to all transactional ID that start with the prefix ${transactional_id_prefix}.
snctl create rolebinding transactional-id-owner-user1 \
  --clusterrole transactional-id-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id} \
  --resource-kafka-transaction-id "startsWith('${transactional_id_prefix}')"
You can remove kafka.transactional_id from the condition-cel to bind the role to all transactional ID in the specified cluster:
snctl create rolebinding transactional-id-owner-user1 \
  --clusterrole transactional-id-owner \
  --user user1@example.com \
  --resource-common-instance ${instance_name} \
  --resource-common-cluster ${cluster_id}
The srn.cluster flag requires the Cluster ID, not the Cluster Name. The Cluster ID is a unique, randomly generated string (for example, pc-y7bti, c-6mhjbx2) and can be found on the cluster overview page in the StreamNative Cloud Console.

​
transactional-id-owner

The Transactional ID Administrator. Grants administrative control over specific Kafka transactional IDs, which are persistent identities used for exactly once semantics.
  • Describe Transactions: Can view the state of active transactions associated with a given transactional ID.
  • Manage ID Lifecycle: Can manage the lifecycle of the transactional ID resource itself. This is an administrative function for platform health, not for application use.