Activation de la fédération SAML avec AWS Identity and Access Management - Amazon OpenSearch Service
Étape 1 : configurer l'application du fournisseur d'identité (Okta)Étape 2 : configurer la AWS configuration pour OktaÉtape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAMÉtape 4 : vérifier l'expérience d'authentification unique initiée par le fournisseur d'identité avec SAMLÉtape 5 : Configuration du contrôle d'accès détaillé 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 AWS Identity and Access Management

OpenSearch L'interface utilisateur prend en charge le langage SAML (Security Assertion Markup Language 2.0), un standard ouvert utilisé par de nombreux fournisseurs d'identité. Cela permet la fédération d'identité avec AWS Identity and Access Management (IAM). Grâce à cette assistance, les utilisateurs de votre compte ou de votre organisation peuvent accéder directement à l' OpenSearch interface utilisateur en assumant les 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, dans le cadre de laquelle ils peuvent s'authentifier auprès du fournisseur d'identité externe et ê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 différentes autorisations d'accès à l' OpenSearch interface utilisateur et aux sources de données associées.

Cette rubrique présente des step-by-step instructions 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.

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

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

Tâche 1 : créer des utilisateurs Okta

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

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

  3. Choisissez Add person (Ajouter une personne).

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

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

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

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

  8. (Facultatif) Décochez la case L'utilisateur doit changer de mot de passe lors de sa 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éer et attribuer des groupes

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

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

  3. Choisissez Add Group (Ajouter un groupe).

  4. Entrez un nom de groupe et choisissez Enregistrer.

  5. Choisissez le groupe nouvellement créé, puis choisissez Affecter des personnes.

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

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

Tâche 3 : créer des applications Okta

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en 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 Next.

  6. Entrez les valeurs suivantes dans l'application ; il n'est pas nécessaire 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 d'audience (ID d'entité SP), entrezurn:amazon:webservices.

    3. 3. Pour le format Name ID, 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 Affectations, puis Attribuer.

  11. Choisissez Affecter 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 à l'adresse https://login.okta.com/en 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'attribut (facultatif), ajoutez les propriétés suivantes :

    1. Indiquez le rôle IAM et le fournisseur d'identité séparés par des virgules à l'aide de l'attribut Role. Vous utiliserez ce même rôle IAM et ce même fournisseur d'identité lors d'une étape ultérieure lors de la configuration de AWS la configuration.

    2. Définissez user.login pour. RoleSessionName Il est utilisé comme identifiant pour les informations d'identification temporaires é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 précisé

    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 précisé

    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 illustré dans l'image suivante. La valeur de l'état du relais par défaut 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 le définir sur n'importe quelle page de l' OpenSearch interface utilisateur, puis fournir cette URL aux utilisateurs finaux auxquels il est destiné.

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

Étape 2 : configurer la AWS configuration pour Okta

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

Tâche 1 : recueillir des informations sur Okta

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

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en 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'URL d'authentification 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 à la console IAM AWS Management Console et ouvrez-la à https://console.aws.amazon.com/iam/l'adresse.

  2. Dans le volet de navigation, sous Gestion des accès, sélectionnez Fournisseurs d'identité.

  3. Choisissez Ajouter un fournisseur.

  4. Pour le 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éer un rôle IAM

Pour créer votre AWS Identity and Access Management rôle, procédez comme suit :

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

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

  3. Choisissez Créer un rôle.

  4. Pour le type d'entité fiable, sélectionnez la 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' AWS Management Console accès.

  7. Choisissez Suivant.

  8. Dans la liste des politiques d'autorisation, cochez les cases correspondant à la politique que vous avez créée précédemment et pour laquelle OpenSearchFullAccess.

  9. Choisissez Suivant.

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

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

  12. Choisissez Créer un rôle.

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

  14. Dans le volet Modifier le relevé, sous Ajouter des actions pour STS, cochez la case correspondant à TagSession.

  15. Choisissez Mettre à jour une politique.

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

Découvrez comment configurer vos rôles IAM pour le contrôle OpenSearch d'accès. Avec les rôles IAM, vous pouvez mettre en œuvre un contrôle d'accès précis pour que vos groupes d'utilisateurs Okta puissent accéder aux ressources. OpenSearch Cette rubrique décrit 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érifier l'expérience d'authentification unique initiée par le fournisseur d'identité avec SAML

Ouvrez l'URL de l'état du relais par défaut 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 cliquant sur 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 détaillées accordées à 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. Vous trouverez ci-dessous 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 détaillé basé sur les attributs SAML

Avec Amazon OpenSearch Service, vous pouvez utiliser le contrôle d'accès détaillé avec SAML pour mapper de manière dynamique les utilisateurs et les groupes de votre fournisseur d'identité aux utilisateurs et rôles de contrôle OpenSearch d'accès précis. 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 détaillé, consultez. Contrôle d'accès précis dans Amazon Service OpenSearch

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.

Rôles Key

Correspond aux 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'attribut :

    • Nom : UserName

    • Valeur : ${user-email}

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

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

    • Nom : groups

    • Filtre : OpenSearch_xxx

    Cet attribut est utilisé comme clé de rôle pour mapper des 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 le 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 la sécurité et cliquez sur Modifier.

  4. Développez le protocole 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 détaillé à 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 le contrôle d'accès détaillé basé sur SAML dans Serverless OpenSearch

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

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

  3. Dans la section Fédération IAM, sélectionnez Modifier.

    Vous pouvez contrôler le contrôle d'accès détaillé 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. Sélectionnez Save.

  7. Dans le volet de navigation, sous Serverless, choisissez Data access policy.

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

  9. Développez une règle, choisissez Ajouter des principes, puis sélectionnez les utilisateurs et les groupes de la fédération IAM.

  10. Ajoutez les principes 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.

    • Définissez éventuellement 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 la CLI 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"}'