Hab im Matrixraum vor ein paar Tagen schon angesprochen, dass es gut wäre einen Feedbackpost für die org-Gemeinschaft zu erstellen. Ich machs einfach mal, auch wenn ich kein Admin bin. Wir könnten einen ähnlichen Post für Feedback auch allmonatlich machen, damit immer ein Kanal offen steht. Mit 100 Posts/Tag scheint die Instanz ja zu florieren.
Wie habt ihr euch alle eingefunden, läuft alles?
Ihr könnt auch einfach friedlich miteinander über Gott und die Welt diskutieren.
@aaaaaaaaargh@feddit.org : Wir haben hier ein halbes Rack voll Infra für die Instanzen, inkl. dedizierte reverse proxies, redundantes 10GbE Netzwerk, Blade Chassis für die Server und Enterprise Storage. Wird alles von uns selbst gewartet und gemanaged. Virtualisierung läuft aktuell noch auf Debian/KVM, ziehen wir aber gerade auf Proxmox um. Die ganzen Apps betreiben wir in Openshift, für Middleware und Backend Komponenten haben wir dedizierte VMs.
Das alles läuft privat gehosted in einem ISO-zertifizierten RZ bei einem mittelständischen Wiener IT-Dienstleister.
Klingt erstmal vernünftig. Warum OpenShift, wenn ich fragen darf? Ist gar nicht so unbedingt eine Glaubensfrage, ich nutze beides leidenschaftslos, mich interessieren nur die Beweggründe zur Technologiewahl.
Wir verwenden das freie Openshift/OKD, macht k8s management um vieles leichter und bringt auch ansonsten viele Features mit (logging, metrics, authentication/authorization, build pipelines, etc…), die man sonst händisch nachbauen muss. Auch viele Sicherheitsstandards, die man bei k8s erst konfigurieren oder dazubasteln muss sind hier schon per default aktiviert.
Welche Authentification/Authorization ist denn in OpenShift standardmäßig enthalten? Und welche Sicherheitsstandards sind vorhanden, die in einem k8s fehlen?
Nochmal: das ist keine nutzlose Konfrontation, ich versuche gerade aktiv zu lernen.
Auf den S2i-Kram von OpenShift bin ich aber in der Tat wirklich ein wenig neidisch.
Per default geht mal OAuth/OpenID/LDAP/AD
Wir verwenden LDAP, damit bekommt man schon mal out-of-the-box recht gute RBAC policies, um namespace und cluster permissions zu segmentieren.
SAML gibt’s derzeit nur eine community Implementierung:
Für security hilft ja schon mal der Ansatz, dass CoreOS praktisch “immutable” ist, und auch die ganzen SELinux und container policies, die per default strikt eingestellt sind. Damit bekommt jeder namespace eine zufällige ID zugewiesen, die dann für pods als UID/GID verwendet wird. Auch sämtliche capabilities usw. sind standardmäßig eingeschränkt. Network namespace isolation kann man auch ganz einfach haben, muss man nur bei der Installation des overlay network intial angeben.
Und dann gibt’s noch support für alle möglichen Technologoien, die ggf für Compliance relevant sein können, siehe hier: