Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Autorizzazioni per la funzione Web Lambda

Lambda Web Functions utilizza AWS Identity and Access Management (IAM) per controllare cosa può fare il codice dell'applicazione (il ruolo di esecuzione) e chi può accedere alla funzione Web (politiche basate sulle risorse). Questa pagina spiega come configurare ogni tipo.

Il diagramma seguente mostra le identità che richiedono le autorizzazioni e ciò che ciascuna utilizza. Il deployer richiama le azioni e le iam:PassRole esigenze di gestione Lambda sul ruolo di esecuzione. L'uploader del codice deve avere s3:PutObject una versione del bucket Amazon S3 e Lambda legge la versione dell'oggetto di codice. Lambda può crittografare il codice di Web Function e le variabili di ambiente con una chiave opzionale gestita dal cliente. AWS KMS Il codice viene eseguito con il ruolo di esecuzione, che garantisce l'accesso ad Amazon CloudWatch Logs e alle tue dipendenze. Un chiamante deve disporre di un endpoint o di credenziali applicative lambda:InvokeWebFunctionEndpoint per un IamAuth endpoint. ApplicationManaged

Ruolo di esecuzione

Il ruolo di esecuzione è un ruolo IAM che Lambda assume quando esegue il codice Web Function. L'applicazione utilizza le autorizzazioni di questo ruolo per interagire con altri servizi. AWS Come minimo, la tua funzione Web necessita dell'autorizzazione per scrivere log su Amazon CloudWatch Logs in modo da poter monitorare la tua applicazione. Se la tua applicazione legge da DynamoDB, scrive su Amazon S3 o chiama AWS altri servizi, aggiungi tali autorizzazioni al ruolo di esecuzione.

Creazione di un ruolo di esecuzione

Per creare un ruolo di esecuzione per la tua funzione Web, crea un ruolo IAM con una policy di fiducia che consenta al responsabile del servizio Lambda di assumerlo e allega una policy di autorizzazioni che garantisca l'accesso di cui ha bisogno l'applicazione.

Se preferisci creare una politica di autorizzazioni personalizzata anziché utilizzare la politica gestita, le autorizzazioni minime necessarie alla funzione Web per la registrazione sono:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:111122223333:log-group:/aws/lambda/web/my-web-app:*",
                "arn:aws:logs:*:111122223333:log-group:/aws/lambda/web/my-web-app.local:*"
            ]
        }
    ]
}

La politica copre due gruppi di log. Lambda scrive i log interni alla regione nel gruppo di .local log e quindi li centralizza nel gruppo di log senza il suffisso nella regione principale. L'ARN del gruppo di log centralizzato utilizza la home Region. L'.localARN utilizza un jolly Region perché Lambda scrive su quel gruppo in ogni regione in cui un endpoint serve il traffico. Ciò consente a un ruolo di esecuzione di supportare endpoint con set di regioni diversi. Se il ruolo non è in grado di scrivere nel gruppo di .local log in una regione, Lambda non fornisce i log da quella regione. Se utilizzi un gruppo di log personalizzato, sostituisci entrambi gli ARN con il nome del gruppo di log e il nome del gruppo di log seguito da. .local Per ulteriori informazioni, consulta Gruppi di log.

Aggiungere autorizzazioni per altri servizi

Se l'applicazione accede ad altri AWS servizi, aggiungi le autorizzazioni corrispondenti al ruolo di esecuzione. L'esempio seguente aggiunge l'accesso in lettura a una tabella DynamoDB e l'accesso in scrittura a un bucket Amazon S3.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:111122223333:log-group:/aws/lambda/web/my-web-app:*",
                "arn:aws:logs:*:111122223333:log-group:/aws/lambda/web/my-web-app.local:*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:Query"
            ],
            "Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/my-table"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::my-output-bucket/*"
        }
    ]
}

L'identità IAM che crea una funzione Web o una revisione utilizza le proprie autorizzazioni, non il ruolo di esecuzione. Tale identità richiede lambda:CreateWebFunction olambda:CreateWebFunctionRevision, iam:PassRole in base al ruolo di esecuzione, l'accesso in lettura al pacchetto di distribuzione in Amazon S3. Per le autorizzazioni di Amazon S3, consulta. Autorizzazioni del chiamante Se utilizzi una chiave gestita dal cliente per crittografare il codice di Web Function e le variabili di ambiente, anche quell'identità necessita di autorizzazioni. AWS KMS Per ulteriori informazioni, consulta Crittografia a riposo per Web Functions.

Resource-based politiche

Una politica basata sulle risorse è un documento di policy JSON che alleghi alla tua funzione Web. Può concedere qualsiasi azione di Web Function ad eccezione lambda:CreateWebFunction dei principali o dei servizi IAM. AWS Ad esempio, può concedere lambda:InvokeWebFunctionEndpoint per un IamAuth endpoint. Può anche concedere azioni di gestione come lambda:GetWebFunctionlambda:CreateWebFunctionRevision, elambda:UpdateWebFunctionEndpoint.

L'allegato alla policy e le relative dichiarazioni utilizzano ARN di risorse diversi:

Per un responsabile IAM nello stesso account, possono concedere l'autorizzazione sia la politica basata sull'identità del principale che la politica basata sulle risorse della funzione Web. Per un principale IAM in un altro account, entrambe le policy devono concedere l'autorizzazione. Questo vale sia per le azioni di invoca che per quelle di gestione.

Per consentire o negare azioni basate sui tag di una funzione Web, utilizza il controllo degli accessi basato sugli attributi (ABAC). Per le chiavi di condizione supportate, vedere. Etichettatura delle funzioni Web

Utilizza politiche basate sulle risorse quando:

Le politiche pubbliche non sono consentite

Non è possibile allegare una politica basata su risorse pubbliche a una funzione Web. Se una policy è pubblica, la richiesta ha esito negativo con un. ValidationException

In questa sezione, public descrive una politica che concede l'accesso a un insieme non specificato di principi. Non descrive l'accessibilità della rete o il tipo di autenticazione dell'endpoint.

Cosa rende pubblica una policy

Una policy è pubblica a meno che non limiti chi può richiamare la risorsa a un insieme ben specificato di principi. Lambda presuppone che la policy sia pubblica e quindi valuta se si qualifica come non pubblica. Una politica è pubblica se consente un principio che qualsiasi cliente potrebbe assumere. AWS Il caso più comune è l'utilizzo di caratteri jolly senza restrizioni, come nell'esempio seguente. Lambda rifiuta questa politica con un. ValidationException Non usarla.

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "lambda:InvokeWebFunctionEndpoint",
  "Resource": "arn:aws:lambda:us-west-2:123456789012:web-function/my-web-function/endpoint/prod"
}

Le seguenti restrizioni non rendono una politica non pubblica:

Esistono due modi per rendere una policy non pubblica.

Specificare i principali nel blocco Principal

Elenca uno o più principi completamente specificati nel Principal blocco. I valori non devono contenere caratteri jolly o variabili di policy. Il numero di principali non ha importanza.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "123456789012",
      "111122223333"
    ]
  },
  "Action": "lambda:InvokeWebFunctionEndpoint",
  "Resource": "arn:aws:lambda:us-west-2:123456789012:web-function/my-web-function/endpoint/prod"
}

Un principale IAM in un altro account necessita inoltre di un'autorizzazione basata sull'identità per richiamare l'endpoint.

Utilizza una chiave di condizione affidabile

Vincola una delle seguenti chiavi di condizione a un valore fisso. Queste chiavi identificano il chiamante autenticato e non possono essere impostate dal richiedente.

La sola denominazione di una chiave affidabile non è sufficiente. È inoltre necessario vincolare il valore:

La seguente politica concede ai responsabili dell'organizzazione l'autorizzazione basata sulle risorse necessaria per richiamare l'endpoint e non è considerata pubblica. Anche un preside IAM di un altro account necessita di un'autorizzazione basata sull'identità.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOrgAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "lambda:InvokeWebFunctionEndpoint",
      "Resource": "arn:aws:lambda:us-west-2:123456789012:web-function/my-web-function/endpoint/prod",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-a1b2c3d4e5"
        }
      }
    }
  ]
}

Cross-account accesso

La seguente politica basata sulle risorse concede a un ruolo IAM specifico in un altro account l'autorizzazione a richiamare un endpoint della tua funzione Web. Il ruolo necessita inoltre di un'autorizzazione basata sull'identità per richiamare l'endpoint.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCrossAccountInvoke",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::444455556666:role/caller-role"
            },
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod"
        }
    ]
}

Affinché la chiamata tra più account abbia esito positivo, devono essere soddisfatte tutte le seguenti condizioni:

Concessione dell'accesso a un AWS service

La seguente politica basata sulle risorse concede al CloudFront servizio l'autorizzazione principale a richiamare la funzione Web. Utilizzate questa politica quando configurate una CloudFront distribuzione con l'endpoint Web Function come origine.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontInvoke",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
                }
            }
        }
    ]
}

La aws:SourceArn condizione limita l'accesso a una distribuzione specifica CloudFront. Senza questa condizione, qualsiasi CloudFront distribuzione in qualsiasi account potrebbe richiamare la tua funzione Web.

Replica ed eventuale coerenza

Quando si allega o si aggiorna una policy basata sulle risorse su una funzione Web che dispone MultiRegiondei nostri PerRegionendpoint, Lambda replica la policy su tutte le repliche in cui operano gli endpoint. Regioni AWS Questa replica alla fine è coerente.

Durante la finestra di replica, Lambda potrebbe valutare le richieste nelle regioni di replica rispetto alla versione precedente della policy. Ciò significa che:

Non esiste alcun segnale di completamento visibile al cliente per la replica delle policy. Verifica il comportamento di autorizzazione o negazione previsto in ogni regione degli endpoint prima di affidarti alla nuova policy. Per il contenimento delle emergenze, aggiorna il routing del traffico o imposta gli endpoint in modo che blocchino tutto il traffico mentre throttleConfig.rateLimit si 0 propaga la modifica delle policy. Per ulteriori informazioni, consulta Throttling.

Per gli HomeRegionendpoint, la policy si applica solo nella regione di origine e non richiede la replica tra regioni. Una modifica può comunque richiedere poco tempo prima che diventi effettiva.

Autorizzazioni per la configurazione della rete

L'identità che configura la rete necessita dell'autorizzazione per creare o aggiornare le risorse Lambda pertinenti. È inoltre necessaria l'autorizzazione per passare i ruoli e il connettore richiesti. A seconda dell'operazione, le autorizzazioni includono:

Il chiamante deve avere lambda:PassNetworkConnector sul connettore di riferimento ogni volta che viene impostata una chiamata create-web-function ocreate-web-function-revision. egressNetworkConnectorArn Ambita questa autorizzazione alle risorse del connettore approvate. Ambito iam:PassRole ai ruoli di esecuzione approvati, che vengono assegnati quando si crea una funzione Web o una revisione, e ai ruoli di operatore approvati, che vengono assegnati quando si crea o si aggiorna un connettore di rete. Per la politica di autorizzazione dei ruoli di operatore, vedere. Autorizzazioni per il ruolo di operatore