As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Acesso a dados entre regiões e contas OpenSearch A interface do usuário suporta o acesso a dados de OpenSearch domínios em diferentes Conta da AWS s e Região da AWS s. Você pode escolher entre duas abordagens, dependendo de suas necessidades. A tabela a seguir compara as duas abordagens. **nota** Tanto o acesso a dados entre contas quanto a pesquisa entre clusters funcionam somente com OpenSearch domínios. Nenhuma das abordagens oferece suporte a coleções OpenSearch sem servidor. | Aspecto | Acesso a dados entre contas | Pesquisa entre clusters | | --- | --- | --- | | Recurso | Associe domínios de outras contas como fontes de dados diretas na OpenSearch interface do usuário | Consulte dados em domínios conectados usando conexões de pesquisa entre clusters | | Mecanismo | Acesso direto — a OpenSearch interface do usuário se conecta diretamente ao domínio de destino em outra conta | Acesso indireto — requer um domínio local na mesma conta da OpenSearch interface do usuário para retransmitir solicitações para domínios remotos | | Suporte entre contas. | Sim | Sim | | Suporte entre regiões | Não — os domínios de origem e de destino devem estar no mesmo Região da AWS | Sim — os domínios de origem e destino podem estar em diferentes s Região da AWS | | Unifique dados em todos os domínios | Não — cada domínio é consultado de forma independente como uma fonte de dados separada | Sim — uma única consulta pode agregar resultados de vários domínios conectados | | Métodos de autenticação | IAM e Centro de Identidade do AWS IAM | IAM (com controle de acesso refinado) | | Complexidade da configuração | Inferior — requer uma função do IAM entre contas para validação | Superior — requer conexões entre clusters, políticas de acesso em ambos os domínios e controle de acesso refinado | | Visibilidade da fonte de dados na OpenSearch interface | Cada domínio entre contas aparece como uma fonte de dados separada | Os domínios remotos são acessados por meio dos aliases de conexão do domínio de origem local | | Acesso de gravação ao domínio remoto | Sim — controlado pela política de acesso do domínio de destino | Não — a pesquisa entre clusters fornece acesso somente de leitura a domínios remotos | **Topics** + [Acesso a dados entre contas a domínios OpenSearch](application-cross-account-data-access-domains.md) + [Pesquisa entre clusters](application-cross-cluster-search.md) # Acesso a dados entre contas a domínios OpenSearch Você pode configurar seus aplicativos de OpenSearch interface de usuário em uma conta para acessar OpenSearch domínios em contas diferentes. Ao criar um aplicativo de OpenSearch interface de usuário com fontes de dados entre contas, você fornece um `iamRoleForDataSourceArn` que aponta para uma função do IAM na conta de destino. OpenSearch A interface do usuário valida a solicitação assumindo essa função e ligando `es:DescribeDomain` para verificar a acessibilidade do domínio. A função entre contas é usada somente para validação do plano de controle. O acesso ao plano de dados é controlado separadamente pela política de acesso do domínio de destino. **Código de exemplo** Os exemplos de código neste tópico são apenas para fins ilustrativos. Eles demonstram funcionalidade básica e podem não incluir tratamento de erros, melhores práticas de segurança ou recursos prontos para produção. Antes de usar o código de amostra na produção, revise-o e modifique-o para atender aos seus requisitos específicos e teste minuciosamente em seu ambiente. ## Principais conceitos Conta de origem O Conta da AWS que hospeda seu aplicativo de OpenSearch interface do usuário. Conta de destino O Conta da AWS local onde o OpenSearch domínio reside. Função entre contas Uma função do IAM na conta de destino que é usada somente para validação do plano de controle. Essa função requer somente a `es:DescribeDomain` permissão. Função do aplicativo IAM Identity Center Uma função do IAM na conta de origem que é usada para acessar o plano de dados do usuário do IAM Identity Center. ## Pré-requisitos Antes de configurar o acesso a dados entre contas, verifique se você tem o seguinte: + AWS CLI instalado e configurado + Acesso à origem e ao destino Conta da AWS + Para fluxos do IAM Identity Center: uma instância Centro de Identidade do AWS IAM organizacional ## Cenários Escolha o cenário que corresponda ao método de autenticação e à configuração do domínio: + [Cenário 1: usuário do IAM acessando um domínio público](#cross-account-scenario-1) + [Cenário 2: usuário do IAM Identity Center acessando um domínio público](#cross-account-scenario-2) + [Cenário 3: usuário do IAM acessando um domínio VPC](#cross-account-scenario-3) + [Cenário 4: usuário do IAM Identity Center acessando um domínio VPC](#cross-account-scenario-4) ## Cenário 1: usuário do IAM acessando um domínio público ### Etapa 1: criar a função IAM entre contas (conta de destino) Crie uma função do IAM na conta de destino que permita que a conta de origem a assuma para validação do domínio. **Para criar a função entre contas** 1. Crie uma política de confiança que permita que a conta de origem assuma a função: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crie a função: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crie uma política de permissões com apenas a `es:DescribeDomain` ação: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Anexe a política de permissões ao perfil: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Etapa 2: criar o OpenSearch domínio (conta de destino) Crie um OpenSearch domínio na conta de destino com controle de acesso refinado e criptografia habilitados: ``` 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 ``` Aguarde até que o status do domínio se torne `Active` antes de continuar. ### Etapa 3: criar o aplicativo de OpenSearch interface do usuário (conta de origem) Crie o aplicativo na conta de origem com a fonte de dados entre contas: ``` 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":"[\"*\"]"}]' ``` ### Etapa 4: verificar e acessar Recupere os detalhes do aplicativo para obter o URL do endpoint: ``` aws opensearch get-application \ --region region \ --id application-id ``` + Navegue até o URL do endpoint do aplicativo a partir da resposta. + Faça login com as credenciais do IAM. + O usuário do IAM assina as solicitações do plano de dados com suas próprias credenciais. + A política de acesso ao domínio de destino controla quais dados o usuário pode acessar. ## Cenário 2: usuário do IAM Identity Center acessando um domínio público ### Etapa 1: criar a função IAM entre contas (conta de destino) Crie uma função do IAM na conta de destino que permita que a conta de origem a assuma para validação do domínio. **Para criar a função entre contas** 1. Crie uma política de confiança que permita que a conta de origem assuma a função: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crie a função: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crie uma política de permissões com apenas a `es:DescribeDomain` ação: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Anexe a política de permissões ao perfil: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Etapa 2: criar o OpenSearch domínio (conta de destino) Crie um OpenSearch domínio na conta de destino. Use o mesmo comando de[Etapa 2: criar o OpenSearch domínio (conta de destino)](#scenario-1-step-2), mas atualize a política de acesso para permitir o papel do aplicativo IAM Identity Center na conta de origem: ``` { "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/*" }] } ``` Aguarde até que o status do domínio se torne `Active` antes de continuar. ### Etapa 3: criar a função do IAM para o aplicativo IAM Identity Center (conta de origem) Crie uma função do IAM na conta de origem que a OpenSearch UI usa para acessar o plano de dados do usuário do IAM Identity Center. **Para criar a função do aplicativo IAM Identity Center** 1. Crie uma política de confiança: ``` { "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. Crie uma política de permissões: ``` { "Version": "2012-10-17", "Statement": [{ "Sid": "OpenSearchDomain", "Effect": "Allow", "Action": ["es:ESHttp*"], "Resource": "*" }] } ``` 1. Crie a função e anexe as políticas: ``` 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 ``` ### Etapa 4: criar o aplicativo de OpenSearch interface do usuário com o IAM Identity Center (conta de origem) ``` 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":"[\"*\"]"}]' ``` ### Etapa 5: criar e atribuir usuários e grupos do IAM Identity Center **Crie um usuário do IAM Identity Center** Execute o comando a seguir. Substitua *placeholder values* por suas próprias informações. ``` 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 ``` **Crie um grupo do IAM Identity Center e adicione o usuário** Execute os seguintes comandos : ``` 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 ``` **Atribua o usuário ou grupo ao aplicativo** Execute este comando: . ``` 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 ``` **Configurar o mapeamento de funções de back-end no domínio de destino** Mapeie o grupo do IAM Identity Center para uma função de OpenSearch segurança no domínio de destino: ``` 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": [] }' ``` ### Etapa 6: verificar e acessar ``` aws opensearch get-application \ --region region \ --id application-id ``` + Navegue até o URL do endpoint do aplicativo. + Faça login com as credenciais de usuário do IAM Identity Center. + As solicitações de dados dos usuários do IAM Identity Center são assinadas com a função de aplicativo do IAM Identity Center, não com a função entre contas. + Mapeamentos de funções de back-end nas permissões de acesso aos dados de controle de domínio. ## Cenário 3: usuário do IAM acessando um domínio VPC ### Etapa 1: criar a função IAM entre contas (conta de destino) Crie uma função do IAM na conta de destino que permita que a conta de origem a assuma para validação do domínio. **Para criar a função entre contas** 1. Crie uma política de confiança que permita que a conta de origem assuma a função: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crie a função: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crie uma política de permissões com apenas a `es:DescribeDomain` ação: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Anexe a política de permissões ao perfil: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Etapa 2: configurar a VPC (conta de destino) Ignore essa etapa se já existir uma VPC na conta de destino. ``` # 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 ``` Saiba mais sobre a [criação de domínios VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html). ### Etapa 3: criar o domínio VPC (conta de destino) ``` 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 ``` Aguarde até que o status do domínio se torne `Active` antes de continuar. ### Etapa 4: autorizar o VPC endpoint para o principal do serviço de interface OpenSearch do usuário (conta de destino) **Importante** Essa é uma etapa crítica exclusiva dos domínios VPC. O serviço de OpenSearch interface do usuário deve ser explicitamente autorizado a acessar o VPC endpoint. ``` # 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 ``` Resposta esperada: ``` { "AuthorizedPrincipalList": [ { "PrincipalType": "AWS_SERVICE", "Principal": "application.opensearchservice.amazonaws.com" } ] } ``` ### Etapa 5: criar o aplicativo de OpenSearch interface do usuário (conta de origem) ``` 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":"[\"*\"]"}]' ``` ### Etapa 6: verificar e acessar Recupere os detalhes do aplicativo para obter o URL do endpoint: ``` aws opensearch get-application \ --region region \ --id application-id ``` + Navegue até o URL do endpoint do aplicativo a partir da resposta. + Faça login com as credenciais do IAM. + O usuário do IAM assina as solicitações do plano de dados com suas próprias credenciais. + A política de acesso ao domínio de destino controla quais dados o usuário pode acessar. ## Cenário 4: usuário do IAM Identity Center acessando um domínio VPC ### Etapa 1: criar a função IAM entre contas (conta de destino) Crie uma função do IAM na conta de destino que permita que a conta de origem a assuma para validação do domínio. **Para criar a função entre contas** 1. Crie uma política de confiança que permita que a conta de origem assuma a função: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:root" }, "Action": "sts:AssumeRole" }] } ``` 1. Crie a função: ``` aws iam create-role \ --role-name OpenSearchUIAccessRole \ --assume-role-policy-document file://trust-policy.json ``` 1. Crie uma política de permissões com apenas a `es:DescribeDomain` ação: ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "es:DescribeDomain", "Resource": "arn:aws:es:region:target-account-id:domain/*" }] } ``` 1. Anexe a política de permissões ao perfil: ``` aws iam put-role-policy \ --role-name OpenSearchUIAccessRole \ --policy-name ValidationOnly \ --policy-document file://permissions-policy.json ``` ### Etapa 2: configurar a VPC (conta de destino) Ignore essa etapa se já existir uma VPC na conta de destino. ``` # 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 ``` Saiba mais sobre a [criação de domínios VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html). ### Etapa 3: criar o domínio VPC (conta de destino) Use o mesmo comando de[Etapa 3: criar o domínio VPC (conta de destino)](#scenario-3-step-3), mas atualize a política de acesso para permitir o papel do aplicativo IAM Identity Center na conta de origem: ``` { "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/*" }] } ``` Aguarde até que o status do domínio se torne `Active` antes de continuar. ### Etapa 4: autorizar o VPC endpoint para o principal do serviço de interface OpenSearch do usuário (conta de destino) **Importante** Essa é uma etapa crítica exclusiva dos domínios VPC. O serviço de OpenSearch interface do usuário deve ser explicitamente autorizado a acessar o VPC endpoint. ``` # 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 ``` Resposta esperada: ``` { "AuthorizedPrincipalList": [ { "PrincipalType": "AWS_SERVICE", "Principal": "application.opensearchservice.amazonaws.com" } ] } ``` ### Etapa 5: criar a função do IAM para o aplicativo IAM Identity Center (conta de origem) Crie uma função do IAM na conta de origem que a OpenSearch UI usa para acessar o plano de dados do usuário do IAM Identity Center. **Para criar a função do aplicativo IAM Identity Center** 1. Crie uma política de confiança: ``` { "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. Crie uma política de permissões: ``` { "Version": "2012-10-17", "Statement": [{ "Sid": "OpenSearchDomain", "Effect": "Allow", "Action": ["es:ESHttp*"], "Resource": "*" }] } ``` 1. Crie a função e anexe as políticas: ``` 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 ``` ### Etapa 6: criar o aplicativo de OpenSearch interface do usuário com o IAM Identity Center (conta de origem) ``` 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":"[\"*\"]"}]' ``` ### Etapa 7: criar e atribuir usuários e grupos do IAM Identity Center **Crie um usuário do IAM Identity Center** Execute o comando a seguir. Substitua *placeholder values* por suas próprias informações. ``` 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 ``` **Crie um grupo do IAM Identity Center e adicione o usuário** Execute os seguintes comandos : ``` 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 ``` **Atribua o usuário ou grupo ao aplicativo** Execute este comando: . ``` 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 ``` **Configurar o mapeamento de funções de back-end no domínio de destino** Mapeie o grupo do IAM Identity Center para uma função de OpenSearch segurança no domínio de destino: ``` 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": [] }' ``` ### Etapa 8: verificar e acessar ``` aws opensearch get-application \ --region region \ --id application-id ``` + Navegue até o URL do endpoint do aplicativo. + Faça login com as credenciais de usuário do IAM Identity Center. + As solicitações de dados dos usuários do IAM Identity Center são assinadas com a função de aplicativo do IAM Identity Center, não com a função entre contas. + Mapeamentos de funções de back-end nas permissões de acesso aos dados de controle de domínio. ## Como gerenciar aplicações do **Atualizar um aplicativo com fontes de dados entre contas** Execute o comando a seguir. Substitua *placeholder values* por suas próprias informações. ``` 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** A operação de atualização substitui toda a matriz de fontes de dados. Inclua todas as fontes de dados que você deseja manter. **Listar aplicativos** Execute este comando: . ``` aws opensearch list-applications \ --region region ``` **Deleta a aplicação** Execute este comando: . ``` aws opensearch delete-application \ --region region \ --id application-id ``` **Revogar o acesso ao VPC endpoint** Execute este comando: . ``` aws opensearch revoke-vpc-endpoint-access \ --domain-name vpc-domain-name \ --service "application.opensearchservice.amazonaws.com" \ --region region ``` ## Referência rápida As tabelas a seguir resumem as principais diferenças entre os tipos de domínio e os métodos de autenticação. **Domínio público comparado ao domínio VPC** | Aspecto | Domínio público | Domínio VPC | | --- | --- | --- | | Autorização de VPC endpoint | Não obrigatório | Obrigatório — deve autorizar application.opensearchservice.amazonaws.com | | Configuração da rede | Nenhum | VPC, sub-rede, grupo de segurança com entrada HTTPS (443) | | Política de acesso do IAM | Obrigatório | Obrigatório | | Função entre contas | Obrigatório para contas cruzadas | Obrigatório para contas cruzadas | **Usuário do IAM comparado ao usuário do IAM Identity Center** | Aspecto | IAM user (Usuário do IAM) | Usuários do IAM Identity Center | | --- | --- | --- | | Credenciais do plano de dados | Credenciais do IAM do próprio usuário | Função do aplicativo IAM Identity Center | | Controle de acesso | Política de acesso ao domínio | Política de acesso ao domínio e mapeamentos de funções de back-end | | Configuração adicional | Nenhum | Função do aplicativo IAM Identity Center, user/group criação, atribuição de aplicativos, mapeamento de funções de back-end | | OpenSearch Configuração do aplicativo de interface do usuário | Nenhuma opção do IAM Identity Center | --iam-identity-center-options obrigatório | ## Observações importantes + O `iamRoleForDataSourceArn` deve estar na mesma conta do`dataSourceArn`. + Isso só `iamRoleForDataSourceArn` é necessário para fontes de dados entre contas. Omita-o para fontes de dados da mesma conta. + A função entre contas só precisa da `es:DescribeDomain` permissão. Ele nunca é usado para acesso ao plano de dados. + Para domínios VPC, tanto a política do IAM quanto a autorização do VPC endpoint devem ser configuradas. + Versões de motor suportadas: OpenSearch 1.3 e superiores. ## Solução de problemas | Problema | Resolução | | --- | --- | | A criação do aplicativo falha com “Não é possível acessar o domínio” | Verifique se a função entre contas tem a es:DescribeDomain permissão e se a política de confiança permite a conta de origem. | | Falha na associação de domínio VPC | Certifique-se de que o VPC endpoint esteja autorizado para. application.opensearchservice.amazonaws.com | | Acesso ao plano de dados negado para o usuário do IAM | Verifique se a política de acesso ao domínio de destino permite o usuário ou o responsável pela função do IAM. | | Acesso ao plano de dados negado para o usuário do IAM Identity Center | Verifique se o mapeamento da função de back-end inclui o ID do grupo do IAM Identity Center e se a política de domínio permite a função do aplicativo do IAM Identity Center. | | Erro de incompatibilidade de conta | Certifique-se de que iamRoleForDataSourceArn esteja na mesma conta do domínio emdataSourceArn. | # Pesquisa entre clusters Usando a [pesquisa entre clusters](cross-cluster-search.md) no Amazon OpenSearch Serverless, você pode realizar consultas e agregações em vários domínios conectados. *A pesquisa entre clusters no Amazon OpenSearch Serverless usa os conceitos de domínio de *origem e domínio* de destino.* Uma solicitação de pesquisa entre clusters começa em um domínio de origem. O domínio de destino pode estar em um domínio diferente Conta da AWS ou Região da AWS (ou ambos) do domínio de origem para consulta. Usando a pesquisa entre clusters, você pode configurar um domínio de origem para associar à sua OpenSearch interface de usuário na mesma conta e, em seguida, criar conexões com os domínios de destino. Como resultado, você pode usar a OpenSearch interface do usuário com dados dos domínios de destino, mesmo se eles estiverem em uma conta ou região diferente. Você paga [taxas de transferência de AWS dados padrão](https://aws.amazon.com/opensearch-service/pricing/) para dados transferidos para dentro e para fora do Amazon OpenSearch Service. Você não é cobrado pelos dados transferidos entre os nós dentro do seu domínio OpenSearch de serviço. Para mais informações sobre as cobranças por dados “entrada” e “saída”, consulte [Transferência de dados](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) na página *Preço sob demanda do Amazon EC2*. Você pode usar a pesquisa entre clusters como mecanismo para que sua OpenSearch interface de usuário seja associada a clusters em uma conta ou região diferente. Por padrão, as solicitações entre domínios são criptografadas em trânsito como parte da node-to-node criptografia. **nota** A OpenSearch ferramenta de código aberto também documenta a [pesquisa entre clusters](https://opensearch.org/docs/latest/search-plugins/cross-cluster-search/). Observe que a configuração da ferramenta de código aberto difere significativamente para clusters de código aberto em comparação com os domínios gerenciados do Amazon OpenSearch Serverless. Mais notavelmente, no Amazon OpenSearch Serverless, você configura conexões entre clusters usando o Console de gerenciamento da AWS em vez de usar solicitações. `cURL` Além disso, o serviço gerenciado usa o AWS Identity and Access Management (IAM) para autenticação entre clusters, além do controle de acesso refinado. Portanto, recomendamos usar o conteúdo deste tópico para configurar a pesquisa entre clusters para seus domínios em vez da documentação de código OpenSearch aberto. **Diferenças funcionais ao usar a pesquisa entre clusters** Em comparação com os domínios regulares, os domínios de destino criados usando a pesquisa entre clusters têm as seguintes diferenças e requisitos funcionais: + Você não pode gravar nem executar comandos `PUT` no cluster remoto. Seu acesso ao cluster remoto é *somente leitura*. + Tanto o domínio de origem quanto o de destino devem ser OpenSearch domínios. Você não pode conectar um domínio do Elasticsearch ou clusters autogerenciados do OpenSearch /Elasticsearch para interface do usuário. OpenSearch + Um domínio pode ter um máximo de 20 conexões com outros domínios. Isso inclui conexões de saída e entrada. + O domínio de origem deve estar na mesma versão ou em uma versão superior à OpenSearch do domínio de destino. Se você quiser configurar conexões bidirecionais entre dois domínios, os dois domínios devem ser da mesma versão. Recomendamos atualizar os dois domínios para a versão mais recente antes de fazer a conexão. Se você precisar atualizar domínios depois de configurar a conexão bidirecional, primeiro exclua e depois recrie a conexão. + Não é possível usar dicionários personalizados ou SQL com clusters remotos. + Você não pode usar CloudFormation para conectar domínios. + Não é possível usar a pesquisa entre clusters em instâncias M3 ou expansíveis (T2 e T3). + A pesquisa entre clusters não funciona para coleções Amazon OpenSearch Serverless. **Pré-requisitos de pesquisa entre clusters para UI OpenSearch** Antes de configurar a pesquisa entre clusters com dois OpenSearch domínios, certifique-se de que seus domínios atendam aos seguintes requisitos: + O controle de acesso refinado está habilitado no domínio + Node-to-node a criptografia está habilitada para ambos os domínios **Topics** + [Configurar permissões de acesso para acesso a dados entre regiões e entre contas com pesquisa entre clusters](#cross-cluster-search-security) + [Criar uma conexão entre domínios](#cross-cluster-search-create-connection) + [Testar a configuração de segurança para acesso a dados entre regiões e contas com pesquisa entre clusters](#cross-cluster-search-security-testing) + [Excluir uma conexão](#cross-cluster-search-deleting-connection) ## Configurar permissões de acesso para acesso a dados entre regiões e entre contas com pesquisa entre clusters Quando você envia uma solicitação de pesquisa entre clusters para o domínio de origem, o domínio avalia essa solicitação em relação à sua política de acesso ao domínio. A pesquisa entre clusters requer controle de acesso refinado. Este é um exemplo de uma política de acesso aberto no domínio de origem. ------ #### [ 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 você incluir índices remotos no caminho, deverá codificar em URL o URI no ARN do domínio. Por exemplo, use o seguinte formato do ARN: `:arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst%3Aremote_index` Não use o seguinte formato de ARN: `arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst:remote_index.` Se você escolher por usar uma política de acesso restritiva além do controle de acesso refinado, sua política deverá permitir o acesso, pelo menos, a `es:ESHttpGet`. Este é um exemplo: ------ #### [ 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/*" } ] } ``` ------ O [controle de acesso refinado](fgac.md) no domínio de origem avalia a solicitação para determinar se ela está assinada com credenciais de autenticação básica HTTP ou do IAM. Se estiver, o controle de acesso refinado avalia então se o usuário tem permissão para realizar a pesquisa e acessar os dados. Os requisitos de permissão para pesquisas são os seguintes: + Se a solicitação pesquisar somente dados no domínio de destino (por exemplo, `dest-alias:dest-index/_search)`), serão necessárias permissões somente no domínio de destino. + Se a solicitação pesquisar dados em ambos os domínios (por exemplo,`source-index,dest-alias:dest-index/_search)`) serão necessárias permissões em ambos os domínios. + Para usar o controle de acesso detalhado, a permissão `indices:admin/shards/search_shards` é necessária além das permissões padrão de leitura ou pesquisa para os índices relevantes. O domínio de origem passa a solicitação para o domínio de destino. O domínio de destino avalia essa solicitação em relação à política de acesso ao domínio. Para oferecer suporte a todos os recursos da OpenSearch interface do usuário, como indexação de documentos e realização de pesquisas padrão, é necessário definir permissões completas. Este é um exemplo de nossa política recomendada no domínio de destino: ------ #### [ 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 você quiser realizar somente pesquisas básicas, o requisito mínimo de política é que a permissão `es:ESCrossClusterGet` seja aplicada ao domínio de destino, sem compatibilidade com curinga. Por exemplo, na política anterior, você especificaria o nome do domínio como */my-destination-domain* e não*/my-destination-domain/\$1*. Nesse caso, o domínio de destino realiza a pesquisa e retorna os resultados para o domínio de origem. O domínio de origem combina seus próprios resultados (se houver) com os resultados do domínio de destino e os retorna para você. ## Criar uma conexão entre domínios Uma conexão de pesquisa entre clusters é unidirecional, do domínio de origem para o domínio de destino. Isso significa que os domínios de destino (em uma conta ou região diferente) não podem consultar o domínio de origem, que é local para a OpenSearch interface do usuário. O domínio de origem cria uma conexão de *saída* com o domínio de destino. O domínio de destino recebe uma solicitação de conexão de *entrada* do domínio de origem. ![\[Esta imagem mostra que uma conexão de pesquisa entre clusters é unidirecional do domínio de origem para o domínio de destino.\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/ui-oubound-inbound-connections.png) **Para criar uma conexão entre domínios** 1. Faça login no console do Amazon OpenSearch Service em [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home). 1. No painel de navegação à esquerda, selecione **Domínios**. 1. Escolha o nome de um domínio para servir como domínio de origem e depois escolha a guia **Conexões**. 1. Na área **Conexões de saída**, escolha **Solicitar**. 1. Em **Alias de conexão**, insira um nome para a conexão. O alias de conexão é usado na OpenSearch interface do usuário para selecionar os domínios de destino. 1. Em **Modo de conexão**, escolha **Direto** para pesquisas ou replicação entre clusters. 1. Para especificar que a conexão deve ignorar clusters indisponíveis durante uma pesquisa, selecione a caixa **Ignorar clusters indisponíveis**. Essa configuração garante que as consultas entre clusters retornem resultados parciais, mesmo que ocorram falhas em um ou mais clusters remotos. 1. Em **Cluster de destino**, escolha entre **Conectar a um cluster neste Conta da AWS** e **Conectar a um cluster em outro Conta da AWS**. 1. Em **ARN de domínio remoto**, insira nome do recurso da Amazon (ARN)(ARN) para o cluster. O ARN do domínio pode estar localizado na área **Informações gerais** da página de detalhes do domínio. O domínio deve atender aos seguintes requisitos: + O ARN deve estar no formato `arn:partition:es:regionaccount-id:type/domain-id`. Por exemplo: `arn:aws:es:us-east-2:111222333444:domain/my-domain` + O domínio deve ser configurado para usar a OpenSearch versão 1.0 (ou posterior) ou a versão 6.7 do Elasticsearch (ou posterior). + O controle de acesso refinado deve estar habilitado no domínio. + O domínio deve estar em execução OpenSearch. 1. Escolha **Solicitar**. A pesquisa entre clusters primeiro valida a solicitação de conexão para ter certeza de que os pré-requisitos são atendidos. Se os domínios forem incompatíveis, a solicitação de conexão entrará no estado `Validation failed`. Se a solicitação de conexão for validada com êxito, ela é enviada para o domínio de destino, onde precisa ser aprovada. Até que essa aprovação seja fornecida, a conexão permanecerá em um estado `Pending acceptance`. Quando a solicitação de conexão é aceita no domínio de destino, o estado muda para `Active` e o domínio de destino torna-se disponível para consultas. A página de domínio mostra os detalhes gerais da integridade do domínio e da instância do domínio de destino. Os proprietários de domínios têm a flexibilidade de criar, visualizar, remover e monitorar conexões de saída e de entrada de seus domínios. Depois de estabelecida a conexão, todo o tráfego que flui entre os nós dos domínios conectados é criptografado. Se você conectar um domínio da VPC a um domínio que não seja de VPC e este domínio for um endpoint público que pode receber tráfego da Internet, o tráfego entre clusters entre os domínios ainda será criptografado e seguro. ## Testar a configuração de segurança para acesso a dados entre regiões e contas com pesquisa entre clusters Depois de configurar as permissões de acesso para acesso a dados entre regiões e contas com a pesquisa entre clusters, recomendamos testar a configuração usando o [https://www.postman.com/](https://www.postman.com/), uma plataforma de terceiros para desenvolvimento colaborativo de APIs. **Para definir a configuração de segurança usando o Postman** 1. No domínio de destino, indexe um documento. Este é um exemplo de solicitação: ``` POST https://dst-domain.us-east-1.es.amazonaws.com/books/_doc/1 { "Dracula": "Bram Stoker" } ``` 1. Para consultar esse índice do domínio de origem, inclua o alias de conexão do domínio de destino dentro da consulta. Você pode encontrar o alias de conexão na guia Conexões no painel do domínio. A seguir está um exemplo de solicitação e resposta truncada: ``` 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. (Opcional) Você pode criar uma configuração que inclua vários domínios em uma única pesquisa. Por exemplo, digamos que você configurou o seguinte: Uma conexão entre `domain-a` e `domain-b`, com um alias de conexão denominado `cluster_b` Uma conexão entre `domain-a` e `domain-c`, com um alias de conexão denominado `cluster_c` Nesse caso, as pesquisas incluem o conteúdo `domain-a`, `domain-b` e `domain-c`. Este é um exemplo de solicitação e resposta truncada: Solicitação ``` 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" } } } ``` Resposta: ``` { "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 você não optou por ignorar clusters indisponíveis na sua configuração de conexão, todos os clusters de destino na sua pesquisa precisam estar disponíveis para que sua solicitação de pesquisa seja executada com êxito. Caso contrário, toda a solicitação falhará — mesmo que um dos domínios não esteja disponível, nenhum resultado da pesquisa será retornado. ## Excluir uma conexão A exclusão de uma conexão interrompe qualquer operação de pesquisa entre clusters no domínio de destino. Você pode executar o seguinte procedimento no domínio de origem e no domínio de destino para remover a conexão. Depois que a conexão é removida, ela permanece visível com o status `Deleted` por 15 dias. Não é possível excluir um domínio com conexões ativas entre clusters. Para excluir um domínio, primeiro remova todas as conexões de entrada e saída desse domínio. Isso garante que você leve em consideração os usuários de domínio entre clusters antes de excluir o domínio. **Para excluir uma conexão** 1. Faça login no console do Amazon OpenSearch Service em [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home). 1. No painel de navegação à esquerda, selecione **Domínios**. 1. Escolha o nome de um domínio existente e depois a guia **Conexões**. 1. Selecione nome de uma conexão a ser excluída. 1. Escolha **Excluir** e depois confirme a exclusão.