Ich migriere derzeit unsere bestehende ELK-Anwendung von EC2 zu Amazon Elasticsearch Service. Erstens habe ich beschlossen, meinen bestehenden Kibana-Server zu behalten und ihn nur so zu wechseln, dass er auf die neue ES-Domäne verweist. Also habe ich meine bestehende Kibana-Konfiguration geändert, wie in diesem Abschnitt empfohlen: Ссылка
Dann begann ich einige Probleme zu haben, die in diesem Artikel behandelt wurden: Kibana wird keine Verbindung zu Elasticsearch im Elasticsearch Service von Amazon herstellen Mit Ausnahme von Schritt 4. Kibana benötigte immer noch eine Authentifizierung über den Header. Da ich CLI oder ein AWS SDK nicht zur Authentifizierung über Zugriffsschlüssel verwende, sondern stattdessen HTTP / S-Aufrufe verwende (z. B. Ссылка in der kibana config-Datei), sieht es so aus, als müsste ich meine HTTP-Anfragen trotzdem signieren (wie in Schritt 4 auf dem vorherigen Link vorgeschlagen), aber ich suche nach anderen Möglichkeiten, um dieses Problem zu lösen, um meine eigener Kibana-Server, Cluster, mit der richtigen Zugriffssteuerung von außen, während der Zugriff auf Elasticsearch nur für bestimmte IAM-Benutzer / Rollen geschützt wird.
Ich habe mich dann entschieden, eine andere Option auszuprobieren: meinen eigenen Proxy zu implementieren (in diesem Fall benutze meinen vorhandenen Nginx-Server, um ihn auf die neue ES-Domäne zu verweisen. Dieser Ansatz wird in Folie 56 zum Reinvent vorgeschlagen bdt209-launch-amazon-elasticsearch-for-real-time-data-analytics slideshare. Auf diese Weise könnte ich den Webserver für die Welt zugänglich machen (über die Ports 443/80), natürlich mit einfacher Web-Authentifizierung, während die ES-Domäne mit sehr restriktiven Zugriffsrichtlinien geschützt wird, die nur IP-basierte (sowie IAM-Rollen) erlauben. Zugriff auf den Elasticsearch-Cluster.
Allerdings bin ich immer noch auf dasselbe Problem gestoßen. Ich bekomme diese Nachricht als Antwort:
%Vor%Was bedeutet, dass ich die Anfrage unterschreiben müsste. Kann ich bitte einige Vorschläge zur Überwindung dieses Problems machen? Muss ich die Webanfragen wirklich programmatisch signieren? Oder gibt es andere Optionen, ohne die Sicherheit und Zugriffskontrolle zu beeinträchtigen (was bedeutet, dass ein eingeschränkter öffentlicher Zugang zu kibana mit sehr eingeschränktem Zugriff (Rolle und IP-basiert) auf den ES-Cluster möglich ist)?
Vielen Dank.
Der Grund des Problems war, dass Nginx den Berechtigungsheader (aktiviert über das Basisauthentifizierungsmodul) hinzugefügt hat, der eine verschlüsselte Zeichenfolge mit den Anmeldedetails für meine benutzerdefinierte Kibana-Instanz enthält.
Wenn dieser Header an den ES-Domänenendpunkt übergeben wird, versucht die ES-Domäne, diesen Header für die Authentifizierung beim empfangenden Server zu verwenden. Da es für meine benutzerdefinierten Autorisierungsanmeldeinformationen nicht voreingestellt ist, wird es einfach mit dem Autorisierungsfehler abgelehnt.
Also musste ich die Header-Weiterleitung vom NGINX-Proxy zum ElasticSearch-Endpunkt deaktivieren, indem ich meine Standort-Zeilengruppe (in meiner NGINX-Konfiguration) durch diese ersetzt habe:
%Vor%Ich weiß, dass es eine genehmigte Antwort hier gibt, aber es hat nicht vollständig für mich gearbeitet, und ich möchte meine Lösung präsentieren, vielleicht kann jemand sie verwenden. Meine Umgebung ist einfach, gewöhnliche aws Linux auf einer t2 Instanz, apt-get installiert nginx und untar kibana Ordner.
meine Datei nginx.conf;
%Vor%Ich glaube, dass die letzten zwei Zeilen wichtig sind und was in anderen Antworten fehlt. Wenn Sie irgendeine Art von Authentication-Header an Aws ES senden, versucht es, eine aws-API-Auth-Methode wie Signatur als Wert zu finden, so dass es nicht mit Auth-Header funktioniert.
Ich hoffe, dass das auch jemandem hilft, ich habe dafür vier Stunden als Nginx-Neuling gebraucht.
Tags und Links amazon-web-services elasticsearch