Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Kontoübergreifender Datenzugriff auf Domains OpenSearch
Sie können Ihre OpenSearch UI-Anwendungen in einem Konto konfigurieren, um auf OpenSearch Domains in verschiedenen Konten zuzugreifen. Wenn Sie eine OpenSearch UI-Anwendung mit kontoübergreifenden Datenquellen erstellen, geben Sie eine an`iamRoleForDataSourceArn`, die auf eine IAM-Rolle im Zielkonto verweist. OpenSearch UI validiert die Anfrage, indem sie diese Rolle übernimmt und anruft, um die Barrierefreiheit der Domain `es:DescribeDomain` zu überprüfen. Die kontoübergreifende Rolle wird nur bei der Datenquellenzuweisung verwendet. Der Zugriff auf die Datenebene wird separat durch die Zugriffsrichtlinie der Zieldomäne gesteuert.
Für die kontenübergreifende Unterstützung von Datenquellen muss in der Zieldomäne eine differenzierte Zugriffskontrolle aktiviert sein. Eine differenzierte Zugriffskontrolle bietet eine zusätzliche Autorisierungsebene, die über die Domänenzugriffsrichtlinie hinausgeht und es Ihnen ermöglicht, den Zugriff auf einzelne Indizes, Dokumente und Felder zu kontrollieren.
## Die wichtigsten Konzepte
Quellkonto
Das AWS-Konto , das Ihre OpenSearch UI-Anwendung hostet.
Zielkonto
Der AWS-Konto Ort, an dem sich die OpenSearch Domain befindet.
Kontoübergreifende Rolle
Eine IAM-Rolle im Zielkonto, die nur während der Datenquellenzuweisung verwendet wird. OpenSearch UI übernimmt diese Rolle beim Aufrufen`es:DescribeDomain`, wodurch der Domänenendpunkt abgerufen und überprüft wird, ob die detaillierte Zugriffskontrolle aktiviert ist. Dabei handelt es sich um einen Ermittlungs- und Validierungsschritt, nicht um eine Sicherheitsgrenze. Die kontoübergreifende Rolle wird niemals für den Zugriff auf die Datenebene verwendet. Nach der Zuordnung werden alle Datenebenenanforderungen unabhängig von der kontenübergreifenden Rolle anhand der Zugriffsrichtlinie und der Backend-Rollenzuordnungen der Domäne autorisiert.
IAM Identity Center-Anwendungsrolle
Eine IAM-Rolle im Quellkonto, die für den Zugriff auf die Benutzerdatenebene von IAM Identity Center verwendet wird.
## So funktioniert die kontenübergreifende Rollenübernahme
[Wenn Sie eine OpenSearch Benutzeroberflächenanwendung mit einer kontenübergreifenden Datenquelle erstellen oder aktualisieren, übernimmt die OpenSearch Benutzeroberfläche mithilfe von Forwarded Access Sessions (FAS) die kontenübergreifende Rolle im Zielkonto.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) FAS gibt die eigene IAM-Identität des aufrufenden Prinzipals an den Anruf weiter. `sts:AssumeRole` Das bedeutet Folgendes:
+ Die Vertrauensrichtlinie des Zielkontos steuert, welche Prinzipale des Quellkontos die kontoübergreifende Rolle übernehmen können.
+ Die Sitzung mit angenommener Rolle trägt die Identität des Anrufers, der die ODER-Anforderung initiiert hat. `CreateApplication` `UpdateApplication`
+ Die kontenübergreifende Rolle wird nur während der Verbindung zu einem Anruf übernommen. `es:DescribeDomain` Sie wird nicht für nachfolgende Datenebenenoperationen verwendet.
Für den Zugriff auf die Datenebene:
+ IAM-Benutzer signieren Anfragen mit ihren eigenen IAM-Anmeldeinformationen. Die Zugriffsrichtlinie der Zieldomain autorisiert diese Anfragen direkt.
+ Die Anfragen von IAM Identity Center-Benutzern sind mit der IAM Identity Center-Anwendungsrolle (`iamRoleForIdentityCenterApplicationArn`) im Quellkonto signiert. Die Zugriffsrichtlinie und die Backend-Rollenzuordnungen der Zieldomain autorisieren diese Anfragen.
## Voraussetzungen
Bevor Sie den kontenübergreifenden Datenzugriff einrichten, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ AWS CLI installiert und konfiguriert
+ Zugriff sowohl auf die Quell- als auch auf die AWS-Konto Zieldateien
+ OpenSearch Domänen mit [aktivierter detaillierter Zugriffskontrolle](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html). Die kontoübergreifende Datenquellenverknüpfung wird für Domänen ohne detaillierte Zugriffskontrolle nicht unterstützt.
+ Für IAM Identity Center-Flows: Eine Organisationsinstanz AWS IAM Identity Center
## Szenarien
Wählen Sie das Szenario aus, das Ihrer Authentifizierungsmethode und Domänenkonfiguration entspricht:
+ [Szenario 1: IAM-Benutzer, der auf eine öffentliche Domain zugreift](#cross-account-scenario-1)
+ [Szenario 2: IAM Identity Center-Benutzer, der auf eine öffentliche Domain zugreift](#cross-account-scenario-2)
+ [Szenario 3: IAM-Benutzer greift auf eine VPC-Domäne zu](#cross-account-scenario-3)
+ [Szenario 4: IAM Identity Center-Benutzer, der auf eine VPC-Domäne zugreift](#cross-account-scenario-4)
## Szenario 1: IAM-Benutzer, der auf eine öffentliche Domain zugreift
### Schritt 1: Erstellen Sie die kontoübergreifende IAM-Rolle (Zielkonto)
Erstellen Sie eine IAM-Rolle im Zielkonto, die es dem Quellkonto ermöglicht, diese Rolle für die Domänenvalidierung zu übernehmen.
**Um die kontoübergreifende Rolle zu erstellen**
1. Erstellen Sie eine Vertrauensrichtlinie, die es dem Quellkonto ermöglicht, die Rolle zu übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{source-account-id}}:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Erstellen Sie die Rolle:
```
aws iam create-role \
--role-name {{OpenSearchUIAccessRole}} \
--assume-role-policy-document file://{{trust-policy.json}}
```
1. Erstellen Sie eine Berechtigungsrichtlinie mit nur der `es:DescribeDomain` folgenden Aktion:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:{{region}}:{{target-account-id}}:domain/*"
}]
}
```
1. Hängen Sie die Berechtigungsrichtlinie an die Rolle an:
```
aws iam put-role-policy \
--role-name {{OpenSearchUIAccessRole}} \
--policy-name {{ValidationOnly}} \
--policy-document file://{{permissions-policy.json}}
```
### Schritt 2: Erstellen Sie die OpenSearch Domain (Zielkonto)
Erstellen Sie eine OpenSearch Domain im Zielkonto mit aktivierter detaillierter Zugriffskontrolle und Verschlüsselung:
```
aws opensearch create-domain \
--domain-name {{domain-name}} \
--engine-version OpenSearch_2.19 \
--cluster-config InstanceType=m5.large.search,InstanceCount=1 \
--ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=100" \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"{{admin}}","MasterUserPassword":"{{master-password}}"}}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--access-policies '{"Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::{{source-account-id}}:root"},"Action":"es:ESHttp*","Resource":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{domain-name}}/*"}]}' \
--region {{region}}
```
**Anmerkung**
Diese Zugriffsrichtlinie erstreckt sich auf den Datenebenenzugriff auf IAM-Prinzipale vom Quellkonto aus. Für einen restriktiveren Zugriff ersetzen Sie den Stammprinzipal des Kontos durch einen bestimmten IAM-Benutzer oder eine bestimmte IAM-Rolle. ARNs Eine differenzierte Zugriffskontrolle bietet eine zusätzliche Autorisierungsebene für die Zugriffskontrolle auf Indizes und Dokumente.
Warten Sie, bis der Domainstatus erreicht ist, `Active` bevor Sie fortfahren.
### Schritt 3: Erstellen Sie die OpenSearch UI-Anwendung (Quellkonto)
Erstellen Sie die Anwendung im Quellkonto mit der kontoübergreifenden Datenquelle:
```
aws opensearch create-application \
--region {{region}} \
--name "{{cross-account-iam-app}}" \
--data-sources '[{
"dataSourceArn":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{domain-name}}",
"dataSourceDescription":"{{Cross-account domain}}",
"iamRoleForDataSourceArn":"arn:aws:iam::{{target-account-id}}:role/{{OpenSearchUIAccessRole}}"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### Schritt 4: Verifizieren und darauf zugreifen
Rufen Sie die Anwendungsdetails ab, um die Endpunkt-URL abzurufen:
```
aws opensearch get-application \
--region {{region}} \
--id {{application-id}}
```
+ Navigieren Sie in der Antwort zur URL des Anwendungsendpunkts.
+ Melden Sie sich mit IAM-Anmeldeinformationen an.
+ Der IAM-Benutzer signiert Datenebenenanfragen mit seinen eigenen Anmeldeinformationen.
+ Die Zugriffsrichtlinie für die Zieldomäne steuert, auf welche Daten der Benutzer zugreifen kann.
## Szenario 2: IAM Identity Center-Benutzer, der auf eine öffentliche Domain zugreift
### Schritt 1: Erstellen Sie die kontoübergreifende IAM-Rolle (Zielkonto)
Erstellen Sie eine IAM-Rolle im Zielkonto, die es dem Quellkonto ermöglicht, diese Rolle für die Domänenvalidierung zu übernehmen.
**Um die kontoübergreifende Rolle zu erstellen**
1. Erstellen Sie eine Vertrauensrichtlinie, die es dem Quellkonto ermöglicht, die Rolle zu übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{source-account-id}}:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Erstellen Sie die Rolle:
```
aws iam create-role \
--role-name {{OpenSearchUIAccessRole}} \
--assume-role-policy-document file://{{trust-policy.json}}
```
1. Erstellen Sie eine Berechtigungsrichtlinie mit nur der `es:DescribeDomain` folgenden Aktion:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:{{region}}:{{target-account-id}}:domain/*"
}]
}
```
1. Hängen Sie die Berechtigungsrichtlinie an die Rolle an:
```
aws iam put-role-policy \
--role-name {{OpenSearchUIAccessRole}} \
--policy-name {{ValidationOnly}} \
--policy-document file://{{permissions-policy.json}}
```
### Schritt 2: Erstellen Sie die OpenSearch Domain (Zielkonto)
Erstellen Sie eine OpenSearch Domain im Zielkonto. Verwenden Sie denselben Befehl wie[Schritt 2: Erstellen Sie die OpenSearch Domain (Zielkonto)](#scenario-1-step-2), aktualisieren Sie jedoch die Zugriffsrichtlinie, um die IAM Identity Center-Anwendungsrolle vom Quellkonto aus zuzulassen:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{source-account-id}}:role/{{NeoIdCAppRole}}"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:{{region}}:{{target-account-id}}:domain/{{domain-name}}/*"
}]
}
```
Warten Sie, bis der Domainstatus erreicht ist, `Active` bevor Sie fortfahren.
### Schritt 3: Erstellen Sie die IAM-Rolle für die IAM Identity Center-Anwendung (Quellkonto)
Erstellen Sie eine IAM-Rolle in dem Quellkonto, das OpenSearch UI für den Zugriff auf die Benutzerdatenebene von IAM Identity Center verwendet.
**Um die IAM Identity Center-Anwendungsrolle zu erstellen**
1. Erstellen Sie eine Vertrauensrichtlinie:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": "arn:aws:iam::{{source-account-id}}:oidc-provider/portal.sso.{{region}}.amazonaws.com/apl/{{application-id}}"
}
}
}
]
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie:
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": ["es:ESHttp*"],
"Resource": "*"
}]
}
```
1. Erstellen Sie die Rolle und fügen Sie die Richtlinien hinzu:
```
aws iam create-role \
--role-name {{NeoIdCAppRole}} \
--assume-role-policy-document file://{{neoidc-trust-policy.json}}
aws iam put-role-policy \
--role-name {{NeoIdCAppRole}} \
--policy-name {{NeoIdCAppPermissions}} \
--policy-document file://{{neoidc-permissions-policy.json}}
```
### Schritt 4: Erstellen Sie die OpenSearch UI-Anwendung mit IAM Identity Center (Quellkonto)
```
aws opensearch create-application \
--region {{region}} \
--name "{{cross-account-idc-app}}" \
--iam-identity-center-options '{
"enabled":true,
"iamIdentityCenterInstanceArn":"arn:aws:sso:::instance/ssoins-{{instance-id}}",
"iamRoleForIdentityCenterApplicationArn":"arn:aws:iam::{{source-account-id}}:role/{{NeoIdCAppRole}}"
}' \
--data-sources '[{
"dataSourceArn":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{domain-name}}",
"dataSourceDescription":"{{Cross-account domain}}",
"iamRoleForDataSourceArn":"arn:aws:iam::{{target-account-id}}:role/{{OpenSearchUIAccessRole}}"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### Schritt 5: IAM Identity Center-Benutzer und -Gruppen erstellen und zuweisen
**Erstellen Sie einen IAM Identity Center-Benutzer**
Führen Sie den folgenden Befehl aus. Ersetzen Sie {{placeholder values}} durch Ihre Informationen.
```
aws identitystore create-user \
--identity-store-id {{d-directory-id}} \
--user-name {{user-email}} \
--display-name "{{display-name}}" \
--name Formatted=string,FamilyName={{last-name}},GivenName={{first-name}} \
--emails Value={{user-email}},Type=work,Primary=true
```
**Erstellen Sie eine IAM Identity Center-Gruppe und fügen Sie den Benutzer hinzu**
Führen Sie die folgenden Befehle aus:
```
aws identitystore create-group \
--identity-store-id {{d-directory-id}} \
--display-name "{{OpenSearchUsers}}" \
--description "{{Users with OpenSearch access}}"
aws identitystore create-group-membership \
--identity-store-id {{d-directory-id}} \
--group-id {{group-id}} \
--member-id UserId={{user-id}}
```
**Weisen Sie den Benutzer oder die Gruppe der Anwendung zu**
Führen Sie den folgenden Befehl aus:
```
aws sso-admin create-application-assignment \
--application-arn "arn:aws:sso:::{{source-account-id}}:application/ssoins-{{instance-id}}/apl-{{application-id}}" \
--principal-id {{user-id-or-group-id}} \
--principal-type {{USER}}
```
**Konfigurieren Sie die Back-End-Rollenzuordnung auf der Zieldomäne**
Ordnen Sie die IAM Identity Center-Gruppe einer OpenSearch Sicherheitsrolle in der Zieldomäne zu:
```
curl -XPUT "https://{{domain-endpoint}}/_plugins/_security/api/rolesmapping/all_access" \
-u {{admin}}:{{master-password}} \
-H 'Content-Type: application/json' \
-d '{
"backend_roles": ["{{group-id}}"],
"hosts": [],
"users": []
}'
```
### Schritt 6: Überprüfen und Zugreifen
```
aws opensearch get-application \
--region {{region}} \
--id {{application-id}}
```
+ Navigieren Sie zur URL des Anwendungsendpunkts.
+ Melden Sie sich mit den Benutzeranmeldedaten für das IAM Identity Center an.
+ Datenanfragen von IAM Identity Center-Benutzern werden mit der IAM Identity Center-Anwendungsrolle signiert, nicht mit der kontoübergreifenden Rolle.
+ Backend-Rollenzuordnungen auf der Domain steuern die Datenzugriffsberechtigungen.
## Szenario 3: IAM-Benutzer greift auf eine VPC-Domäne zu
### Schritt 1: Erstellen Sie die kontoübergreifende IAM-Rolle (Zielkonto)
Erstellen Sie eine IAM-Rolle im Zielkonto, die es dem Quellkonto ermöglicht, diese Rolle für die Domänenvalidierung zu übernehmen.
**Um die kontoübergreifende Rolle zu erstellen**
1. Erstellen Sie eine Vertrauensrichtlinie, die es dem Quellkonto ermöglicht, die Rolle zu übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{source-account-id}}:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Erstellen Sie die Rolle:
```
aws iam create-role \
--role-name {{OpenSearchUIAccessRole}} \
--assume-role-policy-document file://{{trust-policy.json}}
```
1. Erstellen Sie eine Berechtigungsrichtlinie mit nur der `es:DescribeDomain` folgenden Aktion:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:{{region}}:{{target-account-id}}:domain/*"
}]
}
```
1. Hängen Sie die Berechtigungsrichtlinie an die Rolle an:
```
aws iam put-role-policy \
--role-name {{OpenSearchUIAccessRole}} \
--policy-name {{ValidationOnly}} \
--policy-document file://{{permissions-policy.json}}
```
### Schritt 2: VPC einrichten (Zielkonto)
Überspringen Sie diesen Schritt, wenn im Zielkonto bereits eine VPC vorhanden ist.
```
# Create VPC
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--region {{region}}
# Create subnet
aws ec2 create-subnet \
--vpc-id {{vpc-id}} \
--cidr-block 10.0.1.0/24 \
--availability-zone {{region}}a \
--region {{region}}
# Create security group
aws ec2 create-security-group \
--group-name {{opensearch-vpc-sg}} \
--description "Security group for OpenSearch VPC domain" \
--vpc-id {{vpc-id}} \
--region {{region}}
# Allow inbound HTTPS
aws ec2 authorize-security-group-ingress \
--group-id {{security-group-id}} \
--protocol tcp \
--port 443 \
--cidr 10.0.0.0/16 \
--region {{region}}
```
Erfahren Sie mehr über die [Erstellung von VPC-Domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html).
### Schritt 3: VPC-Domain (Zielkonto) erstellen
```
aws opensearch create-domain \
--domain-name {{vpc-domain-name}} \
--engine-version OpenSearch_2.19 \
--cluster-config InstanceType=m5.large.search,InstanceCount=1 \
--ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=100" \
--vpc-options "SubnetIds={{subnet-id}},SecurityGroupIds={{security-group-id}}" \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"{{admin}}","MasterUserPassword":"{{master-password}}"}}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--access-policies '{"Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::{{source-account-id}}:root"},"Action":"es:ESHttp*","Resource":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{vpc-domain-name}}/*"}]}' \
--region {{region}}
```
**Anmerkung**
Diese Zugriffsrichtlinie umfasst den Datenebenenzugriff auf IAM-Prinzipale vom Quellkonto aus. Für einen restriktiveren Zugriff ersetzen Sie den Stammprinzipal des Kontos durch einen bestimmten IAM-Benutzer oder eine bestimmte IAM-Rolle. ARNs Eine differenzierte Zugriffskontrolle bietet eine zusätzliche Autorisierungsebene für die Zugriffskontrolle auf Indizes und Dokumente.
Warten Sie, bis der Domainstatus erreicht ist, `Active` bevor Sie fortfahren.
### Schritt 4: Autorisieren Sie den VPC-Endpunkt für den OpenSearch UI-Serviceprinzipal (Zielkonto)
**Wichtig**
Dies ist ein kritischer Schritt, der nur für VPC-Domains gilt. Der OpenSearch UI-Service muss explizit autorisiert sein, auf den VPC-Endpunkt zuzugreifen.
```
# Authorize the service principal
aws opensearch authorize-vpc-endpoint-access \
--domain-name {{vpc-domain-name}} \
--service "application.opensearchservice.amazonaws.com" \
--region {{region}}
# Verify authorization
aws opensearch list-vpc-endpoint-access \
--domain-name {{vpc-domain-name}} \
--region {{region}}
```
Erwartete Antwort:
```
{
"AuthorizedPrincipalList": [
{
"PrincipalType": "AWS_SERVICE",
"Principal": "application.opensearchservice.amazonaws.com"
}
]
}
```
### Schritt 5: Erstellen Sie die OpenSearch UI-Anwendung (Quellkonto)
```
aws opensearch create-application \
--region {{region}} \
--name "{{cross-account-vpc-iam-app}}" \
--data-sources '[{
"dataSourceArn":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{vpc-domain-name}}",
"dataSourceDescription":"{{Cross-account VPC domain}}",
"iamRoleForDataSourceArn":"arn:aws:iam::{{target-account-id}}:role/{{OpenSearchUIAccessRole}}"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### Schritt 6: Überprüfen und zugreifen
Rufen Sie die Anwendungsdetails ab, um die Endpunkt-URL abzurufen:
```
aws opensearch get-application \
--region {{region}} \
--id {{application-id}}
```
+ Navigieren Sie in der Antwort zur URL des Anwendungsendpunkts.
+ Melden Sie sich mit IAM-Anmeldeinformationen an.
+ Der IAM-Benutzer signiert Datenebenenanfragen mit seinen eigenen Anmeldeinformationen.
+ Die Zugriffsrichtlinie für die Zieldomäne steuert, auf welche Daten der Benutzer zugreifen kann.
## Szenario 4: IAM Identity Center-Benutzer, der auf eine VPC-Domäne zugreift
### Schritt 1: Erstellen Sie die kontoübergreifende IAM-Rolle (Zielkonto)
Erstellen Sie eine IAM-Rolle im Zielkonto, die es dem Quellkonto ermöglicht, diese Rolle für die Domänenvalidierung zu übernehmen.
**Um die kontoübergreifende Rolle zu erstellen**
1. Erstellen Sie eine Vertrauensrichtlinie, die es dem Quellkonto ermöglicht, die Rolle zu übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{source-account-id}}:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Erstellen Sie die Rolle:
```
aws iam create-role \
--role-name {{OpenSearchUIAccessRole}} \
--assume-role-policy-document file://{{trust-policy.json}}
```
1. Erstellen Sie eine Berechtigungsrichtlinie mit nur der `es:DescribeDomain` folgenden Aktion:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:{{region}}:{{target-account-id}}:domain/*"
}]
}
```
1. Hängen Sie die Berechtigungsrichtlinie an die Rolle an:
```
aws iam put-role-policy \
--role-name {{OpenSearchUIAccessRole}} \
--policy-name {{ValidationOnly}} \
--policy-document file://{{permissions-policy.json}}
```
### Schritt 2: VPC einrichten (Zielkonto)
Überspringen Sie diesen Schritt, wenn im Zielkonto bereits eine VPC vorhanden ist.
```
# Create VPC
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--region {{region}}
# Create subnet
aws ec2 create-subnet \
--vpc-id {{vpc-id}} \
--cidr-block 10.0.1.0/24 \
--availability-zone {{region}}a \
--region {{region}}
# Create security group
aws ec2 create-security-group \
--group-name {{opensearch-vpc-sg}} \
--description "Security group for OpenSearch VPC domain" \
--vpc-id {{vpc-id}} \
--region {{region}}
# Allow inbound HTTPS
aws ec2 authorize-security-group-ingress \
--group-id {{security-group-id}} \
--protocol tcp \
--port 443 \
--cidr 10.0.0.0/16 \
--region {{region}}
```
Erfahren Sie mehr über die [Erstellung von VPC-Domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html).
### Schritt 3: VPC-Domain (Zielkonto) erstellen
Verwenden Sie denselben Befehl wie[Schritt 3: VPC-Domain (Zielkonto) erstellen](#scenario-3-step-3), aktualisieren Sie jedoch die Zugriffsrichtlinie, um die IAM Identity Center-Anwendungsrolle vom Quellkonto aus zuzulassen:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{source-account-id}}:role/{{NeoIdCAppRole}}"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:{{region}}:{{target-account-id}}:domain/{{vpc-domain-name}}/*"
}]
}
```
Warten Sie, bis der Domainstatus erreicht ist, `Active` bevor Sie fortfahren.
### Schritt 4: Autorisieren Sie den VPC-Endpunkt für den OpenSearch UI-Serviceprinzipal (Zielkonto)
**Wichtig**
Dies ist ein kritischer Schritt, der nur für VPC-Domains gilt. Der OpenSearch UI-Service muss explizit autorisiert sein, auf den VPC-Endpunkt zuzugreifen.
```
# Authorize the service principal
aws opensearch authorize-vpc-endpoint-access \
--domain-name {{vpc-domain-name}} \
--service "application.opensearchservice.amazonaws.com" \
--region {{region}}
# Verify authorization
aws opensearch list-vpc-endpoint-access \
--domain-name {{vpc-domain-name}} \
--region {{region}}
```
Erwartete Antwort:
```
{
"AuthorizedPrincipalList": [
{
"PrincipalType": "AWS_SERVICE",
"Principal": "application.opensearchservice.amazonaws.com"
}
]
}
```
### Schritt 5: Erstellen Sie die IAM-Rolle für die IAM Identity Center-Anwendung (Quellkonto)
Erstellen Sie eine IAM-Rolle in dem Quellkonto, das OpenSearch UI für den Zugriff auf die Benutzerdatenebene von IAM Identity Center verwendet.
**Um die IAM Identity Center-Anwendungsrolle zu erstellen**
1. Erstellen Sie eine Vertrauensrichtlinie:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": "arn:aws:iam::{{source-account-id}}:oidc-provider/portal.sso.{{region}}.amazonaws.com/apl/{{application-id}}"
}
}
}
]
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie:
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": ["es:ESHttp*"],
"Resource": "*"
}]
}
```
1. Erstellen Sie die Rolle und fügen Sie die Richtlinien hinzu:
```
aws iam create-role \
--role-name {{NeoIdCAppRole}} \
--assume-role-policy-document file://{{neoidc-trust-policy.json}}
aws iam put-role-policy \
--role-name {{NeoIdCAppRole}} \
--policy-name {{NeoIdCAppPermissions}} \
--policy-document file://{{neoidc-permissions-policy.json}}
```
### Schritt 6: Erstellen Sie die OpenSearch UI-Anwendung mit IAM Identity Center (Quellkonto)
```
aws opensearch create-application \
--region {{region}} \
--name "{{cross-account-vpc-idc-app}}" \
--iam-identity-center-options '{
"enabled":true,
"iamIdentityCenterInstanceArn":"arn:aws:sso:::instance/ssoins-{{instance-id}}",
"iamRoleForIdentityCenterApplicationArn":"arn:aws:iam::{{source-account-id}}:role/{{NeoIdCAppRole}}"
}' \
--data-sources '[{
"dataSourceArn":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{vpc-domain-name}}",
"dataSourceDescription":"{{Cross-account VPC domain}}",
"iamRoleForDataSourceArn":"arn:aws:iam::{{target-account-id}}:role/{{OpenSearchUIAccessRole}}"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### Schritt 7: IAM Identity Center-Benutzer und -Gruppen erstellen und zuweisen
**Erstellen Sie einen IAM Identity Center-Benutzer**
Führen Sie den folgenden Befehl aus. Ersetzen Sie {{placeholder values}} durch Ihre Informationen.
```
aws identitystore create-user \
--identity-store-id {{d-directory-id}} \
--user-name {{user-email}} \
--display-name "{{display-name}}" \
--name Formatted=string,FamilyName={{last-name}},GivenName={{first-name}} \
--emails Value={{user-email}},Type=work,Primary=true
```
**Erstellen Sie eine IAM Identity Center-Gruppe und fügen Sie den Benutzer hinzu**
Führen Sie die folgenden Befehle aus:
```
aws identitystore create-group \
--identity-store-id {{d-directory-id}} \
--display-name "{{OpenSearchUsers}}" \
--description "{{Users with OpenSearch access}}"
aws identitystore create-group-membership \
--identity-store-id {{d-directory-id}} \
--group-id {{group-id}} \
--member-id UserId={{user-id}}
```
**Weisen Sie den Benutzer oder die Gruppe der Anwendung zu**
Führen Sie den folgenden Befehl aus:
```
aws sso-admin create-application-assignment \
--application-arn "arn:aws:sso:::{{source-account-id}}:application/ssoins-{{instance-id}}/apl-{{application-id}}" \
--principal-id {{user-id-or-group-id}} \
--principal-type {{USER}}
```
**Konfigurieren Sie die Back-End-Rollenzuordnung auf der Zieldomäne**
Ordnen Sie die IAM Identity Center-Gruppe einer OpenSearch Sicherheitsrolle in der Zieldomäne zu:
```
curl -XPUT "https://{{domain-endpoint}}/_plugins/_security/api/rolesmapping/all_access" \
-u {{admin}}:{{master-password}} \
-H 'Content-Type: application/json' \
-d '{
"backend_roles": ["{{group-id}}"],
"hosts": [],
"users": []
}'
```
### Schritt 8: Überprüfen und Zugreifen
```
aws opensearch get-application \
--region {{region}} \
--id {{application-id}}
```
+ Navigieren Sie zur URL des Anwendungsendpunkts.
+ Melden Sie sich mit den Benutzeranmeldedaten für das IAM Identity Center an.
+ Datenanfragen von IAM Identity Center-Benutzern werden mit der IAM Identity Center-Anwendungsrolle signiert, nicht mit der kontoübergreifenden Rolle.
+ Backend-Rollenzuordnungen auf der Domain steuern die Datenzugriffsberechtigungen.
## Verwalten von -Anwendungen
**Aktualisieren Sie eine Anwendung mit kontoübergreifenden Datenquellen**
Führen Sie den folgenden Befehl aus. Ersetzen Sie {{placeholder values}} durch Ihre Informationen.
```
aws opensearch update-application \
--region {{region}} \
--id {{application-id}} \
--data-sources '[{
"dataSourceArn":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{domain-1}}",
"dataSourceDescription":"{{First cross-account domain}}",
"iamRoleForDataSourceArn":"arn:aws:iam::{{target-account-id}}:role/{{OpenSearchUIAccessRole}}"
},{
"dataSourceArn":"arn:aws:es:{{region}}:{{target-account-id}}:domain/{{domain-2}}",
"dataSourceDescription":"{{Second cross-account domain}}",
"iamRoleForDataSourceArn":"arn:aws:iam::{{target-account-id}}:role/{{OpenSearchUIAccessRole}}"
}]'
```
**Wichtig**
Der Aktualisierungsvorgang ersetzt das gesamte Datenquellen-Array. Schließt alle Datenquellen ein, die Sie behalten möchten.
**Anwendungen auflisten**
Führen Sie den folgenden Befehl aus:
```
aws opensearch list-applications \
--region {{region}}
```
**Löschen einer Anwendung**
Führen Sie den folgenden Befehl aus:
```
aws opensearch delete-application \
--region {{region}} \
--id {{application-id}}
```
**VPC-Endpunktzugriff widerrufen**
Führen Sie den folgenden Befehl aus:
```
aws opensearch revoke-vpc-endpoint-access \
--domain-name {{vpc-domain-name}} \
--service "application.opensearchservice.amazonaws.com" \
--region {{region}}
```
## Kurzreferenz
In den folgenden Tabellen werden die wichtigsten Unterschiede zwischen Domaintypen und Authentifizierungsmethoden zusammengefasst.
**Public Domain im Vergleich zu VPC-Domain**
| Aspekt | Öffentliche Domäne | VPC-Domäne |
| --- | --- | --- |
| VPC-Endpunktautorisierung | Nicht erforderlich | Erforderlich — muss autorisiert werden application.opensearchservice.amazonaws.com |
| Netzwerk-Setup | Keine | VPC, Subnetz, Sicherheitsgruppe mit eingehendem HTTPS (443) |
| IAM-Zugriffsrichtlinie | Erforderlich | Erforderlich |
| Kontoübergreifende Rolle | Für eine kontoübergreifende Nutzung erforderlich | Für kontoübergreifende Konten erforderlich |
**IAM-Benutzer im Vergleich zu IAM Identity Center-Benutzer**
| Aspekt | IAM-Benutzer | IAM Identity Center-Benutzer |
| --- | --- | --- |
| Anmeldeinformationen auf der Datenebene | Eigene IAM-Anmeldeinformationen des Benutzers | IAM Identity Center-Anwendungsrolle |
| Zugriffskontrolle | Domain-Zugriffsrichtlinie | Zuordnungen von Domänenzugriffsrichtlinien und Back-End-Rollen |
| Zusätzliche Einrichtung | Keine | IAM Identity Center-Anwendungsrolle, user/group Erstellung, Anwendungszuweisung, Rollenzuweisung im Backend |
| OpenSearch Konfiguration der UI-Anwendung | Keine IAM Identity Center-Optionen | --iam-identity-center-options erforderlich |
## Wichtige Hinweise
+ Der `iamRoleForDataSourceArn` muss sich im selben Konto befinden wie der`dataSourceArn`.
+ Das `iamRoleForDataSourceArn` ist nur für kontoübergreifende Datenquellen erforderlich. Lassen Sie es für Datenquellen mit demselben Konto weg.
+ Für die kontoübergreifende Rolle ist nur die Genehmigung erforderlich. `es:DescribeDomain` Sie wird niemals für den Zugriff auf die Datenebene verwendet.
+ Für VPC-Domänen müssen sowohl die IAM-Richtlinie als auch die VPC-Endpunktautorisierung konfiguriert werden.
+ Unterstützte Engine-Versionen: OpenSearch 1.3 und höher.
+ Für die kontenübergreifende Datenquellenverknüpfung muss in der Zieldomäne eine detaillierte Zugriffskontrolle aktiviert sein.
## Fehlerbehebung
| Problem | Auflösung |
| --- | --- |
| Die Anwendungserstellung schlägt mit der Meldung „Zugriff auf Domäne nicht möglich“ fehl | Stellen Sie sicher, dass die kontoübergreifende Rolle über die es:DescribeDomain erforderlichen Berechtigungen verfügt und dass die Vertrauensrichtlinie das Quellkonto zulässt. |
| VPC-Domänenzuweisung schlägt fehl | Stellen Sie sicher, dass der VPC-Endpunkt für application.opensearchservice.amazonaws.com autorisiert ist. |
| Der Zugriff auf die Datenebene wurde dem IAM-Benutzer verweigert | Vergewissern Sie sich, dass die Zugriffsrichtlinie für die Zieldomäne den IAM-Benutzer oder Rollenprinzipal zulässt. |
| Der Zugriff auf die Datenebene wurde dem IAM Identity Center-Benutzer verweigert | Stellen Sie sicher, dass die Back-End-Rollenzuordnung die IAM Identity Center-Gruppen-ID enthält und dass die Domänenrichtlinie die IAM Identity Center-Anwendungsrolle zulässt. |
| Fehler: Konto stimmt nicht überein | Stellen Sie sicher, dass iamRoleForDataSourceArn es sich um dasselbe Konto handelt wie die Domain indataSourceArn. |