Having recently completed a rather arduous PCI DSS v4.0 certification for a multi-cloud payments platform, I found the ZTNA policy construction to be one of the most nuanced and critical components. Many discussions focus on the high-level principles of Zero Trust, but the devil, as always, is in the explicit policy definitions. The generic "allow this, deny that" is insufficient; for compliance, policies must be contextual, granular, and auditable, mapping directly to control objectives.
Our architecture utilized a hybrid ZTNA approach, with an identity-aware proxy (Pomerium) for user-to-application access and a service mesh (Istio) for service-to-service communication within the cardholder data environment (CDHE). The key was creating a unified policy language that could be expressed across both layers, ensuring that access decisions were consistent whether the request originated from a human or a service account.
Below are anonymized and sanitized policy templates representing our core constructs. They are written in a declarative format inspired by actual implementations but generalized for clarity. Note the heavy reliance on *contextual signals* beyond simple IP or role.
**Template 1: User-to-Application Access (PCI Scope: CDE Admin Portal)**
```yaml
policy_id: pci-cde-admin-access
description: "Granular access to PCI Admin Portal. Requires strict device posture, privileged identity, and time-bound session."
resource_matchers:
- host: admin.cde.internal
path: /v1/*
principal_matchers:
- identity_provider: "okta"
groups: ["cde-platform-admins"]
authentication_strength: "phishing-resistant" # Requires WebAuthn
conditions:
- device_posture:
os: ["macOS", "Windows 11"]
disk_encryption: true
managed: true # Device must be MDM-enrolled
- time_window:
days: ["Mon", "Tue", "Wed", "Thu", "Fri"]
hours: "09:00-17:00 UTC"
- network_context:
# Not IP-based, but uses enterprise location context from IdP
location_context: ["corporate-office", "vpn-gateway"]
actions:
- ALLOW
- enforce:
mfa_interval: 3600
session_lifetime: 28800
audit_logging: FULL
```
*Rationale: This moves far beyond VPN-style network access. It binds access to a specific user group, requires strong phishing-resistant auth, validates device health and management state, restricts time of access, and uses abstract network context (not brittle IP lists). The session is ephemeral and continuously re-evaluated.*
**Template 2: Service-to-Service Communication (PCI Scope: CDE Backend Services)**
```yaml
policy_id: pci-s2s-payment-processing
description: "Service mesh policy for payment processor API. Enforces mTLS, namespace isolation, and purpose-bound credentials."
source:
- workloads:
labels:
app: "transaction-api"
namespace: "pci-ns-01"
service_account: "sa-transaction-api@project.iam.gserviceaccount.com"
destination:
- workloads:
labels:
app: "payment-processor"
namespace: "pci-ns-01"
ports: [8443]
rules:
- when:
- source: # Context from SPIFFE/X.509 certificate and workload metadata
principal: "spiffe://tenant.cloud/pci-ns-01/transaction-api"
request_headers:
x-purpose: "process-card-present"
to_ports:
- number: 8443
methods: ["POST"]
path: "/v1/authorize"
effect: ALLOW
- else: DENY_AND_LOG
```
*Rationale: This is a classic Zero Trust service mesh policy. It authenticates both ends via mTLS with SPIFFE identities, authorizes based on the precise source workload identity, namespace, and even a custom header declaring the request's purpose. It defaults to an explicit deny, logging all unauthorized attempts for audit trails required by PCI DSS.*
**Critical Observations and Trade-offs:**
* **Agent vs. Agentless:** For user access, we used a lightweight agent for continuous device posture assessment. For service mesh, the "agent" is the Envoy sidecar. The management overhead is non-trivial but provides the telemetry and enforcement depth that agentless solutions often lack for high-compliance workloads.
* **Policy Distribution:** These policies are defined as code in Git, with changes peer-reviewed and applied via CI/CD pipelines to both the ZTNA gateway and the service mesh control plane (Istio). This ensures consistency and an immutable audit log.
* **Vendor Neutrality:** While our examples use specific technology semantics, the conceptual framework—contextual signals, default deny, and explicit allow—should be portable across major ZTNA vendors (Zscaler, Cloudflare Access, Netskope) and service meshes.
The primary takeaway is that effective ZTNA for compliance is not a product but a policy architecture. The templates must encode business logic (who, what, when, under what conditions) and technical controls (how strongly proven) in a single declarative statement. This moves security from the network perimeter to the individual transaction, which is the essence of both Zero Trust and modern PCI compliance.
Boring is beautiful
Absolutely. The unified policy language across user and service layers is the only sane way to avoid a compliance catastrophe. Too many teams treat these as separate worlds, then scramble during an audit to prove consistent enforcement.
Where this usually falls apart isn't in the policy definition, but in the policy *distribution* and drift. How are you ensuring these declarative templates are actually the source of truth pushed to both Pomerium and Istio? If someone manually tweaks an Istio AuthorizationPolicy but the "master" template repo isn't updated, you're now non-compliant and won't know until the next pen test.
I'd be morbidly curious to see how you've wired the CI/CD for this. A single lint-and-apply pipeline that manages both, or are you leaning on a GitOps operator? If it's the former, I hope you've got some brutal validation steps that reject any config not originating from the template structure.
Speed up your build