Kubernetes security for regulated SaaS in Germany: controls that survive audit

Why regulated SaaS on Kubernetes is a control-design problem

Managed Kubernetes removes a large slice of control-plane toil, but it does not remove your responsibility for workload configuration, data flows and access paths. For regulated SaaS, auditors and customer security teams ask the same questions whether you run on EKS, AKS or GKE: who can change production, how are tenants or environments separated, where do logs land, and how do you prove a preventive control blocked a bad deployment.

Framework mappings (SOC 2 trust criteria, ISO 27001 Annex A themes, DORA's ICT risk management expectations in Articles 5-16) do not mandate a vendor product category. They expect risk-based controls, documented rationale and samples of operating evidence. Kubernetes is a valid place to implement those controls - if RBAC, network policy, secrets handling and admission are treated as part of the compliance scope, not as 'platform internals'.

Identity and RBAC: least privilege that survives churn

Cluster-admin for application teams is the fastest way to fail a review. The pattern that holds up ties human access to your central identity provider (SSO with MFA), uses short-lived credentials for automation, and separates roles for deploy, read-only support and break-glass.

• ✓Namespace-scoped roles for application teams; cluster-wide change reserved to platform engineering with ticketed approval.
• ✓No long-lived kubeconfig files in CI secrets where OIDC or cloud-native federation is available.
• ✓Regular access reviews that sample both cloud IAM bindings and Kubernetes RBAC - they diverge quickly without inventory.
• ✓Audit logs from the API server and cloud control plane retained in the same archive as application logs.

Network policies and segmentation

Default-allow pod networking is convenient during development and expensive during incident response. For multi-tenant or multi-environment SaaS, network policies (or service mesh policies where you already operate a mesh) should enforce a documented matrix: which namespaces may reach databases, egress to the internet, and internal admin tools.

On EKS, AKS and GKE, policies must align with cloud networking reality - security groups, private link, firewall rules and cluster CNI behaviour. A network policy that looks correct in YAML but is bypassed by a load balancer misconfiguration is a common audit finding. Diagram the allowed paths once; generate policies from that diagram rather than accumulating one-off rules per ticket.

Secrets, images and admission

Secrets in plain manifests or unrotated bootstrap tokens show up in almost every first external assessment. Prefer external secret stores integrated with the cluster (cloud secret managers with CSI drivers, sealed secrets with a defined rotation owner, or equivalent patterns your risk assessment accepts).

Admission control is where preventive guardrails meet compliance narrative: block privileged pods, enforce resource limits, require standard labels for cost and data classification, and reject images that are not from your approved registry or that fail signature verification where you have adopted it. Policy engines (OPA Gatekeeper, Kyverno, or cloud-native policy add-ons) should reference your control matrix so an auditor sees one story from policy PDF to enforced rejection in the API server audit log.

Evidence for SOC 2, ISO 27001 and DORA-minded buyers

Detection without retention is not evidence. For Type II SOC 2 and ISO surveillance audits, samples span weeks or months: API audit entries showing who changed a RoleBinding, tickets approving a network policy exception, vulnerability scan results for running images, and backup or restore tests for stateful workloads.

DORA does not rewrite Kubernetes best practice, but financial-sector customers often map your hosting to their ICT risk management and incident obligations (Articles 5-16 and the incident management chapter from Article 17 onwards). Your job as a SaaS provider is to make technical artefacts exportable: configuration baselines, log queries, change records and test results - without claiming to interpret DORA on their behalf.

What Stratoworks does

We design and implement landing zones, cluster baselines, guardrails and evidence paths in Terraform and in your runbooks - on EKS, AKS or GKE. If you already run a CNAPP or Kubernetes security scanner, we align preventive controls and logging so tool findings and audit samples point at the same objects.

We do not sell or operate a Kubernetes security product. Boutique here means hands-on engineering for German and EU regulated SaaS teams: proportionate controls, reproducible configuration, and an evidence store your customers and auditors can actually sample.

FAQ