A misconfigured Kubernetes cluster running customer-facing workloads at a UK challenger bank does not announce itself. It sits quietly behind an Application Load Balancer, pulling images from a public registry, running privileged containers with cluster-admin service accounts mounted as default. Then a single supply-chain compromise turns it into a lateral movement playground.
The FCA's Operational Resilience rules (PS21/3) require firms to set impact tolerances for important business services and remain within them through severe but plausible scenarios — including cyber. The PRA's SS2/21 reinforces the expectation that third-party and cloud-hosted services are mapped, tested, and recoverable. Kubernetes is now the substrate for a meaningful share of UK financial services workloads on EKS, AKS, and GKE. Yet the misconfigurations our consultants find on engagement are not exotic — they are the same seven, repeatedly.
Here is what we see in production, why it matters under the UK regulatory regime in 2026, and what to fix this quarter.
Why Kubernetes Misconfiguration Is a 2026 Problem, Not a 2022 One
Three forces are converging. First, the Cyber Security and Resilience Bill — introduced to Parliament and progressing through 2026 — will widen the scope of regulated entities and sharpen incident reporting expectations under the NIS Regulations 2018. Cloud and managed service providers are squarely in scope. Second, FCA and PRA supervisory work continues to probe third-party dependency mapping; clusters orchestrating payments, KYC, or fraud workloads are exactly the kind of "important business service" infrastructure that supervisors want evidence on. Third, UK firms with EU subsidiaries or customers are pulled into DORA (Regulation 2022/2554, applicable from 17 January 2025 for EU-based financial entities) — which forces ICT risk management down to the workload level.
Container security Kubernetes posture is no longer a platform team concern. It is a regulatory artefact.
The Seven Misconfigurations We Find Most Often
1. Privileged containers and root filesystems
Containers running as root with privileged: true or writable root filesystems remain depressingly common. A compromised pod becomes a node compromise. Set runAsNonRoot: true, readOnlyRootFilesystem: true, and drop all Linux capabilities by default. Enforce via Pod Security Admission at the restricted level on every namespace except those with documented exceptions.
2. Over-permissioned service accounts
The default service account auto-mounted into every pod, combined with cluster-wide RoleBindings, is the single biggest privilege escalation path. Disable automount (automountServiceAccountToken: false) by default. Use IRSA on EKS, Workload Identity on GKE, and Azure AD Workload Identity on AKS to bind pods to scoped cloud IAM — never long-lived static credentials in secrets.
3. Unscanned and untrusted images
Images pulled from Docker Hub without digest pinning, no SBOM, no signature verification. Container image scanning must happen at three points: in CI (Trivy, Grype, or Snyk), at the registry (ECR, ACR, Artifact Registry native scanning), and at admission (Sigstore Cosign verification via Kyverno or OPA Gatekeeper). Pin by digest, not tag. Reject unsigned images at admission.
4. Flat pod networking
Clusters where any pod can reach any other pod on any port. NetworkPolicies are a Day 1 control, not a Day 90 aspiration. Default-deny ingress and egress per namespace, then explicitly allow. On EKS use the VPC CNI with security groups for pods; on AKS use Azure NPM or Calico; on GKE use dataplane v2 with Cilium.
5. Exposed Kubernetes API and kubelet
Public API endpoints without IP allow-lists, kubelet read-only ports left open, etcd unencrypted at rest. Restrict API server access to corporate CIDRs and private endpoints (EKS private cluster, AKS private cluster, GKE authorised networks). Enable etcd encryption at rest with KMS-backed keys. Audit logs streamed to a SIEM, retained per FCA SYSC 9 expectations.
6. Secrets in plain ConfigMaps or base64 'encryption'
Base64 is not encryption. Use External Secrets Operator with AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Rotate. Audit access. Never commit .env files or Helm values containing secrets to Git — even private repos.
7. No runtime detection
Posture management catches the misconfiguration. It does not catch the cryptominer, the reverse shell, or the suspicious exec into a payments pod. Deploy Falco, Tetragon, or a commercial runtime tool. Pipe alerts into the SOC with playbooks tied to FCA incident reporting thresholds.
EKS, AKS, and GKE Hardening: What Is Different
EKS AKS GKE hardening shares principles but diverges in execution. On EKS, the shared responsibility line sits at the control plane — AWS manages it, you own node configuration, IRSA, and the VPC CNI. Enable EKS audit logs to CloudWatch and use Pod Identity (the 2023 successor to IRSA) for new workloads. On AKS, use Microsoft Defender for Containers, Azure Policy for Kubernetes, and private clusters with API server VNet integration. On GKE, run Autopilot where possible — it enforces many of the seven controls by default — and use Binary Authorization for signature enforcement.
Map every control to a CIS Kubernetes Benchmark item and a control in your ISO/IEC 27001:2022 Annex A statement of applicability. Auditors want the traceability.
Common Mistakes That Survive Pen Tests but Fail Audits
Teams patch the OWASP Top 10 in the application and ignore the orchestrator. They run image scanning in CI but allow :latest tags into production. They write NetworkPolicies for one namespace and leave kube-system wide open. They enable audit logs but never review them. Each of these passes a typical web app pen test and fails a serious cloud configuration review.
How Pyralink Helps
Pyralink Innovation Ltd is a UK cybersec