02 Projekte, Namespaces, RBAC und SCC
OpenShift Projects sind Kubernetes Namespaces mit zusätzlicher OpenShift-UX. RBAC entscheidet, wer API-Objekte ändern darf. SCCs bestimmen, unter welchen Linux-/Container-Sicherheitsbedingungen Pods laufen dürfen.
Fachliche Erklärung
Ein Projekt ist eine fachliche und organisatorische Grenze: Team, Anwendung, Umgebung oder Produktdomäne.
RBAC ist die Zugriffskontrolle auf die API. SCC ist die Laufzeitkontrolle für Pods. Beides löst unterschiedliche Probleme und darf nicht verwechselt werden.
Typisches Enterprise-Modell
Cluster Admins verwalten Cluster-weite Ressourcen, Nodes, Operators und SCCs.
Platform Engineers liefern Namespace-Templates, Quotas, NetworkPolicies und GitOps-Struktur.
Dev-Teams deployen innerhalb ihres Projekts nur freigegebene Ressourcen.
CI-ServiceAccounts bekommen nur Rechte, die für Build und Deployment nötig sind.
Security-Grundregel
Die Anwendung muss mit zufälliger UID, non-root, read-only Root-Filesystem und minimalen Capabilities funktionieren.
anyuid oder privileged ist keine Lösung für normale Java-Apps, sondern ein Ausnahmefall mit Begründung, Review und Ablaufdatum.
Ausführliches Enterprise-Beispiel
Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.
Fachlicher Ablauf
- Kunde bestellt über Portal.
- order-api validiert Auftrag.
- billing-api erzeugt Rechnung.
- payment-api prüft Zahlung.
- Events informieren Lager und Reporting.
Technischer Ablauf
- Route nimmt HTTPS an.
- Service verteilt auf Pods.
- Pods lesen ConfigMaps und Secrets.
- Readiness schützt Rollout.
- Monitoring misst Fehlerquote und Latenz.
Konfigurations- und Codebeispiele
YAML
apiVersion: v1
kind: ServiceAccount
metadata:
name: order-api-sa
namespace: shop
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: config-reader
namespace: shop
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: order-api-config-reader
namespace: shop
subjects:
- kind: ServiceAccount
name: order-api-sa
roleRef:
kind: Role
name: config-reader
apiGroup: rbac.authorization.k8s.io
# SCC-Grundregel: erst Anwendung restricted-v2-fähig machen.
# Nur bei begründeter Ausnahme eigene SCC erstellen und gezielt binden.
BASH
oc adm policy who-can create pods -n shop
oc get rolebindings -n shop
oc get scc
oc adm policy add-scc-to-user restricted-v2 -z order-api-sa -n shop
Typische Fehlerbilder und Diagnose
Pending Pods
Prüfe Ressourcen, Node-Selector, Taints, PVC und Quotas. Nicht sofort am Java-Code suchen.
CrashLoopBackOff
Prüfe Logs des vorherigen Containers, Config/Secrets, Port, JVM Memory und Health Endpoints.
Route erreichbar, App nicht
Prüfe Service-Selector, Endpoints, Readiness, TLS-Termination und NetworkPolicy.
Praxisaufgabe
Nimm eine Legacy-App, die in /tmp, /opt/app/logs und /var schreibt. Entscheide, was in EmptyDir, PVC, stdout logging oder Container-Image gehört.
Merksätze
- Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
- Security und Betrieb gehören von Anfang an zum Deployment.
- Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
- Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.