Monitoring und Orchestrierung von Pods

F

Fluffy

Guest
Hallo,

Ich bin gerade dabei meinen umzu von VPS auf Root-server vorzunehmen und wollte, gerne bestimmte applicationen in Container packen(rkt).

Ich habe mehrere Applikationen welche per NginX und Reverse-Proxy ans Internet angebunden sind, diese würde ich gerne aufspalten.

Nun habe ich faili2ban, und kibana installiert.
kibana soll auch in einem Pod laufen und logs auswerten,

Nun wollte ich mal wissen was "Best Practice" ist.

Ich hätte sonst nämlich vor, fail2ban für ssh auf dem Host aufzusetzen, und fail2ban für den NginX-Pod, die Logs die ich analysieren will würde ich in gemountete volumns schreiben, und für den analysierenden Pod(read only) mounten.
Und Dateien würde ich der Persistenz halber in Volumns schreiben, gleiches gilt für zu benutztende SSL-Zertifikate, etc.

Wie sieht es mit DB-Pods aus?
Ein DBMS für alle Applikationen, oder ein Pod mit DBMS pro Applikation-Pod, oder DBMS im gleichen Pod laufen lassen.

Es geht hier um eine überschaubare Anzahl von Anfragen und Benutzern.
Private Projecte, Repositories, etc.

Gruß

Fluffy
 
Zuletzt bearbeitet von einem Moderator:
Ich kenne mich zwar mit rkt nicht sonderlich gut aus, aber fail2ban wirst du vermutlich auf dem Host laufen lassen müssen und dann halt alle Logs, die ausgewertet werden müssen, einfach in Host-mounted Volumes schreiben. Ansonsten müsstest du privilegierte Container verwenden, wie man sie von Docker kennt (docker run --privileged ...), was wiederum ein zusätzliches Sicherheitsrisiko bedeutet, da diese auf devfs des Hosts etc. zugreifen können. Keine Ahnung ob rkt sowas unterstützt. Aber nur so wirst du IPTables-Regeln nutzen können, weil die ja sonst nur auf das virtuelle Interface matchen würden und somit vom Container-Routing umgangen werden. Die Netzwerk-Interfaces des Hosts kennt ja der Container üblicherweise nicht und auf die müssen die Regeln letztendlich angewendet werden. Auch bin ich mir nicht sicher, ob iptables innerhalb von RKT-Containern überhaupt funktioniert.

Alternativ kannst du auch Kubernetes mit RKTs nutzen. Da hast du dann die Möglichkeit eine Art Addon-Container zu verwenden, denen du die privilegierten Rechte geben kannst. Ich denke aber, dass das für einen einzelnen Server etwas Overkill wäre. Kubernetes ist ja dann doch eher für richtige Private Clouds gedacht und das Setup ist zum Teil etwas Tricky, wenn man nicht auf Tools wie Rancher zurückgreift, die dann wiederum zusätzlichen Overhead verursachen.

Best Practice wäre es allerdings etwaige Angriffe bereits vor dem Server mit einem NIDS abzufangen und dann sicherheitshalber noch ein HIDS auf den Nodes zu verwenden, das mit dem NIDS kommuniziert und diesem die Blockierungen überlässt.
 
Hi Fluffy,

ich richte meine pods immer so ein, dass die Datenbank nur für den einen Service im pod gedacht ist. Zwecks fail2ban, ich würde mir die Logs, die vom reverse-proxy: nginx, haproxy, ... geschrieben werden, anschauen und anhand dieser Daten IPs bannen. Man greift ja auf alle container über den reverse-proxy zu.

Ein kubernetes cluster halte ich für das kleine Setup übertrieben. :p

LG
 
Zuletzt bearbeitet:
Hallo,

Also ich würde euch ja gerne danken und Eure Antworten "liken" aber ich seh es nicht ein dafür ajax.googleapis.com oder s3-kram zu aktivieren ;) aber fühlt Euch gedrückt :D .

Dann lasse ich DB local in den jeweiligen Pods laufen und mappe die Logs in locale Volums und lasse das dann von fail2ban auf dem Host auswerten.
Bin gerade dabei Skripte zu schreiben um das blocken zu extrahieren und angriffe die nicht geblockt werden, weil es nur einmal versucht wird und dann kann ich das alles auch über die Konsole auf dem Host machen :D.
Ein HIDS auf den Pods ist ein netter Gedanke, den ich definitiv bei Gelegenheit verfolge, aber zZ denke ich overkill.

Gruß

Fluffy
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben