Orchestrator/bahn/aisupport/powers/db-dxp-platform/POWER.md

name, displayName, description, keywords, author

name	displayName	description	keywords	author
db-dxp-platform	DB DXP Platform Guide	Nachschlagewerk zum DB Developer Experience Platform (DXP) Ökosystem: pipeship, CDaaS GitLab Runner, Developer Portal (Tenants, GitOps/Flux, Crossplane), Compliance Suite und DBCS/Kubernetes-Integration. Erklärt, was die Bausteine sind und wie sie zusammenspielen.	dxp developer portal pipeship cdaas compliance suite dbcs backstage crossplane flux gitops tenant	einfachbahn-lab

DB DXP Platform Guide

Overview

Diese Knowledge-Base-Power erklärt das Ökosystem der Developer Experience Platform (DXP) der DB Systel (Teil von build IT). Sie beantwortet Fragen wie „Was ist pipeship/CDaaS?", „Wofür brauche ich einen Tenant?", „Wie hängen Developer Portal, GitOps und Crossplane zusammen?". Für die konkrete Repo-Initialisierung mit pipeship siehe die Power DB pipeship Onboarding.

Die Bausteine

Produkt	Zweck
pipeship	Pipeline-as-a-Service: fertige, DB-konforme GitLab-CI/CD-Pipeline-Module (per include aus Artifactory)
CDaaS	Continuous-Delivery-as-a-Service: gehärtete GitLab Runner (Shared, Base/Multi-Tenant, selfhosted für AWS/k8s/OpenShift)
Developer Portal	Self-Service-Oberfläche (Backstage) für Tenants, Templates, Integrationen, Status, Compliance
Compliance Suite	Scannt Repos auf Secrets, Schwachstellen, Lizenzen; erstellt SBOMs
DBCS	DB Container Services: OpenShift-Cluster + KAS (Kubernetes-as-a-Service)

Gemeinsame Tool-Basis: GitLab, Artifactory, CDaaS, OpenShift (DBCS).

Zentrale URLs

• Developer Portal: https://db.de/dxp · https://dp.dxc.comp.db.de
• pipeship: https://db.de/pipeship
• CDaaS: https://db.de/cdaas
• DBCS: https://db.de/dbcs
• Compliance Findings: https://dp.dxc.comp.db.de/compliance/repositories
• Kubernetes-UI Headlamp: https://headlamp.dxc.comp.db.de
• GitLab: https://git.tech.rz.db.de · Artifactory: https://bahnhub.tech.rz.db.de
• Digitalshop: https://dbdigitalshop.service-now.com/digitalshop

Kernkonzepte

DXP Mandant (Tenant)

Logische Einheit im Developer Portal, die alle Ressourcen einer Anwendung bündelt (nicht teamorientiert). Verwaltet Rollen, Kostenstellen, Integrationen zentral; Repos erben die Konfiguration. Jeder Tenant erhält den K8s-Namespace p-{tenant-name}-tenant mit AGE-Key, Metadata/Environment-Ressourcen, ServiceAccount/RoleBinding und Crossplane-XRs. Bestellung einmalig kostenfrei im Digitalshop (kostenpflichtig nur deployte Ressourcen).

Provisionierung: Crossplane + FluxCD (GitOps)

• Zielzustand liegt als YAML im GitOps-Repo (tenant-information).
• Flux reconciled asynchron (kein direkter Effekt beim Push wie bei Pipelines).
• Crossplane provisioniert die Ressourcen (DBMC-Datenbanken, DBCS-Namespaces, Artifactory).
• Software-Templates (Backstage Scaffolder) scaffolden komplette App-Repos inkl. pipeship-Pipeline, K8s-Namespace, DB und CDaaS-Runner.

flowchart TB
    DP[Developer Portal<br/>Backstage] -->|Tenant + Templates| GR[GitOps-Repo<br/>tenant-information]
    GR -->|Flux reconcile| CP[Crossplane]
    CP --> NS[K8s-Namespace DBCS]
    CP --> DB[(DBMC-Datenbank)]
    CP --> AF[Artifactory-Registries]

Rollen (Least Privilege)

managers (fachlich, entscheiden über Zugriff/Metadata), owners (technisch, Integrationen), developers (i. d. R. Lese-, je Integration Schreibrechte), readers (nur einsehen). Pro Rolle wird automatisch eine ACAT-Gruppe im BKU AD erzeugt. Besteller wird Manager.

CDaaS Runner-Varianten

• Shared Agent: geteilte GitLab Shared Runner (Fair-Use, nur kleine Pipelines), Tag cdaas-shared-agent.
• Base Runner (Beta): zentral, mandantenfähig, Pay-per-Use; Tags z. B. build-base-runner, prod-base-runner. Sicherheit über Cred&Gator (Berechtigung an Pipeline gebunden, nicht an Runner).
• Selfhosted Agents: Helm (k8s/OpenShift) oder CDK-Library (AWS), im eigenen Namespace/Account.

Compliance Suite (Scanner)

• Secrets (Betterleaks), Dependencies (Syft+Grype), DB Compliance (Projekteinstellungen, README/LICENSE/scm-info.yaml), Licenses (Grant).
• Wöchentliche Scans (Di/Do/Sa 18:00), Dependency-Checks alle 12 h. SBOM bei jedem Scan.
• Basisscans kostenlos; Ergebnisse im Developer Portal.

DBCS/Kubernetes-Integration

• Namespaces (OpenShift „Projects") werden als Project-Ressource (kas.dp.db.de/v1alpha1) im GitOps-Repo beschrieben.
• pipeshipSupport: true legt automatisch Secrets an (artifactory-stage/-read/-release, docker-pull-secret, gitlab-user/gitlab-test-user).
• OpenShift unterstützt keine Wildcards in docker-pull-secrets → Registries explizit in customDockerRepos deklarieren.
• Cluster-Inspektion für Advanced User über Headlamp (SSO) oder das Kubernetes-Plugin im Portal.

Häufige Fragen

• „pipeship oder CDaaS?" — pipeship liefert die Pipeline-Logik (Jobs/Module), CDaaS die Runner, auf denen sie läuft. pipeship baut auf CDaaS auf.
• „Brauche ich einen Tenant?" — Für GitOps-Provisionierung (DBMC/DBCS) und pipeship-Onboarding ja. Nur um Compliance-Findings zu sehen: nein.
• „Wo liegt was?" — Grundkonfiguration im Portal-UI; Infrastruktur-YAML im GitOps-Repo; Schnellstart über Software-Templates.

Best Practices

• Updates zeitnah (Empfehlung ≤ 14 Tage), automatisiert via Renovate → bleibt compliant.
• Gruppennamen GitLab = Artifactory-Team-Name, nur Kleinbuchstaben/Zahlen.
• Vor pipeshipSupport: true vorhandene Secrets (pipeship-secrets, age/GPG-Keys) sichern — werden überschrieben.

Weiterführend

Vollständige Wissensbasis im Repo einfachbahn-lab/doku/deployment-doku, Datei docs/08-dxp-plattform.md. Doku-Quellen (DB-Login nötig): git.tech.rz.db.de/pipeship/docs/docs-as-code, .../devex-core/buildit-docu, .../cdaas/documentation.