Configuración de métodos de autenticación de clústeres 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.
Métodos de autenticación del clúster
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), 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 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 firmados por CA de Amazon Trust Services
El secreto CLIENT_CERTIFICATE_TLS_AUTH 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
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----- <certificate contents> -----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 #8
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Para una clave privada cifrada, utilice la siguiente estructura:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----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 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 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 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.
Cómo Lambda elige un agente de arranque
Lambda elige un agente de arranque 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.
