Kubernetes in Production at Banks: From Proof of Concept to Regulatory Compliance

By mid-2022, most banks had completed Kubernetes proof-of-concept deployments. The question was no longer “can we run Kubernetes?” but “how do we run Kubernetes in production while satisfying regulators?” The gap between POC and production is where most Kubernetes deployments fail — not because of technical limitations, but because of operational and compliance gaps.

We have deployed production Kubernetes clusters at tier-one banks that satisfy regulatory audit requirements. The architecture is fundamentally different from Kubernetes at a SaaS startup. Here is what production Kubernetes looks like in a regulated environment.

Who Is This Guide For?

This guide is for platform engineers, infrastructure architects, and compliance leads at banks deploying Kubernetes in production. If you need to move from POC to production while satisfying regulatory requirements, this is for you.

By the End of This, You’ll Know…

• Why production Kubernetes in banking differs from Kubernetes at tech companies
• How to architect clusters for regulatory compliance and audit readiness
• The security hardening that satisfies bank auditors and regulators
• How to operate Kubernetes clusters that meet uptime SLAs

Why Production Kubernetes Is Different in Banking

Banking Kubernetes has requirements that tech company Kubernetes does not:

• Auditability: Every configuration change must be traceable to an individual and approved through change management
• Segregation: Trading, risk, settlement, and reporting systems operate in separate security domains
• Data residency: Certain data must remain in specific geographic regions
• Incident response: Trading outages cost millions per minute. Recovery must be deterministic, not best-effort

Kubernetes at a SaaS startup is a deployment platform. Kubernetes at a bank is a regulated computing environment that must satisfy the same audit requirements as any other production system.

Cluster Architecture

Multi-Cluster Deployment

Banks typically run multiple Kubernetes clusters:

• Production cluster: Runs customer-facing workloads with strict SLAs
• Pre-production cluster: Runs staging and integration testing workloads
• Development cluster: Runs development and experimentation workloads
• Disaster recovery cluster: Runs standby workloads in a separate region

Cluster Topology

Each cluster follows a standard topology:

• Control plane: Managed by the cloud provider (EKS, GKE) or self-managed across multiple availability zones
• Node pools: Separate node pools for different workload types (CPU, GPU, memory-optimised)
• Namespace isolation: Separate namespaces for each team and workload type
• Network policies: Default-deny all traffic, allow only explicitly permitted communication

Security Hardening

Pod Security Standards

Kubernetes Pod Security Standards define three security levels:

• Privileged: Unrestricted (no security controls). Only for system components.
• Baseline: Minimally restrictive. Prevents known privilege escalations. Most workloads.
• Restricted: Heavily restricted. For security-sensitive workloads (payment processing, risk calculation).

RBAC

Role-Based Access Control (RBAC) defines who can do what in the cluster:

• Cluster-admin: Full cluster access. Limited to 2-3 platform engineers.
• Namespace-admin: Full access within a namespace. Limited to namespace owners.
• Developer: Deploy and manage workloads within a namespace.
• Viewer: Read-only access to namespace resources.

Network Policies

Default-deny all pod-to-pod communication. Allow only explicitly permitted communication:

1
2
3
4
5
6
7
8
9

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Regulatory Compliance

Evidence Collection

Kubernetes provides audit capabilities that satisfy regulatory requirements:

• Audit logs: Every API request is logged with user, timestamp, and action
• Resource annotations: Every resource is annotated with owner, team, and compliance status
• Change history: Every configuration change is recorded in version control

Change Management

Kubernetes changes follow the same change management process as any other production change:

• Pull request: Configuration changes are submitted as pull requests
• Code review: Changes are reviewed by at least one other engineer
• Approval: Changes are approved by the release manager
• Deployment: Changes are deployed through the CI/CD pipeline

Compliance Automation

Use policy-as-code to enforce compliance:

• OPA Gatekeeper: Enforce policies on Kubernetes resources before they are created
• Kyverno: Kubernetes-native policy engine
• Kubewarden: Policy engine using WebAssembly

What You Can Actually Use Today

• EKS: Amazon Elastic Kubernetes Service with managed control plane
• GKE: Google Kubernetes Engine with Autopilot for fully managed clusters
• Rancher: Multi-cluster Kubernetes management
• OPA Gatekeeper: Policy-as-code for Kubernetes

FAQ

How long does it take to deploy production Kubernetes in a bank?

A production-ready cluster takes 3-6 months. This includes security hardening, compliance configuration, and operational tooling. Ongoing operation requires 2-3 dedicated platform engineers.

Can we use managed Kubernetes (EKS, GKE) in banking?

Yes, with caveats. Managed Kubernetes reduces operational overhead but introduces cloud provider dependency. Ensure the managed service meets your compliance requirements (PCI DSS, SOX, GDPR).

How do we handle Kubernetes upgrades in production?

Use a rolling upgrade strategy with canary deployments. Upgrade one node pool at a time, monitoring for errors before proceeding. Test upgrades in pre-production before production.

We help banks deploy production Kubernetes clusters that satisfy regulatory requirements. If you need to move from POC to production, get in touch.