<a id="cmf-access-control"></a>

# 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](/platform/current/security/authorization/rbac/overview.html).

<a id="cmf-rbac-scopes"></a>

## 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](/platform/current/security/authorization/rbac/rbac-predefined-roles.html#use-predefined-rbac-roles-in-cp).

| 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-rbac-scopes).

<a id="cmf-access-control-cmf-cluster-resources"></a>

### 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.

<a id="cmf-access-control-env-cluster-resources"></a>

### 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](artifacts.md#cmf-artifacts).

<a id="cmf-resource-isolation"></a>

## 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](catalog.md#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](#cmf-access-control-secrets).

<a id="cmf-access-control-role-permissions"></a>

## 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](#cmf-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.

<a id="cmf-access-control-secrets"></a>

### 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](catalog.md#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.

<a id="cmf-access-control-detached-savepoints"></a>

### 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                     |

<a id="cmf-access-control-kubernetes-clusters"></a>

### 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](kubernetes-clusters.md#cmf-k8s-register-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](kubernetes-clusters.md#cmf-kubernetes-clusters).

<a id="cmf-access-control-applications"></a>

### 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](#cmf-access-control-compute-pools).

<a id="cmf-access-control-compute-pools"></a>

### 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.

<a id="cmf-access-control-artifacts"></a>

### 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](artifacts.md#cmf-artifacts).

<a id="cmf-access-control-ui"></a>

## 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.

<a id="cmf-access-control-cli"></a>

## 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.

<a id="af-ac-cluster-id"></a>

### Cluster identifiers

A role binding is scoped to either the CMF cluster or an
environment cluster. For details, see [RBAC scopes](#cmf-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](../installation/embedded-mds.md#cmf-embedded-mds-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](#cmf-access-control-env-cluster-resources). Omit it to scope the role binding to the CMF
  cluster, which applies to [CMF cluster resources](#cmf-access-control-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](../installation/embedded-mds.md#cmf-embedded-mds-deployment-modes).

<a id="cmf-resource-name-matching"></a>

### 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.

<a id="cmf-access-control-example-scenarios"></a>

### 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.

```bash
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](#cmf-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`:

```bash
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`.

```bash
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](#cmf-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:

```bash
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:

```bash
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:

```bash
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:

```bash
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](artifacts.md#cmf-artifacts).

## Related content

- [RBAC Overview](/platform/current/security/authorization/rbac/overview.html)
- [Predefined roles](/platform/current/security/authorization/rbac/rbac-predefined-roles.html#use-predefined-rbac-roles-in-cp)
- [Authentication for CMF](../installation/authentication.md#cmf-authenticate)
- [Authorization for CMF](../installation/authorization.md#cmf-authorize)