Concepts clés Comment fonctionne l'hypothèse des rôles entre comptes Conditions préalables Scénarios Scénario 1 : accès d'un utilisateur IAM à un domaine public Scénario 2 : accès d'un utilisateur de l'IAM Identity Center à un domaine public Scénario 3 : accès d'un utilisateur IAM à un domaine VPC Scénario 4 : accès d'un utilisateur du centre d'identité IAM à un domaine VPC Gestion des applications Référence rapide Remarques importantes Résolution des problèmes

Accès aux données entre comptes aux domaines OpenSearch

Vous pouvez configurer vos applications d' OpenSearch interface utilisateur dans un seul compte pour accéder aux OpenSearch domaines de différents comptes. Lorsque vous créez une application d' OpenSearch interface utilisateur avec des sources de données inter-comptes, vous fournissez un iamRoleForDataSourceArn qui pointe vers un rôle IAM dans le compte cible. OpenSearch L'interface utilisateur valide la demande en assumant ce rôle et en appelant es:DescribeDomain pour vérifier l'accessibilité du domaine. Le rôle entre comptes est utilisé uniquement lors de l'association de sources de données. L'accès au plan de données est contrôlé séparément par la politique d'accès du domaine cible.

La prise en charge des sources de données entre comptes nécessite l'activation d'un contrôle d'accès précis sur le domaine cible. Le contrôle d'accès précis fournit une couche d'autorisation supplémentaire au-delà de la politique d'accès au domaine, vous permettant de contrôler l'accès à des index, documents et champs individuels.

Concepts clés

Compte source: Celui Compte AWS qui héberge votre application d' OpenSearch interface utilisateur.
Compte cible: L' Compte AWS endroit où réside le OpenSearch domaine.
Rôle multicompte: Rôle IAM dans le compte cible utilisé uniquement lors de l'association de sources de données. OpenSearch L'interface utilisateur assume ce rôle lors de l'appeles:DescribeDomain, qui récupère le point de terminaison du domaine et vérifie que le contrôle d'accès détaillé est activé. Il s'agit d'une étape de découverte et de validation, et non d'une limite de sécurité. Le rôle multi-comptes n'est jamais utilisé pour accéder au plan de données. Après association, toutes les demandes de plan de données sont autorisées par la politique d'accès du domaine et les mappages de rôles principaux, indépendamment du rôle entre comptes.
Rôle d'application IAM Identity Center: Rôle IAM dans le compte source utilisé pour accéder au plan de données utilisateur d'IAM Identity Center.

Comment fonctionne l'hypothèse des rôles entre comptes

Lorsque vous créez ou mettez à jour une application d' OpenSearch interface utilisateur avec une source de données entre comptes, l' OpenSearch interface utilisateur assume le rôle entre comptes dans le compte cible à l'aide de sessions d'accès transmises (FAS). FAS propage l'identité IAM du principal appelant à l'appel. sts:AssumeRole Autrement dit :

La politique de confiance du compte cible contrôle les principaux du compte source qui peuvent assumer le rôle multicompte.
La session de rôle assumé porte l'identité de l'appelant à l'origine de la UpdateApplication demande CreateApplication ou de la demande.
Le rôle multi-comptes n'est assumé que lors de l'association à appeleres:DescribeDomain. Il n'est pas utilisé pour les opérations ultérieures sur le plan de données.

Pour accéder au plan de données :

Les utilisateurs IAM signent les demandes avec leurs propres informations d'identification IAM. La politique d'accès du domaine cible autorise directement ces demandes.
Les demandes des utilisateurs d'IAM Identity Center sont signées avec le rôle d'application IAM Identity Center (iamRoleForIdentityCenterApplicationArn) dans le compte source. La politique d'accès du domaine cible et les mappages des rôles principaux autorisent ces demandes.

Conditions préalables

Avant de configurer l'accès aux données entre comptes, assurez-vous de disposer des éléments suivants :

AWS CLI installé et configuré
Accès à la fois à la source et à la cible Compte AWS
OpenSearch domaines pour lesquels le contrôle d'accès détaillé est activé. L'association de sources de données entre comptes n'est pas prise en charge pour les domaines ne disposant pas d'un contrôle d'accès précis.
Pour les flux IAM Identity Center : une instance d' AWS IAM Identity Center organisation

Scénarios

Choisissez le scénario qui correspond à votre méthode d'authentification et à la configuration de votre domaine :

Scénario 1 : accès d'un utilisateur IAM à un domaine public
Scénario 2 : accès d'un utilisateur de l'IAM Identity Center à un domaine public
Scénario 3 : accès d'un utilisateur IAM à un domaine VPC
Scénario 4 : accès d'un utilisateur du centre d'identité IAM à un domaine VPC

Scénario 1 : accès d'un utilisateur IAM à un domaine public

Étape 1 : créer le rôle IAM entre comptes (compte cible)

Créez un rôle IAM dans le compte cible qui permet au compte source de l'assumer pour la validation du domaine.

Pour créer le rôle multi-comptes

Créez une politique de confiance qui autorise le compte source à assumer le rôle :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::source-account-id:root"
    },
    "Action": "sts:AssumeRole"
  }]
}

Créez le rôle :


aws iam create-role \
  --role-name OpenSearchUIAccessRole \
  --assume-role-policy-document file://trust-policy.json

Créez une politique d'autorisation avec uniquement l'es:DescribeDomainaction suivante :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "es:DescribeDomain",
    "Resource": "arn:aws:es:region:target-account-id:domain/*"
  }]
}

Associez la politique d'autorisation au rôle :


aws iam put-role-policy \
  --role-name OpenSearchUIAccessRole \
  --policy-name ValidationOnly \
  --policy-document file://permissions-policy.json

Étape 2 : Création du OpenSearch domaine (compte cible)

Créez un OpenSearch domaine dans le compte cible avec un contrôle d'accès et un cryptage précis activés :


aws opensearch create-domain \
  --domain-name domain-name \
  --engine-version OpenSearch_2.19 \
  --cluster-config InstanceType=m5.large.search,InstanceCount=1 \
  --ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=100" \
  --advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"admin","MasterUserPassword":"master-password"}}' \
  --node-to-node-encryption-options '{"Enabled":true}' \
  --encryption-at-rest-options '{"Enabled":true}' \
  --domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
  --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::source-account-id:root"},"Action":"es:ESHttp*","Resource":"arn:aws:es:region:target-account-id:domain/domain-name/*"}]}' \
  --region region

Note

Cette politique d'accès définit l'accès au plan de données aux principaux IAM à partir du compte source. Pour un accès plus restrictif, remplacez le principal racine du compte par un utilisateur ou un rôle ARNs IAM spécifique. Le contrôle d'accès détaillé fournit une couche d'autorisation supplémentaire pour contrôler l'accès aux index et aux documents.

Attendez que le statut du domaine devienne identique Active avant de continuer.

Étape 3 : Création de l'application d' OpenSearch interface utilisateur (compte source)

Créez l'application dans le compte source avec la source de données multi-comptes :


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":"[\"*\"]"}]'

Étape 4 : vérification et accès

Récupérez les détails de l'application pour obtenir l'URL du point de terminaison :


aws opensearch get-application \
  --region region \
  --id application-id

Accédez à l'URL du point de terminaison de l'application depuis la réponse.
Connectez-vous à l'aide des informations d'identification IAM.
L'utilisateur IAM signe les demandes de plan de données avec ses propres informations d'identification.
La politique d'accès au domaine cible contrôle les données auxquelles l'utilisateur peut accéder.

Scénario 2 : accès d'un utilisateur de l'IAM Identity Center à un domaine public

Étape 1 : créer le rôle IAM entre comptes (compte cible)

Créez un rôle IAM dans le compte cible qui permet au compte source de l'assumer pour la validation du domaine.

Pour créer le rôle multi-comptes

Créez une politique de confiance qui autorise le compte source à assumer le rôle :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::source-account-id:root"
    },
    "Action": "sts:AssumeRole"
  }]
}

Créez le rôle :


aws iam create-role \
  --role-name OpenSearchUIAccessRole \
  --assume-role-policy-document file://trust-policy.json

Créez une politique d'autorisation avec uniquement l'es:DescribeDomainaction suivante :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "es:DescribeDomain",
    "Resource": "arn:aws:es:region:target-account-id:domain/*"
  }]
}

Associez la politique d'autorisation au rôle :


aws iam put-role-policy \
  --role-name OpenSearchUIAccessRole \
  --policy-name ValidationOnly \
  --policy-document file://permissions-policy.json

Étape 2 : Création du OpenSearch domaine (compte cible)

Créez un OpenSearch domaine dans le compte cible. Utilisez la même commande queÉtape 2 : Création du OpenSearch domaine (compte cible), mais mettez à jour la politique d'accès pour autoriser le rôle d'application IAM Identity Center à partir du compte source :


{
  "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/*"
  }]
}

Attendez que le statut du domaine devienne identique Active avant de continuer.

Étape 3 : Création du rôle IAM pour l'application IAM Identity Center (compte source)

Créez un rôle IAM dans le compte source que l' OpenSearch interface utilisateur utilise pour accéder au plan de données utilisateur d'IAM Identity Center.

Pour créer le rôle d'application IAM Identity Center

Créez une politique de confiance :


{
  "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"
        }
      }
    }
  ]
}

Créez une politique d'autorisation :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OpenSearchDomain",
    "Effect": "Allow",
    "Action": ["es:ESHttp*"],
    "Resource": "*"
  }]
}

Créez le rôle et associez les politiques :


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

Étape 4 : Création de l'application d' OpenSearch interface utilisateur avec IAM Identity Center (compte source)


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":"[\"*\"]"}]'

Étape 5 : créer et attribuer des utilisateurs et des groupes IAM Identity Center

Création d'un utilisateur IAM Identity Center

Exécutez la commande suivante. Remplacez les placeholder values par vos propres informations.


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

Créez un groupe IAM Identity Center et ajoutez l'utilisateur

Exécutez les commandes suivantes :


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

Affecter l'utilisateur ou le groupe à l'application

Exécutez la commande suivante :


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

Configurer le mappage des rôles de backend sur le domaine cible

Associez le groupe IAM Identity Center à un rôle OpenSearch de sécurité sur le domaine cible :


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": []
  }'

Étape 6 : vérification et accès


aws opensearch get-application \
  --region region \
  --id application-id

Accédez à l'URL du point de terminaison de l'application.
Connectez-vous à l'aide des informations d'identification utilisateur d'IAM Identity Center.
Les demandes de données des utilisateurs d'IAM Identity Center sont signées avec le rôle d'application IAM Identity Center, et non avec le rôle multi-comptes.
Mappages des rôles principaux sur les autorisations d'accès aux données de contrôle de domaine.

Scénario 3 : accès d'un utilisateur IAM à un domaine VPC

Étape 1 : créer le rôle IAM entre comptes (compte cible)

Créez un rôle IAM dans le compte cible qui permet au compte source de l'assumer pour la validation du domaine.

Pour créer le rôle multi-comptes

Créez une politique de confiance qui autorise le compte source à assumer le rôle :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::source-account-id:root"
    },
    "Action": "sts:AssumeRole"
  }]
}

Créez le rôle :


aws iam create-role \
  --role-name OpenSearchUIAccessRole \
  --assume-role-policy-document file://trust-policy.json

Créez une politique d'autorisation avec uniquement l'es:DescribeDomainaction suivante :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "es:DescribeDomain",
    "Resource": "arn:aws:es:region:target-account-id:domain/*"
  }]
}

Associez la politique d'autorisation au rôle :


aws iam put-role-policy \
  --role-name OpenSearchUIAccessRole \
  --policy-name ValidationOnly \
  --policy-document file://permissions-policy.json

Étape 2 : configurer le VPC (compte cible)

Ignorez cette étape si un VPC existe déjà dans le compte cible.


# 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

En savoir plus sur la création de domaines VPC.

Étape 3 : Création du domaine VPC (compte cible)


aws opensearch create-domain \
  --domain-name vpc-domain-name \
  --engine-version OpenSearch_2.19 \
  --cluster-config InstanceType=m5.large.search,InstanceCount=1 \
  --ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=100" \
  --vpc-options "SubnetIds=subnet-id,SecurityGroupIds=security-group-id" \
  --advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"admin","MasterUserPassword":"master-password"}}' \
  --node-to-node-encryption-options '{"Enabled":true}' \
  --encryption-at-rest-options '{"Enabled":true}' \
  --domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
  --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::source-account-id:root"},"Action":"es:ESHttp*","Resource":"arn:aws:es:region:target-account-id:domain/vpc-domain-name/*"}]}' \
  --region region

Note

Attendez que le statut du domaine devienne identique Active avant de continuer.

Étape 4 : Autoriser le point de terminaison VPC pour le principal du service d' OpenSearch interface utilisateur (compte cible)

Important

Il s'agit d'une étape critique propre aux domaines VPC. Le service d' OpenSearch interface utilisateur doit être explicitement autorisé à accéder au point de terminaison 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

Réponse attendue :


{
  "AuthorizedPrincipalList": [
    {
      "PrincipalType": "AWS_SERVICE",
      "Principal": "application.opensearchservice.amazonaws.com"
    }
  ]
}

Étape 5 : Création de l'application d' OpenSearch interface utilisateur (compte source)


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":"[\"*\"]"}]'

Étape 6 : vérification et accès

Récupérez les détails de l'application pour obtenir l'URL du point de terminaison :


aws opensearch get-application \
  --region region \
  --id application-id

Accédez à l'URL du point de terminaison de l'application depuis la réponse.
Connectez-vous à l'aide des informations d'identification IAM.
L'utilisateur IAM signe les demandes de plan de données avec ses propres informations d'identification.
La politique d'accès au domaine cible contrôle les données auxquelles l'utilisateur peut accéder.

Scénario 4 : accès d'un utilisateur du centre d'identité IAM à un domaine VPC

Étape 1 : créer le rôle IAM entre comptes (compte cible)

Créez un rôle IAM dans le compte cible qui permet au compte source de l'assumer pour la validation du domaine.

Pour créer le rôle multi-comptes

Créez une politique de confiance qui autorise le compte source à assumer le rôle :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::source-account-id:root"
    },
    "Action": "sts:AssumeRole"
  }]
}

Créez le rôle :


aws iam create-role \
  --role-name OpenSearchUIAccessRole \
  --assume-role-policy-document file://trust-policy.json

Créez une politique d'autorisation avec uniquement l'es:DescribeDomainaction suivante :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "es:DescribeDomain",
    "Resource": "arn:aws:es:region:target-account-id:domain/*"
  }]
}

Associez la politique d'autorisation au rôle :


aws iam put-role-policy \
  --role-name OpenSearchUIAccessRole \
  --policy-name ValidationOnly \
  --policy-document file://permissions-policy.json

Étape 2 : configurer le VPC (compte cible)

Ignorez cette étape si un VPC existe déjà dans le compte cible.


# 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

En savoir plus sur la création de domaines VPC.

Étape 3 : Création du domaine VPC (compte cible)

Utilisez la même commande queÉtape 3 : Création du domaine VPC (compte cible), mais mettez à jour la politique d'accès pour autoriser le rôle d'application IAM Identity Center à partir du compte source :


{
  "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/*"
  }]
}

Attendez que le statut du domaine devienne identique Active avant de continuer.

Étape 4 : Autoriser le point de terminaison VPC pour le principal du service d' OpenSearch interface utilisateur (compte cible)

Important

Il s'agit d'une étape critique propre aux domaines VPC. Le service d' OpenSearch interface utilisateur doit être explicitement autorisé à accéder au point de terminaison 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

Réponse attendue :


{
  "AuthorizedPrincipalList": [
    {
      "PrincipalType": "AWS_SERVICE",
      "Principal": "application.opensearchservice.amazonaws.com"
    }
  ]
}

Étape 5 : Création du rôle IAM pour l'application IAM Identity Center (compte source)

Créez un rôle IAM dans le compte source que l' OpenSearch interface utilisateur utilise pour accéder au plan de données utilisateur d'IAM Identity Center.

Pour créer le rôle d'application IAM Identity Center

Créez une politique de confiance :


{
  "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"
        }
      }
    }
  ]
}

Créez une politique d'autorisation :


{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OpenSearchDomain",
    "Effect": "Allow",
    "Action": ["es:ESHttp*"],
    "Resource": "*"
  }]
}

Créez le rôle et associez les politiques :


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

Étape 6 : Création de l'application d' OpenSearch interface utilisateur avec IAM Identity Center (compte source)


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":"[\"*\"]"}]'

Étape 7 : créer et attribuer des utilisateurs et des groupes IAM Identity Center

Création d'un utilisateur IAM Identity Center

Exécutez la commande suivante. Remplacez les placeholder values par vos propres informations.


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

Créez un groupe IAM Identity Center et ajoutez l'utilisateur

Exécutez les commandes suivantes :


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

Affecter l'utilisateur ou le groupe à l'application

Exécutez la commande suivante :


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

Configurer le mappage des rôles de backend sur le domaine cible

Associez le groupe IAM Identity Center à un rôle OpenSearch de sécurité sur le domaine cible :


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": []
  }'

Étape 8 : Vérification et accès


aws opensearch get-application \
  --region region \
  --id application-id

Accédez à l'URL du point de terminaison de l'application.
Connectez-vous à l'aide des informations d'identification utilisateur d'IAM Identity Center.
Les demandes de données des utilisateurs d'IAM Identity Center sont signées avec le rôle d'application IAM Identity Center, et non avec le rôle multi-comptes.
Mappages des rôles principaux sur les autorisations d'accès aux données de contrôle de domaine.

Gestion des applications

Mettre à jour une application avec des sources de données multicomptes

Exécutez la commande suivante. Remplacez les placeholder values par vos propres informations.


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"
  }]'

Important

L'opération de mise à jour remplace l'ensemble du tableau de sources de données. Incluez toutes les sources de données que vous souhaitez conserver.

Lister les applications

Exécutez la commande suivante :


aws opensearch list-applications \
  --region region

Supprimer une application

Exécutez la commande suivante :


aws opensearch delete-application \
  --region region \
  --id application-id

Révoquer l'accès au point de terminaison VPC

Exécutez la commande suivante :


aws opensearch revoke-vpc-endpoint-access \
  --domain-name vpc-domain-name \
  --service "application.opensearchservice.amazonaws.com" \
  --region region

Référence rapide

Les tableaux suivants résument les principales différences entre les types de domaines et les méthodes d'authentification.

Comparaison entre le domaine public et le domaine VPC
Aspect	Domaine public	Domaine VPC
Autorisation du point de terminaison VPC	Facultatif	Obligatoire — doit autoriser `application.opensearchservice.amazonaws.com`
Configuration du réseau	Aucune	VPC, sous-réseau, groupe de sécurité avec HTTPS (443) entrant
Politique d'accès IAM	Obligatoire	Obligatoire
Rôle multicompte	Nécessaire pour les comptes multiples	Nécessaire pour les comptes multiples

Comparaison entre un utilisateur IAM et un utilisateur IAM Identity Center
Aspect	Utilisateur IAM	Utilisateur du centre d'identité IAM
Informations d'identification du plan de données	Informations d'identification IAM propres à l'utilisateur	Rôle d'application IAM Identity Center
Contrôle d’accès	Stratégie d'accès au domaine	Politique d'accès au domaine et mappage des rôles principaux
Configuration supplémentaire	Aucune	Rôle de l'application IAM Identity Center, user/group création, attribution des applications, mappage des rôles principaux
OpenSearch Configuration de l'application d'interface utilisateur	Aucune option de centre d'identité IAM	`--iam-identity-center-options` obligatoire

Remarques importantes

iamRoleForDataSourceArnIl doit figurer sur le même compte que ledataSourceArn.
Le n'iamRoleForDataSourceArnest requis que pour les sources de données entre comptes. Omettez-le pour les sources de données du même compte.
Le rôle multi-comptes ne nécessite que l'es:DescribeDomainautorisation. Il n'est jamais utilisé pour accéder au plan de données.
Pour les domaines VPC, la politique IAM et l'autorisation des points de terminaison VPC doivent être configurées.
Versions du moteur prises en charge : OpenSearch 1.3 et versions ultérieures.
L'association de sources de données entre comptes nécessite l'activation d'un contrôle d'accès précis sur le domaine cible.

Résolution des problèmes

Problème	Résolution
La création de l'application échoue avec le message « Impossible d'accéder au domaine »	Vérifiez que le rôle multi-comptes dispose de l'`es:DescribeDomain`autorisation requise et que la politique de confiance autorise le compte source.
L'association de domaines VPC échoue	Assurez-vous que le point de terminaison VPC est autorisé pour. `application.opensearchservice.amazonaws.com`
Accès au plan de données refusé à l'utilisateur IAM	Vérifiez que la politique d'accès au domaine cible autorise l'utilisateur IAM ou le principal de rôle.
Accès au plan de données refusé à l'utilisateur d'IAM Identity Center	Vérifiez que le mappage des rôles principaux inclut l'ID de groupe IAM Identity Center et que la politique de domaine autorise le rôle d'application IAM Identity Center.
Erreur d'incompatibilité du compte	Assurez-vous qu'il `iamRoleForDataSourceArn` se trouve dans le même compte que le domaine dans`dataSourceArn`.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Accès aux données entre régions et entre comptes

Accès aux données interrégionales aux domaines OpenSearch