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.

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 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, and monitor their role-binding changes in the audit logs.

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.

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 and statements within any environment they have access to.

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

CMF UI permissions

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.

Manage role bindings with the Confluent CLI

You 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 principals or roles, so 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.

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

CMF UI permissions

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

Related content