Access Control¶

Die ayedo Software Delivery Plattform implementiert umfassende Zugriffssteuerungsmechanismen, um sicherzustellen, dass nur autorisierte Benutzer auf Ressourcen zugreifen können. Dieses Dokument beschreibt die verschiedenen Access-Control-Mechanismen und deren Konfiguration.

Überblick¶

Die Plattform nutzt OIDC (OpenID Connect) für zentrale Authentifizierung und Autorisierung über Keycloak als zentralen Identity Provider. Folgende Komponenten unterstützen OIDC-basierte Zugriffssteuerung:

• Keycloak: Zentraler Identity Provider mit Realm- und Federation-Support
• Kubernetes: RBAC mit OIDC-Integration via Keycloak
• GitLab: Project-based Access Control mit OIDC
• ArgoCD: Application-Deployment-Zugriff mit OIDC und RBAC
• HashiCorp Vault: Secrets-Management-Zugriff mit OIDC
• Harbor: Container-Registry-Zugriff mit OIDC
• Grafana: Dashboard-Access mit OIDC

Keycloak Access Control¶

Keycloak Zugriffslevel¶

Keycloak selbst hat verschiedene Zugriffslevel für die Administration:

Empfohlene Zugriffsstrategie:

• Platform Administratoren: Master Realm Admin-Zugriff
• Realm Administratoren: realm-admin für spezifischen Realm (z.B. production)
• Application Owners: manage-clients für spezifischen Realm
• Security Officers: view-users für Compliance-Audits

Keycloak Realms¶

Die ayedo SDP unterstützt Multi-Realm-Setup:

# Beispiel-Realm-Struktur
master              # Master Realm (Platform-Administration)
  ├── production    # Production Realm (Production Workloads)
  ├── staging       # Staging Realm (Staging Workloads)
  └── development   # Development Realm (Dev Workloads)

Vorteile:

• Isolation: Getrennte Benutzer, Gruppen und Clients pro Umgebung
• Compliance: Produktions-Zugriffe getrennt von Test-Umgebungen
• Flexibilität: Unterschiedliche Identity-Provider-Konfigurationen pro Realm

Keycloak Federation (Identity Brokering)¶

Keycloak unterstützt Federation mit Upstream-Identity-Providern:

Unterstützte Provider:

• Azure Entra ID (Azure AD) - OIDC/SAML
• Google Workspace - OIDC
• GitHub - OIDC
• GitLab - OIDC
• Generic OIDC/SAML - Beliebige OIDC/SAML-Provider

Beispiel-Konfiguration für Azure Entra ID:

1. Identity Provider in Keycloak erstellen:
2. Navigieren zu: Identity Providers → Add provider → OpenID Connect v1.0
3. Alias: azure-ad
4. Authorization URL: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
5. Token URL: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
6. Client ID: Azure App Registration Client ID

7. Client Secret: Azure App Registration Client Secret

8. Mapper für Group Claims konfigurieren:

9. Mappers → Create
10. Name: azure-groups
11. Mapper Type: Claim to Group Membership
12. Claims: groups

Vorteile der Federation:

• Keine Benutzerverwaltung in Keycloak notwendig
• Single Source of Truth (Azure AD, Google Workspace, etc.)
• Bestehende Gruppen und Berechtigungen wiederverwendbar
• Zentrales User Lifecycle Management

Keycloak Client-Konfiguration¶

Für jede Anwendung wird ein OIDC-Client in Keycloak erstellt:

# Beispiel: Kubernetes OIDC-Client
Client ID: kubernetes
Client Protocol: openid-connect
Access Type: confidential
Valid Redirect URIs:
  - http://localhost:8000
  - http://localhost:18000
Standard Flow Enabled: true
Direct Access Grants Enabled: false
Service Accounts Enabled: false

# Client Scopes
Default Client Scopes:
  - email
  - profile
  - groups

Wichtige Settings:

• Valid Redirect URIs: Muss http://localhost:* für kubelogin enthalten
• groups Scope: Muss als Default Scope aktiviert sein
• Audience Mapper: aud Claim muss Client ID enthalten

Group Claims¶

Group Claims ermöglichen die Zuweisung von Berechtigungen basierend auf Gruppenmitgliedschaften im Identity Provider (Keycloak oder Upstream-Provider wie Azure AD).

Kubernetes¶

Um kubelogin mit Group Claims zu verwenden, muss die kubeconfig wie folgt konfiguriert werden:

users:
  - name: user@ayedo-cluster
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        args:
          - oidc-login
          - get-token
          - --oidc-issuer-url=https://keycloak.example.com/realms/production
          - --oidc-client-id=kubernetes
          - --oidc-client-secret=<client-secret>
          - --oidc-extra-scope=email,groups # groups-Scope aktivieren
        command: kubectl

# Token anzeigen
cat ~/.kube/cache/oidc-login/<token-file> | jq -r .id_token

# Token bei jwt.io dekodieren
# Payload sollte "groups": ["group1", "group2"] enthalten

Harbor¶

Harbor unterstützt Group Claims für Project-Zugriff und Admin-Rechte.

Konfiguration:

harbor:
  oidc:
    groupClaimName: groups
    adminGroup: harbor-admins

Grafana¶

OPS Grafana (Platform Monitoring)¶

grafana:
  ops:
    oidc:
      enabled: true
      userGroups:
        grafanaAdmin: platform-admins
        grafanaEditor: platform-engineers
        grafanaViewer: developers
      scopes: "openid email groups"
      allowedDomains:
        - example.com

User Grafana (Application Monitoring)¶

grafana:
  user:
    oidc:
      enabled: true
      userGroups:
        grafanaAdmin: app-admins
        grafanaEditor: developers
        grafanaViewer: stakeholders
      scopes: "openid email groups"
      allowedDomains:
        - example.com

User Onboarding¶

Dieser Abschnitt beschreibt, wie neue Benutzer für Grafana und Harbor berechtigt werden.

Grafana¶

Vorgehensweise:

1. Application Developer meldet sich via OIDC in Grafana an
2. Administrator meldet sich mit statischem Admin-User an
3. Administrator befördert den OIDC-User zu Grafana Admin

kubectl get secret user-grafana-env -n monitoring -o json | \
  jq '.data | map_values(@base64d)'

Admin-Promotion:

Unter https://grafana.example.com/admin/users kann der Administrator OIDC-Benutzern Admin-Rechte zuweisen.

Harbor¶

Vorgehensweise:

1. Application Developer meldet sich via OIDC in Harbor an
2. Administrator meldet sich mit statischem Admin-User an
3. Administrator befördert den OIDC-User zu Harbor Admin

kubectl get secret harbor-init-secret -n harbor -o json | \
  jq '.data."harbor-password" | @base64d'

Admin-Promotion:

Unter https://harbor.example.com/harbor/users kann der Administrator OIDC-Benutzern Admin-Rechte zuweisen.

GitLab¶

Vorgehensweise:

1. Application Developer meldet sich via OIDC in GitLab an
2. Administrator fügt Benutzer zu entsprechenden GitLab-Groups hinzu
3. Benutzer erhält rollenbasierte Berechtigungen durch Group-Membership

kubectl get secret gitlab-gitlab-initial-root-password -n gitlab -o json | \
  jq '.data.password | @base64d'

Group-Membership:

Unter https://gitlab.example.com/admin/groups kann der Administrator Benutzer zu Groups hinzufügen und Rollen zuweisen.

ArgoCD¶

Vorgehensweise:

1. Platform Administrator konfiguriert RBAC-Policies (siehe oben)
2. Application Developer meldet sich via OIDC in ArgoCD an
3. Berechtigungen werden automatisch über Group Claims vergeben

kubectl get secret argocd-initial-admin-secret -n argocd -o json | \
  jq '.data.password | @base64d'

RBAC-Validation:

Unter https://argocd.example.com/settings/accounts können Administratoren Benutzer-Berechtigungen prüfen.

HashiCorp Vault¶

Vorgehensweise:

1. Platform Administrator konfiguriert OIDC Auth Method und Policies (siehe oben)
2. Application Developer meldet sich via OIDC in Vault an (UI oder CLI)
3. Berechtigungen werden automatisch über Group Claims und Policies vergeben

OIDC-Login via CLI:

# Via CLI
vault login -method=oidc role=developer

# Browser öffnet sich für Keycloak-Login
# Nach erfolgreichem Login erhält User ein Vault-Token

OIDC-Login via UI:

Unter https://vault.example.com/ui/vault/auth → Method: OIDC → Sign in with OIDC Provider

GitLab Access Control¶

GitLab Zugriffslevel¶

GitLab unterstützt rollenbasierte Zugriffskontrolle auf Project- und Group-Ebene:

OIDC-Integration¶

GitLab wird über OIDC mit Keycloak integriert:

gitlab:
  oidc:
    enabled: true
    name: "Keycloak"
    issuer: "https://keycloak.example.com/realms/production"
    client_id: "gitlab"
    client_secret: "<client-secret>"
    scope: ["openid", "email", "profile", "groups"]
    discovery: true
    uid_field: "preferred_username"

OIDC-Client-Konfiguration in Keycloak:

Client ID: gitlab
Client Protocol: openid-connect
Access Type: confidential
Valid Redirect URIs:
  - https://gitlab.example.com/users/auth/openid_connect/callback
Standard Flow Enabled: true
Client Scopes:
  - openid
  - email
  - profile
  - groups

Group Sync¶

GitLab kann Gruppen automatisch aus Keycloak synchronisieren:

gitlab:
  oidc:
    group_claim: groups
    external_groups:
      - developers
      - platform-admins
    admin_groups:
      - platform-admins

Zugriffs-Mapping:

• Keycloak-Gruppe platform-admins → GitLab Admin
• Keycloak-Gruppe developers → GitLab Developer (projektspezifisch)

GitLab Runner RBAC¶

GitLab Runner werden typischerweise mit Service-Accounts in Kubernetes registriert:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-runner
  namespace: gitlab
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gitlab-runner
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/exec", "pods/log"]
    verbs: ["get", "list", "create", "delete"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gitlab-runner
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: gitlab-runner
subjects:
  - kind: ServiceAccount
    name: gitlab-runner
    namespace: gitlab

ArgoCD Access Control¶

ArgoCD Zugriffslevel¶

ArgoCD nutzt projektbasierte RBAC-Policies:

OIDC-Integration¶

ArgoCD wird über OIDC mit Keycloak integriert:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  url: https://argocd.example.com
  oidc.config: |
    name: Keycloak
    issuer: https://keycloak.example.com/realms/production
    clientID: argocd
    clientSecret: $oidc.keycloak.clientSecret
    requestedScopes: ["openid", "profile", "email", "groups"]

OIDC-Client-Konfiguration in Keycloak:

Client ID: argocd
Client Protocol: openid-connect
Access Type: confidential
Valid Redirect URIs:
  - https://argocd.example.com/auth/callback
Standard Flow Enabled: true
Client Scopes:
  - openid
  - email
  - profile
  - groups

RBAC-Policies¶

ArgoCD-RBAC wird über Group Claims gesteuert:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:readonly
  policy.csv: |
    # Platform Administratoren haben Admin-Rechte
    g, platform-admins, role:admin

    # Developers haben Developer-Rechte auf ihre Projekte
    g, backend-developers, role:developer

    # Custom Role: Developer kann Applications syncen
    p, role:developer, applications, get, */*, allow
    p, role:developer, applications, sync, */*, allow
    p, role:developer, applications, override, */*, allow
    p, role:developer, applications, update, */*, allow

    # Namespace-basierte Policies
    p, role:backend-developer, applications, *, backend-*/*, allow
    p, role:frontend-developer, applications, *, frontend-*/*, allow

Policy-Syntax:

p, <role>, <resource>, <action>, <object>, <effect>
g, <group>, <role>

Downstream-Cluster hinzufügen¶

Platform Administratoren fügen Downstream-Cluster zu ArgoCD hinzu:

# Cluster hinzufügen
argocd cluster add <cluster-context> \
  --name production-cluster \
  --namespace argocd

# Cluster-RBAC prüfen
argocd cluster list

Downstream-Cluster-RBAC:

ArgoCD erstellt automatisch ein ServiceAccount im Ziel-Cluster:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd-manager
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: argocd-manager-role
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: argocd-manager-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: argocd-manager-role
subjects:
  - kind: ServiceAccount
    name: argocd-manager
    namespace: kube-system

HashiCorp Vault Access Control¶

Vault Zugriffslevel¶

Vault nutzt Policies für granulare Zugriffskontrolle:

OIDC-Integration¶

Vault wird über OIDC mit Keycloak integriert:

# OIDC Auth Method aktivieren
vault auth enable oidc

# OIDC-Konfiguration
vault write auth/oidc/config \
  oidc_discovery_url="https://keycloak.example.com/realms/production" \
  oidc_client_id="vault" \
  oidc_client_secret="<client-secret>" \
  default_role="default"

# OIDC-Role für Platform Admins
vault write auth/oidc/role/platform-admin \
  bound_audiences="vault" \
  allowed_redirect_uris="https://vault.example.com/ui/vault/auth/oidc/oidc/callback" \
  allowed_redirect_uris="http://localhost:8250/oidc/callback" \
  user_claim="email" \
  groups_claim="groups" \
  policies="admin" \
  ttl=8h

# OIDC-Role für Developers
vault write auth/oidc/role/developer \
  bound_audiences="vault" \
  allowed_redirect_uris="https://vault.example.com/ui/vault/auth/oidc/oidc/callback" \
  allowed_redirect_uris="http://localhost:8250/oidc/callback" \
  user_claim="email" \
  groups_claim="groups" \
  policies="developer" \
  ttl=8h

OIDC-Client-Konfiguration in Keycloak:

Client ID: vault
Client Protocol: openid-connect
Access Type: confidential
Valid Redirect URIs:
  - https://vault.example.com/ui/vault/auth/oidc/oidc/callback
  - http://localhost:8250/oidc/callback
Standard Flow Enabled: true
Client Scopes:
  - openid
  - email
  - profile
  - groups

Vault Policies¶

Beispiel-Policies für verschiedene Rollen:

Admin Policy:

# admin-policy.hcl
path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

Developer Policy:

# developer-policy.hcl
# Developers können Secrets in ihren Namespaces verwalten
path "secret/data/production/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

# Developers können Secrets in staging lesen und schreiben
path "secret/data/staging/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

ReadOnly Policy:

# readonly-policy.hcl
path "secret/data/*" {
  capabilities = ["read", "list"]
}

path "secret/metadata/*" {
  capabilities = ["list"]
}

Group-basierte Policies¶

Vault-Policies werden automatisch über Group Claims zugewiesen:

# External Group für Platform Admins erstellen
vault write identity/group \
  name="platform-admins" \
  type="external" \
  policies="admin"

# External Group für Developers erstellen
vault write identity/group \
  name="developers" \
  type="external" \
  policies="developer"

# Group Alias für OIDC-Provider erstellen
vault write identity/group-alias \
  name="platform-admins" \
  mount_accessor=$(vault auth list -format=json | jq -r '."oidc/".accessor') \
  canonical_id=$(vault read -field=id identity/group/name/platform-admins)

vault write identity/group-alias \
  name="developers" \
  mount_accessor=$(vault auth list -format=json | jq -r '."oidc/".accessor') \
  canonical_id=$(vault read -field=id identity/group/name/developers)

Kubernetes Auth Method¶

Für Pod-zu-Vault-Authentifizierung nutzt die SDP Kubernetes Auth:

# Kubernetes Auth aktivieren
vault auth enable kubernetes

# Kubernetes Auth konfigurieren
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  token_reviewer_jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

# Role für Applications erstellen
vault write auth/kubernetes/role/app \
  bound_service_account_names=app \
  bound_service_account_namespaces=production \
  policies=developer \
  ttl=24h

Kubernetes RBAC¶

Die Plattform nutzt Kubernetes RBAC für granulare Zugriffssteuerung auf Cluster-Ressourcen.

Standard-Rollen¶

OIDC-basierte RBAC¶

Kubernetes RBAC kann mit OIDC-Groups verknüpft werden:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: Group
    name: platform-admins
    apiGroup: rbac.authorization.k8s.io

Namespace-basierte RBAC¶

Entwickler erhalten typischerweise Zugriff nur auf ihre Namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developers-edit
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io

Network Policies¶

Network Policies ergänzen die Zugriffssteuerung auf Netzwerkebene.

Beispiel: Namespace-Isolation¶

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-from-other-namespaces
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}

Compliance-Mapping¶

Die beschriebenen Access-Control-Mechanismen erfüllen folgende Compliance-Anforderungen:

Best Practices¶

1. Principle of Least Privilege¶

• Gewähren Sie nur die minimal notwendigen Berechtigungen
• Nutzen Sie Namespace-RBAC statt Cluster-RBAC
• Implementieren Sie zeitlich begrenzte Zugriffsrechte

2. Multi-Factor Authentication (MFA)¶

• Erzwingen Sie MFA auf Identity-Provider-Ebene
• Nutzen Sie Hardware-Token für privilegierte Accounts
• Implementieren Sie Conditional Access Policies

3. Audit Logging¶

• Aktivieren Sie Kubernetes Audit Logging
• Nutzen Sie Audit Logs für Compliance

4. Regular Access Reviews¶

• Führen Sie quartalsweise Access Reviews durch
• Entfernen Sie inaktive Benutzer automatisch
• Dokumentieren Sie Berechtigungsänderungen

5. Break-Glass Access¶

• Implementieren Sie Break-Glass-Prozeduren für Notfälle (siehe Runbooks)
• Nutzen Sie separate Admin-Accounts
• Loggen Sie alle Break-Glass-Zugriffe

Troubleshooting¶

Problem: OIDC-Login funktioniert nicht¶

Symptom: Benutzer können sich nicht via OIDC anmelden.

Lösung:

1. Keycloak-Logs prüfen:

   kubectl logs -n keycloak -l app=keycloak --tail=100
   

2. OIDC-Discovery-Endpoint testen:

   curl -s https://keycloak.example.com/realms/production/.well-known/openid-configuration | jq
   

3. Client-Konfiguration validieren:

   # In Keycloak UI: Realms → production → Clients → <client-id>
   # Prüfen:
   # - Valid Redirect URIs korrekt?
   # - Client Secret korrekt?
   # - Standard Flow Enabled?
   

Problem: Group Claims fehlen im Token¶

Symptom: Benutzer haben keine Gruppenberechtigungen.

Lösung:

1. Prüfen Sie den Token-Inhalt (siehe oben: Token-Debugging)
2. Validieren Sie die Client Scopes in Keycloak
3. Stellen Sie sicher, dass der groups-Scope als Default Client Scope aktiviert ist
4. Prüfen Sie Group Mapper-Konfiguration in Keycloak

Problem: GitLab OIDC-Login schlägt fehl¶

Symptom: GitLab zeigt OIDC-Fehler beim Login.

Lösung:

1. GitLab-Logs prüfen:

   kubectl logs -n gitlab -l app=webservice --tail=100 | grep -i oidc
   

2. Redirect URI validieren:

   # Muss exakt sein: https://gitlab.example.com/users/auth/openid_connect/callback
   

3. Client Secret prüfen:

   kubectl get secret gitlab-oidc-secret -n gitlab -o jsonpath='{.data.provider}' | base64 -d
   

Problem: ArgoCD RBAC-Policies funktionieren nicht¶

Symptom: Benutzer haben nicht die erwarteten Berechtigungen in ArgoCD.

Lösung:

1. RBAC-ConfigMap prüfen:

   kubectl get configmap argocd-rbac-cm -n argocd -o yaml
   

2. Benutzer-Groups im Token prüfen:

   # In ArgoCD UI: User Info → Groups
   

3. Policy-Test durchführen:

   argocd admin settings rbac can \
     <user-email> get applications '*/*'
   

4. ArgoCD-Server-Logs prüfen:

   kubectl logs -n argocd -l app.kubernetes.io/name=argocd-server --tail=100 | grep -i rbac
   

Problem: Vault OIDC-Login schlägt fehl¶

Symptom: Vault zeigt Fehler beim OIDC-Login.

Lösung:

1. Vault-Logs prüfen:

   kubectl logs -n vault -l app.kubernetes.io/name=vault --tail=100
   

2. OIDC-Auth-Method-Konfiguration prüfen:

   vault read auth/oidc/config
   

3. OIDC-Role prüfen:

   vault read auth/oidc/role/developer
   

4. Redirect URI validieren:

   # Beide URIs müssen in Keycloak konfiguriert sein:
   # - https://vault.example.com/ui/vault/auth/oidc/oidc/callback
   # - http://localhost:8250/oidc/callback
   

Problem: Vault Policies werden nicht angewendet¶

Symptom: Benutzer haben nicht die erwarteten Vault-Berechtigungen.

Lösung:

1. Token-Policies prüfen:

   vault token lookup
   

2. Group-Membership prüfen:

   vault list identity/group/name
   vault read identity/group/name/developers
   

3. Group Alias prüfen:

   vault list identity/group-alias/id
   vault read identity/group-alias/id/<alias-id>
   

4. Policy-Inhalt validieren:

   vault policy read developer