- Authors

- Name
- Phillip Pham
- @ddppham
TL;DR
- TISAX-Zertifizierung (AL3) ist fuer Automobilzulieferer Pflicht -- Kubernetes laesst sich VDA-ISA-konform betreiben
- Praxiserprobte Architektur mit Network Policies, Encryption at Rest, RBAC und lueckenlosem Audit-Logging
- Automobilzulieferer sparen bis zu €1,5 Mio. IT-Kosten durch moderne Container-Infrastruktur
- Das VDA-ISA-Kontrollframework laesst sich direkt auf Kubernetes-Ressourcen wie Pod Security Standards und Namespace-Isolation mappen
Kubernetes für Automotive: TISAX-zertifizierte Container-Infrastruktur 2026
Deutsche Automobilzulieferer stehen vor einer doppelten Herausforderung: OEMs fordern TISAX-Zertifizierung als Voraussetzung für die Zusammenarbeit, gleichzeitig erfordert die Digitalisierung – von Connected Car bis Industrie 4.0 – moderne, skalierbare IT-Infrastrukturen. Kubernetes bietet die Lösung für dieses Spannungsfeld.
TISAX: Der Sicherheitsstandard der Automobilindustrie
Was ist TISAX?
TISAX (Trusted Information Security Assessment Exchange) ist das Prüfverfahren der deutschen Automobilindustrie für Informationssicherheit, basierend auf dem VDA ISA (Information Security Assessment).
Assessment Levels (AL)
| Level | Anforderung | Prüfmethode | Typische Anwendung |
|---|---|---|---|
| AL1 | Normal | Selbstauskunft | Interne Nutzung |
| AL2 | Hoch | Remote-Prüfung | Standard-Zulieferer |
| AL3 | Sehr hoch | Vor-Ort-Prüfung | Prototypen, Entwicklung |
TISAX-Labels
| Label | Beschreibung | Kubernetes-Relevanz |
|---|---|---|
| Info High | Hoher Schutzbedarf | Network Policies, Encryption |
| Info Very High | Sehr hoher Schutzbedarf | Air-Gap, HSM-Integration |
| Proto | Prototypenschutz | Strikte Isolation |
| Con | Vertraulichkeit | RBAC, Audit-Logging |
| Avail | Verfügbarkeit | HA, DR, Multi-Zone |
VDA ISA Anforderungen und Kubernetes-Mapping
Kontrollen und Umsetzung
# VDA ISA Mapping auf Kubernetes
apiVersion: v1
kind: ConfigMap
metadata:
name: vda-isa-mapping
namespace: tisax-compliance
data:
controls.yaml: |
# 1. Informationssicherheits-Policies
information-security-policies:
vda-isa: "1.1, 1.2, 1.3"
kubernetes:
- Pod Security Standards
- Network Policies
- RBAC Policies
evidence:
- policy-definitions.yaml
- namespace-configs/
# 2. Organisation der Informationssicherheit
organization:
vda-isa: "2.1, 2.2"
kubernetes:
- Namespace-Ownership
- RBAC Role Bindings
evidence:
- rbac-matrix.xlsx
- team-responsibilities.md
# 3. Asset Management
asset-management:
vda-isa: "3.1, 3.2, 3.3"
kubernetes:
- Resource Labels
- Container Registry
- ConfigMaps/Secrets
evidence:
- asset-inventory.yaml
- image-catalog.md
# 4. Zugriffssteuerung
access-control:
vda-isa: "4.1, 4.2, 4.3, 4.4"
kubernetes:
- RBAC
- Service Accounts
- OIDC Integration
- MFA
evidence:
- rbac-roles/
- authentication-config.yaml
# 5. Kryptographie
cryptography:
vda-isa: "5.1, 5.2"
kubernetes:
- Secrets Encryption
- mTLS (Service Mesh)
- TLS Certificates
evidence:
- encryption-config.yaml
- certificate-inventory.md
# 6. Physische Sicherheit
physical-security:
vda-isa: "6.1, 6.2"
kubernetes:
- Cloud Provider Datacenter
- Node Security Groups
evidence:
- datacenter-certification.pdf
- cloud-security-config.yaml
Namespace-Struktur für TISAX
# TISAX-konforme Namespace-Hierarchie
apiVersion: v1
kind: Namespace
metadata:
name: oem-project-vw
labels:
tisax-label: "proto"
tisax-al: "3"
data-classification: "strictly-confidential"
oem: "volkswagen"
project-phase: "development"
annotations:
tisax.vda.de/scope-id: "SCOPE-12345"
tisax.vda.de/assessment-date: "2025-11-15"
tisax.vda.de/valid-until: "2028-11-15"
tisax.vda.de/auditor: "TÜV Süd"
---
apiVersion: v1
kind: Namespace
metadata:
name: oem-project-bmw
labels:
tisax-label: "info-high"
tisax-al: "2"
data-classification: "confidential"
oem: "bmw"
---
apiVersion: v1
kind: Namespace
metadata:
name: production-systems
labels:
tisax-label: "avail"
tisax-al: "2"
data-classification: "internal"
Case Study: Tier-1 Zulieferer erreicht TISAX AL3
Ausgangssituation
Ein deutscher Tier-1 Zulieferer für Antriebstechnik:
- Umsatz: €800 Mio.
- Kunden: VW, BMW, Mercedes, Audi
- Problem 1: Jeder OEM fordert TISAX – verschiedene Labels
- Problem 2: Legacy-Infrastruktur nicht zertifizierbar
- Problem 3: Prototypendaten auf unsicheren Fileservern
- Problem 4: 3 Monate bis zur nächsten OEM-Auditierung
Kubernetes-Architektur für TISAX AL3
# TISAX AL3 Cluster-Konfiguration
apiVersion: apps/v1
kind: Deployment
metadata:
name: prototype-cad-viewer
namespace: oem-project-vw
labels:
app: cad-viewer
tisax-scope: "proto"
annotations:
tisax.compliance/data-handling: "prototype-drawings"
tisax.compliance/encryption: "required"
tisax.compliance/access-logging: "enabled"
spec:
replicas: 2
selector:
matchLabels:
app: cad-viewer
template:
metadata:
labels:
app: cad-viewer
tisax-scope: "proto"
spec:
serviceAccountName: cad-viewer-sa
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: cad-viewer
image: cad-viewer:v2.0@sha256:abc123...
imagePullPolicy: Always
ports:
- containerPort: 8443
name: https
env:
- name: WATERMARK_ENABLED
value: "true"
- name: DOWNLOAD_DISABLED
value: "true"
- name: SCREENSHOT_PREVENTION
value: "enabled"
- name: SESSION_TIMEOUT_MINUTES
value: "15"
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
resources:
requests:
cpu: "1"
memory: "2Gi"
limits:
cpu: "2"
memory: "4Gi"
volumeMounts:
- name: cad-data
mountPath: /data
readOnly: true
- name: tmp
mountPath: /tmp
volumes:
- name: cad-data
persistentVolumeClaim:
claimName: prototype-data-encrypted
- name: tmp
emptyDir:
medium: Memory
sizeLimit: 100Mi
RBAC für OEM-Projekte
# Strikte Trennung zwischen OEM-Projekten
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: vw-project-engineer
namespace: oem-project-vw
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch"]
# Kein Zugriff auf Secrets - nur über Vault
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: vw-team-binding
namespace: oem-project-vw
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: vw-project-engineer
subjects:
- kind: Group
name: ad-group-vw-project
apiGroup: rbac.authorization.k8s.io
---
# WICHTIG: Kein Cross-Namespace Zugriff
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: oem-isolation
namespace: oem-project-vw
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector: {} # Nur innerhalb des Namespace
egress:
- to:
- podSelector: {}
# Logging erlaubt
- to:
- namespaceSelector:
matchLabels:
name: logging
ports:
- protocol: TCP
port: 514
Prototypenschutz-Maßnahmen
# DLP (Data Loss Prevention) für Prototypen
apiVersion: v1
kind: ConfigMap
metadata:
name: dlp-config
namespace: oem-project-vw
data:
policy.yaml: |
# TISAX Proto Label Requirements
data-loss-prevention:
enabled: true
# Keine Downloads erlaubt
downloads:
blocked: true
exceptions: []
# Wasserzeichen auf allen Dokumenten
watermarking:
enabled: true
content: "CONFIDENTIAL - ${USER} - ${TIMESTAMP}"
# Clipboard-Überwachung
clipboard:
monitoring: true
blocking: true
# Screenshot-Prävention
screenshot:
prevention: true
detection: true
alert: true
# USB-Blockierung
usb:
blocked: true
logging: true
# Print-Kontrolle
printing:
blocked: true
exceptions:
- role: project-manager
approval-required: true
Ergebnisse
| Metrik | Vorher | Nachher |
|---|---|---|
| TISAX-Zertifizierung | Keine | AL3 (Proto + Con) |
| OEM-Audits bestanden | 0/4 | 4/4 |
| Prototypen-Incidents | 3/Jahr | 0 |
| IT-Kosten | €2,8 Mio./Jahr | €1,3 Mio./Jahr |
| Time-to-Market | 18 Monate | 10 Monate |
Automotive Use Cases für Kubernetes
1. Connected Car Backend
# Vehicle Backend Services
apiVersion: apps/v1
kind: Deployment
metadata:
name: vehicle-connectivity
namespace: connected-car
spec:
replicas: 10
template:
spec:
containers:
- name: mqtt-broker
image: vehicle-mqtt:v3.0@sha256:...
ports:
- containerPort: 8883
name: mqtts
env:
- name: MAX_CONNECTIONS
value: "1000000"
- name: TLS_VERSION
value: "1.3"
- name: CLIENT_AUTH
value: "certificate"
resources:
requests:
cpu: "4"
memory: "8Gi"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: vehicle-connectivity-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: vehicle-connectivity
minReplicas: 10
maxReplicas: 100
metrics:
- type: Pods
pods:
metric:
name: mqtt_connections
target:
type: AverageValue
averageValue: "100000"
2. MES/Produktions-Integration
# Manufacturing Execution System Integration
apiVersion: apps/v1
kind: Deployment
metadata:
name: mes-connector
namespace: production
spec:
replicas: 3
template:
spec:
containers:
- name: mes-adapter
image: mes-connector:v2.5@sha256:...
env:
- name: MES_PROTOCOL
value: "OPC-UA"
- name: PRODUCTION_LINE
value: "LINE-A,LINE-B,LINE-C"
- name: DATA_COLLECTION_INTERVAL_MS
value: "100"
ports:
- containerPort: 4840
name: opcua
volumeMounts:
- name: mes-certs
mountPath: /etc/opcua/certs
readOnly: true
volumes:
- name: mes-certs
secret:
secretName: opcua-certificates
3. Qualitätssicherung mit KI
# Visual Inspection ML Pipeline
apiVersion: apps/v1
kind: Deployment
metadata:
name: visual-inspection
namespace: quality-assurance
spec:
replicas: 5
template:
spec:
containers:
- name: inspection-model
image: visual-inspection:v4.0@sha256:...
resources:
limits:
nvidia.com/gpu: 1
env:
- name: MODEL_PATH
value: "/models/defect-detection-v4"
- name: CONFIDENCE_THRESHOLD
value: "0.95"
- name: INFERENCE_TIMEOUT_MS
value: "100"
volumeMounts:
- name: models
mountPath: /models
readOnly: true
volumes:
- name: models
persistentVolumeClaim:
claimName: ml-models-pvc
4. Supply Chain Visibility
# Lieferketten-Transparenz
apiVersion: apps/v1
kind: Deployment
metadata:
name: supply-chain-tracker
namespace: logistics
spec:
replicas: 3
template:
spec:
containers:
- name: tracker-api
image: supply-chain:v2.0@sha256:...
env:
- name: BLOCKCHAIN_ENABLED
value: "true"
- name: EDI_INTEGRATION
value: "EDIFACT,VDA4905"
- name: REAL_TIME_TRACKING
value: "enabled"
ports:
- containerPort: 8443
TISAX-Audit vorbereiten
Prüfungsschwerpunkte
| VDA ISA Bereich | Kubernetes-Nachweis |
|---|---|
| Policies | Pod Security Standards, Network Policies |
| Zugriffssteuerung | RBAC-Matrix, Service Accounts |
| Kryptographie | Encryption Config, TLS-Zertifikate |
| Logging | Audit-Logs, SIEM-Integration |
| Incident Mgmt | AlertManager-Config, Runbooks |
| BCM | DR-Plan, PDBs, Multi-Zone |
Dokumentation für Auditor
## TISAX Kubernetes Evidence Package
### 1. Sicherheits-Policies
- [ ] Pod Security Standards (Restricted/Baseline)
- [ ] Network Policies pro Namespace
- [ ] RBAC-Dokumentation
### 2. Zugriffskontrolle
- [ ] RBAC-Matrix (Rolle → Berechtigung → Person)
- [ ] Service Account Inventory
- [ ] MFA-Konfiguration (OIDC)
- [ ] Privileged Access Management
### 3. Kryptographie
- [ ] Encryption at Rest Config
- [ ] TLS-Zertifikat-Übersicht
- [ ] Key Management Prozess
- [ ] mTLS Service Mesh Config
### 4. Logging & Monitoring
- [ ] Kubernetes Audit Policy
- [ ] Log-Retention (mind. 1 Jahr)
- [ ] Alerting-Regeln
- [ ] SIEM-Integration
### 5. Prototypenschutz (wenn Proto-Label)
- [ ] DLP-Konfiguration
- [ ] Watermarking
- [ ] Access-Protokollierung
- [ ] Physische Sicherheit Clients
Managed Kubernetes für Automotive
Provider-Anforderungen
| Kriterium | AL2 | AL3 (Proto) |
|---|---|---|
| ISO 27001 | ✓ | ✓ |
| TISAX-zertifiziert | Nice-to-have | ✓ |
| Standort DE | ✓ | ✓ |
| Dedizierte Nodes | Optional | ✓ |
| HSM-Integration | Optional | ✓ |
| Air-Gap Option | Nein | Optional |
| 24/7 Support | ✓ | ✓ |
| Audit-Support | ✓ | ✓ |
OEM-spezifische Anforderungen
Große OEMs haben zusätzliche Anforderungen:
- VW: KGAS (Konzerndatenschutz-Genehmigung)
- BMW: ISMS nach BMW-Standard
- Mercedes: Daimler TSS
- Audi: Audi Partner Security
ROI-Berechnung
Kosten ohne TISAX vs. mit TISAX-Kubernetes
| Szenario | Kosten |
|---|---|
| Auftragsverlust ohne TISAX | €5-50 Mio./Jahr |
| TISAX-Projekt (Legacy) | €500K-2 Mio. |
| TISAX mit Kubernetes | €200K-500K |
| Laufende Compliance (Legacy) | €300K/Jahr |
| Laufende Compliance (K8s) | €100K/Jahr |
Break-Even
- Initial: Kubernetes-Migration amortisiert sich in 6-12 Monaten
- Laufend: 60-70% geringere Compliance-Kosten
Fazit
Kubernetes ermöglicht Automobilzulieferern die TISAX-Zertifizierung bei gleichzeitiger Modernisierung der IT-Infrastruktur. Die Vorteile:
- Compliance: TISAX AL2/AL3 durch Design
- Flexibilität: Schnelle Anpassung an OEM-Anforderungen
- Skalierbarkeit: Von Prototyp bis Serienproduktion
- Kosteneffizienz: 40-60% geringere IT-Kosten
Mit dem richtigen Partner und der richtigen Architektur wird TISAX vom Blocker zum Enabler für digitale Innovation.
Weiterführende Artikel:
- Kubernetes Compliance: DSGVO und BSI in Deutschland
- Kubernetes RBAC für Enterprise-Umgebungen
- Kubernetes Security Hardening: Best Practices für Production
- Kubernetes Identity Management für deutsche Unternehmen
- Kubernetes Kosten: Intern vs. Extern im Vergleich
Sie benötigen TISAX-zertifizierte Kubernetes-Infrastruktur für Ihre Automotive-Projekte? Kontaktieren Sie uns für eine kostenlose Erstberatung.
Kubernetes-Beratung gesucht?
Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
TISAX-Compliance auf Kubernetes ohne eigenes Security-Team
TISAX-Zertifizierung für Automobilzulieferer auf Kubernetes erreichen, ohne ein eigenes Security-Team aufzubauen. VDA-ISA-Kontrollen praktisch umgesetzt mit Managed Kubernetes.
Kubernetes Automotive ASPICE 2026: Container für SDV und Compliance
Entdecken Sie, wie Kubernetes Automotive ASPICE 2026 Standards für die SDV-Entwicklung & Compliance revolutioniert. Effiziente Entwicklung, Tests und sichere Prozesse für OEMs in Deutschland – ein entscheidender Schritt für Kubernetes Compliance Deutschland.
Kubernetes für Automobilzulieferer: Edge, CI/CD und TISAX
Wie Automobilzulieferer Kubernetes für Edge Computing in der Fertigung, CI/CD Pipelines und TISAX/ASPICE-Compliance einsetzen. Mit K3s und ArgoCD Beispielen.
Kubernetes CIS Benchmarks: Hardening-Leitfaden für mehr Sicherheit & Compliance
Entdecken Sie, wie Sie Ihre Kubernetes-Cluster mit CIS Benchmarks härten. Dieser umfassende Leitfaden bietet praktische Schritte für mehr **Kubernetes Compliance in Deutschland**, robuste **Container-Sicherheit** und die Einhaltung deutscher Sicherheitsstandards.
Kubernetes pgvector: PostgreSQL als performanten Vector Store implementieren
Erfahren Sie, wie Sie pgvector nutzen, um PostgreSQL auf Kubernetes als performanten und datenschutzkonformen Vector Store für KI-Anwendungen im deutschen Mittelstand zu etablieren. Profitieren Sie von einer zukunftssicheren hybriden Datenarchitektur, die lokalen Anforderungen gerecht wird.