Connect zu privaten Identitätsanbietern her
Amazon Bedrock AgentCore Identity unterstützt die Verbindung zu OAuth 2.0-Identitätsanbietern (IdPs), die in Ihrer AWS VPC gehostet werden, wie z. B. selbst gehosteten Keycloak, oder anderen OIDC-compliant Autorisierungsservern PingFederate, ohne diese dem öffentlichen Internet auszusetzen. Auf diese Weise können Sie Private sowohl IdPs für die eingehende JWT-Autorisierung mit AgentCore Runtime und Gateway als auch für ausgehende OAuth2-Anmeldeinformationen verwenden. AgentCore
Die private Konnektivität zu einer gehosteten VPC IdPs wird mithilfe von Amazon VPC Lattice-Ressourcen-Gateways und Ressourcenkonfigurationen hergestellt, wobei dasselbe Muster verwendet wird, das für den Gateway-VPC-Ausgang verwendet wirdAgentCore . AgentCore Identity verwendet die AWSServiceRoleForBedrockAgentCoreIdentity serviceverknüpfte Rolle, um VPC-Lattice-Ressourcen in Ihrem Konto für private Konnektivität mit Ihren IdP-Endpunkten zu erstellen und zu verwalten.
Wichtig
AgentCore unterstützt zwei VPC-Lattice-Konnektivitätsmodi: Managed Lattice (einfacher, AgentCore verwaltet den Ressourcenlebenszyklus) und selbstverwaltetes Lattice (erweitert, mit kontenübergreifender Unterstützung und vollständiger Governance-Transparenz). Jeder Modus hat unterschiedliche Kompromisse in Bezug auf Komplexität, Kosten und Kontrolle. Einen detaillierten Vergleich mit Vor- und Nachteilen finden Sie unter Unterstützte VPC-Ausgangsmodi.
Anwendungsfälle
Private Identitätsanbieter sind in Unternehmensumgebungen üblich, in denen Unternehmen:
-
Führen Sie selbst gehostete Autorisierungsserver in ihrer VPC aus, um Compliance- oder Datenresidenzanforderungen zu erfüllen
-
Verwenden Sie private OIDC-Discovery-Endpunkte, die nicht öffentlich zugänglich sind
-
Erfordern Sie, dass der gesamte Authentifizierungsverkehr im AWS Netzwerk bleibt, ohne das öffentliche Internet zu durchqueren
Eingehende JWT-Autorisierung mit einem privaten IdP
Wenn Sie die eingehende JWT-Autorisierung für AgentCore Runtime oder AgentCore Gateway konfigurieren, verwendet der Autorisierer die Discovery-URL, um die öffentlichen Schlüssel (JWKS) des IdP abzurufen und eingehende JWT-Token zu validieren. Wenn Ihr IdP in einer VPC gehostet wird und die Discovery-URL nicht öffentlich zugänglich ist, müssen Sie einen privaten Endpunkt konfigurieren, damit AgentCore Identity die OIDC-Discovery- und JWKS-Endpunkte des IdP erreichen kann.
Konfigurieren Sie die eingehende Autorisierung mit einem privaten IdP
Um die eingehende JWT-Autorisierung mit einem privaten IdP zu konfigurieren, nehmen Sie den privateEndpoint Block bei der Erstellung oder Aktualisierung Ihrer Runtime oder Ihres AgentCore Gateways in die Autorisierungskonfiguration auf.
Beispiel: CreateAgentRuntime mit privatem IdP für eingehende Authentifizierung
{ "agentRuntimeName": "my-runtime", "authorizerConfiguration": { "customJWTAuthorizer": { "discoveryUrl": "https://idp.internal.example.com/.well-known/openid-configuration", "allowedAudiences": [ "my-agent-audience" ], "allowedClients": [ "my-client-id" ], "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0abc123def456", "subnetIds": [ "subnet-0abc123", "subnet-0def456" ], "endpointIpAddressType": "IPV4", "securityGroupIds": [ "sg-0abc123def" ] } } } } }
Beispiel: CreateGateway mit privatem IdP für eingehende Authentifizierung
{ "name": "my-gateway", "authorizerConfiguration": { "customJWTAuthorizer": { "discoveryUrl": "https://idp.internal.example.com/.well-known/openid-configuration", "allowedAudiences": [ "my-gateway-audience" ], "allowedClients": [ "my-client-id" ], "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0abc123def456", "subnetIds": [ "subnet-0abc123", "subnet-0def456" ], "endpointIpAddressType": "IPV4", "securityGroupIds": [ "sg-0abc123def" ] } } } } }
Wenn Ihr IdP ein TLS-Zertifikat verwendet, das von einer privaten Zertifizierungsstelle ausgestellt wurde, können Sie einen internen Application Load Balancer mit einem öffentlichen ACM-Zertifikat davor platzieren. Weitere Informationen finden Sie unter Problemumgehung für private Zertifikate: ALB.
Für selbstverwaltetes Lattice ersetzen Sie es durch: managedVpcResource selfManagedLatticeResource
Beispiel: CreateAgentRuntime mit selbstverwaltetem Lattice für eingehende Authentifizierung
{ "agentRuntimeName": "my-runtime", "authorizerConfiguration": { "customJWTAuthorizer": { "discoveryUrl": "https://idp.internal.example.com/.well-known/openid-configuration", "allowedAudiences": [ "my-agent-audience" ], "allowedClients": [ "my-client-id" ], "privateEndpoint": { "selfManagedLatticeResource": { "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123" } } } } }
Beispiel: CreateGateway mit selbstverwaltetem Lattice für eingehende Authentifizierung
{ "name": "my-gateway", "authorizerConfiguration": { "customJWTAuthorizer": { "discoveryUrl": "https://idp.internal.example.com/.well-known/openid-configuration", "allowedAudiences": [ "my-gateway-audience" ], "allowedClients": [ "my-client-id" ], "privateEndpoint": { "selfManagedLatticeResource": { "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123" } } } } }
Anbieter für ausgehende OAuth-Anmeldeinformationen mit einem privaten IdP
Wenn Sie einen Anbieter für ausgehende OAuth2-Anmeldeinformationen konfigurieren, der einen privaten IdP verwendet, muss AgentCore Identity den Token-Endpunkt des IdP erreichen, um Autorisierungscodes gegen Zugriffstoken auszutauschen oder Client-Anmeldeinformationen zu gewähren. Wenn der Token-Endpunkt des IdP in Ihrer VPC gehostet wird, müssen Sie einen privaten Endpunkt auf dem Anmeldeinformationsanbieter konfigurieren.
Konfigurieren Sie den Anbieter für ausgehende Anmeldeinformationen mit einem privaten IdP
Um einen Anbieter für ausgehende OAuth-Anmeldeinformationen mit einem privaten IdP zu konfigurieren, schließen Sie den privateEndpoint Block ein, wenn Sie den Anbieter für Anmeldeinformationen mithilfe eines benutzerdefinierten Anbieters mit manueller Konfiguration erstellen.
Beispiel: Erstellen Sie einen OAuth-Anbieter für Anmeldeinformationen mit einem privaten IdP
{ "name": "my-private-idp-provider", "credentialProviderType": "OAUTH", "oauthCredentialProvider": { "providerType": "CUSTOM", "customProviderConfiguration": { "issuer": "https://idp.internal.example.com/realms/my-realm", "authorizationEndpoint": "https://idp.internal.example.com/realms/my-realm/protocol/openid-connect/auth", "tokenEndpoint": "https://idp.internal.example.com/realms/my-realm/protocol/openid-connect/token" }, "clientId": "my-client-id", "clientSecret": "my-client-secret", "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0abc123def456", "subnetIds": [ "subnet-0abc123", "subnet-0def456" ], "endpointIpAddressType": "IPV4", "securityGroupIds": [ "sg-0abc123def" ] } } } }
Für selbstverwaltetes Lattice ersetzen Sie es durch: managedVpcResource selfManagedLatticeResource
{ "name": "my-private-idp-provider", "credentialProviderType": "OAUTH", "oauthCredentialProvider": { "providerType": "CUSTOM", "customProviderConfiguration": { "issuer": "https://idp.internal.example.com/realms/my-realm", "authorizationEndpoint": "https://idp.internal.example.com/realms/my-realm/protocol/openid-connect/auth", "tokenEndpoint": "https://idp.internal.example.com/realms/my-realm/protocol/openid-connect/token" }, "clientId": "my-client-id", "clientSecret": "my-client-secret", "privateEndpoint": { "selfManagedLatticeResource": { "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123" } } } }
Voraussetzungen
Stellen Sie vor der Konfiguration eines privaten Identitätsanbieters Folgendes sicher:
-
Ihr Identity Provider läuft und ist in Ihrer VPC zugänglich.
-
Der OIDC-Discovery-Endpunkt (
/.well-known/openid-configuration), der JWKS-Endpunkt und der Token-Endpunkt des IdP sind von den angegebenen Subnetzen aus erreichbar. -
Ihre Sicherheitsgruppen erlauben eingehenden Verkehr auf dem von Ihrem IdP verwendeten Port (normalerweise Port 443 für HTTPS).
-
Für Managed Lattice muss Ihr IAM-Prinzipal über die erforderlichen
iam:CreateServiceLinkedRoleBerechtigungen verfügen, um die dienstbezogene Identity Network-Rolle in Ihrem Namen erstellen zu AgentCore können. Die erforderliche IAM-Richtlinie finden Sie unter Dienstverknüpfte Rolle in Identity Network. -
Für Managed Lattice benötigt Ihr IAM-Principal außerdem die folgende Amazon EC2 EC2-Berechtigung:
ec2:CreateNetworkInterface.
Service-linked Rolle für private Identitätsanbieter
Wenn Sie einen privaten Endpunkt für einen Identitätsanbieter konfigurieren, verwendet AgentCore Identity die AWSServiceRoleForBedrockAgentCoreIdentity serviceverknüpfte Rolle, um die Konnektivität zu Ihrem VPC-gehosteten IdP zu verwalten. Diese Rolle wird automatisch erstellt, wenn Sie zum ersten Mal einen verwalteten privaten Endpunkt für einen Identitätsanbieter konfigurieren, sofern Ihr IAM-Prinzipal über die erforderlichen Berechtigungen verfügt. iam:CreateServiceLinkedRole
Das vollständige Richtliniendokument und Anweisungen zum Erstellen, Bearbeiten und Löschen dieser Rolle finden Sie unter Service-verknüpfte Rolle in Identity Network.
Einschränkungen und Überlegungen
-
Die Discovery-URL muss HTTPS sein: Die OIDC-Discovery-URL des IdP muss HTTPS verwenden. HTTP-Endpunkte werden nicht unterstützt.
-
Private Zertifikate: Ihr IdP muss ein öffentlich vertrauenswürdiges TLS-Zertifikat verwenden, oder Sie müssen ein ALB mit einem öffentlichen ACM-Zertifikat davor platzieren. Weitere Informationen finden Sie unter Problemumgehung für private Zertifikate: ALB.
-
Cross-account: Für Cross-account private IdP-Konnektivität ist die selbstverwaltete Lattice-Option erforderlich. Managed Lattice unterstützt keine kontenübergreifenden Szenarien.
Weitere Einschränkungen im Zusammenhang mit der VPC-Lattice-Konnektivität finden Sie unter Einschränkungen und Überlegungen unter Herstellen einer Connect zu privaten Ressourcen in Ihrer VPC mithilfe von VPC Lattice.