Skip to main content

​
Overview

By default, Self-service creates Kafka ACLs for both application instances and application instance permissions for an associated service account. For Confluent Cloud clusters, as of Console v1.38, you can instead manage service accounts through Confluent Cloud RBAC role-bindings. This provides the added benefit of provisioning permissions for the subject resources via schema registry RBAC role bindings. Console v1.37 introduced the concept of Child Resources. This enables the implicit provisioning of a subject permission when a topic permission is created either via ownership in an application instance or through an ApplicationInstancePermission (also known as an approved Topic Request in the UI). For example, a topic request that seeks write access to another ApplicationInstance’s topic will result in the associated application instance’s service account receiving a DeveloperWrite and DeveloperRead role binding.
For application managed service accounts (see the release notes for v1.31.0), role binding support is not currently implemented and Kafka ACLs will continue to be created for these resources.

​
Enable role bindings

Go to your Confluent Cloud cluster provider’s settings.
When configuring Confluent Cloud as your provider and providing the necessary API key and secret, make sure to use a Confluent Cloud API key that’s scoped to Cloud resource management with sufficient permissions to manage role bindings.
Confluent Cloud cluster provider settings Enter your Confluent Cloud organization ID, schema registry ID and environment ID. You can find the values for Schema registry and environment IDs by using the Confluent CLI which will also prompt you to select an appropriate environment. Your Confluent Cloud organization ID can be found on the organization settings page in the Confluent Cloud dashboard. Once all fields are populated, tick the Enable Confluent Cloud Role Bindings over ACLs checkbox.

​
Validate the migration

After approving a topic request or applying an ApplicationInstance/ApplicationInstancePermission, open Console and go to Service account page. From there, you should see the relevant role bindings that have been created for the relevant resources. Service account role bindings tab

​
Troubleshoot

Previously created ACLs will not be deleted when you enable role bindings but future applications of resources will result in only the role bindings being created for the relevant service accounts.
You’ll need to fetch all your existing ApplicationInstancePermissions and ApplicationInstances and re-apply them. First, run conduktor get ApplicationInstance and conduktor get ApplicationInstancePermission, save the output to a .yaml file and then run conduktor apply -f <saved-file>.yaml.