Access Control for Confluent Manager for Apache Flink

Confluent Manager for Apache Flink® models its access control around two central resources to which different types of users have access.

  • FlinkApplication: This defines your Flink application, which starts the Flink Cluster in Application mode. Depending on their assigned role, developers have access to their Flink environment to create, update, and view Flink applications.
  • FlinkEnvironment: The environment contains where and how to deploy the application, such as the Kubernetes namespace or central configurations that cannot be overridden. You can use Flink environments to separate the privileges of different teams or organizations. System administrators are responsible for managing the Flink environments and provisioning them correctly.

Understand user roles for Flink resources

You grant a user access to CMF resources.

The following table shows roles and the operations the role is allowed for CMF resources.

Role Name: Role Scope Create/Update FlinkEnvironment Delete FlinkEnvironment Create/Update FlinkApplication in FlinkEnvironment View FlinkApplication and access the Flink Web UI in FlinkEnvironment Add new role-bindings
super.user: Cluster-level Yes Yes Yes Yes Yes
SystemAdmin: Cluster-level Yes Yes Yes Yes Yes
ClusterAdmin: Cluster-level Yes No Yes Yes No
UserAdmin: Cluster-level No No No No Yes
ResourceOwner: Resource-level No No Yes Yes Yes
DeveloperRead: Resource-level No No No Yes No
DeveloperManage: Resource-level No No Yes Yes No

The following roles do not have access to the CMF resources:

  • SecurityAdmin
  • AuditAdmin
  • Operator
  • DeveloperWrite

Cluster identifiers

To create role bindings, you need the cluster identifiers for the components in your CMF deployment. For CMF, you use the following cluster identifiers:

  • cmf: Always set to the CMF-id, which is the identifier for the CMF cluster. Currently, changing this ID is not supported.
  • flinkEnvironment: your environment name

Important

Currently, only a single instance of CMF is supported per MDS installation.

The following example command shows how to create a role binding with the identifiers for your cluster.

Example:

confluent iam rbac role-binding create \
--principal User:<user> \
--role DeveloperRead \
--cmf CMF-id \
--flink-environment <flink-environment-name>
--resource FlinkApplication:<flink-application-name>
Copy

Example Scenarios

Scenario: A system administrator (u-admin) needs to manage permissions to all the Flink environments, but doesn’t need to create, update, view, or delete the environments

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

Scenario: A team manager needs to manage all the permissions for the Flink applications in the Flink environment confluent, but doesn’t need to create, update, view, or delete the applications.

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

Note

As you must have observed from the above example, granting UserAdmin on CMF level only allows managing permissions for the Flink environments. In order to manage permissions for the Flink applications in specific environment, you need to grant UserAdmin on the Flink environment level.

Scenario: A team lead needs to manage all Flink applications in an environment.

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

This role binding will allow the team lead to manage all Flink applications in the prod-env environment, including creating and updating applications. However, for editing the applications, the lead might also need to be able to view the environment, because the defaults for the application come from the environment. For more information, see Confluent Manager for Apache Flink Environments and Confluent Manager for Apache Flink Applications. To allow this, you can add a role binding for the DeveloperRead role for the environment.

confluent iam rbac role-binding create \
    --principal User:u-teamlead \
    --role DeveloperRead \
    --cmf CMF-id \
    --resource FlinkEnvironment:prod-env
Copy

Scenario: A developer needs to manage a specific Flink application.

confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role DeveloperManage \
    --cmf CMF-id \
    --flink-environment prod-env \
    --resource FlinkApplication:my-flink-app
Copy
confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role DeveloperRead \
    --cmf CMF-id \
    --resource FlinkEnvironment:prod-env
Copy

If you want to prevent the developer from viewing the environment, you can remove the second role binding.

Scenario: On-call team needs access to all applications in all environments and to all applications in every environment, but does not need to manage permissions on either the applications or the environments.

confluent iam rbac role-binding create \
    --principal User:u-oncall \
    --role ClusterAdmin \
    --cmf CMF-id
Copy

For each environment:

confluent iam rbac role-binding create \
    --principal User:u-oncall \
    --role ClusterAdmin \
    --cmf CMF-id \
    --flink-environment <environment-name>
Copy

Note

This permission also allows the on call team to create new environments. If you want to restrict this, you should create a ClusterAdmin for each environment. Another thing to note is that this role will still allow the user to create a new environment with the name prod-env if it doesn’t already exist.

confluent iam rbac role-binding create \
    --principal User:u-oncall \
    --role ClusterAdmin \
    --cmf CMF-id \
    --flink-environment prod-env
Copy

Scenario: A developer needs to delete stale environments.

confluent iam rbac role-binding create \
    --principal User:u-developer \
    --role SystemAdmin \
    --cmf CMF-id
Copy

Related content