> ## Documentation Index > Fetch the complete documentation index at: https://docs.automq.com/llms.txt > Use this file to discover all available pages before exploring further. # SASL Authentication > AutoMQ enhances security with SASL authentication, providing Kafka API compatibility, cloud scalability, and cost-efficiency while supporting SASL_PLAINTEXT and SASL_SSL. Refer to [Overview▸](/automq-cloud/manage-security/overview), the AutoMQ data plane service is based on the Kafka API, providing SASL authentication functionality. This document introduces how to configure SASL authentication for an instance and provides client access examples. ## Enable SASL\_PLAINTEXT The SASL\_PLAINTEXT protocol allows users to upload access credentials through non-encrypted transmission. The server then performs authentication and verification, followed by ACL access control checks on the authenticated identities. The SASL\_PLAINTEXT protocol provided by AutoMQ supports the following authentication mechanisms: `PLAIN`, `SCRAM-SHA-256`, `SCRAM-SHA-512`. ### Step 1: Server Configuration 1. To use SASL\_PLAINTEXT, click **Advanced Options >> Enable the following parameters** when creating an instance. Refer to the interface in the figure below: * TransitEncryption option: **Enable Plaintext.** * Authentication Method: **Enable SASL authentication.**

2. After enabling SASL\_PLAINTEXT, access the instance details page to view the corresponding access point information.

3. After obtaining the access point, you need to create an ACL user and corresponding ACL permissions for the Kafka client. Subsequent clients will access the server using the ACL user credentials. For operation documentation, refer to [Manage Kafka ACLs▸](/automq-cloud/manage-security/manage-kafka-acls). ### Step 2: Client Configuration Kafka clients utilize the SASL\_PLAINTEXT protocol to connect to the server. Consult the Apache Kafka documentation for detailed examples and be sure to configure the following parameters. The username and password should correspond to the ACL user information you created earlier. Before connecting using SASL\_PLAINTEXT, ensure that the ACL user has been granted the necessary resource operation permissions. ```properties theme={null} # Configure SASL_PLAINTEXT security.protocol=SASL_PLAINTEXT # Configure Mechanism, Support PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 sasl.mechanism=SCRAM-SHA-512 # Configure the Jaas Config,set LoginModule,UserName,Password sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \ username="XXXX" \ password="XXXX"; ``` ## Enable SASL\_SSL The SASL\_SSL protocol facilitates the transmission of access credentials over a TLS-encrypted communication channel. This enables the server to perform identity authentication and verification. Once identities are successfully authenticated, they undergo ACL access control verification. To enable TLS transport encryption in an AutoMQ BYOC environment, users must provide a CA and server certificate, ensuring that the certificate matches the domain name. Additionally, users are required to periodically review the certificates to prevent service disruption due to expired certificates. ### Step 1: Create CA and Certificate If your organization cannot obtain certificates issued by a trusted CA, you can refer to the documentation below to self-sign and maintain a private CA and certificate. Furthermore, for production environments, it is recommended to manage CA and certificates using [AWS Private CA Product](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). 1. **Configure the CA signing policy file** `ca.cnf`. ```properties highlight={19-20} theme={null} [ ca ] default_ca = CA_AutoMQ_Default [ CA_AutoMQ_Default ] default_days = 3650 database = index.txt serial = serial.txt default_md = sha256 copy_extensions = copy unique_subject = no policy = signing_policy [ req ] prompt = no distinguished_name = distinguished_name x509_extensions = extensions [ distinguished_name ] organizationName = commonName = [ extensions ] keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyCertSign basicConstraints = critical,CA:true,pathlen:1 [ signing_policy ] organizationName = supplied commonName = optional ``` 2. **Generate the CA private key** `ca.key` and set file access permissions. ```bash theme={null} openssl genrsa -out ca.key 2048 chmod 400 ca.key ``` 3. **Generate the CA public certificate** `ca.crt`. ```bash theme={null} openssl req -new -x509 -config ca.cnf -key ca.key -days 3650 -batch -out ca.crt ``` The command above will generate the `ca.crt` file as the CA public certificate, which needs to be deployed to both AutoMQ instances and Kafka clients afterwards. 4. **Create the broker certificate configuration file** `broker.cnf`. The Broker in the AutoMQ BYOC environment provides record resolution services through a Private DNS Zone. Therefore, the SAN information needs to be consistent with the Zone domain name selected when creating the AutoMQ instance to ensure that domain name resolution and certificate matching pass. In general, it is recommended to directly fill in the Zone domain name for the certificate's DNS, for example, \*.your-private-zone-name. ```ini highlight={7,8,13} theme={null} [ req ] prompt = no distinguished_name = distinguished_name req_extensions = extensions [ distinguished_name ] organizationName = commonName = [ extensions ] subjectAltName = @alt_names [ alt_names ] DNS.1 = ``` 5. **Generate the broker's private key** `broker.key`. ```bash theme={null} openssl genrsa -out broker.key 2048 ``` 6. **Generate the Broker Certificate Signing Request (CSR)** `broker.csr`. ```bash theme={null} openssl req -new -key broker.key -out broker.csr -nodes -config broker.cnf ``` 7. **Use the previously mentioned CA private key to sign the CSR and generate the Broker certificate** `broker.crt`. ```bash theme={null} openssl x509 -req -CA ca.crt -CAkey ca.key -in broker.csr -out broker.crt -days 3650 -CAcreateserial -extensions extensions -extfile broker.cnf ``` The output file `broker.crt` is the signed Broker public certificate. It is recommended to set it as read-only. For subsequent deployment, the files `broker.crt`, `broker.key`, and `ca.crt` are needed. ### Step 2: Server Configuration 1. Using SASL\_SSL requires clicking on **Advanced Options >> Enable the following parameters** when creating the instance. Refer to the interface depicted in the diagram below: * TransitEncryption: **Enable TLS Encryption.** * Authentication Method: **Enable SASL authentication.** * Upload CA: Upload the CA certificate file obtained in the previous step, `ca.crt`. * Upload Server Cert: Upload the Broker certificate file obtained in the previous step, `broker.crt`. * Upload Private Key: Upload the private key file for the Broker certificate obtained in the previous step, `broker.key`.

2. After enabling SASL\_SSL, access the instance details page to view the endpoint information.