Configurazione del cluster Amazon MSK e della rete Amazon VPC per Lambda

Per connettere la tua AWS Lambda funzione al cluster Amazon MSK, devi configurare correttamente il cluster e l'Amazon Virtual Private Cloud (VPC) in cui risiede. Questa pagina descrive come configurare il cluster e il VPC. Se il cluster e il VPC sono già configurati correttamente, consulta Configurazione delle origini eventi di Amazon MSK per Lambda Configurare la mappatura delle sorgenti degli eventi.

Panoramica dei requisiti di configurazione di rete per le integrazioni Lambda e MSK

La configurazione di rete richiesta per un'integrazione Lambda e MSK dipende dall'architettura di rete dell'applicazione. Ci sono tre risorse principali coinvolte in questa integrazione: il cluster Amazon MSK, la funzione Lambda e la mappatura delle sorgenti degli eventi Lambda. Ognuna di queste risorse risiede in un VPC diverso:

La mappatura dell'origine degli eventi è la risorsa intermedia tra il cluster MSK e la funzione Lambda. La mappatura delle sorgenti degli eventi ha due funzioni principali. Innanzitutto, esegue il polling del cluster MSK per verificare la presenza di nuovi messaggi. Quindi, richiama la funzione Lambda con quei messaggi. Poiché queste tre risorse sono diverse VPCs, sia le operazioni di poll che quelle di invoke richiedono chiamate di rete tra VPC.

I requisiti di configurazione di rete per la mappatura delle sorgenti degli eventi dipendono dal fatto che venga utilizzata la modalità provisioning o la modalità on-demand, come illustrato nel diagramma seguente:

Il modo in cui la mappatura delle sorgenti degli eventi Lambda analizza il cluster MSK alla ricerca di nuovi messaggi è lo stesso in entrambe le modalità. Per stabilire una connessione tra la mappatura delle sorgenti degli eventi e il cluster MSK, Lambda crea un ENI iperpiano (o ne riutilizza uno esistente, se disponibile) nella sottorete privata per stabilire una connessione sicura. Come illustrato nel diagramma, questo ENI iperpiano utilizza la configurazione della sottorete e del gruppo di sicurezza del cluster MSK, non la funzione Lambda.

Dopo aver analizzato il messaggio dal cluster, il modo in cui Lambda richiama la funzione è diverso in ciascuna modalità:

Un gateway NAT consente alle risorse della sottorete privata di accedere alla rete Internet pubblica. L'utilizzo di questa configurazione significa che il traffico attraversa Internet prima di richiamare la funzione Lambda. AWS PrivateLink gli endpoint consentono alle sottoreti private di connettersi in modo sicuro ai AWS servizi o ad altre risorse VPC private senza attraversare la rete Internet pubblica. Vedi Configurazione di un gateway NAT per un'origine di eventi MSK o Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK per i dettagli su come configurare queste risorse.

Finora, abbiamo dato per scontato che il cluster MSK risieda in una sottorete privata all'interno del VPC, che è il caso più comune. Tuttavia, anche se il cluster MSK si trova in una sottorete pubblica all'interno del VPC, è necessario configurare gli AWS PrivateLink endpoint per abilitare una connessione sicura. La tabella seguente riassume i requisiti di configurazione della rete in base a come si configura il cluster MSK e la mappatura delle sorgenti degli eventi Lambda:

Inoltre, i gruppi di sicurezza associati al cluster MSK devono consentire il traffico sulle porte corrette. Assicuratevi di aver configurato le seguenti regole per i gruppi di sicurezza:

Configurazione di un gateway NAT per un'origine di eventi MSK

Puoi configurare un gateway NAT per consentire alla mappatura della fonte degli eventi di interrogare i messaggi dal cluster e richiamare la funzione tramite un percorso attraverso il tuo VPC. Questo è necessario solo se la mappatura delle sorgenti degli eventi utilizza la modalità on demand e il cluster risiede all'interno di una sottorete privata del VPC. Se il cluster risiede in una sottorete pubblica del VPC o la mappatura delle sorgenti degli eventi utilizza la modalità provisioning, non è necessario configurare un gateway NAT.

Un gateway NAT consente alle risorse di una sottorete privata di accedere alla rete Internet pubblica. Se hai bisogno di connettività privata a Lambda, vedi Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK invece.

Dopo aver configurato il gateway NAT, è necessario configurare le tabelle di routing appropriate. Ciò consente al traffico proveniente dalla sottorete privata di indirizzarsi verso la rete Internet pubblica tramite il gateway NAT.

I seguenti passaggi guidano l'utente nella configurazione di un gateway NAT utilizzando la console. Ripetere questi passaggi se necessario per ogni zona di disponibilità (AZ).

Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK

Puoi configurare gli AWS PrivateLink endpoint per eseguire il polling dei messaggi dal tuo cluster e richiamare la funzione tramite un percorso attraverso il tuo VPC. Questi endpoint dovrebbero consentire al cluster MSK di accedere a quanto segue:

La configurazione PrivateLink degli endpoint è necessaria solo se la mappatura delle sorgenti degli eventi utilizza la modalità on-demand. Se la mappatura delle sorgenti degli eventi utilizza la modalità provisioned, Lambda stabilisce automaticamente le connessioni necessarie.

PrivateLink gli endpoint consentono un accesso sicuro e privato ai servizi tramite. AWS AWS PrivateLink In alternativa, per configurare un gateway NAT per consentire al cluster MSK di accedere alla rete Internet pubblica, vedere. Configurazione di un gateway NAT per un'origine di eventi MSK

Dopo aver configurato gli endpoint VPC, il cluster MSK dovrebbe avere accesso diretto e privato a Lambda, STS e, facoltativamente, a Secrets Manager.

I seguenti passaggi guidano l'utente nella configurazione di un endpoint utilizzando la console. PrivateLink Ripetere questi passaggi se necessario per ogni endpoint (Lambda, STS, Secrets Manager).

Per impostazione predefinita, gli endpoint Amazon VPC dispongono di policy IAM aperte che consentono un ampio accesso alle risorse. La best practice consiste nel limitare queste policy per eseguire le azioni necessarie utilizzando quell'endpoint. Ad esempio, per l'endpoint Secrets Manager, è possibile modificarne la policy in modo che solo il ruolo di esecuzione della funzione possa accedere al segreto.

{
    "Statement": [
        {
            "Action": "secretsmanager:GetSecretValue",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws::iam::123456789012:role/my-role"
                ]
            },
            "Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
        }
    ]
}

Per gli endpoint AWS STS e Lambda, puoi limitare il principale chiamante al principale del servizio Lambda. Tuttavia, assicurati di utilizzarlo "Resource": "*" in queste politiche.

{
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "lambda.amazonaws.com"
                ]
            },
            "Resource": "*"
        }
    ]
} 

{
    "Statement": [
        {
            "Action": "lambda:InvokeFunction",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "lambda.amazonaws.com"
                ]
            },
            "Resource": "*"
        }
    ]
}