Securing Payment Processing on Azure with No Public Endpoints

A payments company needed to isolate its Azure Kubernetes infrastructure ahead of its PCI-DSS 4.0 assessment.

Payments ยท PCI-DSS 4.0

The challenge

The client's Kubernetes cluster had a public API endpoint protected only by an IP allowlist. As engineering teams grew and worked remotely, keeping the allowlist current became a source of drift and friction.

Application ingress also had several separate TLS termination points, which left internal services more exposed to lateral movement than they needed to be.

Assessment ahead

The work had to be in place before the client's PCI-DSS 4.0 assessment. A publicly reachable administrative endpoint on an in-scope cluster is the kind of exposure an assessor will question.

What we built

We deployed our private AKS with WAF ingress implementation package:

  • A private control plane. The cluster moved to Azure Private Link, with control plane DNS records in an isolated Private DNS zone reachable only through ExpressRoute and internal Bastion hosts.
  • WAF inspection at the edge. Azure Application Gateway WAF v2 with the OWASP Core Rule Set inspects traffic and filters common attacks such as SQL injection before requests reach the cluster.
  • Automated secret and certificate lifecycle. The Azure Key Vault CSI driver with secret rotation, so static credentials are not stored on cluster nodes.
  • A Well-Architected review. The configuration was reviewed against the Security and Reliability pillars, and Availability Zone redundancy and Pod Disruption Budgets were put in place.

Where it landed

The private cluster, WAF ingress, and secret rotation were in place ahead of the client's PCI-DSS 4.0 assessment. The client's team owns the architecture code and runbooks in its own repository.

Find your tier in three questions.

Or book a free 30-minute architecture assessment.