Security Deployment Profiles in Confluent Platform¶
Confluent Platform offers multiple security deployment profiles tailored to meet the diverse security needs of various deployment scenarios. The following table provides a comprehensive overview of the available security deployment profiles for your Confluent Platform cluster and the security configurations they support.
Security options¶
Confluent Platform supports many different security options for authentication, authorization, encryption, and identity provider protocols. To help you understand the security options available for your Confluent Platform clusters and the security deployment profiles that support them. The purpose of this section is to summarize all of the available options and provide links to learn more about them. The table below this section lists different security deployment profiles supported in Confluent Platform clusters and the security options they support.
Authentication methods¶
Various authentication methods are available to meet diverse security needs across different deployment scenarios, ensuring secure communication and authentication within your Confluent Platform cluster.
For details, see Authentication Methods.
Click to expand or collapse the summary of authentication methods
- HTTP Basic Authentication
Uses Base64-encoded usernames and passwords included in HTTP request headers to authenticate clients and services over HTTP.
For details, see HTTP Basic Authentication.
- LDAP
Uses Lightweight Directory Access Protocol (LDAP) to verify user credentials against an LDAP directory, allowing applications and services to authenticate users by querying and validating user information in a centralized directory service.
For details, see Configure Kafka Clients for LDAP Authentication.
- mTLS
Uses Mutual Transport Layer Security (mTLS) to ensure that clients and services authenticate each other using certificates. Secure communication is provided by using TLS to encrypt data in motion (or data in transit) and using certificates to authenticate identities.
For details, see Mutual TLS (mTLS) Authentication.
- OIDC (SSO)
Uses OpenID Connect (OIDC) to extend OAuth 2.0 to provide single sign-on capabilities provided by an external identity provider (IdP). OIDC SSO allows clients and services to authenticate once and gain access to multiple services and applications.
For details, see Configure SSO using OIDC.
- SASL/GSSAPI (Kerberos)
Uses the Kerberos protocol within the SASL framework to provide secure, mutual authentication between clients and services, leveraging GSSAPI to interface with Kerberos.
For details, see Use SASL/GSSAPI Authentication.
- SASL/OAUTHBEARER (with IdP as token issuer)
Uses OAuth 2.0 bearer tokens issued by an external identity provider (IdP) to securely authenticate clients and services within the SASL framework.
For details, see Use SASL/OAUTHBEARER Authentication.
- SASL/OAUTHBEARER (with MDS as token issuer)
Uses OAuth 2.0 bearer tokens issued by the Confluent Metadata Service (MDS) to securely authenticate clients and services within the SASL framework.
For details, see Use SASL/OAUTHBEARER Authentication.
- SASL/PLAIN or SASL/PLAIN (with LDAP server)
Uses the SASL framework with plain text for authentication. Because SASL/PLAIN transmits credentials (usernames and passwords) in plain text, it is vulnerable to interception unless used over secure channels using TLS.
For details, see Use SASL/PLAIN Authentication.
- SASL/SCRAM
Uses Salted Challenge Response Authentication Mechanism (SCRAM) with salted and hashed passwords to securely authenticate clients and services, providing protection against replay attacks and password theft.
Uses the SASL framework with the Salted Challenge Response Authentication Mechanism (SCRAM) and salted, hashed passwords to securely authenticate clients and services, providing protection against replay attacks and password theft.
For details, see: Use SASL/SCRAM Authentication.
Authorization mechanisms¶
Authorization mechanisms are used to control access to resources in your Confluent Platform cluster.
For details, see Authorization.
Click to expand or collapse the summary of authorization mechanisms
- ACLs
Access control lists (ACLs) provide a mechanism to control access to resources in your Confluent Platform cluster by defining the set of users, clients, and services that are allowed or denied access to specific resources.
For details, see Use Access Control Lists (ACLs) for Authorization.
- RBAC
Role-Based Access Control (RBAC) allows fine-grained access management by defining roles with specific permissions and assigning these roles to users and services.
For details, see Use Role-Based Access Control (RBAC) for Authorization.
Encryption¶
Encryption is used to secure data in motion (or data in transit) and at data at rest in your Confluent Platform cluster.
For details, see Encryption.
Click to expand or collapse summary of encryption options
- TLS
Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over computer networks. TLS is the successor to the deprecated Secure Sockets Layer (SSL) protocol, offering improved security features and more robust support against modern threats.
For details, see TLS Encryption.
Identity provider protocols¶
Identity provider (IdP) protocols are frameworks or sets of rules used to define how identities (users and services) are authenticated and managed within your Confluent Platform cluster. These protocols are used to integrate with external identity providers and provide a single source of truth for user and service authentication.
Click to expand or collapse the summary of identity provider (IdP) protocols
- LDAP
Lightweight Directory Access Protocol (LDAP) is a protocol used to access and maintain distributed directory information services over an IP network.
For details, see LDAP.
- OIDC
OpenID Connect (OIDC) extends OAuth 2.0 authorization to provide sign-in and profile information about authenticated users. OIDC is widely used to implement single sign-on (SSO) for integration with external identity providers and to provide a single source of truth for user and service authentication.
For details, see Configure SSO for Confluent Control Center using OIDC.
Security deployment profiles¶
The columns in the following table represent the different security options available for your Confluent Platform clusters and the security deployment profiles that support them.
- Authentication: Kafka client: Options for Kafka clients authenticating to Confluent Server brokers
- Authentication: Kafka client to non-Kafka component: Options for Kafka clients authenticating to Schema Registry, REST Proxy, ksqlDB, and Confluent Control Center
- Authentication: Service-to-service: Options for authenticating Schema Registry to Confluent Server, Connect to Schema Registry, Connect to Confluent Server, etc.
- Authentication: User: Options for users authenticating using Confluent Control Center or Confluent CLI
- Authorization: Options for controlling access to resources in your Confluent Platform cluster
- Encryption: Options for encrypting data in motion (or data in transit)
- Identity provider protocols: Options for integrating with external identity providers
| Profile | Authentication: Kafka client | Authentication: Client to non-Kafka component | Authentication: Service to service | Authentication: User | Authorization | Encryption | Identity provider protocols |
|---|---|---|---|---|---|---|---|
| 1 | SASL (/PLAIN, /GSSAPI, /SCRAM) or mTLS | mTLS | mTLS | HTTP Basic Authentication | ACLs | TLS | |
| 2 | SASL (/GSSAPI, /SCRAM) or mTLS | SASL (/GSSAPI, /SCRAM) | mTLS | HTTP Basic Authentication | ACLs | TLS | |
| 3 | SASL (/PLAIN, /PLAIN with LDAP server, /GSSAPI, /SCRAM) or mTLS | HTTP Basic Authentication | OAuthBearer (powered by LDAP and MDS-issued tokens) | HTTP Basic Authentication | RBAC | TLS | LDAP |
| 4 | SASL (/PLAIN, /PLAIN with LDAP server, /GSSAPI, /SCRAM) or mTLS | HTTP Basic Authentication | OAuthBearer powered by LDAP and MDS-issued tokens | OIDC (SSO) | RBAC | TLS | Both OIDC and LDAP |
| 5 | SASL (/OAUTHBEARER with IdP-issued tokens, /PLAIN, /PLAIN with LDAP server, /GSSAPI, /SCRAM) or mTLS | HTTP Basic Authentication | OAuthBearer with IdP-issued tokens | OIDC (SSO) | RBAC | TLS | Both OIDC and LDAP |
| 6 | SASL (/OAUTHBEARER with IdP-issued tokens, /PLAIN, /SCRAM, /GSSAPI) or mTLS | mTLS | mTLS | HTTP Basic Authentication | ACLs | TLS | OIDC |
| 7 | SASL (/OAUTHBEARER with IdP-issued tokens, /PLAIN, /PLAIN with LDAP server, /SCRAM, /GSSAPI) or mTLS | OAuthBearer with IdP-issued tokens or HTTP Basic Authentication | OAuthBearer with IdP-issued tokens | OIDC (SSO) | RBAC | TLS | Both OIDC and LDAP |
| 8 | SASL (/OAUTHBEARER with IdP-issued tokens, /PLAIN, /SCRAM, /GSSAPI) or mTLS | OAuthBearer with IdP-issued tokens or mTLS | mTLS | HTTP Basic Authentication | ACLs | TLS | OIDC |
| 9 | SASL (/OAUTHBEARER with IdP-issued tokens, /PLAIN, /SCRAM, /GSSAPI) or mTLS | OAuthBearer with IdP-issued tokens | OAuth | OIDC (SSO) | RBAC | TLS | OIDC |