Access Control

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
• OpenBao: Secrets-Management-Zugriff mit OIDC (Vault-API-kompatibel; Nachfolger von HashiCorp Vault in der SDP)
• 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: - Navigieren zu: Identity Providers → Add provider → OpenID Connect v1.0 - Alias: azure-ad - Authorization URL: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize - Token URL: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token - Client ID: Azure App Registration Client ID - Client Secret: Azure App Registration Client Secret

2. Mapper für Group Claims konfigurieren: - Mappers → Create - Name: azure-groups - Mapper Type: Claim to Group Membership - 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

Beispiel zum Debuggen:

```bash
# 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

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

**Username:** `admin`

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

**Username:** `root`

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

**Username:** `admin`

RBAC-Validation:

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

OpenBao

Vorgehensweise:

1. Platform Administrator konfiguriert OIDC Auth Method und Policies (siehe oben)
2. Application Developer meldet sich via OIDC in OpenBao 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 OpenBao-Token

OIDC-Login via UI:

Unter https://openbao.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

OpenBao Access Control

OpenBao Zugriffslevel

OpenBao nutzt Policies für granulare Zugriffskontrolle:

OIDC-Integration

OpenBao 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://openbao.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://openbao.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://openbao.example.com/ui/vault/auth/oidc/oidc/callback
  - http://localhost:8250/oidc/callback
Standard Flow Enabled: true
Client Scopes:
  - openid
  - email
  - profile
  - groups

OpenBao 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

OpenBao-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-OpenBao-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 Logging & Audit (Portal) 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: OpenBao OIDC-Login schlägt fehl

Symptom: OpenBao zeigt Fehler beim OIDC-Login.

Lösung:

1. OpenBao-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://openbao.example.com/ui/vault/auth/oidc/oidc/callback
   # - http://localhost:8250/oidc/callback
   

Problem: OpenBao Policies werden nicht angewendet

Symptom: Benutzer haben nicht die erwarteten OpenBao-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