# Configuración de métodos de autenticación de clústeres de Amazon MSK en Lambda
Lambda necesita permiso para acceder a su clúster de Amazon MSK, recuperar registros y llevar a cabo otras tareas. Amazon MSK admite varios métodos para autenticarse con su clúster de MSK.
**Topics**
+ [Acceso sin autenticar](#msk-unauthenticated)
+ [Autenticación SASL/SCRAM](#msk-sasl-scram)
+ [Autenticación TLS mutua](#msk-mtls)
+ [Autenticación de IAM](#msk-iam-auth)
+ [Cómo Lambda elige un agente de arranque](#msk-bootstrap-brokers)
## Acceso sin autenticar
Si ningún cliente accede al clúster a través de Internet, puede utilizar el acceso no autenticado.
## Autenticación SASL/SCRAM
Lambda admite [autenticación simple y autenticación de capa de seguridad/mecanismo de autenticación de respuesta por desafío saltado (SASL/SCRAM)](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html), con cifrado de seguridad de la capa de transporte (TLS) y la función hash SHA-512. Para que Lambda se conecte al clúster, las credenciales de autenticación (nombre de usuario y contraseña) se almacenan en un secreto de Secrets Manager. Haga referencia a este secreto al configurar la asignación de orígenes de eventos.
Para obtener más información sobre Secrets Manager, consulte [Sign-in credentials authentication with Secrets Manager](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html) en la *Guía para desarrolladores de Amazon Managed Streaming para Apache Kafka*.
**nota**
Amazon MSK no admite la autenticación SASL/PLAIN.
## Autenticación TLS mutua
TLS mutua (mTLS) proporciona autenticación bidireccional entre el cliente y el servidor. El cliente envía un certificado al servidor para que el servidor verifique el cliente. El servidor también envía un certificado al cliente para que el cliente verifique el servidor.
Para las integraciones de Amazon MSK con Lambda, el clúster de MSK actúa como servidor y Lambda actúa como cliente.
+ Para que Lambda verifique el clúster de MSK, configure un certificado de cliente como secreto en Secrets Manager y haga referencia a este certificado en la configuración de asignación de orígenes de eventos. El certificado de servidor debe estar firmado por una entidad de certificación que esté en el almacén de confianza del servidor.
+ El clúster de MSK también envía un certificado de servidor a Lambda. El certificado de servidor debe estar firmado por una entidad de certificación que esté en el almacén de confianza de AWS.
Amazon MSK no admite certificados de servidor autofirmados. Todos los agentes de Amazon MSK utilizan [certificados públicos](https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html) firmados por [CA de Amazon Trust Services](https://www.amazontrust.com/repository/), en los que Lambda confía de forma predeterminada.
### Configuración del secreto de mTLS
El secreto CLIENT\$1CERTIFICATE\$1TLS\$1AUTH requiere un campo de certificado y un campo de clave privada. Para una clave privada cifrada, el secreto requiere una contraseña de clave privada. El certificado y la clave privada deben estar en formato PEM.
**nota**
Lambda admite los algoritmos de cifrado de claves privadas [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1) (pero no PBES2).
El campo de certificado debe contener una lista de certificados y debe comenzar por el certificado de cliente, seguido de cualquier certificado intermedio, y finalizar con el certificado raíz. Cada certificado debe comenzar en una nueva línea con la siguiente estructura:
```
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
```
Secrets Manager admite secretos de hasta 65 536 bytes, que supone suficiente espacio para cadenas de certificados largas.
El formato de la clave privada debe ser [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208), con la siguiente estructura:
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Para una clave privada cifrada, utilice la siguiente estructura:
```
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
```
El siguiente ejemplo muestra el contenido de un secreto para la autenticación de mTLS mediante una clave privada cifrada. Para una clave privada cifrada, incluya la contraseña de la clave privada en el secreto.
```
{
"privateKeyPassword": "testpassword",
"certificate": "-----BEGIN CERTIFICATE-----
MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw
...
j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk
cmUuiAii9R0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb
...
rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no
c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg==
-----END CERTIFICATE-----",
"privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp
...
QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ
zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA==
-----END ENCRYPTED PRIVATE KEY-----"
}
```
Para obtener más información sobre mTLS para Amazon MSK e instrucciones sobre cómo generar un certificado de cliente, consulte [Mutual TLS client authentication for Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) en la *Guía para desarrolladores de Amazon Managed Streaming para Apache Kafka*.
## Autenticación de IAM
Puede utilizar AWS Identity and Access Management (IAM) para autenticar la identidad de los clientes que se conectan al clúster de MSK. Con la autenticación de IAM, Lambda confía en los permisos del [rol de ejecución](lambda-intro-execution-role.md) de la función para conectarse al clúster, recuperar registros y llevar a cabo otras acciones necesarias. Para ver un ejemplo de política que contenga los permisos necesarios, consulte [Create authorization policies for the IAM role](https://docs.aws.amazon.com/msk/latest/developerguide/create-iam-access-control-policies.html) en la *Guía para desarrolladores de Amazon Managed Streaming para Apache Kafka*.
Si la autenticación de IAM está activa en el clúster de MSK y no proporciona ningún secreto, Lambda utilizará de forma automática la autenticación de IAM.
Para obtener más información acerca de la autenticación de IAM en Amazon MSK, consulte [IAM access control](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html).
## Cómo Lambda elige un agente de arranque
Lambda elige un [agente de arranque](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) en función de los métodos de autenticación disponibles en el clúster y de si proporciona un secreto para la autenticación. Si proporciona un secreto para mTLS o SASL/SCRAM, Lambda elige de forma automática ese método de autenticación. Si no proporciona ningún secreto, Lambda selecciona el método de autenticación más seguro que esté activo en el clúster. El siguiente es el orden de prioridad en el que Lambda selecciona un agente, de la autenticación más segura a la menos segura:
+ mTLS (secreto proporcionado para mTLS)
+ SASL/SCRAM (secreto proporcionado para SASL/SCRAM)
+ SASL IAM (no se proporciona secreto y la autenticación de IAM está activa)
+ TLS no autenticada (no se proporciona secreto y la autenticación de IAM no está activa)
+ Texto sin formato (no se proporciona secreto y tanto la autenticación de IAM como la TLS no autenticada no están activas)
**nota**
Si Lambda no puede conectarse al tipo de agente más seguro, no intentará conectarse a un tipo de agente diferente (menos seguro). Si quiere que Lambda elija un tipo de agente más débil, desactive todos los métodos de autenticación más seguros del clúster.