How to secure Kubernetes for financial services

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

The Kubernetes threat model for fintech

Kubernetes was designed for developer productivity, not regulatory compliance. Out of the box, pods can communicate freely across namespaces, default service accounts carry more permissions than they should, and secrets are stored as base64-encoded (not encrypted) values in etcd. For a fintech processing real money, this default posture is unacceptable.

The attack surface is layered: the API server, the kubelet, the container runtime, the pod network, and the supply chain (container images). Each layer needs its own controls. During our penetration testing engagements, we routinely demonstrate full cluster compromise starting from a single application-level vulnerability — because the internal Kubernetes controls were never tightened.

RBAC: lock down the API server

Role-Based Access Control determines who (human or service account) can do what within the cluster. The most common RBAC mistake in fintech clusters is granting cluster-admin to CI/CD service accounts or using the default service account in application namespaces without restricting its permissions.

RBAC hardening rules

• Create dedicated service accounts per workload. Never use the default service account. Set automountServiceAccountToken: false unless the pod genuinely needs API server access.
• Use Roles/RoleBindings, not ClusterRoles. Namespace-scoped roles limit blast radius. Only cluster-level operators (cert-manager, ingress controllers) should use ClusterRoles.
• Audit with kubectl auth can-i --list for every service account. If it can create pods, exec into pods, or read secrets in namespaces it does not own, tighten the bindings.
• Integrate with your identity provider (OIDC via Keycloak, Okta, or AWS IAM) for human access. Remove static kubeconfig files from developer laptops.

Network policies: segment the pod network

By default, every pod can reach every other pod in the cluster. This means a compromised user-facing service can directly query your database pods, payment processing pods, or internal admin APIs. Network policies are Kubernetes' built-in firewall — but they only work if your CNI plugin supports them (Calico, Cilium, and Weave do; the default kubenet does not).

Start with a default-deny policy in every namespace, then explicitly allow only the traffic flows your application requires. Your payment service should talk to the payment database and the message queue — nothing else. This mirrors the network segmentation you would implement in a well-designed VPC.

Pod security standards

Kubernetes Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy. They define three profiles — Privileged, Baseline, and Restricted — enforced via the built-in Pod Security Admission controller. Financial workloads should run under the Restricted profile.

Key restrictions for fintech pods

• Run as non-root. Set runAsNonRoot: true and specify a numeric runAsUser.
• Drop all capabilities. Set securityContext.capabilities.drop: ["ALL"] and only add back specific capabilities if genuinely needed.
• Read-only root filesystem. Set readOnlyRootFilesystem: true. Use emptyDir volumes for temporary write needs.
• No privilege escalation. Set allowPrivilegeEscalation: false.
• No hostNetwork, hostPID, or hostIPC. These break pod isolation entirely.

Secrets management: move beyond Kubernetes secrets

Kubernetes secrets are base64-encoded, not encrypted. Anyone with read access to the namespace can decode them. For financial workloads, use an external secrets operator like External Secrets Operator (ESO) to sync secrets from AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault into Kubernetes secrets at runtime. This keeps your secret values out of etcd and your Git repositories entirely.

If you must use native Kubernetes secrets, enable etcd encryption at rest using a KMS provider. But even then, ESO is the stronger approach because it centralises secret rotation, access auditing, and lifecycle management outside the cluster.

Image security and admission control

Every container image is a potential supply chain attack vector. Scan images in your CI pipeline using tools like Trivy, Grype, or Snyk Container. But scanning alone is not enough — you need admission controllers to enforce policies at deploy time.

Use Kyverno or OPA Gatekeeper to enforce rules like: images must come from your private registry, images must have been scanned within the last 24 hours, and images must not run as root. These policies prevent a developer from accidentally deploying an unvetted image or bypassing your CI/CD security controls.

Runtime security with Falco

Static controls prevent known-bad configurations. Runtime security detects unknown-bad behavior — a pod spawning an unexpected shell, reading /etc/shadow, or making outbound connections to unusual IP addresses. Falco monitors kernel system calls in real time and alerts on anomalous activity.

For fintech clusters, configure Falco rules to alert on: any exec into a production pod, any outbound connection to non-allowlisted destinations from payment workloads, any read of sensitive file paths, and any modification to the container filesystem at runtime.

CIS benchmarks: your compliance baseline

The CIS Kubernetes Benchmark provides over 200 specific configuration checks across the API server, etcd, kubelet, and worker nodes. Run kube-bench against your cluster regularly to identify deviations. For managed services like EKS, use the EKS-specific benchmark — some controls are managed by AWS and not applicable.

Map CIS benchmark findings to your regulatory requirements. CBN compliance and ISO 27001 both require evidence of infrastructure hardening — CIS benchmark reports provide exactly that evidence.

Related reading

Blog: Securing AWS for fintech · Microservices security for fintech · Cloud security checklist

Guides: CBN compliance security · ISO 27001 for Nigerian fintech · Fintech security checklist

Services: Secure architecture review · Penetration testing · Vulnerability assessment