Disclaimer: This post is for informational and educational purposes only. It does not constitute legal, regulatory, or compliance advice. Payment Card Industry Data Security Standard (PCI DSS) compliance is organization-specific. You’re ultimately responsible for your own compliance posture. Work with a Qualified Security Assessor (QSA) and your legal counsel to assess and validate your obligations. Nothing here represents a guarantee of compliance or an Attestation of Compliance (AoC).
If your IT systems handle payment card data, PCI DSS compliance is not a project you can ever finish. It’s a state you must maintain continuously across every cluster, every team, and every change your environment goes through.
Kubernetes makes continuous compliance operationally… interesting. Configurations drift. Teams share infrastructure. Pods come and go. The controls you establish at deployment need to hold as your fleet grows and your organization changes. Most compliance failures in Kubernetes environments aren’t the result of missing controls at launch. They happen because those controls weren’t enforced consistently afterward.
This post covers how to think about structuring a Payment Card Industry Data Security Standard (PCI DSS)-aware Kubernetes environment using Spectro Cloud Palette, and specifically how Palette’s four core constructs (tenants, projects, cluster profiles, and clusters) can support the isolation, access control, and consistency your compliance program depends on.
The shared responsibility model, stated plainly
No infrastructure management platform can ever remove or take on your compliance obligations.
In its multi-tenant and dedicated software as a service (SaaS) deployment models, Spectro Cloud is responsible for the security and integrity of the Palette management plane: its infrastructure, software supply chain, tenant data isolation, and platform-level controls. Palette holds SOC 2 Type 2 and ISO 27001 certifications (among many others) and its Kubernetes distributions are hardened against Center for Internet Security (CIS) benchmarks.
In a self-hosted deployment, you own and operate the management plane, and that responsibility shifts to your side of the line.
Regardless of deployment model, you are responsible for how you configure and operate the clusters Palette provisions, the workloads you deploy on those clusters, how you manage access, how you handle cardholder data, and how you demonstrate PCI DSS compliance to your QSA.
Palette gives you tooling and guardrails. You define the policies, implement the controls, and own the outcome. The Spectro Cloud Trust Center provides the documentation and certifications your QSA may want to review when assessing the management plane. Note that access requires an invitation and a signed NDA — contact your Spectro Cloud representative to request access.
Tenants: the top-level isolation boundary
A tenant in Palette is the top-level organizational unit. In the multi-tenant SaaS deployment model, where different customers share our management plane, Palette applies a tenant filter to every operation, tenant data is encrypted, and all message communication uses tenant-specific channels. By design, one tenant cannot access another’s resources.
For PCI purposes, the tenant boundary is the strongest management-plane isolation control available. Which deployment model you choose shapes the shared responsibility conversation with your QSA.
Multi-tenant SaaS is our default deployment model, and for many commercial organizations we work with, it’s the starting point.
If your organization has data sovereignty requirements, needs full control over management plane upgrade cycles, or cannot reach public SaaS endpoints, dedicated SaaS may be a better fit. Dedicated SaaS runs the management plane in a cloud region you specify, in Spectro Cloud’s account, with Spectro Cloud still managing the plane but on isolated infrastructure.
If you need the management plane inside your own environment entirely, including air-gapped installations, self-hosted is the option. A self-hosted instance puts more infrastructure responsibility on your side of the line.
Know which model you are using and what it means for your AoC documentation before your QSA conversation happens.
Projects: enforcing environment separation
Within a tenant, projects logically group clusters, profiles, and cloud accounts. Resources created within a project are scoped to that project, and are not visible or accessible from other projects.
PCI DSS requires separation between development, test, and production environments, with access controls enforcing that boundary. Projects give you that separation at the management-plane level. A developer with cluster administrator rights in a development project can be assigned view-only access in pci-production. That assignment is explicit, auditable, and enforced by Palette’s role-based access control (RBAC) model.
A practical structure might use pci-production, pci-staging, and development as separate projects, each with distinct RBAC policies. Tenant-level roles give your security and platform teams cross-project visibility. Project-level roles give application teams access only to what they need.
One clarification your QSA will (or should!) raise: project-level isolation is a logical and access control boundary, not a network boundary. Separate virtual private clouds (VPCs) or subnets need to echo your environment separation at the network level. Project structure supports your access control and documentation story. It does not replace network controls.
Cluster profiles: encoding compliance requirements as configuration
A cluster profile in Palette is a declarative, layered blueprint for a Kubernetes cluster. It defines the full stack: OS, Kubernetes distribution, Container Network Interface (CNI), Container Storage Interface (CSI), and any add-on layers you choose.
For PCI DSS, cluster profiles matter because they provide a way to encode security requirements as version-controlled configuration that is applied consistently to every cluster instantiated from the profile.
Beyond the initial deployment, Palette regularly checks each cluster’s current state against the profile and remediates any configuration drift, which is relevant to the PCI DSS requirement to detect and respond to unauthorized changes to critical system configurations. Whether that behavior satisfies the requirement in your environment is a determination your QSA must make.
A profile built to handle PCI workloads typically has secured multiple layer components. The OS layer uses a CIS-hardened distribution. Palette ships distributions hardened against CIS benchmarks by default. The CNI layer can run Calico or Cilium, both of which support the network policy enforcement that a PCI DSS-scoped environment requires.
For secrets management, consider HashiCorp Vault or AWS Secrets Manager rather than relying on Kubernetes Secrets alone. Kubernetes Secrets are base64-encoded by default, which is not sufficient for PCI DSS. Both HashiCorp and AWS options provide encryption, audit logging, and access control that the standard requires.
Other add-on layers worth considering for a PCI-scoped profile include OPA Gatekeeper or Kyverno for admission control, Falco or Cilium Tetragon for runtime threat detection, and a log forwarder to ship Kubernetes API server audit logs to your Security Information and Event Management (SIEM) platform. All of these are available as verified Palette packs. This is not an exhaustive list, and your QSA should help determine what controls are appropriate for your specific environment.
Profile versioning gives you an audit trail of when security controls changed. When a new Kubernetes patch is available or a new CIS benchmark is published, you update the profile and Palette propagates the change across all clusters using it in parallel. That is relevant to the PCI DSS requirement to protect system components from known vulnerabilities by applying security patches. Your QSA will assess whether your patching process and cadence satisfy that requirement in practice.
One thing to keep in mind: including a Vault add-on in a profile does not mean your application teams are using Vault correctly. Profile-level controls establish a baseline. Workload-level controls, developer guidance, and code review enforce how that baseline is actually used.
Clusters: where scoping decisions have consequences
Individual clusters are the runtime environments where your workloads run. In Palette, clusters are instantiated from cluster profiles and scoped to a project or to the tenant level.
The cluster boundary is a meaningful security boundary in ways that namespace-level separation within a shared cluster is not. Misconfigurations, overprivileged service accounts, and lateral movement risks are all easier to contain when cardholder data environment (CDE) workloads run on dedicated clusters.
Using dedicated clusters for PCI workloads gives you several concrete advantages:
- Network-level isolation is cleaner because cluster nodes run in separate VPCs or subnets, which limits lateral movement if a non-CDE workload is compromised.
- Each cluster has its own control plane and Kubernetes RBAC, so a misconfiguration in a development cluster cannot propagate to production.
- Your QSA can scope and review the PCI production cluster without accounting for every other workload in a shared environment. The goal when working on PCI compliance is to reduce your burden by taking as much out of scope as possible!
- You can also apply security patches to CDE clusters on a schedule appropriate to their sensitivity, independent of other clusters.
A reasonable cluster structure for a PCI environment might look like this: a pci-prod cluster for payment services and cardholder data processing, a pci-staging cluster for pre-production CDE testing, a platform services cluster for centralized logging, monitoring, and secrets management (which may be in scope depending on how it connects to the CDE), and a development cluster that is explicitly out of scope.
Even when you’re using dedicated clusters, any connected systems need careful mapping. For example, centralized logging and monitoring infrastructure that receives data from your CDE cluster may end up being brought into scope. Work with your QSA to document all data flows before you finalize your architecture.
Access control across both planes
We’ve already talked a little about access control, but you’ll need to govern user access on two levels. Palette RBAC and Kubernetes RBAC are separate systems:
- Palette RBAC governs who can access the management plane, create or modify cluster profiles, and provision or delete clusters.
- Kubernetes RBAC governs who can interact with workloads, APIs, and resources within a cluster.
Both need to be configured correctly, and both need to be audited independently. A user with broad Palette tenant-level permissions could, in theory, modify the cluster profile governing your PCI production cluster. A user with broad Kubernetes cluster-admin rights could access cardholder data. These are different risks addressed by different controls. Locking down one does not compensate for the other.
Connect Palette to your identity provider via single sign-on (SSO) so that all management plane access uses corporate identities. PCI DSS requires multifactor authentication (MFA) for all access to the CDE and the systems that manage it, and that requirement extends to Palette management plane access, not just application-level logins.
Configuration drift and the reconciliation loop
PCI DSS requires a change-detection mechanism that alerts personnel to unauthorized modification of critical system files and configurations. In a manually managed fleet, enforcing such a mechanism consistently across clusters takes real effort. For example, emergency changes during an incident may bypass change management processes. Operator access to cloud consoles can produce configuration changes that are invisible to your compliance tooling. Clusters can therefore diverge from their documented baseline without anyone noticing until the next audit.
Palette’s reconciliation against cluster profiles is relevant here. If a cluster’s state deviates from its profile, Palette can alert your team or automatically remediate the drift, depending on policy. That gives you fleet-wide change detection without need for per-cluster monitoring scripts (though your QSA will assess whether that mechanism satisfies the standard’s requirement in the context of your specific environment.)
Note that Palette’s drift detection is not a substitute for Kubernetes API server audit logging. PCI DSS requires audit trails for all access to, and changes in, the CDE. Those logs need to be shipped to a tamper-evident destination outside the cluster. The reconciliation loop handles configuration integrity; audit logging handles accountability.
What Palette does NOT do
Despite all of the security controls and smart architectural decisions it offers, Palette cannot automatically make your clusters or workloads PCI DSS-compliant.
An infrastructure management platform, even one as robust and expansive as Palette, does not replace a QSA, manage the security of your application code, guarantee that your configurations satisfy any specific PCI DSS control, or issue an AoC for your workloads.
Your QSA will assess your full environment. Palette’s role is to give you consistent, auditable, policy-driven infrastructure to support that assessment.
Getting started
If you’re starting to work on a Kubernetes environment that will likely fall under PCI DSS, the best thing to do is define your scope first.
Work with your QSA to map which clusters, services, and systems are in CDE scope before you finalize your architecture. Use consistent labels and metadata in Palette projects and cluster configurations to document that scope in a form your QSA can audit.
Build a PCI-specific cluster profile from day one, and version it to maintain that audit trail. Consider dedicated clusters for CDE workloads rather than relying on namespace separation within a shared cluster. Audit both the Palette management plane and Kubernetes RBAC within your clusters, and document the controls in both places.
To see how Palette structures security controls in practice, book a meeting with one of our experts. Get started here.