Confluent Cloud Security FAQ

Q: What happens when an ACL and an RBAC role binding disagree?

ACL DENY rules are evaluated first and always win. If no ACL DENY applies, then an ACL ALLOW or an RBAC role binding is sufficient to grant access. All RBAC roles grant ALLOW. For details, see Order of precedence.

Confluent Cloud secures your data with encryption in transit and at rest, granular authorization through role-based access control (RBAC) and access control lists (ACLs), network-level controls such as IP filtering, and auditing through audit logs.

For an overview, see Manage Security on Confluent Cloud.

General security questions

What security features does Confluent Cloud provide?

Confluent Cloud security spans four areas:

Authentication: user accounts, single sign-on (SSO), service accounts, API keys, OAuth and OpenID Connect (OIDC), and mutual TLS (mTLS) authentication. For authentication questions, see Confluent Cloud Identity FAQ.
Authorization: RBAC, ACLs, and IP filtering.
Encryption: TLS in transit, encryption at rest with optional self-managed keys, and client-side field level encryption.
Monitoring: audit logs of administrative and data-plane activity.

Where can I find Confluent Cloud compliance and certification information?

Confluent publishes compliance certifications, security reports, and related documentation on the Confluent Trust & Security page and in the Confluent Trust Center.

Authorization questions

When should I use RBAC and when should I use ACLs?

Use RBAC as the primary mechanism to provide a consistent approach across all resources in Confluent Cloud. RBAC assigns predefined roles at organization, environment, cluster, or resource scope, and covers Confluent Cloud resources, including Apache Kafka®.

Use ACLs to manage access to Kafka resources, such as topics, consumer groups, and transactional IDs, in a way that is compatible with other standard Kafka implementations. When you need a DENY rule, use ACLs because RBAC does not provide a DENY rule.

You can use both together. For more information, see Role-based Access Control (RBAC) on Confluent Cloud, ACL Overview, and Use ACLs with RBAC on Confluent Cloud.

What happens when an ACL and an RBAC role binding disagree?

ACL DENY rules are evaluated first and always win. If no ACL DENY applies, then an ACL ALLOW or an RBAC role binding is sufficient to grant access. All RBAC roles grant ALLOW.

For details, see Order of precedence.

Can I create custom RBAC roles?

No. Confluent Cloud includes a set of predefined roles that you scope to specific resources to fit most access patterns. For the list of roles and what each one grants, see Predefined RBAC Roles in Confluent Cloud.

Do I need to clean up API keys when I remove a role binding?

Yes. Removing a role binding does not automatically delete API keys belonging to the principal, which is the user or service account. For example, a ksqlDB API key can continue to be used to authenticate a user or service account after you remove the role binding. If other role bindings exist or if more are created for the user or service account later, the API key would allow a caller access. As a best practice, remove API keys and role bindings when removing access for an application.

For more information, see Limitations and Delete unneeded API keys and service accounts.

Network security questions

How do I restrict which public networks can reach my Confluent Cloud resources?

Use IP filtering. IP groups are lists of Classless Inter-Domain Routing (CIDR) blocks that describe your trusted source public networks. You attach IP groups to IP filters scoped to your organization or to a specific environment. Confluent Cloud denies requests from public network IP addresses outside your filters and records the attempts in your audit log.

For more information, see IP Filtering on Confluent Cloud.

Does IP filtering apply to private networking?

No. IP filtering applies only to requests made over public networks. You cannot use it to limit requests made over private network connections.

Can I use private networking instead of the public internet?

Yes. Confluent Cloud connects through AWS PrivateLink, Azure Private Link, Google Cloud Private Service Connect, virtual private cloud (VPC) and virtual network (VNet) peering, AWS Transit Gateway, and Private Network Interface (PNI). For the options and how to choose between them, see Confluent Cloud Networking FAQ.

Encryption in transit questions

Is all traffic to Confluent Cloud encrypted?

Yes. TLS encrypts all connections carrying data in transit to and from Confluent Cloud. Confluent Cloud services prefer TLS 1.3 and fall back to TLS 1.2.

For more information, see Manage Data in Transit with TLS on Confluent Cloud.

Which TLS versions does Confluent Cloud support?

Basic, Standard, Enterprise, and Freight clusters support TLS 1.3 and TLS 1.2. You cannot configure the protocol versions, and both remain enabled.
Newly created Dedicated clusters enable TLS 1.3 by default. For Dedicated clusters created before April 30, 2026, you must manually enable TLS 1.3, as described in Enable TLS 1.3 on Dedicated clusters. After enabling TLS 1.3, you can optionally disable TLS 1.2.

Which cipher suites does Confluent Cloud support?

All cluster types negotiate a shared set of TLS 1.2 and TLS 1.3 cipher suites. Some TLS 1.2 suites are marked legacy and exist only for backward compatibility. Do not adopt these cipher suites for new deployments.

For the full list, see Supported cipher suites.

Can I restrict which cipher suites my cluster negotiates?

Only Dedicated clusters can restrict the set of cipher suites used. For details, see Restrict cipher suites.

Do I need to do anything special with TLS certificates?

Avoid certificate pinning. Confluent Cloud uses TLS certificates issued by Let’s Encrypt, which can update intermediate certificates at any time. If you replace a certificate, directly or by Let’s Encrypt, it causes connection failures for pinned clients. If your organization requires pinning, pin to the Let’s Encrypt ISRG Root X1 certificate rather than any intermediate certificate.

For more information, see Manage TLS certificates.

Encryption at rest questions

Is data at rest encrypted by default?

Yes. Confluent Cloud encrypts customer data at rest on encrypted volumes using the native encryption services of the underlying cloud provider. You do not need to configure anything. For more information, see Encryption of data at rest on Kafka clusters.

Can I use my own encryption keys?

Yes. Dedicated, Enterprise, and Freight clusters accept self-managed encryption keys, also called bring your own key (BYOK). Confluent Cloud supports AWS Key Management Service (KMS), Azure Key Vault, and Google Cloud Cloud KMS.

You must select Use self-managed encryption keys when you create your cluster. You cannot change this setting after you provision the cluster.

For the full requirements, see Requirements.

If I revoke my encryption key, is my data immediately inaccessible?

Revoking access to the key prevents Confluent Cloud from using it, but you must delete the cluster to make it fully inaccessible.

For more about revoking your key, see Revoke Access to Data at Rest for Dedicated and Enterprise Kafka Clusters on Confluent Cloud.

What happens if my key policy is misconfigured?

If your key policy is misconfigured, your cluster operations that need that key can fail. In some cases, a key policy change can lock Confluent Cloud out of the key, which makes your cluster unavailable until you restore access.

For more information, see Troubleshoot Key Policy Issues for Self-Managed Encryption Keys and Recover from key policy lockout.

Client-side encryption questions

What is client-side field level encryption?

Client-side field level encryption (CSFLE) encrypts individual fields, such as personally identifiable information (PII), in your client application. Your consumers decrypt the fields. Anyone without access to the decryption keys, including administrators, sees only ciphertext.

For more information, see Protect Sensitive Data Using Client-Side Field Level Encryption on Confluent Cloud.

How is CSFLE different from encryption at rest and TLS?

CSFLE protects specific fields end to end. Those fields remain encrypted in the broker, in Confluent Cloud tooling, and in downstream consumers that lack the key. By contrast, TLS protects data while it moves between your clients and Confluent Cloud; encryption at rest protects data on disk. Both remain transparent to your application, and anyone authorized to read the topic sees plaintext.

What do I need to use CSFLE?

CSFLE requires the Stream Governance Advanced package and a supported client. These are the supported clients:

Apache Kafka® Java client shipped with Confluent Platform 7.4.5, 7.5.4, or 7.6.1 and later
Confluent Go Client
Confluent .NET Client

For the full list of clients and versions, see Requirements. To try CSFLE end to end, see Quick Start - Use CSFLE to Protect Sensitive Data.

Can I encrypt the whole payload instead of individual fields?

Yes. Client-Side Payload Encryption (CSPE) encrypts the entire message payload rather than selected fields. For more information, see Protect Sensitive Data Using Client-Side Payload Encryption on Confluent Cloud.

Auditing and monitoring questions

What activity is recorded in audit logs?

Confluent Cloud audit logs capture administrative and data-plane activity in your organization, including authentication events and API key management operations such as CreateAPIKey, DeleteAPIKey, UpdateAPIKey, and GetAPIKey.

For more information, see Audit Log Concepts on Confluent Cloud.

Can I access internal service logs for Confluent Cloud?

No. Internal service logs for Confluent Cloud fully managed services, such as Kafka brokers and Schema Registry, are not directly accessible. Use audit logs, the Confluent Cloud Metrics, connector events, and the Confluent Cloud Console to monitor and debug your workloads.