# Security Deployment Profiles in Confluent Platform Confluent Platform supports many security deployment profiles that meet a diverse range of security needs. On this page you’ll find a comprehensive overview of the security options that make up a deployment profile. You’ll find a table that details the profiles for your Confluent Platform cluster and the security configurations they support. ## Security options Confluent Platform supports many security options for authentication, authorization, encryption, and identity provider protocols. This section summarizes the available configuration options and provides links to learn more about them. ### Authentication methods Many 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](authentication/overview.md#authentication-overview).
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](authentication/http-basic-auth/overview.md#http-basic-auth). 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](authentication/ldap/client-authentication-ldap.md#client-auth-with-ldap). 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](authentication/mutual-tls/overview.md#kafka-ssl-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](authentication/sso-for-c3/configure-sso-using-oidc.md#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](authentication/sasl/gssapi/overview.md#kafka-sasl-auth-gssapi). 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](authentication/sasl/oauthbearer/overview.md#cp-oauth-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](authentication/sasl/oauthbearer/overview.md#cp-oauth-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](authentication/sasl/plain/overview.md#kafka-sasl-auth-plain). 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](authentication/sasl/scram/overview.md#kafka-sasl-auth-scram).
### Authorization mechanisms Authorization mechanisms are used to control access to resources in your Confluent Platform cluster. For details, see [Authorization](authorization/overview.md#authorization-overview).
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](authorization/acls/overview.md#acls-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](authorization/rbac/overview.md#rbac-overview).
### 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](protect-data/encrypt-tls.md#encrypt-tls).
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](protect-data/encrypt-tls.md#encrypt-tls).
### 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](authentication/ldap/overview.md#ldap-authentication-overview). 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](authentication/sso-for-c3/configure-sso-using-oidc.md#configure-sso-using-oidc).
## Security deployment profiles The following table defines the different security options that make up a security deployment profile for Confluent Platform clusters. The security options that make up a deployment profile are: - **Authentication** - **Kafka client**: Options for Kafka clients authenticating to Confluent Server brokers - **Kafka client to non-Kafka component**: Options for Kafka clients authenticating to Schema Registry, REST Proxy, and ksqlDB - **Service-to-service**: Options for authentication between any two Confluent Platform services, for example Schema Registry to Confluent Server, Connect to Schema Registry, and so forth - **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 Authorization Encryption Identity provider protocols
Kafka clients Client to non-Kafka component Service to service User
1 mTLS or SASL with one of:
  • PLAIN
  • GSSAPI
  • SCRAM
 mTLS mTLS HTTP Basic Authentication ACLs TLS
2 mTLS or SASL with one of:
  • GSSAPI
  • SCRAM
 GSSAPI or SCRAM mTLS HTTP Basic Authentication ACLs TLS
3 mTLS or SASL with one of:
  • PLAIN
  • PLAIN with LDAP server
  • GSSAPI
  • SCRAM
 HTTP Basic Authentication OAuthBearer (powered by LDAP and MDS-issued tokens) HTTP Basic Authentication RBAC TLS LDAP
4 mTLS or SASL with one of:
  • PLAIN
  • PLAIN with LDAP server
  • GSSAPI
  • SCRAM
 HTTP Basic Authentication OAuthBearer powered by LDAP and MDS-issued tokens OIDC (SSO) RBAC TLS Both OIDC and LDAP
5 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • PLAIN with LDAP server
  • GSSAPI
  • SCRAM
 HTTP Basic Authentication OAuthBearer with IdP-issued tokens OIDC (SSO) RBAC TLS Both OIDC and LDAP
6 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • GSSAPI
  • SCRAM
 mTLS mTLS HTTP Basic Authentication ACLs TLS OIDC
7 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • PLAIN with LDAP server
  • GSSAPI
  • SCRAM
 OAuthBearer with IdP-issued tokens or HTTP Basic Authentication OAuthBearer with IdP-issued tokens OIDC (SSO) RBAC TLS Both OIDC and LDAP
8 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • GSSAPI
  • SCRAM
 mTLS or OAuthBearer with IdP-issued tokens mTLS HTTP Basic Authentication ACLs TLS OIDC
9 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • GSSAPI
  • SCRAM
 OAuthBearer with IdP-issued tokens OAuth OIDC (SSO) RBAC TLS OIDC
10 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • GSSAPI
  • SCRAM
 OAuthBearer with IdP-issued tokens mTLS OIDC (SSO) RBAC TLS OIDC
11 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • GSSAPI
  • SCRAM
 mTLS mTLS OIDC (SSO) RBAC TLS OIDC
12 mTLS or SASL with one of:
  • OAUTHBEARER with IdP-issued tokens
  • PLAIN
  • GSSAPI
  • SCRAM
 mTLS mTLS Basic username, password (file-based user identity management) RBAC TLS Not applicable

You can also deploy Apache Flink® within the Confluent Platform. Deployments that include Flink make use of mTLS authentication with one of the following client to non-Kafka component: - PLAIN - GSSAPI - SCRAM Service to service and user authentication also use mTLS in Apache Flink® deployments. Authorization uses HTTP basic authentication with encryption through ACLS. TLS is the supported provider protocol for deployments that use Flink. ## Related content - [Mastering Kafka Security across Hybrid Environments with Confluent Platform](https://www.confluent.io/resources/online-talk/kafka-security-hybrid-environment/) - [Configure Security for Confluent Platform with Confluent for Kubernetes](https://docs.confluent.io/operator/current/co-security-overview.html) - [Configure Security for Confluent Platform with Ansible Playbooks](https://docs.confluent.io/ansible/current/ansible-security.html)