Projektzugriffsrechte in OpenShift implementieren Namespace-basierte Autorisierungsgrenzen für Multi-Tenant-Ressourcenisolation und teamorientierte Zugriffskontrolle. Diese projektspezifischen Sicherheits-Frameworks ermöglichen granulare Berechtigungskontrolle innerhalb organisatorischer Strukturen und unterstützen kollaborative Entwicklungsworkflows mit definierten Sicherheitsgrenzen.
OpenShift-Projekte erweitern Kubernetes-Namespaces um zusätzliche Sicherheitsrichtlinien, Ressourcenquoten und Zugriffskontrollmechanismen für erweiterte Multi-Tenancy. Diese Projekt-Abstraktion implementiert geschäftslogik-orientierte Sicherheitsgrenzen und erleichtert die Verwaltung komplexer Anwendungslandschaften.
Projekt-Mitgliedschaftsmodelle definieren Benutzer-zu-Projekt-Beziehungen mit rollenbasierter Berechtigungszuweisung für teamorientierte Zugriffskontrolle. Diese Mitgliedschaftskonzepte unterstützen die Abbildung von Organisationsstrukturen auf Plattform-Sicherheitsmodelle.
[Diagramm: Projekt-Zugriffsrechte-Architektur mit Rollen, Berechtigungen und Netzwerk-Policies]
OpenShift-Projekte bieten mehrere Sicherheitsebenen:
Namespace-Isolation: Jedes Projekt ist ein separater Namespace mit eigenen Ressourcen und Netzwerksegmentierung.
RBAC-Integration: Projektspezifische Rollen und Berechtigungen steuern, wer was innerhalb des Projekts tun kann.
Ressourcenquoten: Begrenzen CPU, Memory und Storage-Verbrauch pro Projekt.
Netzwerk-Policies: Kontrollieren die Kommunikation zwischen Projekten und externen Services.
Security Context Constraints: Definieren Sicherheitsrichtlinien für Container-Ausführung.
OpenShift definiert standardmäßig drei Hauptrollen auf Projektebene, die unterschiedliche Verantwortungsbereiche und Berechtigungsstufen abdecken.
| Rolle | Berechtigungen | Zielgruppe | Anwendungsfälle |
|---|---|---|---|
| admin | Vollständige Projekt-Administration | Projekt-Manager, Team-Leads | Benutzer verwalten, Quotas einsehen, alle Ressourcen steuern |
| edit | Ressourcen erstellen/ändern | Entwickler, DevOps-Engineers | Apps deployen, Services konfigurieren, Builds starten |
| view | Nur-Lese-Zugriff | Stakeholder, Support-Teams | Monitoring, Debugging, Status-Überprüfung |
Die Projekt-Admin-Rolle gewährt vollständige administrative Kontrolle innerhalb der Projektgrenzen, einschließlich Benutzerverwaltung und Ressourcenkonfiguration. Diese administrative Rolle ermöglicht umfassende Projekt-Governance ohne Cluster-Level-Zugriff.
Admin-Berechtigungen umfassen:
# Benutzer zu Projekt hinzufügen
oc policy add-role-to-user edit developer@company.com -n my-project
# Projekt-Quotas anzeigen (aber nicht ändern)
oc describe quota -n my-project
# Alle Ressourcen im Projekt verwalten
oc get all -n my-projectDie Projekt-Editor-Rolle ermöglicht Ressourcenerstellung, -änderung und -löschung innerhalb von Projekten ohne administrative Privilegien. Diese Entwicklerrolle unterstützt Anwendungsentwicklungs-Workflows ohne Sicherheitsrisiko.
Editor-Berechtigungen: - Pods, Services, Routes erstellen und verwalten - ConfigMaps und Secrets bearbeiten - Builds und Deployments starten - Logs anzeigen und Container debuggen - Keine Benutzer-Verwaltung oder RBAC-Änderungen
Die Projekt-Viewer-Rolle bietet Nur-Lese-Zugriff auf Projekt-Ressourcen für Monitoring, Audit und Troubleshooting-Zwecke. Diese Beobachterrolle unterstützt Compliance-Monitoring ohne Änderungsmöglichkeiten.
Custom-Projektrollen ermöglichen organisationsspezifische Rollendefinitionen mit maßgeschneiderten Berechtigungssets für einzigartige Projektanforderungen:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: database-manager
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "create", "update"]
resourceNames: ["db-credentials"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "update", "patch"]OpenShift unterstützt verschiedene Muster für die Zuweisung von Projektberechtigungen an Benutzer und Gruppen.
Direkte Benutzerzuweisung ermöglicht individuelle Benutzerberechtigungsgewährung für spezifische Projektzugriffsanforderungen. Diese direkte Zuweisung bietet granulare Kontrolle für außergewöhnliche Zugriffsfälle.
# Einzelnen Benutzer als Admin hinzufügen
oc policy add-role-to-user admin alice@company.com -n my-project
# Mehrere Rollen gleichzeitig zuweisen
oc policy add-role-to-user edit developer1@company.com -n my-project
oc policy add-role-to-user view developer1@company.com -n shared-monitoringGruppenbasierte Zuweisungen implementieren kollektive Berechtigungsverwaltung durch LDAP-Gruppen oder OpenShift-Gruppen für skalierbare Benutzerverwaltung. Diese Gruppenzuweisungen reduzieren den administrativen Aufwand für große Teams.
# Gruppe zu Projekt hinzufügen
oc policy add-role-to-group edit developers -n my-project
# LDAP-Gruppe verwenden
oc policy add-role-to-group admin "CN=Project Admins,OU=Groups,DC=company,DC=com" -n my-projectService-Account-Projektzugriff gewährt automatisierten Systemen und CI/CD-Pipelines notwendige Projektberechtigungen für DevOps-Workflow-Integration:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cicd-binding
namespace: production
subjects:
- kind: ServiceAccount
name: jenkins
namespace: cicd-tools
roleRef:
kind: Role
name: deployment-manager
apiGroup: rbac.authorization.k8s.ioTemporäre Zugriffe implementieren zeitlich begrenzte Projektberechtigungen für Auftragnehmer-Zugriff oder Notfallreaktionsszenarien. Diese temporären Berechtigungen unterstützen flexibles Zugriffs-Management.
OpenShift ermöglicht granulare Kontrolle über den Zugriff auf spezifische Ressourcentypen und -instanzen innerhalb von Projekten.
Ressourcentyp-Berechtigungen definieren granulare Zugriffskontrolle für verschiedene Kubernetes-Ressourcentypen innerhalb von Projekten:
# Beispiel: Nur Secrets-Verwaltung erlauben
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: my-project
name: secrets-manager
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "create", "update", "delete"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]Ressourceninstanz-Berechtigungen implementieren individuelle Ressourcenzugriffskontrolle für spezifische Anwendungskomponenten oder sensible Ressourcen:
# Zugriff nur auf spezifische Secrets
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "update"]
resourceNames: ["app-database-credentials", "app-api-keys"]Label-basierte Zugriffskontrolle nutzt Ressourcen-Labels für dynamische Berechtigungszuweisung basierend auf Ressourcenmerkmalen:
# Labels für Zugriffskontrolle setzen
oc label secret database-credentials access-level=restricted -n my-project
# Role für label-basierte Berechtigung
oc create role restricted-secrets --verb=get,list \
--resource=secrets --resource-name='*' -n my-projectModerne Anwendungsarchitekturen erfordern oft kontrollierte Kommunikation und Ressourcenfreigabe zwischen verschiedenen Projekten.
Cross-Projekt-Service-Zugriff ermöglicht kontrollierte Service-Kommunikation zwischen Projekten für Mikroservice-Architektur-Unterstützung:
# Network Policy für Cross-Projekt-Zugriff
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-frontend
namespace: backend-services
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend-projectGeteilte Ressourcen implementieren Ressourcenfreigabe-Mechanismen zwischen Projekten für gemeinsame Infrastrukturnutzung:
# Service Account für shared Services erstellen
oc create sa monitoring-collector -n shared-services
# Cross-Projekt-Berechtigung für Monitoring
oc policy add-role-to-user view system:serviceaccount:shared-services:monitoring-collector -n production
oc policy add-role-to-user view system:serviceaccount:shared-services:monitoring-collector -n developmentKollaborative Projektmodelle definieren Multi-Projekt-Workflows für komplexe Anwendungsbereitstellungen über mehrere Projekte:
Pipeline-Projekt-Struktur: - Development-Projekt: Entwicklung und erste Tests - Testing-Projekt: Integrationstest und QA - Staging-Projekt: Pre-Production-Validation - Production-Projekt: Live-Anwendung
OpenShift-Projekte unterstützen granulare Netzwerksicherheitsrichtlinien für erweiterte Isolation und kontrollierte Kommunikation.
Projekt-Netzwerk-Isolation implementiert Netzwerksegmentierung zwischen Projekten für erweiterte Sicherheitsgrenzen:
# Standard-Isolation: Alle eingehenden Verbindungen blockieren
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- IngressIngress-Traffic-Kontrolle definiert erlaubte externe Traffic-Muster für Projekt-Ressourcen:
# Nur HTTP/HTTPS-Traffic von Load Balancer erlauben
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-web-traffic
namespace: web-frontend
spec:
podSelector:
matchLabels:
app: web-app
policyTypes:
- Ingress
ingress:
- from: []
ports:
- protocol: TCP
port: 8080
- protocol: TCP
port: 8443Egress-Traffic-Beschränkungen begrenzen ausgehende Netzwerkkommunikation von Projekt-Ressourcen für Daten-Exfiltrations-Prävention:
# Nur DNS und spezifische Services erlauben
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-egress
namespace: secure-app
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to: []
ports:
- protocol: UDP
port: 53 # DNS
- to:
- namespaceSelector:
matchLabels:
name: database-servicesProjektzugriffsrechte umfassen auch die Kontrolle über Ressourcenverbrauch und -limits innerhalb von Projekten.
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: development
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
persistentvolumeclaims: "5"Storage-Quotas beschränken Persistent-Storage-Verbrauch für Kostenkontrolle und Ressourcenmanagement:
apiVersion: v1
kind: ResourceQuota
metadata:
name: storage-quota
namespace: production
spec:
hard:
requests.storage: 100Gi
gold.storageclass.storage.k8s.io/requests.storage: 50Gi
standard.storageclass.storage.k8s.io/requests.storage: 50GiObjekt-Anzahl-Quotas begrenzen Kubernetes-Objekterstellung für API-Server-Schutz:
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-quota
namespace: development
spec:
hard:
count/pods: "10"
count/services: "5"
count/routes.route.openshift.io: "3"
count/secrets: "20"Projektzugriffsrechte integrieren verschiedene Sicherheitsrichtlinien für umfassenden Schutz auf Projektebene.
Security Context Constraints auf Projektebene definieren Container-Sicherheitsrichtlinien für projektspezifische Sicherheitsanforderungen:
# Custom SCC für Projekt erstellen
oc create -f - <<EOF
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: restricted-project-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowPrivilegedContainer: false
runAsUser:
type: MustRunAsNonRoot
seLinuxContext:
type: MustRunAs
EOF
# SCC an Service Account binden
oc adm policy add-scc-to-user restricted-project-scc \
system:serviceaccount:my-project:defaultImage-Sicherheitsrichtlinien definieren erlaubte Container-Images und Registry-Zugriff für Projektbereitstellungen:
apiVersion: config.openshift.io/v1
kind: Image
metadata:
name: cluster
spec:
allowedRegistriesForImport:
- domainName: registry.company.com
- domainName: quay.io
insecure: falseProjektzugriffsrechte umfassen umfassende Monitoring- und Audit-Funktionen für Sicherheitsüberwachung und Compliance.
# Projekt-spezifische Events anzeigen
oc get events --sort-by='.lastTimestamp' -n my-project
# Benutzeraktivitäten in Audit-Logs
oc adm node-logs --role=master --path=audit/audit.log | \
grep "my-project" | grep "user.*alice"Zugriffsmuster-Analyse identifiziert ungewöhnliche Zugriffsmuster für Sicherheits-Anomalie-Erkennung:
Wichtige Metriken für Monitoring: - Fehlgeschlagene Autorisierungsversuche pro Benutzer - Ungewöhnliche API-Zugriffsmuster - Ressourcenerstellung außerhalb der Geschäftszeiten - Cross-Projekt-Zugriffe von unerwarteten Sources
Automatisierte Compliance-Berichte für Projektzugriff:
# Alle Benutzer mit Admin-Rechten auflisten
oc get rolebinding -o wide -n my-project | grep admin
# Service Account Berechtigungen überprüfen
oc describe rolebinding,clusterrolebinding --all-namespaces | \
grep -A 5 -B 5 "system:serviceaccount:my-project"| Problem | Symptom | Ursache | Lösung |
|---|---|---|---|
| “Forbidden” beim Projekt-Zugriff | HTTP 403 Error | Keine Projekt-Berechtigung | RoleBinding für Benutzer erstellen |
| Ressourcen nicht sichtbar | Leere Liste bei oc get |
View-Berechtigung fehlt | View-Rolle zuweisen |
| Cross-Projekt-Zugriff verweigert | Service nicht erreichbar | Network Policy blockiert | Network Policy anpassen |
| Service Account kann nicht deployen | Pod-Creation fehlschlägt | SCC-Berechtigung fehlt | Service Account zu SCC hinzufügen |
# Effektive Berechtigungen eines Benutzers prüfen
oc auth can-i --list --as=alice@company.com -n my-project
# Spezifische Berechtigung testen
oc auth can-i create pods --as=alice@company.com -n my-project
# RoleBindings für Projekt anzeigen
oc describe rolebinding -n my-project
# Network Policies prüfen
oc get networkpolicy -n my-project -o yamlAutomatisierte Zugriffs-Bereinigung implementiert periodische Zugriffs-Reviews und Entfernung ungenutzter Berechtigungen:
#!/bin/bash
# Skript für regelmäßige Berechtigung-Reviews
# Finde Benutzer ohne Login in letzten 90 Tagen
for project in $(oc get projects -o name | cut -d/ -f2); do
echo "Reviewing project: $project"
oc get rolebinding -n $project -o custom-columns=NAME:.metadata.name,USERS:.subjects[*].name --no-headers | \
while read binding users; do
echo " Binding: $binding, Users: $users"
# Hier würde Logik für Last-Login-Check folgen
done
donePrinzip der minimalen Berechtigungen: Gewähren Sie nur die minimal notwendigen Berechtigungen für die jeweilige Aufgabe. Beginnen Sie mit der View-Rolle und erweitern Sie bei Bedarf.
Gruppenbasierte Verwaltung: Verwenden Sie LDAP- oder OpenShift-Gruppen für Rollenzuweisungen anstelle direkter Benutzerzuweisungen. Dies vereinfacht die Verwaltung und erhöht die Konsistenz.
Regelmäßige Access-Reviews: Führen Sie vierteljährliche Reviews aller Projektzugriffsrechte durch, um ungenutzte oder übermäßige Berechtigungen zu identifizieren.
Network Policy Standards: Implementieren Sie standardmäßig restriktive Network Policies und öffnen Sie nur explizit benötigte Kommunikationswege.
Service Account Hygiene: Erstellen Sie spezifische Service Accounts für verschiedene Anwendungen und Automatisierungen anstelle der Verwendung des default Service Account.
Dokumentation und Monitoring: Dokumentieren Sie alle Custom Roles und überwachen Sie deren Nutzung für kontinuierliche Optimierung der Sicherheitsrichtlinien.