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à.

Configura l'autorizzazione in entrata per il tuo gateway

Prima di creare il gateway, è necessario configurare l'autorizzazione in entrata. L'autorizzazione in entrata convalida gli utenti che tentano di accedere alle destinazioni tramite il gateway. AgentCore AgentCore supporta i seguenti tipi di autorizzazione in entrata:

Se non intendi utilizzare la configurazione di autorizzazione predefinita utilizzando Amazon Cognito, seleziona l'argomento che corrisponde al tipo di autorizzazione che intendi utilizzare per scoprire come configurarla:

IAM-based autorizzazione in entrata

IAM-based l'autorizzazione in entrata consente di utilizzare le credenziali IAM del chiamante del gateway per l'autorizzazione. Puoi usare questa opzione se desideri creare un'identità IAM tramite la quale gli utenti che chiamano il tuo gateway possano essere autenticati.

Per configurare l'autorizzazione IAM-based in entrata

Policy di esempio

L'esempio seguente mostra una policy che è possibile allegare a un'identità per consentirle di richiamare un gateway con l'ID my-gateway-12345

{
"Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGatewayInvocation",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:InvokeGateway"
      ],
      "Resource": [
        "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway-12345"
      ]
    }
  ]
}

Risorse

Autorizzazione in entrata basata su JSON Web Token (JWT)

Un JSON Web Token (JWT) è un token sicuro e compatto utilizzato per l'autorizzazione. È possibile creare un JWT con un provider di identità supportato. Dopo aver creato un JWT, è possibile recuperarlo e specificarlo come configurazione di autorizzazione al momento della creazione del gateway.

È possibile utilizzare la AgentCore CLI per configurare un gateway con un provider di identità JWT esistente. Per saperne di più sui metodi di configurazione JWT, seleziona uno dei seguenti argomenti:

Configura un autorizzatore JWT

Crea un'applicazione e un client con un provider di identità supportato. Per un esempio di Amazon Cognito, consulta Guida introduttiva ad Amazon Cognito. Annota l'URL di rilevamento OIDC e l'ID del cliente.

Eseguite il comando seguente in una directory AgentCore del progetto:

agentcore add gateway \
  --name MyGateway \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --discovery-url <OIDC_DISCOVERY_URL> \
  --allowed-clients <CLIENT_ID>

La AgentCore CLI utilizza la configurazione OIDC esistente; non crea le risorse del provider di identità. Per richiamare il gateway, richiedete un token di accesso dal vostro provider. Per Amazon Cognito, consulta The token issuer endpoint nella Amazon Cognito Developer Guide.

Configura un JWT manualmente

Amazon Bedrock AgentCore supporta i JWT di tutti i provider di identità. Puoi vedere alcuni esempi in Configurazione e configurazione del provider.

Nel processo di creazione del JWT, prendi nota dei seguenti valori, che inserirai CustomJWTAuthorizerConfiguration quando crei un gateway, se sono applicabili al tuo caso d'uso:

Questi valori ti serviranno per effettuare le seguenti operazioni:

Ambito della pubblicità nelle sfide di autenticazione

Quando un client invia una richiesta a un JWT-authorized gateway senza un token di accesso valido, il gateway restituisce una risposta di errore con un'WWW-Authenticateintestazione che annuncia gli ambiti OAuth richiesti. Questo segue il formato RFC 6750 Bearer token challenge e consente MCP-compliant ai client di scoprire automaticamente gli ambiti necessari per l'acquisizione dei token.

Il gateway restituisce le seguenti risposte a seconda dell'errore:

Il scope valore contiene gli ambiti delimitati da spazi configurati come ambiti consentiti in quelli del gateway. CustomJWTAuthorizerConfiguration Il resource_metadata valore rimanda al documento OAuth Protected Resource Metadata del gateway all'indirizzo/.well-known/oauth-protected-resource, che i client possono recuperare per scoprire il server di autorizzazione e gli ambiti supportati.

Utilizza un provider di identità private () VPC-hosted

AgentCore Gateway supporta l'autorizzazione JWT-based in entrata con provider di identità ospitati all'interno del tuo VPC. Puoi configurare un privateEndpoint on customJWTAuthorizer per consentire di AgentCore raggiungere i tuoi endpoint privati di rilevamento OIDC, token e JWKS senza esporli alla rete Internet pubblica.

Il tuo responsabile IAM deve avere l'iam:CreateServiceLinkedRoleautorizzazione peridentity-network.bedrock-agentcore.amazonaws.com, in modo che AgentCore Identity possa creare il ruolo AWSServiceRoleForBedrockAgentCoreIdentity collegato al servizio per tuo conto, se non esiste già.

privateEndpointSi applica al dominio in. discoveryUrl Se il tuo provider di identità utilizza domini diversi per altri endpoint (ad esempio, il token o l'endpoint JWKS si risolve in un dominio diverso rispetto all'URL di scoperta), usa per specificare una configurazione dell'endpoint privato separata privateEndpointOverrides per ogni dominio aggiuntivo.

L'esempio seguente crea un gateway con un provider di identità privato utilizzando Lattice gestito:

{
  "name": "my-private-idp-gateway",
  "protocolType": "MCP",
  "roleArn": "arn:aws:iam::123456789012:role/my-gateway-role",
  "authorizerType": "CUSTOM_JWT",
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": [
        "my-audience"
      ],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "managedVpcResource": {
          "vpcIdentifier": "vpc-0abc123def456",
          "subnetIds": ["subnet-0abc123", "subnet-0def456"],
          "endpointIpAddressType": "IPV4",
          "securityGroupIds": ["sg-0abc123def"]
        }
      }
    }
  }
}

Se il token o gli endpoint JWKS utilizzano un dominio diverso dall'URL di scoperta, aggiungi una privateEndpointOverrides voce per ogni dominio aggiuntivo. Attualmente, privateEndpointOverrides è supportato solo con risorse Lattice autogestite:

{
  ...
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": ["my-audience"],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "selfManagedLatticeResource": {
          "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123"
        }
      },
      "privateEndpointOverrides": [
        {
          "domain": "my-token-server.internal.example.com",
          "privateEndpoint": {
            "selfManagedLatticeResource": {
              "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-def456"
            }
          }
        }
      ]
    }
  }
}

Per le configurazioni Lattice autogestite, per più account e le configurazioni avanzate, vedi Connessione a risorse private nel tuo VPC utilizzando VPC Lattice. Per una guida completa che copre gli scenari di IdP privati in entrata e in uscita, consulta Connessione a provider di identità privati. Connettiti a provider di identità privati

Autorizzazione in entrata non caricata

Con l'autorizzazione in entrata offload, il gateway non prende alcuna decisione di autorizzazione autonomamente. Invece, trasferisce l'autorizzazione a un altro componente:

AgentCore offre due tipi di offload:

Con entrambi i tipi, sei tu a decidere dove viene effettivamente applicata l'autorizzazione:

Authenticate-only autorizzazione

Con l'autorizzazione di sola autenticazione (AUTHENTICATE_ONLY), il gateway verifica la firma Signature Version 4 (Sigv4) del chiamante per confermarne l'identità, ma non prende alcuna decisione di autorizzazione autonoma. Qualsiasi principale IAM autenticato può richiamare il gateway indipendentemente dalle proprie autorizzazioni e la richiesta viene inoltrata alla destinazione. L'autorizzazione è delegata al servizio di destinazione a valle o a un motore di policy collegato al gateway.

Nessuna autorizzazione

È possibile creare un gateway configurato senza autorizzazione utilizzandoauthorizerType=NONE. Il gateway non eseguirà alcuna autorizzazione sulla richiesta del gateway in ingresso e la richiesta può non essere autenticata.

Best practice in materia di sicurezza

Effettua l'onboarding di un runtime esistente senza modificarne l'autenticazione

Quando si associa un tipo di autorizzazione in entrata non caricato a un tipo di autorizzazione in uscita corrispondente che inoltra l'identità del chiamante al runtime, l'onboarding a un gateway può essere semplice: basta impostare un endpoint override sul client esistente, senza richiedere modifiche all'autenticazione: