Identity and Access Management dans Amazon OpenSearch Service

Amazon OpenSearch Service propose plusieurs méthodes pour contrôler l'accès à vos domaines. Cette rubrique présente différents types de stratégies, explique leurs interactions et indique comment créer vos propres stratégies personnalisées.

Types de stratégies

OpenSearch Le service prend en charge trois types de politiques d'accès :

Stratégies basées sur les ressources

Vous ajoutez une stratégie basée sur les ressources, souvent appelée stratégie d'accès au domaine, lorsque vous créez un domaine. Ces politiques spécifient quelles actions un principal peut effectuer sur les sous-ressources du domaine (à l'exception de la recherche entre clusters). Les sous-ressources incluent les OpenSearch index et. APIs L'élément Principal spécifie les comptes, les utilisateurs ou les rôles qui sont autorisés à y accéder. L'élément Resource définit les sous-ressources qui sont accessibles à ces mandataires.

Par exemple, la politique suivante basée sur les ressources accorde à test-user l'accès total (es:*) aux sous-ressources de test-domain :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Deux considérations importantes s'appliquent à cette stratégie :

Vous pouvez spécifier un nom d'index partiel en ajoutant un caractère générique. Cet exemple identifie tous les index commençant par commerce :

arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*

Dans ce cas, le caractère générique signifie que test-user peut envoyer des requêtes aux index de test-domain dont le nom commence par commerce.

Pour restreindre davantage test-user, vous pouvez appliquer la stratégie suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search"
    }
  ]
}

À présent, test-user ne peut effectuer qu'une seule opération : rechercher sur l'index commerce-data. Tous les autres index au sein du domaine sont inaccessibles et, sans autorisation d'utiliser les actions es:ESHttpPut ou es:ESHttpPost, test-user ne peut pas ajouter ou modifier des documents.

Ensuite, vous pouvez décider de configurer un rôle pour les utilisateurs avancés. Cette politique donne power-user-role accès aux PUT méthodes HTTP GET et pour tous les utilisateurs URIs de l'index :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:role/power-user-role"
        ]
      },
      "Action": [
        "es:ESHttpGet",
        "es:ESHttpPut"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*"
    }
  ]
}

Si votre domaine se trouve dans un VPC ou utilise un contrôle d'accès détaillé, vous pouvez utiliser une politique d'accès aux domaines ouverts. Sinon, votre stratégie d'accès au domaine doit contenir certaines restrictions, soit par le principal, soit par l'adresse IP.

Pour plus d'informations sur les différentes actions disponibles, consultez Références des éléments de stratégie. Pour un contrôle nettement plus précis de vos données, utilisez une stratégie d'accès ouverte au domaine avec contrôle précis des accès.

Politiques basées sur l’identité

Contrairement aux politiques basées sur les ressources, qui font partie de chaque domaine de OpenSearch service, vous associez des politiques basées sur l'identité aux utilisateurs ou aux rôles utilisant le AWS Identity and Access Management service (). IAM Tout comme les stratégies basées sur une ressource, celles basées sur une identité déterminent qui est autorisé à accéder à un service, quelles actions peuvent être exécutées et, le cas échéant, les ressources concernées.

Bien que ce ne soit certainement pas nécessaire, les stratégies basées sur une identité ont tendance à être plus génériques. Ils régissent souvent uniquement les API actions de configuration qu'un utilisateur peut effectuer. Une fois ces politiques en place, vous pouvez utiliser des politiques basées sur les ressources (ou un contrôle d'accès précis) dans OpenSearch Service pour permettre aux utilisateurs d'accéder aux index et. OpenSearch APIs

Les politiques basées sur l'identité étant associées à des utilisateurs ou à des rôles (principaux), elles JSON ne spécifient aucun principal. La stratégie suivante accorde l'accès à des actions commençant par Describe et List. Cette combinaison d'actions fournit un accès en lecture seule aux configurations de domaine, mais pas aux données stockées dans le domaine lui-même :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "es:Describe*",
        "es:List*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Un administrateur peut avoir un accès complet au OpenSearch service et à toutes les données stockées sur tous les domaines :

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

Les politiques basées sur l'identité vous permettent d'utiliser des balises pour contrôler l'accès à la configuration. API La stratégie suivante, par exemple, permet aux principaux attachés d'afficher et de mettre à jour la configuration d'un domaine si ce domaine dispose de la balise team:devops :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:UpdateDomainConfig",
      "es:DescribeDomain",
      "es:DescribeDomainConfig"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/team": [
          "devops"
        ]
      }
    }
  }]
}

Vous pouvez également utiliser des balises pour contrôler l'accès au OpenSearch API. Les politiques basées sur des balises s'appliquent OpenSearch API uniquement aux HTTP méthodes. Par exemple, la politique suivante permet aux principaux rattachés d'envoyer GET des PUT demandes OpenSearch API si le domaine possède le environment:production tag :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:ESHttpGet",
      "es:ESHttpPut"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

Pour un contrôle plus précis de la OpenSearch API, pensez à utiliser un contrôle d'accès précis.

OpenSearch Le service prend en charge les clés de condition TagKeys globales RequestTag et les clés de condition pour la configurationAPI, et non le OpenSearch API. Ces conditions s'appliquent uniquement aux API appels qui incluent des balises dans la demande, telles que CreateDomainAddTags, etRemoveTags. La stratégie suivante permet aux principaux attachés de créer des domaines, mais uniquement s'ils disposent de la balise team:it dans la requête :

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "es:CreateDomain",
      "es:AddTags"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:RequestTag/team": [
          "it"
        ]
      }
    }
  }
}

Pour plus de détails sur l'utilisation des balises pour le contrôle d'accès et sur les différences entre les politiques basées sur les ressources et les politiques basées sur l'identité, consultez le guide de l'utilisateur. IAM

Stratégies basées sur l'IP

Les politiques basées sur l'IP limitent l'accès à un domaine à une ou plusieurs adresses IP ou CIDR blocs. Techniquement, les stratégies basées sur l'adresse IP ne sont pas un type de stratégie distincte. Elles sont simplement des stratégies basées sur une ressource qui spécifient un principal anonyme et incluent un élément Condition spécial.

Le principal avantage des politiques basées sur l'IP est qu'elles autorisent les requêtes non signées adressées à un domaine de OpenSearch service, ce qui vous permet d'utiliser des clients tels que curl et OpenSearch Dashboards ou d'accéder au domaine via un serveur proxy. Pour en savoir plus, consultez Utilisation d'un proxy pour accéder au OpenSearch service à partir de tableaux de bord.

La politique suivante accorde à toutes les HTTP demandes provenant de la plage d'adresses IP spécifiée l'accès à test-domain :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Si votre domaine possède un point de terminaison public et n'utilise pas de contrôle d'accès précis, nous vous recommandons de combiner IAM les principaux et les adresses IP. Cette politique n'accorde test-user HTTP l'accès que si la demande provient de la plage d'adresses IP spécifiée :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": [
        "arn:aws:iam::987654321098:user/test-user"
      ]
    },
    "Action": [
      "es:ESHttp*"
    ],
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": [
          "192.0.2.0/24"
        ]
      }
    },
    "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
  }]
}

En cas de conflit entre plusieurs stratégies

Si les stratégies sont en désaccord ou ne mentionnent explicitement un utilisateur, cela crée des situations complexes. Comprendre comment IAM fonctionne le guide de l'IAMutilisateur fournit un résumé concis de la logique d'évaluation des politiques :

Par exemple, si une politique basée sur les ressources vous accorde l'accès à une sous-ressource de domaine (un OpenSearch index ouAPI), mais qu'une politique basée sur l'identité vous en refuse l'accès, l'accès vous est refusé. Si une stratégie basée sur une identité accorde l'accès et celle basée sur une ressource ne spécifie rien concernant votre accès, vous êtes autorisé à accéder. Pour un récapitulatif complet des issues possibles en matière de sous-ressources de domaine, consultez le tableau suivant des recoupements entre stratégies.

Références des éléments de stratégie

OpenSearch Le service prend en charge la plupart des éléments de IAMpolitique figurant dans la référence des éléments de politique, à l'exception deNotPrincipal. Le tableau suivant indique les éléments les plus courants.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "es:ESHttpGet",
        "es:DescribeDomain"
      ],
      "Resource": "*"
    }
  ]
}

"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}

Options avancées et API considérations

OpenSearch Le service comporte plusieurs options avancées, dont l'une a des implications en matière de contrôle d'accès :rest.action.multi.allow_explicit_index. Avec sa configuration par défaut sur true (vrai), elle permet aux utilisateurs de contourner les autorisations au niveau des sous-ressources dans certaines circonstances.

Prenons l'exemple suivant de stratégie basée sur une ressource :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": [
        "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*",
        "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk"
      ]
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*"
    }
  ]
}

Cette politique accorde un accès test-user complet test-index et OpenSearch globalAPI. Elle autorise également les demandes GET sur restricted-index.

L'exemple suivant de demande d'indexation échoue, comme vous pouviez vous y attendre, en raison d'une erreur d'autorisation :

PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1
{
  "title": "Your Name",
  "director": "Makoto Shinkai",
  "year": "2016"
}

Contrairement à l'indexAPI, le bloc vous API permet de créer, de mettre à jour et de supprimer de nombreux documents en un seul appel. Cependant, vous spécifiez souvent ces opérations dans le corps de la demande plutôt que dans la demandeURL. Étant donné que le OpenSearch service contrôle l'accès aux sous-ressources du domaine, il test-user peut en fait utiliser la masse API pour apporter restricted-index des modifications. URLs Même si l'utilisateur n'a pas les autorisations POST pour l'index, la demande suivante aboutit :

POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk
{ "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } }
{ "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

Dans ce cas, la stratégie d'accès ne parvient pas à remplir sa fonction. Pour empêcher les utilisateurs de passer outre ce type de restrictions, vous pouvez remplacer la valeur de rest.action.multi.allow_explicit_index par false (faux). Si cette valeur est fausse, tous les appels aux commandes bulk, mget et msearch APIs qui spécifient les noms d'index dans le corps de la requête cessent de fonctionner. En d'autres termes, les appels _bulk ne fonctionnent plus, mais les appels test-index/_bulk, oui. Ce deuxième point de terminaison contient un nom d'index, de sorte que vous n'avez pas besoin d'en spécifier un dans le corps de la demande.

OpenSearch Les tableaux de bord reposent largement sur mget et msearch, il est donc peu probable qu'ils fonctionnent correctement après cette modification. Pour une correction partielle, vous pouvez laisser rest.action.multi.allow_explicit_index la valeur true et refuser à certains utilisateurs l'accès à une ou plusieurs d'entre ellesAPIs.

Pour plus d'informations sur la modification de ce paramètre, consultez Paramètres avancés du cluster.

De même, la stratégie basée sur une ressource ci-après engendre deux problèmes subtils :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/test-user"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/test-user"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*"
    }
  ]
}

Plutôt que de combiner de vastes autorisations avec des refus ciblés, l'approche la plus sûre consiste à appliquer le principe du moindre privilège et à accorder uniquement les autorisations qui sont requises pour exécuter une tâche. Pour plus d'informations sur le contrôle de l'accès à des index ou à des OpenSearch opérations individuels, consultezContrôle d'accès précis dans Amazon Service OpenSearch .

Configuration des politiques d'accès

Exemples de stratégies supplémentaires

Bien que ce chapitre contienne de nombreux exemples de politiques, le contrôle d' AWS accès est un sujet complexe qu'il est préférable de comprendre à l'aide d'exemples. Pour en savoir plus, consultez la section Exemples de politiques IAM basées sur l'identité dans le Guide de l'IAMutilisateur.