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à. # Accesso ai dati tra regioni e account diversi OpenSearch L'interfaccia utente supporta l'accesso ai dati da OpenSearch domini su diversi server Account AWS. Regione AWS Puoi scegliere tra due approcci a seconda delle tue esigenze. La tabella seguente mette a confronto i due approcci. **Nota** Sia l'accesso ai dati tra account che la ricerca tra cluster funzionano solo con i domini. OpenSearch Nessuno dei due approcci supporta OpenSearch le raccolte Serverless. | Aspetto | Accesso ai dati tra account | Funzionalità di ricerca tra cluster | | --- | --- | --- | | Funzionalità | Associa i domini di altri account come fonti di dati dirette nell'interfaccia utente OpenSearch | Interroga i dati su domini connessi utilizzando connessioni di ricerca tra cluster | | Meccanismo | Accesso diretto: l' OpenSearch interfaccia utente si connette direttamente al dominio di destinazione in un altro account | Accesso indiretto: richiede un dominio locale nello stesso account dell' OpenSearch interfaccia utente per inoltrare le richieste ai domini remoti | | Supporto multi-account | Sì | Sì | | Supporto tra regioni | No, i domini di origine e di destinazione devono appartenere allo stesso Regione AWS | Sì, i domini di origine e di destinazione possono trovarsi in diversi Regione AWS | | Unisci i dati tra i domini | No, ogni dominio viene interrogato in modo indipendente come fonte di dati separata | Sì, una singola query può aggregare i risultati di più domini connessi | | Metodi di autenticazione | IAM e AWS IAM Identity Center | IAM (con controllo granulare degli accessi) | | Complessità della configurazione | Inferiore: richiede un ruolo IAM su più account per la convalida | Superiore: richiede connessioni tra cluster, politiche di accesso su entrambi i domini e un controllo granulare degli accessi | | Visibilità delle fonti di dati nell'interfaccia utente OpenSearch | Ogni dominio tra account viene visualizzato come una fonte di dati separata | Si accede ai domini remoti tramite gli alias di connessione del dominio di origine locale | | Accesso in scrittura al dominio remoto | Sì, controllato dalla politica di accesso del dominio di destinazione | No: la ricerca tra cluster fornisce l'accesso in sola lettura ai domini remoti | **Topics** + [Accesso ai dati tra account diversi ai domini OpenSearch](application-cross-account-data-access-domains.md) + [Funzionalità di ricerca tra cluster](application-cross-cluster-search.md) # Accesso ai dati tra account diversi ai domini OpenSearch Puoi configurare le applicazioni OpenSearch dell'interfaccia utente in un account per accedere ai OpenSearch domini di account diversi. Quando OpenSearch crei un'applicazione UI con fonti di dati tra account diversi, fornisci un elemento `iamRoleForDataSourceArn` che rimanda a un ruolo IAM nell'account di destinazione. OpenSearch L'interfaccia utente convalida la richiesta assumendo questo ruolo e chiamando `es:DescribeDomain` per verificare l'accessibilità del dominio. Il ruolo tra account diversi viene utilizzato solo per la convalida del piano di controllo. L'accesso al piano dati è controllato separatamente dalla politica di accesso del dominio di destinazione. **Codice di esempio** Gli esempi di codice in questo argomento sono solo a scopo illustrativo. Dimostrano funzionalità di base e potrebbero non includere la gestione degli errori, le migliori pratiche di sicurezza o le funzionalità pronte per la produzione. Prima di utilizzare il codice di esempio in produzione, esaminatelo e modificatelo per soddisfare i vostri requisiti specifici e testatelo accuratamente nel vostro ambiente. ## Concetti chiave Account di origine Il Account AWS che ospita la tua applicazione OpenSearch UI. Account Target Il Account AWS luogo in cui risiede il OpenSearch dominio. Ruolo tra account Un ruolo IAM nell'account di destinazione utilizzato solo per la convalida del piano di controllo. Questo ruolo richiede solo l'`es:DescribeDomain`autorizzazione. Ruolo applicativo IAM Identity Center Un ruolo IAM nell'account di origine utilizzato per l'accesso al piano dati degli utenti di IAM Identity Center. ## Prerequisiti Prima di configurare l'accesso ai dati tra account diversi, assicurati di disporre di quanto segue: + AWS CLI installato e configurato + Accesso sia ai file di origine che a quelli Account AWS di destinazione + Per i flussi di IAM Identity Center: un'istanza AWS IAM Identity Center dell'organizzazione ## Scenari Scegli lo scenario che corrisponde al tuo metodo di autenticazione e alla configurazione del dominio: + [Scenario 1: utente IAM che accede a un dominio pubblico](#cross-account-scenario-1) + [Scenario 2: utente di IAM Identity Center che accede a un dominio pubblico](#cross-account-scenario-2) + [Scenario 3: utente IAM che accede a un dominio VPC](#cross-account-scenario-3) + [Scenario 4: utente IAM Identity Center che accede a un dominio VPC](#cross-account-scenario-4) ## Scenario 1: utente IAM che accede a un dominio pubblico ### Fase 1: Creare il ruolo IAM per più account (account di destinazione) Crea un ruolo IAM nell'account di destinazione che consenta all'account di origine di assumerlo per la convalida del dominio. **Per creare il ruolo tra account** 1. Crea una politica di fiducia che consenta all'account di origine di assumere il ruolo: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crea il ruolo: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crea una politica di autorizzazioni con la sola `es:DescribeDomain` azione: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Allega la politica delle autorizzazioni al ruolo: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Fase 2: Creare il OpenSearch dominio (account di destinazione) Crea un OpenSearch dominio nell'account di destinazione con il controllo granulare degli accessi e la crittografia abilitati: ``` 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":"*"},"Action":"es:ESHttp*","Resource":"arn:aws:es:region:target-account-id:domain/domain-name/*"}]}' \ --region region ``` Attendi che lo stato del dominio diventi `Active` tale prima di procedere. ### Fase 3: Creare l'applicazione OpenSearch UI (account di origine) Crea l'applicazione nell'account di origine con l'origine dati tra account: ``` 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":"[\"*\"]"}]' ``` ### Fase 4: Verifica e accedi Recupera i dettagli dell'applicazione per ottenere l'URL dell'endpoint: ``` aws opensearch get-application \ --region region \ --id application-id ``` + Passa all'URL dell'endpoint dell'applicazione dalla risposta. + Accedi con le credenziali IAM. + L'utente IAM firma le richieste del piano dati con le proprie credenziali. + La policy di accesso al dominio di destinazione controlla a quali dati l'utente può accedere. ## Scenario 2: utente di IAM Identity Center che accede a un dominio pubblico ### Fase 1: Creare il ruolo IAM per più account (account di destinazione) Crea un ruolo IAM nell'account di destinazione che consenta all'account di origine di assumerlo per la convalida del dominio. **Per creare il ruolo tra account** 1. Crea una politica di fiducia che consenta all'account di origine di assumere il ruolo: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crea il ruolo: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crea una politica di autorizzazioni con la sola `es:DescribeDomain` azione: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Allega la politica delle autorizzazioni al ruolo: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Fase 2: Creare il OpenSearch dominio (account di destinazione) Crea un OpenSearch dominio nell'account di destinazione. Utilizza lo stesso comando[Fase 2: Creare il OpenSearch dominio (account di destinazione)](#scenario-1-step-2), ma aggiorna la policy di accesso per consentire il ruolo dell'applicazione IAM Identity Center dall'account di origine: ``` { "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/*" }] } ``` Attendi che lo stato del dominio diventi tale `Active` prima di procedere. ### Fase 3: Creare il ruolo IAM per l'applicazione IAM Identity Center (account di origine) Crea un ruolo IAM nell'account di origine che l' OpenSearch interfaccia utente utilizza per l'accesso al piano dati degli utenti di IAM Identity Center. **Per creare il ruolo applicativo IAM Identity Center** 1. Crea una politica di fiducia: ``` { "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. Crea una politica di autorizzazioni: ``` { "Version": "2012-10-17", "Statement": [{ "Sid": "OpenSearchDomain", "Effect": "Allow", "Action": ["es:ESHttp*"], "Resource": "*" }] } ``` 1. Crea il ruolo e allega le politiche: ``` 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 ``` ### Fase 4: Creare l'applicazione OpenSearch UI con IAM Identity Center (account di origine) ``` 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":"[\"*\"]"}]' ``` ### Fase 5: Creare e assegnare utenti e gruppi di IAM Identity Center **Crea un utente IAM Identity Center** Eseguire il seguente comando seguente. Sostituisci *placeholder values* con le informazioni appropriate. ``` 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 ``` **Crea un gruppo IAM Identity Center e aggiungi l'utente** Esegui i comandi seguenti: ``` 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 ``` **Assegna l'utente o il gruppo all'applicazione** Esegui il comando seguente: ``` 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 ``` **Configura la mappatura dei ruoli di backend sul dominio di destinazione** Mappa il gruppo IAM Identity Center su un ruolo OpenSearch di sicurezza nel dominio di destinazione: ``` 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": [] }' ``` ### Fase 6: Verifica e accesso ``` aws opensearch get-application \ --region region \ --id application-id ``` + Vai all'URL dell'endpoint dell'applicazione. + Accedi con le credenziali utente di IAM Identity Center. + Le richieste di dati degli utenti di IAM Identity Center vengono firmate con il ruolo applicativo IAM Identity Center, non con il ruolo tra account. + Le mappature dei ruoli di backend sul dominio controllano le autorizzazioni di accesso ai dati. ## Scenario 3: utente IAM che accede a un dominio VPC ### Fase 1: Creare il ruolo IAM per più account (account di destinazione) Crea un ruolo IAM nell'account di destinazione che consenta all'account di origine di assumerlo per la convalida del dominio. **Per creare il ruolo tra account** 1. Crea una politica di fiducia che consenta all'account di origine di assumere il ruolo: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crea il ruolo: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crea una politica di autorizzazioni con la sola `es:DescribeDomain` azione: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Allega la politica delle autorizzazioni al ruolo: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Fase 2: Configurare il VPC (account di destinazione) Salta questo passaggio se nell'account di destinazione esiste già un VPC. ``` # 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 regiona \ --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 ``` Scopri di più sulla [creazione di domini VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html). ### Fase 3: Creare il dominio VPC (account di destinazione) ``` 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":"*"},"Action":"es:ESHttp*","Resource":"arn:aws:es:region:target-account-id:domain/vpc-domain-name/*"}]}' \ --region region ``` Attendi che lo stato del dominio diventi tale `Active` prima di procedere. ### Passaggio 4: autorizzare l'endpoint VPC per il principale OpenSearch del servizio UI (account di destinazione) **Importante** Si tratta di un passaggio fondamentale che riguarda esclusivamente i domini VPC. Il servizio OpenSearch UI deve essere esplicitamente autorizzato ad accedere all'endpoint VPC. ``` # 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 ``` Risposta prevista: ``` { "AuthorizedPrincipalList": [ { "PrincipalType": "AWS_SERVICE", "Principal": "application.opensearchservice.amazonaws.com" } ] } ``` ### Fase 5: Creare l'applicazione OpenSearch UI (account di origine) ``` 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":"[\"*\"]"}]' ``` ### Passaggio 6: verifica e accesso Recupera i dettagli dell'applicazione per ottenere l'URL dell'endpoint: ``` aws opensearch get-application \ --region region \ --id application-id ``` + Passa all'URL dell'endpoint dell'applicazione dalla risposta. + Accedi con le credenziali IAM. + L'utente IAM firma le richieste del piano dati con le proprie credenziali. + La policy di accesso al dominio di destinazione controlla a quali dati l'utente può accedere. ## Scenario 4: utente IAM Identity Center che accede a un dominio VPC ### Fase 1: Creare il ruolo IAM per più account (account di destinazione) Crea un ruolo IAM nell'account di destinazione che consenta all'account di origine di assumerlo per la convalida del dominio. **Per creare il ruolo tra account** 1. Crea una politica di fiducia che consenta all'account di origine di assumere il ruolo: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crea il ruolo: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crea una politica di autorizzazioni con la sola `es:DescribeDomain` azione: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Allega la politica delle autorizzazioni al ruolo: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Fase 2: Configurare il VPC (account di destinazione) Salta questo passaggio se nell'account di destinazione esiste già un VPC. ``` # 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 regiona \ --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 ``` Scopri di più sulla [creazione di domini VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html). ### Fase 3: Creare il dominio VPC (account di destinazione) Utilizza lo stesso comando[Fase 3: Creare il dominio VPC (account di destinazione)](#scenario-3-step-3), ma aggiorna la policy di accesso per consentire il ruolo dell'applicazione IAM Identity Center dall'account di origine: ``` { "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/*" }] } ``` Attendi che lo stato del dominio diventi tale `Active` prima di procedere. ### Passaggio 4: autorizzare l'endpoint VPC per il principale OpenSearch del servizio UI (account di destinazione) **Importante** Si tratta di un passaggio fondamentale che riguarda esclusivamente i domini VPC. Il servizio OpenSearch UI deve essere esplicitamente autorizzato ad accedere all'endpoint VPC. ``` # 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 ``` Risposta prevista: ``` { "AuthorizedPrincipalList": [ { "PrincipalType": "AWS_SERVICE", "Principal": "application.opensearchservice.amazonaws.com" } ] } ``` ### Fase 5: Creare il ruolo IAM per l'applicazione IAM Identity Center (account di origine) Crea un ruolo IAM nell'account di origine che l' OpenSearch interfaccia utente utilizza per l'accesso al piano dati degli utenti di IAM Identity Center. **Per creare il ruolo applicativo IAM Identity Center** 1. Crea una politica di fiducia: ``` { "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. Crea una politica di autorizzazioni: ``` { "Version": "2012-10-17", "Statement": [{ "Sid": "OpenSearchDomain", "Effect": "Allow", "Action": ["es:ESHttp*"], "Resource": "*" }] } ``` 1. Crea il ruolo e allega le politiche: ``` 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 ``` ### Fase 6: Creare l'applicazione OpenSearch UI con IAM Identity Center (account di origine) ``` 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":"[\"*\"]"}]' ``` ### Fase 7: Creare e assegnare utenti e gruppi di IAM Identity Center **Crea un utente IAM Identity Center** Eseguire il seguente comando seguente. Sostituisci *placeholder values* con le informazioni appropriate. ``` 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 ``` **Crea un gruppo IAM Identity Center e aggiungi l'utente** Esegui i comandi seguenti: ``` 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 ``` **Assegna l'utente o il gruppo all'applicazione** Esegui il comando seguente: ``` 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 ``` **Configura la mappatura dei ruoli di backend sul dominio di destinazione** Mappa il gruppo IAM Identity Center su un ruolo OpenSearch di sicurezza nel dominio di destinazione: ``` 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": [] }' ``` ### Fase 8: Verifica e accesso ``` aws opensearch get-application \ --region region \ --id application-id ``` + Vai all'URL dell'endpoint dell'applicazione. + Accedi con le credenziali utente di IAM Identity Center. + Le richieste di dati degli utenti di IAM Identity Center vengono firmate con il ruolo applicativo IAM Identity Center, non con il ruolo tra account. + Le mappature dei ruoli di backend sul dominio controllano le autorizzazioni di accesso ai dati. ## Gestione delle applicazioni **Aggiorna un'applicazione con fonti di dati tra account diversi** Eseguire il seguente comando seguente. Sostituisci *placeholder values* con le informazioni appropriate. ``` 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" }]' ``` **Importante** L'operazione di aggiornamento sostituisce l'intero array di fonti di dati. Includi tutte le fonti di dati che desideri conservare. **Elenca le applicazioni** Esegui il comando seguente: ``` aws opensearch list-applications \ --region region ``` **Eliminazione di un'applicazione** Esegui il comando seguente: ``` aws opensearch delete-application \ --region region \ --id application-id ``` **Revoca l'accesso agli endpoint VPC** Esegui il comando seguente: ``` aws opensearch revoke-vpc-endpoint-access \ --domain-name vpc-domain-name \ --service "application.opensearchservice.amazonaws.com" \ --region region ``` ## Riferimento rapido Le tabelle seguenti riassumono le principali differenze tra i tipi di dominio e i metodi di autenticazione. **Dominio pubblico rispetto al dominio VPC** | Aspetto | Dominio pubblico | Dominio VPC | | --- | --- | --- | | Autorizzazione degli endpoint VPC | Campo non obbligatorio | Obbligatoria: deve autorizzare application.opensearchservice.amazonaws.com | | Configurazione della rete | Nessuno | VPC, sottorete, gruppo di sicurezza con HTTPS (443) in ingresso | | Politica di accesso IAM | Richiesto | Richiesto | | Ruolo tra account | Obbligatorio per più account | Obbligatorio per più account | **Utente IAM rispetto all'utente IAM Identity Center** | Aspetto | Utente IAM | Utente IAM Identity Center | | --- | --- | --- | | Credenziali del piano dati | Credenziali IAM proprie dell'utente | Ruolo applicativo IAM Identity Center | | Controllo accessi | Policy di accesso al dominio | Policy di accesso al dominio e mappatura dei ruoli di backend | | Configurazione aggiuntiva | Nessuno | Ruolo dell'applicazione IAM Identity Center, user/group creazione, assegnazione delle applicazioni, mappatura dei ruoli di backend | | OpenSearch Configurazione dell'applicazione UI | Nessuna opzione IAM Identity Center | --iam-identity-center-options obbligatorio | ## Note importanti + `iamRoleForDataSourceArn`Deve essere nello stesso account del`dataSourceArn`. + `iamRoleForDataSourceArn`È richiesto solo per le fonti di dati tra account diversi. Omettilo per le fonti di dati dello stesso account. + Il ruolo tra account diversi richiede solo l'autorizzazione. `es:DescribeDomain` Non viene mai utilizzato per l'accesso al piano dati. + Per i domini VPC, è necessario configurare sia la policy IAM che l'autorizzazione degli endpoint VPC. + Versioni del motore supportate: OpenSearch 1.3 e successive. ## Risoluzione dei problemi | Problema | Risoluzione | | --- | --- | | La creazione dell'applicazione non riesce con «Impossibile accedere al dominio» | Verifica che il ruolo interaccount disponga dell'es:DescribeDomainautorizzazione e che la politica di attendibilità consenta l'accesso all'account di origine. | | L'associazione del dominio VPC non riesce | Assicurati che l'endpoint VPC sia autorizzato per. application.opensearchservice.amazonaws.com | | Accesso al piano dati negato per l'utente IAM | Verifica che la policy di accesso al dominio di destinazione consenta l'utente o il responsabile del ruolo IAM. | | Accesso al piano dati negato per l'utente IAM Identity Center | Verifica che la mappatura dei ruoli di backend includa l'ID del gruppo IAM Identity Center e che la policy del dominio consenta il ruolo dell'applicazione IAM Identity Center. | | Errore di mancata corrispondenza dell'account | Assicurati che iamRoleForDataSourceArn si trovi nello stesso account del dominio indataSourceArn. | # Funzionalità di ricerca tra cluster Utilizzando la [ricerca tra cluster](cross-cluster-search.md) in Amazon OpenSearch Serverless, puoi eseguire query e aggregazioni su più domini connessi. La ricerca tra cluster in Amazon OpenSearch Serverless utilizza i concetti di dominio di *origine e dominio* di *destinazione*. Una richiesta di ricerca tra cluster proviene da un dominio di origine. Il dominio di destinazione può appartenere a un dominio diverso Account AWS o Regione AWS (o entrambi) al dominio di origine da cui eseguire la query. Utilizzando la ricerca tra cluster, puoi configurare un dominio di origine da associare all' OpenSearch interfaccia utente nello stesso account e quindi creare connessioni ai domini di destinazione. Di conseguenza, puoi utilizzare l' OpenSearch interfaccia utente con i dati dei domini di destinazione anche se si trovano in un account o in una regione diversi. Paghi [AWS i costi standard di trasferimento](https://aws.amazon.com/opensearch-service/pricing/) dei dati per i dati trasferiti da e verso il OpenSearch Servizio Amazon. Non ti vengono addebitati costi per i dati trasferiti tra i nodi all'interno OpenSearch del tuo dominio Service. Per ulteriori informazioni sui costi di «ingresso» e «uscita» dei dati, consulta la pagina dei prezzi *On-Demand di Amazon EC2* per il [trasferimento dei dati](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer). Puoi utilizzare la ricerca tra cluster come meccanismo per associare l' OpenSearch interfaccia utente a cluster in un account o in una regione diversa. Per impostazione predefinita, le richieste tra domini sono crittografate in transito come parte della crittografia. node-to-node **Nota** Lo OpenSearch strumento open source documenta anche la ricerca [tra cluster](https://opensearch.org/docs/latest/search-plugins/cross-cluster-search/). Tieni presente che la configurazione dello strumento open source differisce in modo significativo per i cluster open source rispetto ai domini Amazon OpenSearch Serverless gestiti. In particolare, in Amazon OpenSearch Serverless, si configurano connessioni tra cluster utilizzando le richieste Console di gestione AWS anziché utilizzando. `cURL` Il servizio gestito utilizza AWS Identity and Access Management (IAM) per l'autenticazione tra cluster oltre al controllo granulare degli accessi. Pertanto, consigliamo di utilizzare il contenuto di questo argomento per configurare la ricerca tra cluster per i domini anziché la documentazione open source. OpenSearch **Differenze funzionali quando si utilizza la ricerca tra cluster** Rispetto ai domini normali, i domini di destinazione creati utilizzando la ricerca tra cluster presentano le seguenti differenze e requisiti funzionali: + Non è possibile scrivere o eseguire `PUT` comandi nel cluster remoto. L'accesso al cluster remoto è di *sola lettura*. + Sia il dominio di origine che quello di destinazione devono essere OpenSearch domini. Non puoi connettere un dominio Elasticsearch o cluster OpenSearch /Elasticsearch autogestiti per l'interfaccia utente. OpenSearch + Un dominio può avere un massimo di 20 connessioni ad altri domini. Ciò include sia le connessioni in uscita che quelle in entrata. + Il dominio di origine deve trovarsi nella stessa versione o in una versione successiva del dominio OpenSearch di destinazione. Se desideri configurare connessioni bidirezionali tra due domini, i due domini devono avere la stessa versione. Ti consigliamo di aggiornare entrambi i domini alla versione più recente prima di effettuare la connessione. Se devi aggiornare i domini dopo aver configurato la connessione bidirezionale, devi prima eliminare la connessione e poi ricrearla. + Non è possibile utilizzare dizionari personalizzati o SQL con i cluster remoti. + Non puoi utilizzarlo per CloudFormation connettere domini. + Non è possibile utilizzare la ricerca tra cluster su istanze M3 o istanze espandibili (T2 e T3). + La ricerca tra cluster non funziona per le raccolte Amazon OpenSearch Serverless. **Prerequisiti di ricerca tra cluster per l'interfaccia utente OpenSearch** Prima di configurare la ricerca tra cluster con due OpenSearch domini, assicurati che i domini soddisfino i seguenti requisiti: + Il controllo granulare degli accessi è abilitato per entrambi i domini + Node-to-node la crittografia è abilitata per entrambi i domini **Topics** + [Configurazione delle autorizzazioni di accesso per l'accesso ai dati tra aree geografiche e tra account con la ricerca tra cluster](#cross-cluster-search-security) + [Creazione di una connessione tra domini](#cross-cluster-search-create-connection) + [Test della configurazione di sicurezza per l'accesso ai dati tra regioni e account diversi con la ricerca tra cluster](#cross-cluster-search-security-testing) + [Eliminazione di una connessione](#cross-cluster-search-deleting-connection) ## Configurazione delle autorizzazioni di accesso per l'accesso ai dati tra aree geografiche e tra account con la ricerca tra cluster Quando invii una richiesta di ricerca tra cluster al dominio di origine, il dominio valuta tale richiesta in base alla propria politica di accesso al dominio. La ricerca tra cluster richiede un controllo granulare degli accessi. Di seguito è riportato un esempio con una politica di accesso aperto sul dominio di origine. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:us-east-1:111222333444:domain/src-domain/*" } ] } ``` ------ **Nota** Se includi indici remoti nel percorso, devi codificare in formato URL l'URI nell'ARN del dominio. Ad esempio, utilizzate il seguente formato ARN: `:arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst%3Aremote_index` Non utilizzare il seguente formato ARN: `arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst:remote_index.` Se si sceglie di utilizzare una politica di accesso restrittiva oltre al controllo granulare degli accessi, la politica deve almeno consentire l'accesso a. `es:ESHttpGet` Di seguito è riportato un esempio: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111222333444:user/john-doe" ] }, "Action": "es:ESHttpGet", "Resource": "arn:aws:es:us-east-1:111122223333:domain/my-domain/*" } ] } ``` ------ Il [controllo granulare degli accessi](fgac.md) sul dominio di origine valuta la richiesta per determinare se è firmata con credenziali di base IAM o HTTP valide. In caso affermativo, il controllo granulare degli accessi valuta successivamente se l'utente è autorizzato a eseguire la ricerca e accedere ai dati. Di seguito sono riportati i requisiti di autorizzazione per le ricerche: + Se la richiesta cerca solo dati nel dominio di destinazione (ad esempio`dest-alias:dest-index/_search)`, le autorizzazioni sono richieste solo nel dominio di destinazione). + Se la richiesta cerca dati su entrambi i domini (ad esempio`source-index,dest-alias:dest-index/_search)`, le autorizzazioni sono necessarie su entrambi i domini). + Per utilizzare un controllo granulare degli accessi, `indices:admin/shards/search_shards` è necessaria l'autorizzazione in aggiunta alle autorizzazioni standard di lettura o ricerca per gli indici pertinenti. Il dominio di origine invia la richiesta al dominio di destinazione. Il dominio di destinazione valuta la richiesta in base alla policy di accesso al dominio. Per supportare tutte le funzionalità OpenSearch dell'interfaccia utente, come l'indicizzazione dei documenti e l'esecuzione di ricerche standard, è necessario impostare le autorizzazioni complete. Di seguito è riportato un esempio della nostra politica consigliata sul dominio di destinazione: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:us-east-2:111222333444:domain/my-destination-domain/*" }, { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESCrossClusterGet", "Resource": "arn:aws:es:us-east-2:111222333444:domain/" } ] } ``` ------ Se desideri eseguire solo ricerche di base, il requisito minimo richiesto dalla policy è l'`es:ESCrossClusterGet`autorizzazione da applicare al dominio di destinazione senza il supporto dei caratteri jolly. Ad esempio, nella politica precedente, è necessario specificare il nome di dominio con e senza. */my-destination-domain* */my-destination-domain/\$1* In questo caso, il dominio di destinazione esegue la ricerca e restituisce i risultati al dominio di origine. Il dominio di origine combina i propri risultati (se presenti) con i risultati del dominio di destinazione e li restituisce all'utente. ## Creazione di una connessione tra domini Una connessione di ricerca tra cluster è unidirezionale dal dominio di origine al dominio di destinazione. Ciò significa che i domini di destinazione (in un account o in una regione diversi) non possono interrogare il dominio di origine, che è locale all'interfaccia utente. OpenSearch Il dominio di origine crea una connessione *in uscita* al dominio di destinazione. Il dominio di destinazione riceve una richiesta di connessione *in entrata* dal dominio di origine. ![\[Questa immagine mostra che una connessione di ricerca tra cluster è unidirezionale dal dominio di origine al dominio di destinazione.\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/ui-oubound-inbound-connections.png) **Per creare una connessione tra domini** 1. Accedi alla console di Amazon OpenSearch Service da [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home). 1. Nella barra di navigazione a sinistra, scegli **Domini**. 1. Scegli il nome di un dominio da utilizzare come dominio di origine, quindi scegli la scheda **Connessioni**. 1. Nell'area **Connessioni in uscita**, scegli **Richiesta**. 1. Per **Alias di connessione**, specifica un nome per la connessione. L'alias di connessione viene utilizzato nell' OpenSearch interfaccia utente per selezionare i domini di destinazione. 1. Per la **modalità di connessione**, scegli **Direct** per le ricerche o la replica tra cluster. 1. **Per specificare che la connessione deve ignorare i cluster non disponibili durante una ricerca, seleziona la casella Ignora i cluster non disponibili.** La scelta di questa opzione garantisce che le query tra cluster restituiscano risultati parziali indipendentemente dagli errori su uno o più cluster remoti. 1. Per **Cluster di destinazione**, scegli tra **Connetti a un cluster in questo Account AWS** e **Connetti a un cluster in un altro Account AWS**. 1. Per l'**ARN del dominio remoto**, inserisci l'Amazon Resource Name (ARN) per il cluster. L'ARN del dominio può essere posizionato nell'area **Informazioni generali** della pagina di dettaglio del dominio. Il dominio deve soddisfare i seguenti requisiti: + L'ARN deve essere nel formato. `arn:partition:es:regionaccount-id:type/domain-id` Esempio: `arn:aws:es:us-east-2:111222333444:domain/my-domain` + Il dominio deve essere configurato per utilizzare la OpenSearch versione 1.0 (o successiva) o la versione 6.7 di Elasticsearch (o successiva). + Il controllo granulare degli accessi deve essere abilitato sul dominio. + Il dominio deve essere in esecuzione. OpenSearch 1. Scegli **Richiedi**. La ricerca tra cluster convalida innanzitutto la richiesta di connessione per assicurare che i prerequisiti siano soddisfatti. Se i domini sono incompatibili, la richiesta di connessione entra nello `Validation failed` stato. Se la richiesta di connessione viene convalidata correttamente, viene inviata al dominio di destinazione, dove deve essere approvata. Fino a quando non viene concessa questa approvazione, la connessione rimane in uno `Pending acceptance` stato. Quando la richiesta di connessione viene accettata nel dominio di destinazione, lo stato cambia in `Active` e il dominio di destinazione diventa disponibile per le query. La pagina del dominio mostra i dettagli generali dello stato del dominio e dello stato dell'istanza del dominio di destinazione. Solo i proprietari dei domini dispongono della flessibilità necessaria per creare, visualizzare, rimuovere e monitorare le connessioni da o verso i propri domini. Una volta stabilita la connessione, tutto il traffico che scorre tra i nodi dei domini connessi viene crittografato. Quando connetti un dominio VPC a un dominio non VPC e il dominio non VPC è un endpoint pubblico in grado di ricevere traffico da Internet, il traffico intercluster tra i domini è ancora crittografato e sicuro. ## Test della configurazione di sicurezza per l'accesso ai dati tra regioni e account diversi con la ricerca tra cluster Dopo aver impostato le autorizzazioni di accesso per l'accesso ai dati tra aree geografiche e tra account con la ricerca tra cluster, ti consigliamo di testare la configurazione utilizzando una piattaforma di terze parti per lo sviluppo collaborativo di [https://www.postman.com/](https://www.postman.com/)API. **Per impostare la configurazione di sicurezza utilizzando Postman** 1. Nel dominio di destinazione, indicizza un documento. Di seguito è riportato un esempio di richiesta: ``` POST https://dst-domain.us-east-1.es.amazonaws.com/books/_doc/1 { "Dracula": "Bram Stoker" } ``` 1. Per eseguire una query su questo indice dal dominio di origine, includere l'alias di connessione del dominio di destinazione all'interno della query. È possibile trovare l'alias di connessione nella scheda Connessioni nel pannello di controllo del dominio. Di seguito sono riportati un esempio di richiesta e una risposta troncata: ``` GET https://src-domain.us-east-1.es.amazonaws.com/connection_alias:books/_search { ... "hits": [ { "_index": "source-destination:books", "_type": "_doc", "_id": "1", "_score": 1, "_source": { "Dracula": "Bram Stoker" } } ] } ``` 1. (Facoltativo) È possibile creare una configurazione che includa più domini in un'unica ricerca. Ad esempio, supponiamo di aver impostato quanto segue: Una connessione tra `domain-a` a`domain-b`, con un alias di connessione denominato `cluster_b` Una connessione tra `domain-a` a`domain-c`, con un alias di connessione denominato `cluster_c` In questo caso, le ricerche includono il contenuto `domain-a``domain-b`, e. `domain-c` Di seguito sono riportati alcuni esempi di richiesta e risposta: Richiesta ``` GET https://src-domain.us-east-1.es.amazonaws.com/local_index,cluster_b:b_index,cluster_c:c_index/_search { "query": { "match": { "user": "domino" } } } ``` Risposta: ``` { "took": 150, "timed_out": false, "_shards": { "total": 3, "successful": 3, "failed": 0, "skipped": 0 }, "_clusters": { "total": 3, "successful": 3, "skipped": 0 }, "hits": { "total": 3, "max_score": 1, "hits": [ { "_index": "local_index", "_type": "_doc", "_id": "0", "_score": 1, "_source": { "user": "domino", "message": "This is message 1", "likes": 0 } }, { "_index": "cluster_b:b_index", "_type": "_doc", "_id": "0", "_score": 2, "_source": { "user": "domino", "message": "This is message 2", "likes": 0 } }, { "_index": "cluster_c:c_index", "_type": "_doc", "_id": "0", "_score": 3, "_source": { "user": "domino", "message": "This is message 3", "likes": 0 } } ] } } ``` Se hai scelto di non ignorare i cluster non disponibili nella configurazione della connessione, tutti i cluster di destinazione che cerchi devono essere disponibili affinché la richiesta di ricerca venga eseguita correttamente. In caso contrario, l'intera richiesta avrà esito negativo: anche se uno dei domini non è disponibile non verrà restituito alcun risultato della ricerca. ## Eliminazione di una connessione L'eliminazione di una connessione interrompe tutte le operazioni di ricerca tra cluster nel dominio di destinazione. È possibile eseguire la procedura seguente sul dominio di origine o di destinazione per rimuovere la connessione. Dopo aver rimosso la connessione, questa rimane visibile con uno stato `Deleted` di 15 giorni. Non è possibile eliminare un dominio con connessioni tra cluster attive. Per eliminare un dominio, rimuovere innanzitutto tutte le connessioni in ingresso e in uscita da tale dominio. Questo per essere certi di considerare gli utenti del dominio tra cluster prima di eliminare il dominio. **Come eliminare una connessione** 1. Accedi alla console di Amazon OpenSearch Service da [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home). 1. Nella barra di navigazione a sinistra, scegli **Domini**. 1. Scegli il nome di un dominio da eliminare, quindi scegli la scheda **Connessioni**. 1. Seleziona il nome di una connessione da eliminare. 1. Scegli **Elimina**, quindi conferma l'eliminazione.