Configure Access Control for Confluent Manager for Apache Flink

This topic describes how to configure access control for resources in Confluent Manager for Apache Flink® (CMF). For a general description of role-based access control (RBAC), see the RBAC Overview.

Starting with version 2.5.0, you can also manage role bindings in the CMF UI. For details, see Manage role bindings in the CMF UI.

RBAC scopes

Every CMF role binding is scoped to a cluster. In CMF, a cluster is an RBAC scope, not a Kubernetes cluster or a Flink cluster. Two kinds exist:

CMF cluster: The scope for resources that belong to the CMF installation as a whole, such as environments, catalogs, and secrets. Each installation has one CMF cluster.
Environment cluster: The scope for resources that belong to a single environment, such as applications and statements. Each environment is its own environment cluster.

Scopes don’t nest. A role binding scoped to the CMF cluster grants no permissions in any environment cluster, and a role binding scoped to one environment cluster grants no permissions in another. Creating an environment doesn’t grant the creator any role in it.

Role bindings outlive environments. Deleting an environment doesn’t delete its role bindings, and if you create an environment with the same name, the old role bindings apply to it again. To prevent a new environment from inheriting access, delete the role bindings for an environment when you delete the environment, either in the CMF UI (see Delete a role binding) or with the Confluent CLI (see Manage role bindings with the Confluent CLI).

Role types

RBAC roles in Confluent Platform fall into two types:

Cluster-level roles: Cluster-level roles grant permissions on all resources in the scope of the role binding.
Resource-level roles: Resource-level roles provide finer-grained permissions, limited to a specific resource type and granted on named instances of that type.

The following table lists the roles that apply to CMF resources. For a list of all predefined RBAC roles for Confluent Platform, see Predefined roles.

Role	Type
super.user	Cluster-level
SystemAdmin	Cluster-level
ClusterAdmin	Cluster-level
UserAdmin	Cluster-level
ResourceOwner	Resource-level
DeveloperRead	Resource-level
DeveloperManage	Resource-level

Note

The super user role isn’t granted the way the other roles in this table are. It’s a static principal list configured either in the Metadata Service (MDS) or on the broker (for example, cmf.mds.super-users for an embedded MDS).

The following roles have no permissions on CMF resources:

AuditAdmin
Operator
DeveloperWrite
SecurityAdmin

Note

You can bind SecurityAdmin to CMF resources with the Confluent CLI, but it only lets the principal view role bindings.

Resource types

CMF defines nine resource types. Each type belongs to one of the two scopes described in RBAC scopes.

CMF cluster resources

The following resource types require a role binding scoped to the CMF cluster:

Environment: Defines where and how to deploy applications, such as the Kubernetes namespace and central configuration that applications can’t override. Environments separate the privileges of different teams or organizations.
Catalog: Exposes Kafka topics as tables with schemas derived from Schema Registry.
Secret: Stores confidential data, such as the credentials that catalogs and databases use to connect to Schema Registry and Kafka.
Detached savepoint: Represents a Flink savepoint that isn’t tied to a running job.
Kubernetes cluster: Represents a Kubernetes cluster managed by CMF. This includes the Kubernetes cluster where CMF itself is installed (the hub cluster) and any spoke clusters that you register by adding a kubeconfig file, for deploying Flink workloads.

Environment cluster resources

The following resource types require a role binding scoped to an environment cluster:

Application: Defines a Flink job that executes as a Flink cluster in application mode.
Statement: Represents a SQL query that CMF executes and maintains.
Compute pool: Provides the compute resources that run SQL statements.
Artifact: Stores a binary file, such as a job JAR, uploaded to CMF in blob storage. Applications reference artifacts with cmf:// URIs. For more information, see Manage Artifacts in Confluent Manager for Apache Flink.

Environment isolation

An environment provides two isolation boundaries: logical isolation through RBAC and physical isolation through the Kubernetes namespace that the environment maps to.

Within an environment, a statement that accesses a catalog or database uses the credentials that the environment maps to it through secret mappings. This applies regardless of which principal submits the statement, because secret mappings are scoped per environment rather than per statement.

Separate environments stay credential-isolated even when they map to the same Kubernetes namespace, because each environment has its own secret mappings. Two environments that share a Kubernetes namespace do lose pod-level isolation from each other. To isolate workloads physically, give each environment its own namespace.

Note

RBAC can isolate which applications, statements, and compute pools each team can view or edit within a shared environment. It can’t give those teams different credentials for the same catalog or database in the environment. To give teams different credentials, separate team resources into individual environments. For details, see Role permissions for secrets.

Role permissions

The following sections list the operations that each role can perform on each resource type.

Role bindings don’t carry over across resource types. Access to a statement doesn’t grant access to the compute pool it runs on, or to any other resource type, even within the same environment. Each resource type a principal needs requires its own role binding.

Scopes don’t nest. A cluster-level role grants the permissions in the following tables for environment cluster resources (applications, statements, compute pools, and artifacts) only when the role binding is scoped to the environment cluster. A role binding scoped only to the CMF cluster grants nothing in any environment cluster. For details, see RBAC scopes. Similarly, Manage role bindings on an environment applies to the environment resource itself, not to role bindings inside that environment cluster.

Warning

Any role with the Manage role bindings operation lets a user grant themselves or others roles within the scope of the role binding. SystemAdmin and UserAdmin can grant any role in the CMF cluster or environment cluster where the role binding is scoped, including roles with more privileges than their own. ResourceOwner can grant roles on the resources that the role binding covers. Assign these roles only to trusted users. If you use a broker-hosted MDS, monitor their role-binding changes in the audit logs. The embedded MDS doesn’t produce an audit log.

Environments

The following table shows the roles that have access to environment resources:

Role	View	Create/Edit	Remove	Manage role bindings
super.user	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	No
UserAdmin	No	No	No	Yes
ResourceOwner	n/a	n/a	n/a	n/a
DeveloperRead	Yes	No	No	No
DeveloperManage	Yes	No	No	No

Note

The ResourceOwner role can’t be bound to an environment resource.

Catalogs

The following table shows the roles that have access to catalog resources:

Role	View	Create/Edit	Remove	Manage role bindings
super.user	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	No
UserAdmin	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes
DeveloperRead	Yes	No	No	No
DeveloperManage	Yes	Yes	Yes	No

Note

A catalog’s databases share the catalog’s own authorization. A database has no separate role-bindable resource within a catalog.

Secrets

The following table shows the roles that have access to secret resources:

Role	View	Create/Edit	Remove	Manage role bindings
super.user	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	No
UserAdmin	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes
DeveloperRead	Yes	No	No	No
DeveloperManage	Yes	Yes	Yes	No

The roles govern operations on the secret resource. They don’t govern how the secret’s credentials are used at runtime. A secret takes effect when an environment maps it to the connectionSecretId of a catalog or database, as described in Secrets and secret mappings.

Note

Creating a secret mapping requires the Create/Edit permission on the environment. Setting a connectionSecretId on a catalog or database requires the Create/Edit permission on the catalog. Neither requires any permission on the secret itself.

Detached savepoints

The following table shows the roles that have access to detached savepoint resources:

Role	View	Create/Edit	Remove	Manage role bindings
super.user	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	No
UserAdmin	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes
DeveloperRead	Yes	No	No	No
DeveloperManage	Yes	Yes	Yes	No

Kubernetes clusters

The following table shows the roles that have access to Kubernetes cluster resources:

Role	View	Edit	Use	Manage role bindings
super.user	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	No
UserAdmin	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes
DeveloperRead	Yes	No	No	No
DeveloperManage	Yes	Yes	Yes	No

Note

Kubernetes clusters have no Create permission, because they can’t be created through the CMF API. CMF registers the hub cluster at installation and registers each spoke cluster when you add its kubeconfig file. For details, see Register a cluster.

The Edit permission on a Kubernetes cluster resource governs decommissioning and recommissioning the cluster within CMF.

The Use permission governs whether the user can create an environment that resides on the Kubernetes cluster.

The default-k8s-cluster cluster is exempt from these checks. Every user can view it. Creating an environment on it doesn’t need the Use permission.

For more information about Kubernetes cluster management, see Manage Multiple Kubernetes Clusters in Confluent Manager for Apache Flink.

Applications

The following table shows the roles that have access to application resources:

Role	View	Create/Edit	Remove	Start/Suspend	Access Flink web UI	Manage role bindings
super.user	Yes	Yes	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	Yes	Yes	No
UserAdmin	No	No	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes	Yes	Yes
DeveloperRead	Yes	No	No	No	Yes	No
DeveloperManage	Yes	Yes	Yes	Yes	Yes	No

Statements

The following table shows the roles that have access to statement resources:

Role	View	Create/Edit	Remove	Access Flink web UI	Manage role bindings
super.user	Yes	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	Yes	No
UserAdmin	No	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes	Yes
DeveloperRead	n/a	n/a	n/a	n/a	n/a
DeveloperManage	Yes	Yes	Yes	Yes	No

Note

The DeveloperRead role can’t be bound to a statement resource.

The Create/Edit permission grants access to view the statement results and exceptions.

To create a statement in a shared compute pool, the user also needs the View permission on that compute pool. For details, see compute pools.

Compute pools

The following table shows the roles that have access to compute pool resources:

Role	View	Create/Edit	Remove	Access Flink web UI	Manage role bindings
super.user	Yes	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	Yes	No
UserAdmin	No	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	No	Yes
DeveloperRead	Yes	No	No	No	No
DeveloperManage	Yes	Yes	Yes	No	No

Note

For a shared compute pool, the Access Flink web UI permission grants access to the web UI of the session cluster, which shows all statements running on it.

Access to the Flink web UI for a dedicated compute pool is governed by the statement permissions.

Artifacts

The following table shows the roles that have access to artifact resources:

Role	View	Create/Edit	Remove	Use	Manage role bindings
super.user	Yes	Yes	Yes	Yes	Yes
SystemAdmin	Yes	Yes	Yes	Yes	Yes
ClusterAdmin	Yes	Yes	Yes	Yes	No
UserAdmin	No	No	No	No	Yes
ResourceOwner	Yes	Yes	Yes	Yes	Yes
DeveloperRead	Yes	No	No	No	No
DeveloperManage	Yes	Yes	Yes	Yes	No

Note

The Use permission governs whether a user can download the artifact’s binary content, or reference the artifact with a cmf:// URI inside an application or a Flink SQL statement. A user granted Use on an artifact can reference it from applications within any environment they have access to. A Flink SQL statement can only reference an artifact in its own environment.

For more information about artifact management, see Manage Artifacts in Confluent Manager for Apache Flink.

Manage role bindings with the Confluent CLI

You can create and manage CMF role bindings with the Confluent CLI. The following sections describe the values that you pass to the role binding commands, followed by example scenarios.

Cluster identifiers

A role binding is scoped to either the CMF cluster or an environment cluster. For details, see RBAC scopes.

The cluster identifiers define the scope of the role binding:

CMF cluster (--cmf): Required in every role binding. The ID of the CMF cluster, which identifies the cluster in MDS.
- If you use an embedded MDS, see Manage role bindings to find the ID.
- If you use a broker-hosted MDS, the ID is always CMF-id.
Environment cluster (--flink-environment): The name of the environment. Include it to scope the role binding to an environment cluster, which applies to Environment cluster resources. Omit it to scope the role binding to the CMF cluster, which applies to CMF cluster resources.

Note

Each CMF installation must use a single MDS. You can use either a CMF embedded MDS or a Kafka broker-hosted MDS, but not both. For details on choosing a mode, see Deployment modes.

Resource name matching

When you bind a resource-level role with --resource, the name determines which resources the binding covers:

Without --prefix, the name matches only the resource with exactly that name.
The name * is a reserved literal that matches every resource of that type, the same convention that Kafka ACLs use. Quote it as "*" so that your shell doesn’t expand it.
With --prefix, the name matches every resource whose name starts with that string, including resources created later.

Example scenarios

The examples use CMF-id, the CMF cluster ID for a broker-hosted MDS. If you use an embedded MDS, replace it with your cluster ID.

Manage role bindings in the CMF cluster

A security administrator (u-admin) needs to manage permissions on resources in the CMF cluster.

confluent iam rbac role-binding create \
    --principal User:u-admin \
    --role UserAdmin \
    --cmf CMF-id

Note

Role bindings don’t cross scope boundaries. This role binding grants permissions in the CMF cluster only. For details, see RBAC scopes.

Manage role bindings in a new environment

A new environment doesn’t inherit roles from the CMF cluster, so unless role bindings remain from a deleted environment with the same name, no principal can manage its role bindings.

Only a super user can create the first role binding. Log in to the Confluent CLI as a super user, then create a role binding scoped to the new environment cluster that grants a role with Manage role bindings. In this example, the environment is customer-analytics:

confluent iam rbac role-binding create \
    --principal User:u-manager \
    --role UserAdmin \
    --cmf CMF-id \
    --flink-environment customer-analytics

Manage a set of applications

A team lead needs to manage all applications in the prod-env environment that begin with the name customer.

confluent iam rbac role-binding create \
    --principal User:u-teamlead \
    --role DeveloperManage \
    --cmf CMF-id \
    --flink-environment prod-env \
    --prefix \
    --resource FlinkApplication:customer

For details on how --resource and --prefix match names, see Resource name matching.

Submit statements to a shared compute pool

A developer (u-developer) needs to submit Flink SQL statements to a specific shared compute pool. They can create and manage statements whose names start with u-developer.

To submit statements to a shared compute pool, the developer needs statement creation permissions and the View permission on the compute pool. Grant DeveloperManage on statements with the name prefix and DeveloperRead on the compute pool resource:

confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role DeveloperManage \
    --cmf CMF-id \
    --flink-environment prod-env \
    --prefix \
    --resource FlinkStatement:u-developer

Then grant DeveloperRead on the compute pool:

confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role DeveloperRead \
    --cmf CMF-id \
    --flink-environment prod-env \
    --resource FlinkComputePool:shared-pool

Reference an artifact from another environment

A developer needs to deploy applications in the environment prod-env that reference a shared artifact from the environment shared.

Deploying an application that references an artifact with a cmf:// URI requires the Use permission on that artifact in the artifact’s environment, and the usual application permissions in the environment where the application is deployed. Grant DeveloperManage on the artifact in the shared environment:

confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role DeveloperManage \
    --cmf CMF-id \
    --flink-environment shared \
    --resource FlinkArtifact:common-connectors.jar

Then grant DeveloperManage on applications in the prod-env environment:

confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role DeveloperManage \
    --cmf CMF-id \
    --flink-environment prod-env \
    --resource FlinkApplication:"*"

With these role bindings, the developer can reference cmf://shared/common-connectors.jar in the job.jarURI field of applications in prod-env, and can view, download, and manage this artifact, but has no access to other artifacts in shared. For more information, see Manage Artifacts in Confluent Manager for Apache Flink.

Manage role bindings in the CMF UI

In the CMF UI, you can view, grant, edit, and delete role bindings in the CMF cluster and in each environment cluster you are allowed to manage.

Enable access to the role bindings pages

The pages require that you enable the UI feature and configure authorization. For the full list of requirements and how to enable the pages, see Manage role bindings.

The role bindings pages appear under Settings when you hold a role that can manage role bindings.

The pages are Role bindings, which lists the role bindings, and Role definitions, which describes the roles. For the permissions that each role has, see Role permissions.

Note

Super users can’t use the role bindings pages, because super user access isn’t expressed as role bindings. Super users must first bootstrap administrator user role bindings with the Confluent CLI or the MDS API.

Scopes don’t nest, so a super user must also bootstrap the first administrator role binding for each new environment with the Confluent CLI. For details, see Manage role bindings in a new environment.

View role bindings

The Role bindings page shows a table with the following columns: Principal, Role, Scope, Resource type, and Resources. Each combination of principal, role, scope, and resource type has one row. Cluster-level roles show All resources. For resource-level roles, each resource name is labeled as a literal match, a prefix match, or all resources.

Use the search box to search by principal, role, resource, or scope. Use the Role, Scope, Resource type, and Resources filters to narrow the table.

The table shows role bindings, not effective access:

It doesn’t expand group membership. A user who has access through Group:<group-name> isn’t listed with a separate row for the resource.
It doesn’t show that a cluster-level role covers every resource in its scope.
It doesn’t show super users.
It doesn’t show role bindings that you are not allowed to manage.

Grant a role

On the Role bindings page, click Add role bindings.
Select User or Group as the Principal type, and enter the principal name.
Select the role. The list separates cluster-level roles from resource-level roles, and offers only the roles that you are allowed to grant.
Select the scope, CMF level or Specific environment. For a specific environment, select the environment.
For a resource-level role, select the resource type. Then select existing resources, or enter names and choose whether each name is a literal or a prefix match. For details on how names match, see Resource name matching.
Click Add role binding.

You can grant roles only on resources that you are allowed to manage. For the permissions that each role has, see Role permissions.

Edit a role binding

You can edit the resource patterns of a resource-level role binding. Click Edit role binding on the row, add or remove patterns, then click Save.

You can’t change the principal, role, or scope of an existing role binding. To change them, delete the role binding and grant a new one. You can’t edit cluster-level role bindings, because they have no patterns. You also can’t save an edit that removes every pattern. Cancel the edit and delete the role binding instead.

If you remove a pattern from your own role binding, or from a group that you belong to, the UI warns you that you might lose your own access.

Delete a role binding

Click Delete role binding on a row and confirm. For a resource-level row, the deletion removes only the patterns shown in that row, and the principal keeps the role on other resources. For a cluster-level row, it removes the role from the scope.

To delete several role bindings at once, select a principal’s rows in the table and click Delete role bindings. Selecting one row for a principal selects all of that principal’s rows.

If the role binding belongs to you, or to a group that you belong to, the confirmation dialog warns that the deletion removes your own access and might not be reversible from the UI. If it is your last role that manages role bindings in a scope, that scope no longer appears for you.

Prepare role bindings during a migration to the embedded MDS

During a migration from a broker-hosted MDS, as described in Migrate from broker-hosted MDS to embedded MDS, you run the embedded MDS alongside the broker-hosted MDS. In this state, the pages read and write the embedded MDS, but the broker-hosted MDS makes the authorization decisions. A banner titled Bindings are not enforced yet states that the role bindings shown aren’t enforced until you set cmf.authorization.authority to cmf. Use this state to prepare role bindings before you switch.

Unless you already copied role bindings, as described in Step 1 of Migrate from broker-hosted MDS to embedded MDS, an embedded MDS starts with no role bindings. Before anyone can use the pages in this state, a super user must use the Confluent CLI or the MDS API to grant a managing role in the embedded MDS to an administrator. For details, see the super user note and Manage role bindings.

Permissions that the CMF UI requires

When you use the CMF UI, you need permissions on additional resources beyond what the Confluent CLI requires. The UI lists related resources for you to select, and listing them requires the View permission:

To work with resources inside an environment, you need View on the environment itself, in addition to View on the resources.
To select a compute pool when creating a statement, you need View on the compute pool.
To select a catalog or database when creating a statement, you need View on the catalog.
To select an artifact from the managed artifact list when creating an application, you need View on the artifact.
To select a Kubernetes cluster when creating an environment, you need View on the Kubernetes cluster.
To select a secret when linking it to a catalog or database, you need View on the secret.

Configure Access Control for Confluent Manager for Apache Flink

RBAC scopes

Role types

Resource types

CMF cluster resources

Environment cluster resources

Environment isolation

Role permissions

Environments

Catalogs

Secrets

Detached savepoints

Kubernetes clusters

Applications

Statements

Compute pools

Artifacts

Manage role bindings with the Confluent CLI

Cluster identifiers

Resource name matching

Example scenarios

Manage role bindings in the CMF cluster

Manage role bindings in a new environment

Manage a set of applications

Submit statements to a shared compute pool

Reference an artifact from another environment

Manage role bindings in the CMF UI

Enable access to the role bindings pages

View role bindings

Grant a role

Edit a role binding

Delete a role binding

Prepare role bindings during a migration to the embedded MDS

Permissions that the CMF UI requires

Related content