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 prevedi di utilizzare la configurazione di autorizzazione predefinita utilizzando Amazon Cognito, seleziona l'argomento corrispondente 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 utilizzare questa opzione se desideri creare un'identità IAM attraverso la quale autenticare gli utenti che chiamano il tuo gateway.

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 quando si crea il gateway.

Puoi utilizzare la AgentCore CLI per configurare un JWT predefinito o crearne uno manualmente con un provider di identità supportato. Per ulteriori informazioni sui diversi metodi di configurazione di un JWT, seleziona uno dei seguenti argomenti:

Configura un JWT predefinito

La AgentCore CLI ti consente di creare facilmente una configurazione di autorizzazione predefinita utilizzando Amazon Cognito che puoi poi utilizzare durante la creazione di un gateway. Quando eseguiagentcore create, la CLI ti richiede di configurare l'autorizzazione in entrata e può configurare automaticamente un pool di utenti Amazon Cognito per te.

agentcore create

Una volta completato il comando, la AgentCore CLI fornisce informazioni di autenticazione e autorizzazione:

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 compilerai CustomJWTAuthorizerConfigurationquando creerai un gateway, se applicabili al tuo caso d'uso:

Avrai bisogno di questi valori per effettuare le seguenti operazioni:

Ambita la 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 pubblicizza 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 nel gateway. CustomJWTAuthorizerConfiguration Il resource_metadata valore rimanda al documento OAuth Protected Resource Metadata del gateway/.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à privato () 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 the customJWTAuthorizer per consentire di AgentCore raggiungere i tuoi endpoint OIDC Discovery, Token e JWKS privati senza esporli alla rete Internet pubblica.

Il tuo responsabile IAM deve disporre dell'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 dall'URL di rilevamento), utilizza questa opzione per specificare una configurazione endpoint privata 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 Lattice autogestito, configurazioni tra account e configurazioni avanzate, consulta Connettiti a risorse private nel tuo VPC usando VPC Lattice. Per una guida completa sugli scenari IdP privati in entrata e in uscita, consulta Connect to private identity provider.

Autorizzazione in entrata scaricata

Con l'autorizzazione in entrata offloaded, 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 applicare effettivamente 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 confermare la sua 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 viene 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 entrata e la richiesta può essere non autenticata.

Migliori pratiche di sicurezza

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

Quando abbini 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 su un gateway può essere semplice: basta impostare un endpoint override sul client esistente, senza che siano necessarie modifiche di autenticazione: