Misschien rollen je ogen omhoog bij de zoveelste blog over zoiets saais als logbeheer met ELK. Maar dat is niet echt de focus van deze blog post. Hier duiken we dieper in het veiligheidsaspect van een ELK stack en helpen we je er zelf een op te zetten.
Laten we zeggen dat je een systeemingenieur/persoon bent die betrokken is bij DevOps en al die logs op een heleboel permanente of tijdelijke (cloud) servers hebt staan. En dan heb je nog je collega's: ontwikkelaars, auditors en gewone gebruikers die deze logs moeten lezen of rapporten moeten krijgen. Al deze mensen toegang geven tot deze logs zal waarschijnlijk resulteren in een hel, als het al mogelijk is.
Het wordt nog moeilijker als de servers en hun logs deel uitmaken van een hoog beschikbare omgeving, waar veel servers en veel logs zijn en het nog moeilijker (lees: onmogelijk) is om logs te krijgen van servers die niet meer bestaan als gevolg van een autoscaling 'scale in'-gebeurtenis. De oplossing is om een logbeheersysteem te gebruiken. Zo'n systeem haalt de logs op van al je servers, transformeert en indexeert ze en slaat ze uiteindelijk op, klaar voor analyse en rapportage.
Een Elastic Stack gebruikt verschillende 'Beats' om de gegevens te verzamelen en naar Logstash te sturen, waar ze worden getransformeerd en vervolgens gepusht en opgeslagen in Elasticsearch. Vervolgens wordt alles gevisualiseerd in Kibana met mooie grafieken en filters, zodat je gemakkelijk kunt vinden wat je nodig hebt.
Een Elastic Stack is vrij eenvoudig te installeren metDocker. Als jeRancher gebruikt(voor Docker container orkestratie), kun je al binnen een paar minuten een draaiende Elastic Stack hebben. En het werkt ook echt, geen gekke dingen.
Er wordt echter weinig tot geen aandacht besteed aan veiligheid en beveiliging. Meestal, als je een Elastic Stack in een bedrijf bekijkt, kun je het vinden op een http-adres (dus niet versleuteld), je hoeft niet in te loggen (zelfs gasten van het netwerk die op het serveradres stuiten kunnen een blik werpen op je logfouten) en iedereen kan gewoon de gegevens in Elasticsearch manipuleren (ideaal als je mislukte inlogpogingen wilt verdoezelen)!
Zowel de open source Search Guard beveiligingsplugin als X-Pack van Elastic.co (onlangs omgedoopt tot het minder pakkendeElastic Stack Features) helpen om de Elastic Stack te beveiligen. Een belangrijk verschil is dat voor X-Pack een betaalde licentie nodig is en dat Search Guard open source is voor veel functies en dat je een betaalde licentie kunt krijgen als je LDAP of AD moet integreren en/of de toegang tot specifieke gegevens moet controleren. Als we alleen al naar de kosten kijken, kiezen we ervoor om de open source versie van Search Guard te gebruiken, de 'Community Edition' bij ACA Group.
Als kind speelde ik bijna uitsluitend met Lego (Nintendo en internet bestonden nog niet of waren nog vrij onbekend). Het leuke van LEGO is dat je alle soorten stenen kunt combineren en iets heel nieuws kunt maken. De enige beperking is je verbeelding!
Bij het bouwen van dit ELK-platform heb ik het op ongeveer dezelfde manier bekeken. Ik gebruikte de ELK Stack van Rancher 1.6 (ziehier) en verving alle containers door docker Search-Guard containers voor Elasticsearch, Logstash en Kibana van https://github.com/khezen.
Voor het beheer van ElasticSearch heb ik Cerebro gekozen (Kopf werkt niet met Secure Elastic Stack) en als laatste Curator om oude indexen op te ruimen.
Traefik containers handelen zowel het beveiligde SSL verkeer af op TLS 1.2 en alleen goede Ciphers (ik heb een hekel aanPOODLE) als de load balancing naar de applicaties aan de achterkant. De Traefik containers zijn op hun beurt verbonden met Amazon ALB's voor Kibana en Cerebro. Daarna heb ik een Beats stack toegevoegd met filebeat en metricbeat op alle applicatieservers om logs of andere gegevens te verzamelen. En ook een homebrew log file cleaner om de logs zelf onder controle te houden.
Samengevat:
Zo ziet de hele stack eruit. Houd in gedachten dat de Rancher Master server en Rancher Agent 3 NOOIT worden weergegeven (maar ze zijn er zeker!).
💡 TIP #1: Er is een direct verband tussen de hoeveelheid servers en logs die u aan Elasticsearch toevertrouwt en de schijfopslag die u gebruikt. Hoe meer servers, hoe meer logs, hoe meer schijfruimte u nodig hebt. Als u echter indexen die u niet nodig hebt correct opschoont met Curator en u ervoor zorgt dat uw collega devs en u proberen de logs laag te houden (wat sowieso een goede gewoonte is), dan kan de hoeveelheid schijfruimte die u nodig hebt laag blijven. Bonus: het houdt je ELK ook snel!
💡TIP#2: Houd al je shards voor alle indexen op alle schijven met een regelmatige cron job erin. Het houdt Elasticsearch langer gezond en mogelijk sneller tegen zeer weinig extra kosten.
Op Amazon VPC - Rancher master met 3 Rancher agents
Op interne VMWare-servers - Rancher-master met 3 Rancher-agenten
Een Search Guard-script in de khezen Elasticsearch-container maakt certificaten aan bij de eerste run. Dit leek echter niet goed te werken voor mij, omdat deze certificaten geïsoleerd worden aangemaakt voor elke Elasticsearch-container. Dit betekent dus dat je ongeveer negen servers hebt die hun eigen (zelfondertekende) certificaten aanmaken. De certificaten worden 'slechts' gebruikt voor communicatie tussen alle Elastic Stack-componenten, dus zelfondertekende certificaten kunnen geen kwaad. Natuurlijk moeten sommige certificaten hetzelfde zijn voor alle containers van het platform.
U kunt het gebrek aan certificaatuniformiteit oplossen door:
Als je Rancher en/of Kubernetes gebruikt, dan weet je dat je wachtwoorden kunt opslaan in Rancher Secrets en Kubernetes Secrets. Je kunt ze dan delen met de containers die ze nodig hebben.
Als je alles goed hebt gedaan, zou je moeten eindigen met een Kibana die achter een Amazon ALB zit met certificaten voor https. Je kunt dan inloggen met het gebruikersaccount dat je gedefinieerd hebt. Hier is een voorbeeld van een Kibana dashboard:
Hieronder vind je alle technische details voor:
Klik op de links om naar de technische details van elke component te gaan.