Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Acceso a datos entre regiones y cuentas
OpenSearch La interfaz de usuario permite acceder a datos de OpenSearch dominios de diferentes Cuenta de AWS s y Región de AWS s. Puede elegir entre dos enfoques en función de sus necesidades. En la siguiente tabla se comparan los dos enfoques.
**nota**
Tanto el acceso a los datos entre cuentas como la búsqueda entre clústeres solo funcionan con OpenSearch los dominios. Ninguno de los enfoques admite las recopilaciones OpenSearch sin servidor.
| Aspecto | Acceso a los datos entre cuentas | Búsqueda en clústeres |
| --- | --- | --- |
| Característica | Asocie dominios de otras cuentas como fuentes de datos directas en OpenSearch la interfaz de usuario | Consulte datos en los dominios conectados mediante conexiones de búsqueda entre clústeres |
| Mecanismo | Acceso directo: la OpenSearch interfaz de usuario se conecta directamente al dominio de destino de otra cuenta | Acceso indirecto: se requiere un dominio local en la misma cuenta que la OpenSearch interfaz de usuario para retransmitir las solicitudes a dominios remotos |
| Compatibilidad entre cuentas | Sí | Sí |
| Compatibilidad entre regiones | No, los dominios de origen y destino deben estar en el mismo Región de AWS | Sí, los dominios de origen y destino pueden estar en Región de AWS s diferentes |
| Unifique datos entre dominios | No, cada dominio se consulta de forma independiente como una fuente de datos independiente | Sí, una sola consulta puede agregar resultados de varios dominios conectados |
| Métodos de autenticación | IAM y AWS IAM Identity Center | IAM (con control de acceso detallado) |
| Complejidad de la configuración | Menor: requiere una función de IAM multicuenta para la validación | Más alto: requiere conexiones entre clústeres, políticas de acceso en ambos dominios y un control de acceso detallado |
| Visibilidad de la fuente de datos en la interfaz OpenSearch | Cada dominio multicuenta aparece como una fuente de datos independiente | Se accede a los dominios remotos a través de los alias de conexión del dominio de origen local |
| Acceso de escritura al dominio remoto | Sí, controlado por la política de acceso del dominio de destino | No, la búsqueda entre clústeres proporciona acceso de solo lectura a dominios remotos |
**Topics**
+ [Acceso a datos multicuenta a dominios OpenSearch](application-cross-account-data-access-domains.md)
+ [Búsqueda en clústeres](application-cross-cluster-search.md)
# Acceso a datos multicuenta a dominios OpenSearch
Puede configurar sus aplicaciones de OpenSearch interfaz de usuario en una cuenta para acceder a los OpenSearch dominios de diferentes cuentas. Al crear una aplicación de OpenSearch interfaz de usuario con fuentes de datos multicuenta, se proporciona una `iamRoleForDataSourceArn` que apunta a una función de IAM en la cuenta de destino. OpenSearch La interfaz de usuario valida la solicitud asumiendo esta función y realizando una llamada `es:DescribeDomain` para verificar la accesibilidad del dominio. La función multicuenta se utiliza únicamente para la validación del plano de control. El acceso al plano de datos se controla por separado mediante la política de acceso del dominio de destino.
**Código de muestra**
Los ejemplos de código de este tema tienen únicamente fines ilustrativos. Demuestran la funcionalidad básica y es posible que no incluyan la gestión de errores, las mejores prácticas de seguridad ni funciones listas para la producción. Antes de utilizar un código de muestra en producción, revíselo y modifíquelo para que cumpla con sus requisitos específicos y pruébelo exhaustivamente en su entorno.
## Conceptos clave
Cuenta de origen
El Cuenta de AWS que aloja su aplicación de OpenSearch interfaz de usuario.
Cuenta objetivo
Lugar Cuenta de AWS en el que reside el OpenSearch dominio.
Función multicuenta
Función de IAM en la cuenta de destino que se utiliza únicamente para la validación del plano de control. Este rol solo requiere el `es:DescribeDomain` permiso.
Función de aplicación de IAM Identity Center
Función de IAM en la cuenta de origen que se utiliza para acceder al plano de datos de los usuarios del IAM Identity Center.
## Requisitos previos
Antes de configurar el acceso a los datos entre cuentas, asegúrese de tener lo siguiente:
+ AWS CLI instalado y configurado
+ Acceso tanto al origen como al destino Cuenta de AWS
+ Para los flujos del IAM Identity Center: una instancia de AWS IAM Identity Center organización
## Escenarios
Elija el escenario que coincida con su método de autenticación y configuración de dominio:
+ [Escenario 1: un usuario de IAM accede a un dominio público](#cross-account-scenario-1)
+ [Escenario 2: un usuario del IAM Identity Center accede a un dominio público](#cross-account-scenario-2)
+ [Escenario 3: usuario de IAM que accede a un dominio de VPC](#cross-account-scenario-3)
+ [Escenario 4: Un usuario del IAM Identity Center accede a un dominio de VPC](#cross-account-scenario-4)
## Escenario 1: un usuario de IAM accede a un dominio público
### Paso 1: Crear el rol de IAM multicuenta (cuenta de destino)
Cree un rol de IAM en la cuenta de destino que permita a la cuenta de origen asumirlo para la validación del dominio.
**Para crear el rol multicuenta**
1. Cree una política de confianza que permita a la cuenta de origen asumir el rol:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Cree el rol:
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. Crea una política de permisos con solo la siguiente `es:DescribeDomain` acción:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. Asocie la política de permisos al rol:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### Paso 2: Crea el OpenSearch dominio (cuenta de destino)
Cree un OpenSearch dominio en la cuenta de destino con un control de acceso detallado y un cifrado 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
```
Espere a que el estado del dominio cambie antes de continuar. `Active`
### Paso 3: Crear la aplicación de OpenSearch interfaz de usuario (cuenta de origen)
Cree la aplicación en la cuenta de origen con la fuente de datos multicuenta:
```
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":"[\"*\"]"}]'
```
### Paso 4: Verificar y acceder
Recupere los detalles de la aplicación para obtener la URL del punto final:
```
aws opensearch get-application \
--region region \
--id application-id
```
+ Navegue hasta la URL del punto final de la aplicación desde la respuesta.
+ Inicie sesión con las credenciales de IAM.
+ El usuario de IAM firma las solicitudes del plano de datos con sus propias credenciales.
+ La política de acceso al dominio de destino controla los datos a los que puede acceder el usuario.
## Escenario 2: un usuario del IAM Identity Center accede a un dominio público
### Paso 1: Crear el rol de IAM multicuenta (cuenta de destino)
Cree un rol de IAM en la cuenta de destino que permita a la cuenta de origen asumirlo para la validación del dominio.
**Para crear el rol multicuenta**
1. Cree una política de confianza que permita a la cuenta de origen asumir el rol:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Cree el rol:
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. Crea una política de permisos con solo la siguiente `es:DescribeDomain` acción:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. Asocie la política de permisos al rol:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### Paso 2: Crea el OpenSearch dominio (cuenta de destino)
Crea un OpenSearch dominio en la cuenta de destino. Utilice el mismo comando que[Paso 2: Crea el OpenSearch dominio (cuenta de destino)](#scenario-1-step-2), pero actualice la política de acceso para permitir el rol de aplicación del Centro de Identidad de IAM desde la cuenta de origen:
```
{
"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/*"
}]
}
```
Espere a que el estado del dominio cambie `Active` antes de continuar.
### Paso 3: Cree la función de IAM para la aplicación IAM Identity Center (cuenta de origen)
Cree una función de IAM en la cuenta de origen que la OpenSearch interfaz de usuario utiliza para acceder al plano de datos de los usuarios del IAM Identity Center.
**Para crear el rol de aplicación del Centro de Identidad de IAM**
1. Cree una política de confianza:
```
{
"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. Cree una política de permisos:
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": ["es:ESHttp*"],
"Resource": "*"
}]
}
```
1. Cree el rol y adjunte las 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
```
### Paso 4: Cree la aplicación de OpenSearch interfaz de usuario con IAM Identity Center (cuenta de origen)
```
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":"[\"*\"]"}]'
```
### Paso 5: Crear y asignar usuarios y grupos del IAM Identity Center
**Cree un usuario del Centro de Identidad de IAM**
Ejecute el comando siguiente. Sustituya *placeholder values* por su propia información.
```
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
```
**Cree un grupo del Centro de identidades de IAM y añada el usuario**
Ejecute los siguientes 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
```
**Asigne el usuario o el grupo a la aplicación**
Use el siguiente 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
```
**Configure la asignación de roles de backend en el dominio de destino**
Asigne el grupo del centro de identidad de IAM a un rol OpenSearch de seguridad en el dominio 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": []
}'
```
### Paso 6: Verificar y acceder
```
aws opensearch get-application \
--region region \
--id application-id
```
+ Navegue hasta la URL del punto final de la aplicación.
+ Inicie sesión con las credenciales de usuario del IAM Identity Center.
+ Las solicitudes de datos de los usuarios del IAM Identity Center se firman con el rol de aplicación del Centro de Identidad de IAM, no con el rol multicuenta.
+ Las asignaciones de funciones de backend en el dominio controlan los permisos de acceso a los datos.
## Escenario 3: usuario de IAM que accede a un dominio de VPC
### Paso 1: Crear el rol de IAM multicuenta (cuenta de destino)
Cree un rol de IAM en la cuenta de destino que permita a la cuenta de origen asumirlo para la validación del dominio.
**Para crear el rol multicuenta**
1. Cree una política de confianza que permita a la cuenta de origen asumir el rol:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Cree el rol:
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. Crea una política de permisos con solo la siguiente `es:DescribeDomain` acción:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. Asocie la política de permisos al rol:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### Paso 2: Configurar la VPC (cuenta de destino)
Omita este paso si ya existe una VPC en la cuenta 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
```
Más información sobre la creación de [dominios de VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html).
### Paso 3: Crear el dominio de VPC (cuenta 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
```
Espere a que el estado del dominio cambie `Active` antes de continuar.
### Paso 4: Autorizar el punto final de la VPC para el principal del servicio de OpenSearch interfaz de usuario (cuenta de destino)
**importante**
Este es un paso fundamental que es exclusivo de los dominios de VPC. El servicio de OpenSearch interfaz de usuario debe estar autorizado explícitamente para acceder al punto final de la 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
```
Respuesta esperada:
```
{
"AuthorizedPrincipalList": [
{
"PrincipalType": "AWS_SERVICE",
"Principal": "application.opensearchservice.amazonaws.com"
}
]
}
```
### Paso 5: Crear la aplicación de OpenSearch interfaz de usuario (cuenta de origen)
```
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":"[\"*\"]"}]'
```
### Paso 6: Verificar y acceder
Recupere los detalles de la aplicación para obtener la URL del punto final:
```
aws opensearch get-application \
--region region \
--id application-id
```
+ Navegue hasta la URL del punto final de la aplicación desde la respuesta.
+ Inicie sesión con las credenciales de IAM.
+ El usuario de IAM firma las solicitudes del plano de datos con sus propias credenciales.
+ La política de acceso al dominio de destino controla los datos a los que puede acceder el usuario.
## Escenario 4: Un usuario del IAM Identity Center accede a un dominio de VPC
### Paso 1: Crear el rol de IAM multicuenta (cuenta de destino)
Cree un rol de IAM en la cuenta de destino que permita a la cuenta de origen asumirlo para la validación del dominio.
**Para crear el rol multicuenta**
1. Cree una política de confianza que permita a la cuenta de origen asumir el rol:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. Cree el rol:
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. Crea una política de permisos con solo la siguiente `es:DescribeDomain` acción:
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. Asocie la política de permisos al rol:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### Paso 2: Configurar la VPC (cuenta de destino)
Omita este paso si ya existe una VPC en la cuenta 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
```
Más información sobre la creación de [dominios de VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html).
### Paso 3: Crear el dominio de VPC (cuenta de destino)
Utilice el mismo comando que[Paso 3: Crear el dominio de VPC (cuenta de destino)](#scenario-3-step-3), pero actualice la política de acceso para permitir el rol de aplicación de IAM Identity Center desde la cuenta de origen:
```
{
"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/*"
}]
}
```
Espere a que el estado del dominio cambie `Active` antes de continuar.
### Paso 4: Autorizar el punto final de la VPC para el principal del servicio de OpenSearch interfaz de usuario (cuenta de destino)
**importante**
Este es un paso fundamental que es exclusivo de los dominios de VPC. El servicio de OpenSearch interfaz de usuario debe estar autorizado explícitamente para acceder al punto final de la 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
```
Respuesta esperada:
```
{
"AuthorizedPrincipalList": [
{
"PrincipalType": "AWS_SERVICE",
"Principal": "application.opensearchservice.amazonaws.com"
}
]
}
```
### Paso 5: Cree la función de IAM para la aplicación IAM Identity Center (cuenta de origen)
Cree una función de IAM en la cuenta de origen que la OpenSearch interfaz de usuario utiliza para acceder al plano de datos de los usuarios del IAM Identity Center.
**Para crear el rol de aplicación del Centro de Identidad de IAM**
1. Cree una política de confianza:
```
{
"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. Cree una política de permisos:
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": ["es:ESHttp*"],
"Resource": "*"
}]
}
```
1. Cree el rol y adjunte las 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
```
### Paso 6: Cree la aplicación de OpenSearch interfaz de usuario con IAM Identity Center (cuenta de origen)
```
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":"[\"*\"]"}]'
```
### Paso 7: Crear y asignar usuarios y grupos del Centro de Identidad de IAM
**Cree un usuario del Centro de Identidad de IAM**
Ejecute el comando siguiente. Sustituya *placeholder values* por su propia información.
```
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
```
**Cree un grupo del Centro de identidades de IAM y añada el usuario**
Ejecute los siguientes 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
```
**Asigne el usuario o el grupo a la aplicación**
Use el siguiente 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
```
**Configure la asignación de roles de backend en el dominio de destino**
Asigne el grupo del centro de identidad de IAM a un rol OpenSearch de seguridad en el dominio 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": []
}'
```
### Paso 8: Verificar y acceder
```
aws opensearch get-application \
--region region \
--id application-id
```
+ Navegue hasta la URL del punto final de la aplicación.
+ Inicie sesión con las credenciales de usuario del IAM Identity Center.
+ Las solicitudes de datos de los usuarios del IAM Identity Center se firman con el rol de aplicación del Centro de Identidad de IAM, no con el rol multicuenta.
+ Las asignaciones de funciones de backend en el dominio controlan los permisos de acceso a los datos.
## Administración de las aplicaciones de
**Actualice una aplicación con fuentes de datos multicuenta**
Ejecute el comando siguiente. Sustituya *placeholder values* por su propia información.
```
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**
La operación de actualización reemplaza toda la matriz de fuentes de datos. Incluya todas las fuentes de datos que desee conservar.
**Enumerar aplicaciones**
Use el siguiente comando:
```
aws opensearch list-applications \
--region region
```
**Eliminación de una aplicación de**
Use el siguiente comando:
```
aws opensearch delete-application \
--region region \
--id application-id
```
**Revocar el acceso al punto final de la VPC**
Use el siguiente comando:
```
aws opensearch revoke-vpc-endpoint-access \
--domain-name vpc-domain-name \
--service "application.opensearchservice.amazonaws.com" \
--region region
```
## Referencia rápida
En las siguientes tablas se resumen las principales diferencias entre los tipos de dominio y los métodos de autenticación.
**Dominio público comparado con el dominio de VPC**
| Aspecto | Dominio público | Dominio de VPC |
| --- | --- | --- |
| Autorización de puntos finales de VPC | No obligatorio | Obligatorio: debe autorizar application.opensearchservice.amazonaws.com |
| Configuración de la red | Ninguno | VPC, subred y grupo de seguridad con HTTPS (443) entrante |
| Política de acceso de IAM | Obligatorio | Obligatorio |
| Función multicuenta | Necesario para el uso de varias cuentas | Necesario para cuentas cruzadas |
**Un usuario de IAM comparado con un usuario de IAM Identity Center**
| Aspecto | Usuario de IAM | Usuario de IAM Identity Center |
| --- | --- | --- |
| Credenciales del plano de datos | Credenciales de IAM propias del usuario | Función de aplicación del IAM Identity Center |
| Control de acceso | Política de acceso al dominio | Política de acceso al dominio y asignación de funciones de back-end |
| Configuración adicional | Ninguno | Rol de aplicación de IAM Identity Center, user/group creación, asignación de aplicaciones, mapeo de roles de back-end |
| OpenSearch Configuración de aplicaciones de interfaz de usuario | No hay opciones de IAM Identity Center | --iam-identity-center-options obligatorio |
## Notas importantes
+ `iamRoleForDataSourceArn`Debe estar en la misma cuenta que. `dataSourceArn`
+ Solo `iamRoleForDataSourceArn` es obligatorio para las fuentes de datos entre cuentas. Omita esta opción para las fuentes de datos de la misma cuenta.
+ La función multicuenta solo necesita el permiso. `es:DescribeDomain` Nunca se usa para acceder al plano de datos.
+ Para los dominios de VPC, se deben configurar tanto la política de IAM como la autorización de puntos de conexión de VPC.
+ Versiones de motor compatibles: OpenSearch 1.3 y superiores.
## Resolución de problemas
| Problema | Resolución |
| --- | --- |
| La creación de la aplicación falla y aparece el mensaje «No se puede acceder al dominio» | Compruebe que la función multicuenta tiene el es:DescribeDomain permiso y que la política de confianza permite la cuenta de origen. |
| Se produce un error en la asociación de dominios de VPC | Asegúrese de que el punto final de la VPC esté autorizado para. application.opensearchservice.amazonaws.com |
| Se ha denegado el acceso al plano de datos al usuario de IAM | Compruebe que la política de acceso al dominio de destino permita al usuario o rol principal de IAM. |
| Se ha denegado el acceso al plano de datos para el usuario del IAM Identity Center | Compruebe que la asignación de funciones de backend incluya el ID de grupo del IAM Identity Center y que la política de dominio permita la función de aplicación del IAM Identity Center. |
| Error de discordancia de cuentas | Asegúrese de que iamRoleForDataSourceArn está en la misma cuenta que el dominio. dataSourceArn |
# Búsqueda en clústeres
Con la [búsqueda entre clústeres](cross-cluster-search.md) en Amazon OpenSearch Serverless, puede realizar consultas y agregaciones en varios dominios conectados.
La búsqueda entre clústeres en Amazon OpenSearch Serverless utiliza los conceptos de dominio de *origen y dominio* de *destino*. Una petición de búsqueda en clústeres se origina en un dominio de origen. El dominio de destino puede estar en un dominio diferente Cuenta de AWS o Región de AWS (o en ambos) del dominio de origen desde el que se realiza la consulta. Mediante la búsqueda entre clústeres, puedes configurar un dominio de origen para asociarlo a tu OpenSearch interfaz de usuario en la misma cuenta y, a continuación, crear conexiones a los dominios de destino. Como resultado, puedes usar la OpenSearch interfaz de usuario con datos de los dominios de destino aunque estén en una cuenta o región diferente.
Usted paga los [cargos de transferencia de AWS datos estándar](https://aws.amazon.com/opensearch-service/pricing/) por los datos transferidos dentro y fuera de Amazon OpenSearch Service. No se le cobrará por los datos transferidos entre los nodos de su dominio OpenSearch de Servicio. Para obtener más información acerca de los cargos de entrada y salida, consulte [Transferencia de datos](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) en la página *Precios bajo demanda de Amazon EC2*.
Puedes usar la búsqueda entre clústeres como mecanismo para que tu OpenSearch interfaz de usuario se asocie a clústeres de una cuenta diferente o de una región diferente. Las solicitudes entre dominios se cifran en tránsito de forma predeterminada como parte del node-to-node cifrado.
**nota**
La OpenSearch herramienta de código abierto también documenta la [búsqueda entre clústeres](https://opensearch.org/docs/latest/search-plugins/cross-cluster-search/). Tenga en cuenta que la configuración de la herramienta de código abierto difiere significativamente para los clústeres de código abierto en comparación con los dominios gestionados de Amazon OpenSearch Serverless.
En particular, en Amazon OpenSearch Serverless, las conexiones entre clústeres se configuran mediante las solicitudes Consola de administración de AWS en lugar de mediante `cURL` solicitudes. Además, el servicio administrado utiliza AWS Identity and Access Management (IAM) para la autenticación entre clústeres, además de un control de acceso detallado.
Por lo tanto, le recomendamos que utilice el contenido de este tema para configurar la búsqueda entre clústeres para sus dominios en lugar de utilizar la documentación de código abierto. OpenSearch
**Diferencias funcionales al utilizar la búsqueda entre clústeres**
En comparación con los dominios normales, los dominios de destino creados mediante la búsqueda entre clústeres tienen las siguientes diferencias y requisitos funcionales:
+ No puede escribir ni ejecutar comandos `PUT` en el clúster remoto. El acceso al clúster remoto es solo de *lectura*.
+ Tanto el dominio de origen como el de destino deben ser OpenSearch dominios. No puedes conectar un dominio de Elasticsearch ni clústeres de OpenSearch /Elasticsearch autogestionados para la interfaz de usuario. OpenSearch
+ Un dominio puede tener un máximo de 20 conexiones a otros dominios. Esto incluye las conexiones entrantes y salientes.
+ El dominio de origen debe estar en la misma versión o en una versión superior a la del dominio de destino. OpenSearch Si desea configurar conexiones bidireccionales entre dos dominios, los dos dominios deben estar en la misma versión. Recomendamos actualizar ambos dominios a la última versión antes de realizar la conexión. Si necesita actualizar los dominios después de configurar la conexión bidireccional, primero debe eliminar la conexión y, a continuación, volver a crearla.
+ No puede usar diccionarios personalizados o SQL con la búsqueda en clústeres.
+ No se puede usar CloudFormation para conectar dominios.
+ No se puede utilizar la búsqueda entre clústeres en instancias M3 o bursátiles (T2 y T3).
+ La búsqueda entre clústeres no funciona en las colecciones de Amazon OpenSearch Serverless.
**Requisitos previos de búsqueda entre clústeres para la interfaz de usuario OpenSearch**
Antes de configurar la búsqueda entre clústeres con dos OpenSearch dominios, asegúrate de que tus dominios cumplen los siguientes requisitos:
+ Control de acceso detallado habilitado para ambos dominios
+ Node-to-node el cifrado está habilitado para ambos dominios
**Topics**
+ [Configuración de permisos de acceso para el acceso a datos entre regiones y cuentas mediante la búsqueda entre clústeres](#cross-cluster-search-security)
+ [Crear una conexión entre dominios](#cross-cluster-search-create-connection)
+ [Probar su configuración de seguridad para el acceso a datos entre cuentas y regiones con búsqueda entre clústeres](#cross-cluster-search-security-testing)
+ [Eliminación de una conexión](#cross-cluster-search-deleting-connection)
## Configuración de permisos de acceso para el acceso a datos entre regiones y cuentas mediante la búsqueda entre clústeres
Al enviar una petición de búsqueda en clústeres al dominio de origen, el dominio evalúa esa petición en comparación con la política de acceso al dominio. La búsqueda en clústeres requiere un control de acceso preciso. A continuación, se muestra un ejemplo con una política de acceso abierto en el dominio de origen.
------
#### [ 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**
Si incluye índices remotos en la ruta, debe codificar la URL del URI en el ARN del dominio.
Por ejemplo, use el siguiente formato de ARN:
`:arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst%3Aremote_index`
No use el siguiente formato ARN.
`arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst:remote_index.`
Si elige utilizar una política de acceso restrictivo además de un control de acceso detallado, la política debe permitir el acceso a `es:ESHttpGet` como mínimo. A continuación, se muestra un ejemplo:
------
#### [ 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/*"
}
]
}
```
------
El [control de acceso detallado](fgac.md) del dominio de origen evalúa la solicitud para determinar si está firmada con credenciales básicas de IAM o HTTP válidas. Si es así, el control de acceso detallado evalúa a continuación si el usuario tiene permiso para realizar la búsqueda y acceder a los datos.
Los siguientes son los requisitos de permiso para las búsquedas:
+ Si la solicitud solo busca datos en el dominio de destino (por ejemplo, `dest-alias:dest-index/_search)`), solo necesitará permisos en el dominio de destino.
+ Si la solicitud busca datos en ambos dominios (por ejemplo, `source-index,dest-alias:dest-index/_search)`), necesita permisos en ambos dominios.
+ En el control de acceso detallado, los usuarios deben tener el permiso `indices:admin/shards/search_shards` además de los permisos de lectura o estándar para los índices pertinentes.
El dominio de origen pasa la solicitud al dominio de destino. El dominio de destino evalúa esta solicitud frente a su política de acceso al dominio. Para admitir todas las funciones de la OpenSearch interfaz de usuario, como la indexación de documentos y la realización de búsquedas estándar, se deben configurar todos los permisos. A continuación, se muestra un ejemplo de nuestra política recomendada en el dominio 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/"
}
]
}
```
------
Si solo desea realizar búsquedas básicas, el requisito mínimo de la política es que el permiso `es:ESCrossClusterGet` se solicite para el dominio de destino sin el uso de caracteres comodín. Por ejemplo, en la política anterior, especificaría el nombre de dominio como */my-destination-domain* y no*/my-destination-domain/\$1*.
En ese caso, el dominio de destino realiza la búsqueda y devuelve los resultados al dominio de origen. El dominio de origen combina sus propios resultados (si los hay) con los resultados del dominio de destino y los devuelve.
## Crear una conexión entre dominios
Una conexión entre clústeres es unidireccional desde el dominio de origen hasta el dominio de destino. Esto significa que los dominios de destino (en una cuenta o región diferente) no pueden consultar el dominio de origen, que es local en la OpenSearch interfaz de usuario. El dominio de origen crea una conexión *outbound* al dominio de destino. El dominio de destino recibe una solicitud de conexión *inbound* del dominio de origen.
![\[Una conexión entre clústeres es unidireccional desde el dominio de origen hasta el dominio de destino.\]](http://docs.aws.amazon.com/es_es/opensearch-service/latest/developerguide/images/ui-oubound-inbound-connections.png)
**Para crear una conexión entre dominios**
1. Inicia sesión en la consola OpenSearch de Amazon Service desde [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home).
1. En el panel de navegación de la izquierda, seleccione **Dominios**.
1. Elija el nombre de un dominio que sirva como dominio de origen y, a continuación, elija la pestaña **Conexiones**.
1. En la sección **Conexiones de salida**, seleccione **Solicitar**.
1. En **Alias de conexión**, ingrese un nombre para la conexión. El alias de conexión se usa en la OpenSearch interfaz de usuario para seleccionar los dominios de destino.
1. En el **modo de conexión**, elija **Directo** para realizar búsquedas o replicaciones entre clústeres.
1. Para especificar que la conexión debe omitir los clústeres no disponibles durante una búsqueda, active la casilla **Omitir los clústeres no disponibles**. Esta configuración garantiza que las consultas entre clústeres devuelvan resultados parciales a pesar de que se produzcan errores en uno o más clústeres remotos.
1. En **Clúster de destino**, elija entre **Conectarse a un clúster de esta Cuenta de AWS** o **Conectarse a un clúster de otra Cuenta de AWS**.
1. En el **ARN de dominio remoto**, escriba el nombre de recurso de Amazon (ARN) para el clúster. El ARN del dominio se encuentra en el área de **información general** de la página de detalles del dominio.
El dominio debe cumplir los siguientes requisitos:
+ El formato del ARN debe ser `arn:partition:es:regionaccount-id:type/domain-id`. Por ejemplo:
`arn:aws:es:us-east-2:111222333444:domain/my-domain`
+ El dominio debe configurarse para usar la OpenSearch versión 1.0 (o posterior) o la versión 6.7 de Elasticsearch (o posterior).
+ Debe estar habilitado el control de acceso preciso en el dominio.
+ El dominio debe estar en ejecución. OpenSearch
1. Seleccione **Solicitar**.
La búsqueda entre clústeres valida primero la solicitud de conexión para asegurarse de que se cumplen los requisitos previos. Si los dominios son incompatibles, la solicitud de conexión entra en el estado `Validation failed`.
Una vez correctamente validada la solicitud de conexión, se envía al dominio de destino, donde tiene que aprobarse. Mientras no se obtenga la aprobación, la conexión permanecerá en el estado de `Pending acceptance`. Cuando se acepta la solicitud de conexión en el dominio de destino, el estado cambia a `Active` y el dominio de destino se vuelve disponible para consultas.
La página de dominio muestra el estado general del dominio y los detalles del estado de la instancia del dominio de destino. Los propietarios de dominios tienen la flexibilidad de crear, visualizar, eliminar y monitorear conexiones desde o hacia sus dominios.
Una vez establecida la conexión, se cifra todo el tráfico que circule entre los nodos de los dominios conectados. Si conecta un dominio de VPC a un dominio que no es VPC y el dominio que no es VPC es un punto de conexión público que puede recibir tráfico de Internet, el tráfico entre clúster entre los dominios sigue cifrado y seguro.
## Probar su configuración de seguridad para el acceso a datos entre cuentas y regiones con búsqueda entre clústeres
Una vez que haya configurado los permisos de acceso a los datos entre regiones y cuentas mediante la búsqueda entre clústeres, le recomendamos que pruebe la configuración con [https://www.postman.com/](https://www.postman.com/), una plataforma de terceros para el desarrollo colaborativo de las API.
**Para configurar la configuración de seguridad mediante Postman**
1. En el dominio de destino, indexe un documento: Lo que sigue es un ejemplo de resultado.
```
POST https://dst-domain.us-east-1.es.amazonaws.com/books/_doc/1
{
"Dracula": "Bram Stoker"
}
```
1. Para consultar este índice desde el dominio de origen, incluya el alias de conexión del dominio de destino dentro de la consulta. Puede encontrar el alias de conexión en la pestaña Conexiones del panel de control del dominio. A continuación, se muestra un ejemplo de solicitud y una respuesta 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) Puede crear una configuración que incluya varios dominios en una sola búsqueda. Por ejemplo, supongamos que tiene lo siguiente:
Una conexión entre `domain-a` a `domain-b`, con un alias de conexión denominado `cluster_b`
Una conexión entre `domain-a` a `domain-c`, con un alias de conexión denominado `cluster_c`
En este caso, las búsquedas incluyen el contenido `domain-a`, `domain-b` y `domain-c`. A continuación se muestra un ejemplo de una solicitud y la respuesta:
Solicitud
```
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"
}
}
}
```
Respuesta:
```
{
"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
}
}
]
}
}
```
Si no eligió omitir los clústeres no disponibles en la configuración de la conexión, todos los clústeres de destino que busca tienen que estar disponibles para que la petición de búsqueda se ejecute correctamente. De lo contrario, se produce un error en toda la solicitud; incluso si uno de los dominios no está disponible, la búsqueda no devuelve ningún resultado.
## Eliminación de una conexión
La eliminación de una conexión detiene cualquier operación de búsqueda entre clústeres en el dominio de destino.
Puede realizar estos pasos en el dominio de origen o de destino para eliminar la conexión. Una vez quitada la conexión, seguirá visible con el estado `Deleted` durante un periodo de 15 días.
No se puede eliminar un dominio con conexiones activas entre clústeres. Para eliminar un dominio, primero quite todas las conexiones entrantes y salientes de ese dominio. Esto es para asegurarse de tener en cuenta a los usuarios del dominio entre clústeres antes de eliminar el dominio.
**Para eliminar una conexión**
1. Inicia sesión en la consola OpenSearch de Amazon Service desde [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home).
1. En el panel de navegación de la izquierda, seleccione **Dominios**.
1. Elija el nombre de un dominio y, a continuación, la pestaña **Contenido**.
1. El nombre de la conexión que se va a eliminar.
1. Elija **Eliminar** y, a continuación, confirme la eliminación.