Identity and Access Management in Amazon OpenSearch Service

Amazon OpenSearch Service bietet verschiedene Möglichkeiten, den Zugriff auf Ihre Domains zu kontrollieren. Dieses Thema geht auf die verschiedenen Richtlinientypen, deren Interaktion miteinander und die Erstellung eigener, benutzerdefinierter Richtlinien ein.

Arten von Richtlinien

OpenSearch Service unterstützt drei Arten von Zugriffsrichtlinien:

Ressourcenbasierte Richtlinien

Beim Erstellen einer Domain fügen Sie eine ressourcenbasierte Richtlinie hinzu, die oft als Domain-Zugriffsrichtlinie bezeichnet wird. Diese Richtlinien legen fest, welche Aktionen ein Prinzipal auf den Subressourcen der Domain durchführen kann (mit Ausnahme der clusterübergreifenden Suche). Zu den Unterressourcen gehören OpenSearch Indizes und. APIs Das Element Principal gibt die Konten, Benutzer oder Rollen an, denen Zugriff gewährt ist. Das Element Resource gibt an, auf welche Unterressourcen diese Prinzipale zugreifen können.

Beispielsweise gewährt die folgende ressourcenbasierte Richtlinie test-user vollen Zugriff (es:*) auf die Unterressourcen auf 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/*"
    }
  ]
}

Zwei wichtige Überlegungen treffen auf diese Richtlinie zu:

Sie können einen partiellen Indexnamen angeben, indem Sie einen Platzhalter hinzufügen. Dieses Beispiel identifiziert alle Indizes, die mit commerce beginnen:

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

In diesem Fall bedeutet der Platzhalter, dass test-user Anfragen an Indizes innerhalb von test-domain stellen kann, deren Namen mit commerce beginnen.

Um test-user weiter einzuschränken, können Sie die folgende Richtlinie anwenden:

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

Nun kann test-user nur noch eine Operation durchführen: die Suche nach dem Index commerce-data. Auf alle anderen Indizes innerhalb der Domain kann nicht zugegriffen werden, und ohne die Berechtigung, die Aktionen es:ESHttpPut oder es:ESHttpPost zu verwenden, kann test-user keine Dokumente hinzufügen oder ändern.

Als nächstes möchten Sie vielleicht eine Rolle für Hauptbenutzer konfigurieren. Diese Richtlinie ermöglicht den power-user-role Zugriff auf die PUT Methoden HTTP GET und für alle URIs im Index enthaltenen Methoden:

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

Wenn sich Ihre Domain in einer differenzierten Zugriffskontrolle befindet VPC oder diese verwendet, können Sie eine offene Domänenzugriffsrichtlinie verwenden. Andernfalls muss Ihre Domain-Zugriffsrichtlinie eine Einschränkung enthalten, entweder nach Prinzipal oder IP-Adresse.

Weitere Informationen zu allen verfügbaren Aktionen finden Sie unter Richtlinienelementreferenz. Für eine weitaus detailliertere Kontrolle über Ihre Daten verwenden Sie eine offene Domain-Zugriffsrichtlinie mit differenzierte Zugriffssteuerung.

Identitätsbasierte Richtlinien

Im Gegensatz zu ressourcenbasierten Richtlinien, die Teil jeder OpenSearch Dienstdomäne sind, fügen Sie Benutzern oder Rollen, die den Dienst () verwenden, identitätsbasierte Richtlinien zu. AWS Identity and Access Management IAM Genauso wie ressourcenbasierte Richtlinien legen identitätsbasierte Richtlinien fest, welche Personen auf einen Service zugreifen können, welche Aktionen sie ausführen können und, sofern zutreffend, für welche Ressourcen sie diese Aktionen ausführen können.

Identitätsbasierte Richtlinien sind in der Regel allgemeiner, dies muss aber nicht unbedingt so sein. Sie regeln häufig nur die API Konfigurationsaktionen, die ein Benutzer ausführen kann. Sobald Sie diese Richtlinien eingerichtet haben, können Sie ressourcenbasierte Richtlinien (oder eine differenzierte Zugriffskontrolle) in OpenSearch Service verwenden, um Benutzern Zugriff auf Indizes und zu gewähren. OpenSearch APIs

Da identitätsbasierte Richtlinien an Benutzer oder Rollen (Prinzipale) gebunden sind, JSON gibt sie keinen Prinzipal an. Die folgende Richtlinie gewährt Zugriff auf Aktionen, die mit Describe und List beginnen. Diese Kombination von Aktionen bietet schreibgeschützten Zugriff auf Domain-Konfigurationen, jedoch nicht direkt auf die in der Domain gespeicherten Daten:

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

Ein Administrator hat möglicherweise vollen Zugriff auf den OpenSearch Dienst und alle in allen Domänen gespeicherten Daten:

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

Mithilfe von identitätsbasierten Richtlinien können Sie Tags verwenden, um den Zugriff auf die Konfiguration zu steuern. API Die folgende Richtlinie ermöglicht es beispielsweise angehängten Prinzipalen, die Konfiguration einer Domain anzuzeigen und zu aktualisieren, wenn die Domain über das Tag team:devops verfügt:

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

Sie können Tags auch verwenden, um den Zugriff auf die zu steuern. OpenSearch API Tag-basierte Richtlinien für die gelten OpenSearch API nur für HTTP Methoden. Mit der folgenden Richtlinie können beispielsweise zugeordnete Principals PUT Anfragen an die Domain sendenGET, OpenSearch API ob die Domain über das environment:production Tag verfügt:

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

Für eine detailliertere Steuerung von sollten Sie eine OpenSearch API differenzierte Zugriffskontrolle in Betracht ziehen.

OpenSearch Der Service unterstützt die RequestTag und die TagKeys globalen Bedingungsschlüssel für die Konfiguration, nicht die. API OpenSearch API Diese Bedingungen gelten nur für API Aufrufe, die Tags in der Anfrage enthaltenCreateDomain, wieAddTags, undRemoveTags. Mit der folgenden Richtlinie können angehängte Prinzipale Domains erstellen, jedoch nur, wenn sie das team:it-Tag in die Anfrage aufnehmen:

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

Weitere Informationen zur Verwendung von Tags für die Zugriffskontrolle und zu den Unterschieden zwischen ressourcenbasierten und identitätsbasierten Richtlinien finden Sie im Benutzerhandbuch. IAM

IP-basierte Richtlinien

IP-basierte Richtlinien beschränken den Zugriff auf eine Domain auf eine oder mehrere IP-Adressen oder Blöcke. CIDR Aus technischer Sicht sind IP-basierte Richtlinien kein eigener Richtlinientyp. Stattdessen sind sie einfach ressourcenbasierte Richtlinien, die einen anonymen Prinzipal angeben und ein besonderes Condition-Element einschließen.

Der Hauptvorteil IP-basierter Richtlinien besteht darin, dass sie unsignierte Anfragen an eine OpenSearch Service-Domain zulassen, sodass Sie Clients wie Curl und OpenSearch Dashboards verwenden oder über einen Proxyserver auf die Domain zugreifen können. Weitere Informationen hierzu finden Sie unter Verwenden eines Proxys für den Zugriff auf den OpenSearch Service über Dashboards.

Die folgende Richtlinie gewährt allen HTTP Anfragen, die aus dem angegebenen IP-Bereich stammen, test-domain Zugriff auf:

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

Wenn Ihre Domain über einen öffentlichen Endpunkt verfügt und keine detaillierte Zugriffskontrolle verwendet, empfehlen wir, IAM Prinzipale und IP-Adressen zu kombinieren. Diese Richtlinie gewährt test-user HTTP Zugriff nur, wenn die Anfrage aus dem angegebenen IP-Bereich stammt:

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

Konflikte in Richtlinien

Komplexitäten entstehen, wenn Richtlinien einander widersprechen oder den Benutzer nicht explizit erwähnen. Die Erläuterung der IAM Funktionsweise im IAMBenutzerhandbuch bietet eine kurze Zusammenfassung der Logik zur Bewertung von Richtlinien:

Wenn Ihnen beispielsweise eine ressourcenbasierte Richtlinie Zugriff auf eine Domain-Unterressource (einen OpenSearch Index oderAPI) gewährt, Ihnen aber eine identitätsbasierte Richtlinie den Zugriff verweigert, wird Ihnen der Zugriff verweigert. Wenn eine identitätsbasierte Richtlinien den Zugriff gewährt, eine ressourcenbasierte Richtlinie aber nicht festlegt, ob Ihnen Zugriff gewährt werden soll oder ob nicht, wird Ihnen der Zugriff gewährt. In der folgenden Tabelle sich überschneidender Richtlinien finden Sie eine vollständige Übersicht der Ergebnisse für Domains-Subressourcen.

Richtlinienelementreferenz

OpenSearch Service unterstützt die meisten Richtlinienelemente in der IAMPolicy Elements Reference, mit Ausnahme von. NotPrincipal Die folgende Tabelle zeigt die gängigsten Elemente.

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

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

Erweiterte Optionen und Überlegungen API

OpenSearch Der Service bietet mehrere erweiterte Optionen, von denen eine Auswirkungen auf die Zugriffskontrolle hat:rest.action.multi.allow_explicit_index. Bei ihrer Standardeinstellung „true" können Benutzer Unterressourcen-Berechtigungen unter bestimmten Bedingungen umgehen.

Beachten Sie beispielsweise die folgende ressourcenbasierte Richtlinie:

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

Diese Richtlinie gewährt test-user vollen Zugriff auf test-index und den OpenSearch GroßteilAPI. Außerdem ermöglicht sie GET-Anforderungen an restricted-index.

Wie zu erwarten, schlägt die folgende Indizierungsanforderung aufgrund eines Berechtigungsfehlers fehl:

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

Im Gegensatz zum Index API API können Sie mit dem Bulk-Modus viele Dokumente in einem einzigen Aufruf erstellen, aktualisieren und löschen. Sie geben diese Operationen jedoch häufig im Anforderungstext und nicht in der Anforderung anURL. Da OpenSearch Service URLs den Zugriff auf Domänen-Subressourcen steuert, test-user kann er tatsächlich die Menge verwenden, API um Änderungen daran vorzunehmen. restricted-index Auch wenn der Benutzer über keine POST-Berechtigungen für den Index verfügt, ist die folgende Anforderung erfolgreich:

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

In diesem Fall funktioniert die Zugriffsrichtlinie nicht wie beabsichtigt. Um Benutzer daran zu hindern, diese Arten von Einschränkungen zu umgehen, können Sie rest.action.multi.allow_explicit_index in „false" ändern. Wenn dieser Wert falsch ist, funktionieren alle Aufrufe von bulk, mget und msearch, die Indexnamen im Hauptteil der Anfrage angebenAPIs, nicht mehr. Mit anderen Worten: Aufrufe an _bulk funktionieren nicht mehr, aber Aufrufe an test-index/_bulk sind hiervon nicht betroffen. Da dieser zweite Endpunkt einen Indexnamen enthält, müssen Sie im Anforderungstext keinen angeben.

OpenSearch Dashboards sind stark von mget und msearch abhängig, weshalb es nach dieser Änderung unwahrscheinlich ist, dass es ordnungsgemäß funktioniert. Bei teilweiser Korrektur können Sie den Wert auf „true“ rest.action.multi.allow_explicit_index belassen und bestimmten Benutzern den Zugriff auf eine oder mehrere dieser Optionen verweigern. APIs

Weitere Informationen zum Ändern dieser Einstellung finden Sie unter Erweiterte Clustereinstellungen.

Dementsprechend enthalt die folgende ressourcenbasierte Richtlinie zwei geringfügige Probleme:

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

Anstatt großzügige Berechtigungen und gezielte Verweigerungen miteinander zu mischen, ist eine sicherere Strategie, der Regel der geringsten Rechte zu folgen und nur die Berechtigungen zu gewähren, die zum Ausführen einer Aufgabe erforderlich sind. Weitere Informationen zur Steuerung des Zugriffs auf einzelne Indizes oder OpenSearch Operationen finden Sie unter. Feinkörnige Zugriffskontrolle in Amazon Service OpenSearch

Konfigurieren von Zugriffsrichtlinien

Zusätzliche Beispielrichtlinien

Obwohl dieses Kapitel viele Beispielrichtlinien enthält, ist die AWS Zugriffskontrolle ein komplexes Thema, das sich am besten anhand von Beispielen verstehen lässt. Weitere Informationen finden Sie im IAMBenutzerhandbuch unter Beispiele für IAM identitätsbasierte Richtlinien.