Use Mutual TLS (mTLS) to Authenticate to Confluent Cloud Resources

You can use mutual TLS (mTLS) for X.509 client certificate authentication and granular access control to Dedicated clusters in your Confluent Cloud organization.

Key benefits

  • Enhanced security: mTLS provides a higher level of security by requiring both the client and server to authenticate each other. This two-way authentication significantly reduces the risk of unauthorized access.
  • Strong access control: It makes it much more difficult for unauthorized users or systems to connect to the Confluent Cloud resources, as they would need valid certificates.
  • Compliance: Many industries have strict regulatory requirements for data protection and access control. mTLS can help meet these compliance standards by providing strong authentication.
  • Protection against attacks: mTLS helps prevent man-in-the-middle attacks and other common security threats by helping to ensure that both parties in the communication are who they claim to be.
  • Data integrity and confidentiality: The encryption provided by TLS, combined with the mutual authentication, ensures that data in motion (or data in transit) is protected from tampering and eavesdropping.
  • Client-side security: It enforces security at the client level, to help ensure that only authorized clients with valid certificates can connect to Confluent Cloud resources.
  • Reduced reliance on passwords: mTLS can be used as an alternative or supplement to traditional username/password authentication, potentially reducing the risks associated with password-based security.
  • Granular access control: Certificates can be issued and managed for specific clients or applications, allowing for more fine-grained control over who can access what resources.

How mTLS works in Confluent Cloud

Here’s a summary of the mTLS handshake process in Confluent Cloud:

  1. Client initiation: The client initiates a TLS connection to your Confluent Cloud cluster.
  2. Server hello: The Confluent Cloud cluster responds and requests the client’s certificate.
  3. Client certificate: The client sends its certificate to the cluster, allowing the cluster to verify the client’s identity.
  4. Server authentication: The Confluent Cloud cluster presents Let’s Encrypt certificates to the client for verification.
  5. Certificate verification: Both the client and server verify each other’s certificates:
    • The Kafka client verifies the cluster’s certificate. For more information, see Manage TLS certificates.
    • The Confluent Cloud cluster verifies the client’s certificate. The cluster verifies the client certificate against the configured Certificate Authorities (CAs) that the administrator set up ahead of time in the Confluent Cloud organization.
  6. Secure connection: After the TLS handshake is successful, the Confluent Cloud cluster must identify the certificate identity principals that match the client certificate metadata for authorization. At least one certificate identity pool must match, otherwise there is an authorization error.

If any step in this process fails, the connection attempt is terminated.

By implementing mTLS, Confluent Cloud ensures that all communication between your clients and Confluent Cloud resources is not only encrypted but also authenticated, providing a robust defense against unauthorized access and data breaches.

Key components of mTLS in Confluent Cloud

Certificates
Both the client and the server must have their own certificates, which are used during the handshake process to prove their identities to each other.
Certificate Authority (CA)
A trusted CA is responsible for issuing and verifying the digital certificates used in the mTLS process. Confluent Cloud typically manages its own server certificates.
Client certificates
Clients need to present a valid certificate that is either self-signed or signed by a trusted CA. This certificate must be configured in the client’s application or service that connects to Confluent Cloud.
TLS Handshake
This is the process where the client and server exchange certificates and validate each other. If either party fails to authenticate the other, the connection is not established.
Encryption
After a successful handshake, all data transmitted between the client and server is encrypted using TLS, providing confidentiality and integrity.

Implementation considerations

Certificate management
Managing certificates and keys securely is crucial. This includes issuing, renewing, and revoking certificates as needed.
Performance
The mTLS handshake can add latency to the initial connection setup. It’s important to consider this in performance-sensitive applications.
Compatibility
Ensure that all parts of your system are compatible with mTLS and can handle the requirements for certificate management.

Related content