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.
Confluent Cloud caps non-Dedicated clusters at 500 role bindings per cluster. At Self-service scale you can hit that ceiling quickly, so we recommend running role bindings on a Dedicated Confluent Cloud cluster. Non-Dedicated cluster types are likely inappropriate for role-binding-managed Self-service deployments beyond a small number of applications.
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.
Console creates role bindings for every application instance on a cluster where you enable them, with the Confluent Cloud API key configured for the cluster. When you approve a request, Console creates a DeveloperRead role binding for read access, or DeveloperWrite and DeveloperRead for write access, for the recipient’s service account on the topic. If the cluster has a Schema Registry ID configured, Console also creates one on the matching subject prefix.If the error comes from Confluent Cloud (ConfluentCloud Downstream Error), the API key isn’t allowed to create role bindings at one of these scopes. Give the owner of the API key the right to manage role bindings in the cluster’s environment, check that the recipient’s spec.serviceAccount is a Confluent service account ID (sa-...), then approve the request again. If the error comes from Console instead, the user who approves doesn’t have the permission to grant access on the application instance.The request stays pending until the approval succeeds.