Topic ACL on service account or API key?

When adding a Kafka topic ACL, is there a best practice of whether to place the ACL on the service account or on the API key?

From what I’ve read in documentation, it “seems” like it should go on the service account, but there is no definitive statement that I found.

Thanks for raising this. We will review the documentation to make this clearer.

One point of clarification in the question: we’d recommend using a service account, and API keys (with ACLs potentially specified) represent the service account. So, whether using ACLs or RBAC, the authorization settings are associated with the service account identity in either case. A note on this: it feels in the Confluent Cloud Console as if ACLs are on a key and if the key gets rotated you would need to set it again, but this is not the case as the ACL is tied to the service account (or user account). This will likely get clarified in the Confluent Cloud Console.

I see this best practice opinion in the Confluent Developer Cloud Security course:

You can use a mix of ACLs and RBACs. This may be helpful if you need to provide a small set of identities with access to a resource in your Confluent Cloud cluster. However, as an investment in the future, we recommend going with RBACs over ACLs.

Note that “placing the ACL on the service account” is the RBAC approach mentioned. I’d agree with the guidance. If you ever think about migrating away from basic authentication, then RBAC will translate more easily. For example, if today you used RBAC with Basic Auth and wanted to migrate to OAuth, you would similarly add a role assignment when creating your identity pool.

The caveat I’d make is that this is general guidance but there might be exceptions. E.g., if some granular DENY rules are needed, you might opt for a combination of RBAC plus ACLs. This’d be an exception rather than the best practice guideline / rule though.