this post was submitted on 30 Jun 2024
67 points (98.6% liked)

Haupteingang

497 readers
1 users here now

Die Standard-Community von feddit.org

In dieser Community geht es ausschließlich um alles rund um die Instanz!

Regeln:

founded 5 months ago
MODERATORS
 

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.^

you are viewing a single comment's thread
view the rest of the comments
[–] aaaaaaaaargh 3 points 4 months ago (1 children)

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.

[–] admin 6 points 4 months ago (1 children)

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.

[–] aaaaaaaaargh 1 points 4 months ago* (last edited 4 months ago) (1 children)

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.

[–] admin 1 points 4 months ago

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: