Containers

Building PCI DSS-Compliant Architectures on Amazon EKS

As cloud adoption accelerates, organizations operating in regulated environments face unique challenges implementing Kubernetes-based solutions. Financial services institutions (FSIs), healthcare providers, and other entities subject to stringent compliance requirements must navigate the intersection of cloud-native technologies and regulatory obligations. Amazon Elastic Kubernetes Service offers a powerful platform for containerized workloads, but its use in regulated environments requires careful consideration of security, data protection, and compliance controls.

A critical challenge for organizations processing payment card data is implementing secure, compliant Kubernetes infrastructure in Payment Card Industry Data security Standard (PCI DSS) environments. A common question is whether shared tenancy infrastructure can meet PCI DSS requirements, or if dedicated hosts are necessary. This architectural decision affects organizations that process credit card data, leverage Kubernetes for their infrastructure, regardless of their node provisioning solution: Karpenter, Cluster Autoscaler, EKS Auto Mode, or manual node management.

Organizations must balance multiple factors: PCI DSS compliance risks, violations and associated penalties, cost implications of shared vs single-tenancy environments, the importance of payment card data security, and the long-term operational implications of their architectural decisions. Wrong choices can lead to financial penalties, unnecessary infrastructure costs, and complex and costly architectural changes.

In this post, we explore key considerations, best practices, and architectural decisions hosting applications on EKS in shared tenancy environments while maintaining PCI DSS compliance. Please note this information is for reference purposes only and does not constitute legal or compliance advice—customers remain responsible for making their own independent assessment, and AWS products or services are provided ‘as is’ without warranties, representations, or conditions of any kind.

Understanding PCI DSS Compliance and Available AWS Resources

AWS supports PCI DSS compliance on EC2 shared tenancy environments, and numerous customers run PCI DSS compliant workloads using this model. AWS provides several resources for customers deploying PCI workloads on shared infrastructure, particularly in Kubernetes environments. This guidance becomes especially critical as organizations increasingly adopt dynamic node provisioning solutions while maintaining compliance and limiting scope.

Node Provisioning Considerations for PCI DSS Environments

Before diving into controls, it’s essential to understand the relationship between node provisioning choices and compliance requirements.

Node Provisioning Options for EKS

Amazon EKS supports multiple approaches to node provisioning:

  • Karpenter: Flexible, high-performance autoscaler provisioning right-sized compute resources in response to application load
  • Cluster Autoscaler: Traditional Kubernetes autoscaling solution that works with AWS Auto Scaling Groups
  • EKS Auto Mode: AWS-managed compute that automatically provisions and manages nodes with minimal configuration
  • Manual Node Management: Direct EC2 instance management without autoscaling

Your node provisioning choice affects node lifecycle management, scaling policies, instance selection, and operational complexity. However, it does not affect the fundamental PCI DSS compliance requirements around Pod security standards, Network policies, RBAC, Access Controls, Encryption, Logging, monitoring or Vulnerability management. Compliance depends on how you architect your EKS cluster and implement security controls at the workload and cluster level, not on which tool provisions your nodes.

Shared Tenancy vs. Dedicated Hosts

Single-tenant nodes via Dedicated Hosts provide an additional layer of physical isolation desired by some regulatory frameworks, but this level of separation is not required by PCI DSS. A well-designed shared tenancy environment with appropriate security controls can meet PCI DSS requirements while maintaining operational efficiency and cost-effectiveness.

The remainder of this post focuses on implementing the appropriate security controls that support PCI DSS compliance regardless of your infrastructure choices.

Recommended Best Practices for PCI DSS on EKS

1. Kubernetes Namespace Isolation

Kubernetes namespaces logically separate workloads within an EKS cluster. By default, all pods across all namespaces can communicate freely. Proper namespace isolation supports segmentation of Cardholder Data Environments (CDE) from non-CDE workloads by restricting pod-to-pod communication.

A. Namespace Design

  • Use dedicated namespaces per application or tenant
  • Restrict cross-namespace access — prohibit shared service accounts or volumes across namespace boundaries

B. Authentication and Authorization

  • Define Kubernetes roles aligned to specific job functions; bind via RoleBindings
  • Prefer namespace-scoped roles and role bindings over ClusterRoles/ClusterRoleBindings to minimize blast radius
  • Use audit2rbac to generate RBAC policy files from Kubernetes audit logs
  • Regularly audit RBAC policies to enforce least privilege.
  • Associate Kubernetes RBAC with AWS IAM using access entries and AWS IAM Authenticator

C. Policy Enforcement

  • Enforce policies using Gatekeeper, Kyverno, or Kubewarden
  • Configure AWS Organizations SCPs as additional permission boundaries where required
  • Implement comprehensive logging and monitoring for RBAC-related events

Strong RBAC configurations supports PCI DSS Requirement 1.3.2 by restricting pod traffic. Kubernetes namespaces also act as a network security control with regards to Requirement 1.4.1, 1.4.2, and 1.4.4 by placing guardrails on the traffic authorized to and through pods in a cluster. This also supports Requirement 7.2.5 by enforcing least privileges and access for systems, applications, or processes within a cluster. Applying CPU and memory limits per namespace prevents resource exhaustion and ensure payment processing workloads have guaranteed capacity, supporting PCI DSS Requirement 2.2.1. Resource limits prevent denial-of-service attacks from compromised container and ensure critical payment processing workloads have guaranteed resources available. The separation between requests (guaranteed resources) and limits (maximum allowed resources) enables efficient resource utilization while maintaining performance isolation.

2. Pod Security Controls

Pod Security Standards (PSS) define three policy levels — Privileged, Baseline, and Restricted enforcing security-related best practices through security. Pod Security Admission (PSA) is the built-in Kubernetes admission controller that enforces PSS policies at the namespace level, supporting PCI DSS Requirement 2.2 (including sub-requirements 2.2.1, 2.2.3, and 2.2.6) for secure configuration hardening standards. Additionally, PSS supports Requirement 11.5.2 for change detection by preventing unauthorized cluster modifications.

A. Pod Security Standards & Admission

PSA operates in three modes per namespace via namespace labels. The enforce mode rejects non-compliant pods at admission and serves as the primary enforcement gate.

  • Enforce restricted levels for PCI CDE workloads, consider baseline levels for non-CDE systems
  • Core security requirements:
    • No privileged containers
    • Non-Root users
    • Read-only root filesystem
    • Drop capabilities unless explicitly required

The Kubernetes API server will reject any pod that doesn’t meet the specified security requirements before it is even scheduled. This provides a critical control point that supports non-compliant workloads cannot enter your PCI environment. The audit mode logs policy violations to the Kubernetes audit logs for compliance reporting, supporting PCI DSS Requirement 10, which mandates logging access attempts. The warn mode provides immediate feedback to developers when attempting to deploy non-compliant configurations, enabling rapid remediation without blocking legitimate operations.

B. SecurityContext Best Practices

As per PCI DSS Requirement 2.2, below are securityContext best practices:

  • runAsNonRoot: true Creates a security boundary limiting the impact of any potential compromise
  • readOnlyRootFilesystem: true Prevents runtime modifications to the container image and blocks attackers from writing malicious files or modifying binaries
  • seccompProfile: RuntimeDefault Applies a security filter to system calls made by container processes. Blocks dangerous system calls that aren’t needed for normal application operation
  •  runAsUser: 10001 Explicitly sets a non-root UID to prevent containers from running as root, even if runAsNonRoot is not enforced by the runtime
  • allowPrivilegeEscalation: false Blocks containers from gaining additional privileges beyond those granted at startup. This prevents exploitation of SUID binaries, kernel vulnerabilities, or container runtime bugs that might otherwise allow an attacker to escalate from a limited container user to root privileges

C. Restrict Host Resources

  • Disable hostPath: Prevents containers from mounting host filesystem directories, blocking access to sensitive host files
  • Disable hostNetwork: Prevents containers from sharing the host’s network namespace, preserving network policy enforcement and CDE segmentation
  • Disable hostPID: Prevents containers from accessing host processes, blocking lateral movement and privilege escalation
  • Disable hostIPC: Prevents containers from accessing host inter-process communication, protecting shared memory from exposure

Disabling these controls maintains strong container-to-host isolation and mitigates container escape vulnerabilities.

D. Monitoring and Auditing using Falco

Falco provides runtime detection of security policy violations by monitoring system behavior catching attacks that bypass static controls. For example, while PSS prevents deploying privileged containers, Falco can detect if a container gain privileged access at runtime through a vulnerability exploit, supporting PCI DSS Requirement 10.4. Falco integrates with Amazon CloudWatch to captures administrative actions (Requirement 10.2.1), and records events details (Requirement 10.2.2) . CloudWatch log access can be restricted to read-only for Requirement 10.3.1 and 10.3.2, and CloudWatch retention and storage policies satisfy Requirement 10.3.3 and 10.3.4.

Amazon GuardDuty complements Falco by providing managed threat detection at the AWS level. GuardDuty EKS Runtime Monitoring deploys a fully managed EKS add-on that monitors container runtime activities — including file access, process execution, and network connections — to detect threats that bypass Kubernetes-layer controls. GuardDuty analyzes both Kubernetes audit logs and runtime events, detecting anomalous behaviors such as unexpected network connections, suspicious process execution, and unauthorized access attempts. This supports continuous monitoring requirements under PCI DSS Requirement 11.5.1 for intrusion detection.

3. Multi-Tenant Scheduling & Node Isolation

Node isolation and workload scheduling controls are fundamental to PCI DSS compliance in EKS environments, regardless of node provisioning approach. The following practices support workload isolation and PCI DSS Requirements 2.2.3 and 2.2.6.

A. Taints and Tolerations

Configure node taints per tenant group to restrict pod scheduling to specifically tainted nodes

B. Label Matching

Implement nodeSelector or affinity rules to limit workload deployment to appropriately labeled nodes.

C. Dedicated Node Groups per Tenant

Create dedicated node groups per tenant using your chosen provisioning method:

  • Karpenter: Use dedicated NodePools per tenant with per-tenant EC2NodeClass
  • Cluster Autoscaler: Configure separate Auto Scaling Groups per tenant
  • EKS Auto Mode: Leverage automated compute management with appropriate taints and labels for tenant isolation. Auto Mode automatically provisions and manages compute resources while respecting your security boundaries through Kubernetes-native controls
  • Manual Management: Create distinct node groups with tenant-specific configurations

D. Inter-pod Anti-affinity Configuration

Implement Hard Constraints (requiredDuringSchedulingIgnoredDuringExecution) to prevent service pods from different tenants from being co-scheduled on the same node.

4. Network Segmentation

Kubernetes network policies restrict network traffic between pods through Ingress and Egress rules, supporting PCI DSS Requirement 2.2 by establishing a secure hardening baseline at the cluster level. Additionally, they support Requirements 1.3.2, 1.4.1, 1.4.2, and 1.4.4 by implementing guardrails for authorized pod traffic. VPCs, AWS Network Firewall, AWS WAF, and Elastic Load Balancers can further enforce network segmentation at the infrastructure level.

Amazon EKS now supports three network policy tiers evaluated in hierarchical order: Admin Tier → Standard NetworkPolicies → Baseline Tier.

A. Default Deny Policy

Apply a default deny-all policy (no ingress or egress) to CDE namespaces before selectively permitting required traffic.

B. Enforce TLS for all communications for encryption in transit

C. Admin Network Policies

Admin Network Policies ( ClusterNetworkPolicy, requires VPC CNI v1.21.1+, Kubernetes 1.29+) enable centralized, cluster-wide traffic control that cannot be overridden by namespace-level policies. For example: use the Admin Tier to enforce organization-wide CDE isolation and the Baseline Tier for default connectivity that developers can override.

D. Application Network Policies

Application Network Policies (EKS Auto Mode only) extend standard policies with DNS-based (FQDN) filtering at Layer 7, eliminating IP/CIDR management for external services — particularly valuable for payment gateway integrations and SaaS services with dynamic IPs.

Additional network security controls include:

  • Pod security groups integration with EC2
  • AWS Network Firewall for CDE perimeter protection
  • VPC Flow Logs for comprehensive monitoring
  • AWS PrivateLink for secure AWS service communication

5. Storage Isolation

Proper storage isolation protects cardholder data and maintains PCI DSS compliance in multi-tenant EKS environments. Encrypted storage with fine-grained access controls ensures sensitive data remains protected at rest and in transit while preventing unauthorized cross-tenant access.

A. Volume Management

It is important to note that EBS volume encryption with KMS alone does not satisfy PCI DSS Requirement 3.5.1.2 for PAN protection. Use the AWS Encryption SDK to encrypt PAN before writing to EBS volumes to support this Requirement.

B. Security Controls

  • Enable encryption in transit for storage drivers (EFS CSI, EBS CSI)
  • Restrict storage access using Roles and RoleBindings at the namespace level, limit service account permissions
  • Avoid hostPath or node-local storage
  • Use security contexts in pod specifications to storage access control
  • Implement encrypted backups

6. Fine grained IAM Isolation

AWS Identity and Access Management (IAM) enables organizations to securely manage and scale access control for both workloads and workforce, serving as the foundation for implementing fine-grained policies and permissions within EKS environments. While customers retain responsibility for meeting PCI DSS Requirement 7, AWS IAM inherently supports Requirement 7.3.3 through its default “deny all” access control system. For comprehensive guidance on using AWS IAM to support Requirements 8 and 9, refer to PCI DSS v4.0 on AWS Compliance Guide.

A. Identity and Role Management

  • Implement IAM Roles for Service Accounts (IRSA) or Amazon EKS Pod Identity
  • Assign dedicated IAM roles per tenant namespace
  • Configure specific IAM roles for Kubernetes service accounts

B. Permission Scoping and Management

  • Define granular IAM policies granting minimum required permissions
  • Avoid wildcard permissions (*) in policy statements
  • Conduct regular audits using AWS IAM Access Analyzer to identify and remove unused permissions
  • Utilize AWS Security Token Service (STS) for temporary credentials

C. Access Control Mechanisms

  • Enable Multi-Factor Authentication (MFA) for IAM users with console access
  • Implement access entries (Cluster identities linked to IAM principals) and policies (Authorization rules for specific cluster actions)

D. Monitoring and Compliance

  • Configure CloudWatch alarms to detect suspicious IAM activity
  • Deploy AWS Config rules for policy violation detection
  • Implement Service Control Policies (SCPs) to enforce organizational compliance guardrails

7. Logging, Monitoring, and Audit Trails

Organizations can leverage multiple AWS services and tools to fulfill PCI DSS Requirement 10 logging mandates. A comprehensive logging and monitoring strategy combines AWS native services with container-specific monitoring tools to create a complete audit trail for compliance assessment and security monitoring.

A. AWS Native Services

  • AWS CloudTrail: Records EKS control plane actions performed and API activity logs for compliance auditing
  • Amazon CloudWatch: Receives EKS Control Plane logs (must be explicitly enabled); Collects cluster metrics via CloudWatch agent ; enables Container Insights for enhanced EKS observability
  • VPC Flow Logs: Captures network traffic metadata for network activity auditing

B. Container-Specific Logging

  • Fluentbit : Run FluentBit as a DaemonSet. Collects cluster-wide container logs and integrates with Container Insights
  • Kubernetes Audit Logs: Records cluster-level activities

C. Security Monitoring

  • AWS GuardDuty threat detection for EKS runtime and audit log events
  • AWS Security Hub for centralized security posture management
  • Amazon Inspector for vulnerability assessment and prioritization
  • Node lifecycle event tracking and container-level metrics collection

This comprehensive logging architecture supports multiple Requirement PCI DSS requirements for activity audit logging, audit log details, and log retention and management.

The integration of Kubernetes audit logs, Gatekeeper violation logs, and Falco alerts creates a robust audit trail that demonstrates continuous compliance monitoring and provides necessary evidence for compliance assessments.

8. Vulnerability Management

PCI DSS Requirement 6.3.1 establishes specific criteria for vulnerability management: implement processes to identify security vulnerabilities, assign risk rankings to vulnerabilities. PCI DSS Requirement 6.3.3 requires that critical security patches/updates be installed within one month, and others installed in a risk-ranked time frame.

A. Container Image Security:

Continuous Vulnerability Scanning (supports Requirement 6.2.3 and 6.2.4): Implement a multi-layered scanning strategy combining native AWS tooling with third-party solutions:

  • Enable Amazon Elastic Container Registry (ECR) image scanning and Amazon Inspector for continuous assessment
  • Integrate third-party scanners (Trivy, Prisma Cloud, Aqua Security, Snyk) into CI/CD pipelines for shift-left detection
  • Configure automated alerting for new CVEs and establish vulnerability remediation workflows

References to third-party tools and services (including but not limited to Falco, HashiCorp Vault, Trivy, Sysdig Secure, Prisma Cloud, Aqua Security, and Snyk) are provided for illustrative purposes only. AWS does not endorse or make any representations regarding third-party tools, and customers should perform their own independent evaluation before adopting any third-party solution.

B. Infrastructure Security:

System Hardening (supports PCI DSS Requirement 2.2): Deploy Bottlerocket OS as the node operating system. Its minimal attack surface, immutable infrastructure model and automated update management reduce the hardening burden while satisfying Requirement 2.2 controls.

C. Infrastructure Vulnerability Management

D. Runtime Security Controls:

For container Runtime Protection, deploy runtime monitoring across multiple layers:

  • Falco and Sysdig Secure for behavioral threat detection
  • GuardDuty Runtime Monitoring for AWS-native threat intelligence
  • SELinux security controls

E. Secrets and Image Provenance

  • HashiCorp Vault for secrets management
  • ImagePolicyWebhook and Kyverno for image provenance enforcement and policy management

F. Security Integration Practices

Treat containers as immutable artifacts—patch images and redeploy rather than modifying live containers. This approach, combined with CI/CD-integrated scanning, ensures vulnerabilities are caught early and the security posture remains consistent across environments.

Conclusion

Amazon EKS supports PCI DSS environments with shared tenancy when strong security controls enforced at both node and workload levels. Your choice of node provisioning—Karpenter, Cluster Autoscaler, EKS Auto Mode, or manual management—does not change the compliance requirements. Each approach can achieve the same security posture when properly configured. Single tenancy via Dedicated Hosts is optional in most cases—not required by PCI DSS itself, though may be mandated by internal policy or warranted due to specific architectural requirements. The critical success factor is defense-in-depth: namespace isolation, Pod Security Standards, network policies, IAM controls, and comprehensive monitoring.

Ready to get started? Contact your AWS account team or visit the AWS Compliance Center to learn more about architecting compliant workloads on AWS.

Do you run PCI workloads on EKS? What controls have helped you achieve compliance? Share your insights in the comments!

About the authors

Piyush Mattoo

Piyush Mattoo is a Solutions Architect at Amazon Web Services, where he specializes in enterprise-scale distributed systems and modern software architecture. He works closely with customers to design and implement cloud-native solutions using containers and AWS services.

Mridul Chopra

Mridul Chopra is a Containers Specialist Technical Account Manager at AWS, where she guides enterprise customers through their container modernization journeys with a focus on Amazon EKS and Kubernetes. She helps organizations design secure, scalable cloud-native solutions focussing on implementing best practices for modern cloud infrastructure.

Ted Tanner

Ted Tanner is a Principal Assurance Consultant and PCI DSS QSA with AWS Security Assurance Services, and has 25 years of IT, security, and compliance experience. He leverages this to provide AWS customers with guidance on compliance and security in the cloud, and how to build and optimize their cloud compliance programs. He is author of two and co-author on 3 whitepapers and guides, and enjoys unblocking customers for migrating to the cloud.