Hatten wir mal, hat mehr Probleme verursacht als gelöst. Haben wir dann wieder abgedreht. Vielleicht in Zukunft mal, wenn der use-case wirklich relevant wird, aber aktuell nicht geplant.
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@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.
Die Instanz hier ist noch im Aufbau, es sind noch nicht alle Instanz- und Email Blocklists konfiguriert. Bitte noch etwas gedulden, kommt alles noch 🙏
Das können wir nicht wirklich beeinflussen, bzw. ist das keine Einstellung soweit ich weiss. Wenn es für dich nach einem Bug klingt am besten im Lemmy Github melden (bzw mal nachsehen ob schon was gemeldet wurde).
Wir haben die Limits jetzt auf 4k bzw 10MB erhöht.
@Der_aus_Aux@feddit.org : Aktuell ist das eingestellt, können wir natürlich anpassen:
- name: PICTRS__MEDIA__IMAGE__MAX_WIDTH
value: "2048"
- name: PICTRS__MEDIA__IMAGE__MAX_HEIGHT
value: "2048"
- name: PICTRS__MEDIA__IMAGE__MAX_AREA
value: "4194304"
- name: PICTRS__MEDIA__IMAGE__MAX_FILE_SIZE
value: "4"
@b2c@lemmy.fediverse.foundation test
@b2c@lemmy.fediverse.founation tes
test
view more: next ›
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: