View a markdown version of this page

Activation de la fédération SAML avec Gestion des identités et des accès AWS - OpenSearch Service Amazon
Étape 1 : configurer l'application du fournisseur d'identité (Okta)Étape 2 : Configuration AWS configuration pour OktaÉtape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAMÉtape 4 : vérification de l' Sign-On expérience unique initiée par le fournisseur d'identité avec SAMLÉtape 5 : Configuration du contrôle d'accès affiné basé sur les attributs SAML

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Activation de la fédération SAML avec Gestion des identités et des accès AWS

OpenSearch L'interface utilisateur prend en charge le langage SAML (Security Assertion Markup Language 2.0), une norme ouverte utilisée par de nombreux fournisseurs d'identité. Cela permet la fédération d'identité avec Gestion des identités et des accès AWS (IAM). Grâce à cette prise en charge, les utilisateurs de votre compte ou de votre organisation peuvent accéder directement à l' OpenSearch interface utilisateur en assumant des rôles IAM. Vous pouvez créer une expérience d'authentification unique initiée par le fournisseur d'identité (IdP) pour vos utilisateurs finaux, leur permettant de s'authentifier auprès du fournisseur d'identité externe et d'être redirigés directement vers la page que vous avez définie dans l'interface utilisateur. OpenSearch Vous pouvez également mettre en œuvre un contrôle d'accès précis en configurant vos utilisateurs finaux ou vos groupes pour qu'ils assument différents rôles IAM avec des autorisations différentes pour accéder à l' OpenSearch interface utilisateur et aux sources de données associées.

Cette rubrique présente des instructions détaillées pour configurer l'utilisation de SAML avec l' OpenSearch interface utilisateur. Dans ces procédures, nous utilisons les étapes de configuration de l'application de gestion des identités et des accès Okta à titre d'exemple. Les étapes de configuration pour les autres fournisseurs d'identité, tels qu'Azure Active Directory et Ping, sont similaires.

Note

Si vous utilisez AWS IAM Identity Center, il n'est pas nécessaire de configurer la fédération SAML comme décrit dans cette rubrique. OpenSearch L'interface utilisateur prend en charge IAM Identity Center de manière native, ce qui fournit un accès SSO sans configuration SAML supplémentaire. IAM Identity Center prend également en charge la gestion des utilisateurs et des groupes au niveau de l'organisation. L'intégration SAML décrite ici est destinée aux fournisseurs d'identité tiers (tels qu'Okta, Azure Active Directory et Ping) qui ne sont pas IAM Identity Center.

Étape 1 : configurer l'application du fournisseur d'identité (Okta)

Pour utiliser SAML avec OpenSearch interface utilisateur, la première étape consiste à configurer votre fournisseur d'identité.

Tâche 1 : Création d'utilisateurs Okta

  1. Connectez-vous à votre organisation Okta en https://login.okta.com/ tant qu'utilisateur doté de privilèges administratifs.

  2. Sur la console d'administration, sous Répertoire dans le volet de navigation, choisissez Personnes.

  3. Choisissez Add person (Ajouter une personne).

  4. Dans le champ Prénom, saisissez le prénom de l'utilisateur.

  5. Pour Nom de famille, entrez le nom de famille de l'utilisateur.

  6. Dans le champ Nom d'utilisateur, entrez le nom d'utilisateur de l'utilisateur au format e-mail.

  7. Choisissez Je vais définir le mot de passe et entrez un mot de passe

  8. (Facultatif) Décochez la case L'utilisateur doit changer le mot de passe lors de la première connexion si vous ne souhaitez pas que l'utilisateur change le mot de passe lors de sa première connexion.

  9. Choisissez Enregistrer.

Tâche 2 : Création et attribution de groupes

  1. Connectez-vous à votre organisation Okta en https://login.okta.com/ tant qu'utilisateur doté de privilèges administratifs.

  2. Sur la console d'administration, sous Répertoire dans le volet de navigation, choisissez Groupes.

  3. Choisissez Add Group (Ajouter un groupe).

  4. Entrez un nom de groupe et choisissez Enregistrer.

  5. Choisissez le groupe que vous venez de créer, puis choisissez Attribuer des personnes.

  6. Choisissez le signe plus (+), puis choisissez OK.

  7. (Facultatif) Répétez les étapes 1 à 6 pour ajouter d'autres groupes.

Tâche 3 : Création d'applications Okta

  1. Connectez-vous à votre organisation Okta en https://login.okta.com/ tant qu'utilisateur doté de privilèges administratifs.

  2. Sur la console d'administration, sous Applications dans le volet de navigation, sélectionnez Applications.

  3. Choisissez Create App Integration (Créer une intégration d'appli).

  4. Choisissez SAML 2.0 comme méthode de connexion, puis choisissez Next.

  5. Entrez un nom pour l'intégration de votre application (par exemple,OpenSearch_UI), puis choisissez Suivant.

  6. Entrez les valeurs suivantes dans l'application ; vous n'avez pas besoin de modifier les autres valeurs :

    1. 1. Pour l'URL d'authentification unique, entrez https://signin.aws.amazon.com/saml pour les AWS régions commerciales ou l'URL spécifique à votre région.

    2. 2. Pour l'URI de l'audience (ID d'entité SP), entrezurn:amazon:webservices.

    3. 3. Dans le champ Format d'identification du nom, entrezEmailAddress.

  7. Choisissez Suivant.

  8. Choisissez Je suis un client Okta qui ajoute une application interne, puis choisissez Il s'agit d'une application interne que nous avons créée.

  9. Choisissez Finish (Terminer).

  10. Choisissez Assignations, puis choisissez Attribuer.

  11. Choisissez Attribuer aux groupes, puis sélectionnez Attribuer à côté des groupes que vous souhaitez ajouter.

  12. Sélectionnez Exécuté.

Tâche 4 : configurer la configuration avancée d'Okta

Après avoir créé l'application SAML personnalisée, procédez comme suit :

  1. Connectez-vous à votre organisation Okta en https://login.okta.com/ tant qu'utilisateur doté de privilèges administratifs.

    Sur la console de l'administrateur, dans la zone Général, choisissez Modifier dans les paramètres SAML.

  2. Choisissez Suivant.

  3. Définissez l'état du relais par défaut sur le point de terminaison de l' OpenSearch interface utilisateur, en utilisant le format suivant :

    https://region.console.aws.amazon.com/aos/home?region=region#opensearch/applications/application-id/redirectToDashboardURL.

    Voici un exemple :

    https://us-east-2.console.aws.amazon.com/aos/home?region=us-east-2#opensearch/applications/abc123def4567EXAMPLE/redirectToDashboardURL

  4. Sous Déclarations d'attributs (facultatif), ajoutez les propriétés suivantes :

    1. Fournissez le rôle IAM et le fournisseur d'identité dans un format séparé par des virgules à l'aide de l'attribut Role. Vous utiliserez ce même rôle IAM et ce même fournisseur d'identité ultérieurement lors de la AWS configuration.

    2. Définissez user.login pour. RoleSessionName Il est utilisé comme identifiant pour les informations d'identification temporaires qui sont émises lorsque le rôle est assumé.

    Pour référence :

    Nom Format du nom Format Exemple

    https://aws.amazon.com/SAML/Attributes/Role

    Non spécifié

    arn:aws:iam::aws-account-id:role/role-name,arn:aws:iam::aws-account-id:saml-provider/provider-name

    arn:aws:iam::111222333444:role/oktarole,arn:aws:iam::111222333444:saml-provider/oktaidp

    https://aws.amazon.com/SAML/Attributes/RoleSessionName

    Non spécifié

    user.login

    user.login

  5. Après avoir ajouté les propriétés de l'attribut, cliquez sur Suivant, puis sur Terminer.

Le format de vos attributs doit être similaire à celui de l'image suivante. La valeur Default Relay State est l'URL permettant de définir la page de destination pour les utilisateurs finaux de votre compte ou de votre organisation une fois qu'ils ont terminé la validation de l'authentification unique auprès d'Okta. Vous pouvez la définir sur n'importe quelle page de l' OpenSearch interface utilisateur, puis fournir cette URL aux utilisateurs finaux auxquels elle est destinée.

La zone « SAML 2.0 » indique l'URL d'état du relais par défaut et l'URL des métadonnées pour une application.

Étape 2 : Configuration AWS configuration pour Okta

Effectuez les tâches suivantes pour configurer votre AWS configuration pour Okta.

Tâche 1 : Collecter les informations d'Okta

Pour cette étape, vous devrez collecter vos informations Okta afin de pouvoir les configurer ultérieurement. AWS

  1. Connectez-vous à votre organisation Okta en https://login.okta.com/ tant qu'utilisateur doté de privilèges administratifs.

  2. Dans l'onglet Connexion, dans le coin inférieur droit de la page, choisissez Afficher les instructions de configuration SAML.

  3. Prenez note de la valeur de l' Sign-onURL unique du fournisseur d'identité. Vous pouvez utiliser cette URL lorsque vous vous connectez à un client SQL tiers tel que SQL Workbench/J.

  4. Utilisez les métadonnées du fournisseur d'identité dans le bloc 4, puis enregistrez le fichier de métadonnées au format .xml (par exemple,metadata.xml).

Tâche 2 : créer le fournisseur IAM

Pour créer votre fournisseur IAM, procédez comme suit :

  1. Connectez-vous au Console de gestion AWS et ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.

  2. Dans le volet de navigation, sous Gestion des accès, sélectionnez Identity providers.

  3. Choisissez Ajouter un fournisseur.

  4. Pour Type de fournisseur, sélectionnez SAML.

  5. Pour Nom du fournisseur, entrez un nom.

  6. Pour le document de métadonnées, choisissez Choisir un fichier et chargez le fichier de métadonnées (.xml) que vous avez téléchargé précédemment.

  7. Choisissez Ajouter un fournisseur.

Tâche 3 : Création d'un rôle IAM

Pour créer votre Gestion des identités et des accès AWS rôle, procédez comme suit :

  1. Connectez-vous au Console de gestion AWS et ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.

  2. Dans le volet de navigation, sous Gestion des accès, choisissez Rôles.

  3. Choisissez Créer un rôle.

  4. Pour Type d'entité sécurisée, sélectionnez Fédération SAML 2.0.

  5. Pour le fournisseur basé sur SAML 2.0, choisissez le fournisseur d'identité que vous avez créé précédemment.

  6. Sélectionnez Autoriser la programmation et l' Console de gestion AWS accès.

  7. Note

    Sous Sign-in Points de terminaison, sélectionnez sans identifiant unique. Si vous sélectionnez avec des identifiants uniques, la SAML:aud condition de la politique de confiance ne correspondra pas à l'audience d'assertion SAML, ce qui entraînera une AccessDenied erreur lorsque les utilisateurs tenteront de se connecter.

  8. Choisissez Suivant.

  9. Dans la liste Politiques d'autorisations, cochez les cases correspondant aux politiques qui accordent des autorisations de OpenSearch service, par exemple une politique AWS gérée AmazonOpenSearchServiceFullAccess.

  10. Choisissez Suivant.

  11. Dans la zone Révision, pour Nom du rôle, entrez le nom de votre rôle ; par exemple,oktarole.

  12. (Facultatif) Dans Description, entrez une brève description de l'objectif du rôle.

  13. Choisissez Créer un rôle.

  14. Accédez au rôle que vous venez de créer, choisissez l'onglet Relations de confiance, puis choisissez Modifier la politique de confiance.

  15. Dans le volet Modifier la déclaration, sous Ajouter des actions pour STS, cochez la case pour TagSession.

  16. Choisissez Mettre à jour une politique.

Étape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAM

Apprenez à configurer vos rôles IAM pour le contrôle OpenSearch d'accès. Grâce aux rôles IAM, vous pouvez mettre en œuvre un contrôle d'accès précis pour permettre à vos groupes d'utilisateurs Okta d'accéder aux ressources. OpenSearch Cette rubrique présente la configuration basée sur les rôles IAM à l'aide de deux exemples de groupes.

Sample group: Alice

Requête :

GET _plugins/_security/api/roles/alice-group

Résultat :

{
  "alice-group": {
    "reserved": false,
    "hidden": false,
    "cluster_permissions": [
      "unlimited"
    ],
    "index_permissions": [
      {
        "index_patterns": [
          "alice*"
        ],
        "dls": "",
        "fls": [],
        "masked_fields": [],
        "allowed_actions": [
          "indices_all"
        ]
      }
    ],
    "tenant_permissions": [
      {
        "tenant_patterns": [
          "global_tenant"
        ],
        "allowed_actions": [
          "kibana_all_write"
        ]
      }
    ],
    "static": false
  }
}
Sample group: Bob

Requête :

GET _plugins/_security/api/roles/bob-group

Résultat :

{
  "bob-group": {
    "reserved": false,
    "hidden": false,
    "cluster_permissions": [
      "unlimited"
    ],
    "index_permissions": [
      {
        "index_patterns": [
          "bob*"
        ],
        "dls": "",
        "fls": [],
        "masked_fields": [],
        "allowed_actions": [
          "indices_all"
        ]
      }
    ],
    "tenant_permissions": [
      {
        "tenant_patterns": [
          "global_tenant"
        ],
        "allowed_actions": [
          "kibana_all_write"
        ]
      }
    ],
    "static": false
  }
}

Vous pouvez mapper les rôles de domaine Amazon OpenSearch Service aux rôles IAM à l'aide du mappage des rôles principaux, comme illustré dans l'exemple suivant :

{
  "bob-group": {
    "hosts": [],
    "users": [],
    "reserved": false,
    "hidden": false,
    "backend_roles": [
      "arn:aws:iam::111222333444:role/bob-group"
    ],
    "and_backend_roles": []
  },
  "alice-group": {
    "hosts": [],
    "users": [],
    "reserved": false,
    "hidden": false,
    "backend_roles": [
      "arn:aws:iam::111222333444:role/alice-group"
    ],
    "and_backend_roles": []
  }
}

Étape 4 : vérification de l' Sign-On expérience unique initiée par le fournisseur d'identité avec SAML

Ouvrez l'URL de Default Relay State pour ouvrir la page d'authentification Okta. Entrez les informations d'identification d'un utilisateur final. Vous êtes automatiquement redirigé vers l' OpenSearch interface utilisateur.

Vous pouvez vérifier vos informations d'identification actuelles en choisissant l'icône utilisateur en bas du panneau de navigation, comme illustré dans l'image suivante :

Le choix de l'icône utilisateur sur la page « Paramètres et configuration » d'Okta affiche les informations d'identification de l'utilisateur actuel.

Vous pouvez également vérifier les autorisations de contrôle d'accès affinées de l'utilisateur en accédant aux outils de développement en bas du panneau de navigation et en exécutant des requêtes dans la console. Voici des exemples de requêtes.

Example 1: Displays information about the current user

Requête :

GET _plugins/_security/api/account

Résultat :

{
  "user_name": "arn:aws:iam::XXXXXXXXXXXX:role/bob-group",
  "is_reserved": false,
  "is_hidden": false,
  "is_internal_user": false,
  "user_requested_tenant": null,
  "backend_roles": [
    "arn:aws:iam::XXXXXXXXXXXX:role/bob-group"
  ],
  "custom_attribute_names": [],
  "tenants": {
    "global_tenant": true,
    "arn:aws:iam::XXXXXXXXXXXX:role/bob-group": true
  },
  "roles": [
    "bob-group"
  ]
}
Example 2: Displays actions permitted for a user

Requête :

GET bob-test/_search

Résultat :

{
  "took": 390,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "bob-test",
        "_id": "ui01N5UBCIHpjO8Jlvfy",
        "_score": 1,
        "_source": {
          "title": "Your Name",
          "year": "2016"
        }
      }
    ]
  }
}
Example 3: Displays actions not permitted for a user

Requête :

GET alice-test

Résultat :

{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
      }
    ],
    "type": "security_exception",
    "reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
  },
  "status": 403
}

Étape 5 : Configuration du contrôle d'accès affiné basé sur les attributs SAML

Avec Amazon OpenSearch Service, vous pouvez utiliser un contrôle d'accès précis avec SAML pour mapper les utilisateurs et les groupes de votre fournisseur d'identité à des utilisateurs et à des rôles de contrôle d'accès OpenSearch précis de manière dynamique. Vous pouvez étendre ces rôles à des OpenSearch domaines spécifiques et à des collections sans serveur, et définir des autorisations au niveau de l'index et une sécurité au niveau du document.

Note

Pour plus d'informations sur le contrôle d'accès précis, consultez. Fine-grained contrôle d'accès dans Amazon OpenSearch Service

Attributs SAML pour un contrôle d'accès précis

Clé du sujet

Correspond à un attribut utilisateur unique, tel qu'une adresse e-mail ou un nom d'utilisateur, qui identifie l'utilisateur à des fins d'authentification.

Clé des rôles

Cartes vers les attributs de groupe ou de rôle de votre IdP qui déterminent les rôles ou les autorisations d'autorisation.

Tâche 1 : configurer Okta pour un contrôle d'accès précis

Pour configurer Okta pour un contrôle d'accès précis

  1. Ajoutez un nouvel attribut pour l' OpenSearch utilisateur principal dans la section Déclarations d'attributs :

    • Nom : UserName

    • Valeur : ${user-email}

    Cet attribut est utilisé comme clé d'objet dans la configuration de contrôle d'accès OpenSearch affinée pour l'authentification.

  2. Ajoutez un attribut de groupe pour les rôles dans la section Déclaration des attributs de groupe :

    • Nom : groups

    • Filtre : OpenSearch_xxx

    Cet attribut est utilisé comme clé de rôle pour mapper les groupes à des rôles de contrôle d'accès OpenSearch précis à des fins d'autorisation.

Tâche 2 : configurer SAML dans le domaine OpenSearch

Pour configurer SAML dans un domaine OpenSearch

  1. Dans la console AWS de gestion, identifiez le domaine de OpenSearch service pour lequel vous souhaitez activer un contrôle d'accès précis pour les utilisateurs de l' OpenSearch interface utilisateur.

  2. Accédez à la page de détails du domaine en question.

  3. Sélectionnez l'onglet Configuration de sécurité et cliquez sur Modifier.

  4. Développez SAML via IAM Federate.

  5. Entrez le subjectKey et roleKey que vous avez défini dans Okta.

  6. Sélectionnez Enregistrer les modifications.

Vous pouvez également configurer un contrôle d'accès précis à l'aide du. AWS CLI

aws opensearch create-domain \
--domain-name testDomain \
--engine-version OpenSearch_1.3 \
--cluster-config InstanceType=r5.xlarge.search,InstanceCount=1,DedicatedMasterEnabled=false,ZoneAwarenessEnabled=false,WarmEnabled=false \
--access-policies '{"Version": "2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:12345678901:domain/neosaml10/*"}]}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"********","MasterUserPassword":"********"}, "IAMFederationOptions":{"Enabled": true,"SubjectKey":"TestSubjectKey","RolesKey":"TestRolesKey"}}' \
--ebs-options "EBSEnabled=true,VolumeType=gp2,VolumeSize=300" \
--no-verify-ssl \
--endpoint-url https://es.us-east-1.amazonaws.com \
--region us-east-1

Pour mettre à jour un domaine existant :

aws opensearch update-domain-config \
--domain-name testDomain \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"********","MasterUserPassword":"********"}, "IAMFederationOptions":{"Enabled": true,"SubjectKey":"TestSubjectKey","RolesKey":"TestRolesKey"}}' \
--ebs-options "EBSEnabled=true,VolumeType=gp2,VolumeSize=300" \
--no-verify-ssl \
--endpoint-url https://es.us-east-1.amazonaws.com \
--region us-east-1

Tâche 3 : configurer SAML dans les collections OpenSearch sans serveur

Pour configurer un contrôle SAML-based d'accès précis dans Serverless OpenSearch

  1. Ouvrez le Console de gestion AWS et accédez à Amazon OpenSearch Service.

  2. Dans le volet de navigation, sous Serverless, choisissez Security, puis Authentication.

  3. Dans la section IAM Federation, sélectionnez Modifier.

    Vous pouvez contrôler le contrôle d'accès affiné basé sur les attributs SAML à l'aide de cette configuration. La fédération IAM est désactivée par défaut.

  4. Sélectionnez Activer la fédération IAM.

  5. Entrez les roleKey valeurs subjectKey et que vous avez définies dans Okta.

    Pour de plus amples informations, veuillez consulter Attributs SAML pour un contrôle d'accès précis.

  6. Cliquez sur Enregistrer.

  7. Dans le volet de navigation, sous Serverless, choisissez Politique d'accès aux données.

  8. Mettez à jour une politique existante ou créez-en une nouvelle.

  9. Développez une règle, choisissez Ajouter des principaux, puis sélectionnez Utilisateurs et groupes IAM Federation.

  10. Ajoutez les principaux requis et choisissez Enregistrer.

  11. Choisissez Accorder.

  12. Selon cette règle, procédez comme suit :

    • Sélectionnez les autorisations que vous souhaitez définir pour les principaux sélectionnés.

    • Spécifiez les collections auxquelles vous souhaitez appliquer les autorisations.

    • Vous pouvez éventuellement définir des autorisations au niveau de l'index.

    Note

    Vous pouvez créer plusieurs règles pour attribuer différentes autorisations à différents groupes de directeurs.

  13. Lorsque vous avez terminé, choisissez Save (Sauvegarder).

  14. Choisissez Créer.

Vous pouvez également utiliser l'interface de ligne de commande pour créer les configurations de sécurité pour les collections, comme indiqué ci-dessous :

aws opensearchserverless create-security-config --region "region"  --type iamfederation --name "configuration_name" --description "description" --iam-federation-options '{"groupAttribute":"GroupKey","userAttribute":"UserKey"}'