Use PCI-DSS v3.2.1 policy constraints

Policy Controller comes with a default library of constraint templates that can be used with the PCI-DSS v3.2.1 bundle to evaluate the compliance of your cluster resources against some aspects of the Payment Card Industry Data Security Standard (PCI-DSS) v3.2.1.

PCI-DSS v3.2.1 policy bundle constraints

Constraint Name Constraint Description Control ID Profile
pci-dss-v3.2.1-resources-have-required-labels Ensures requirements for a firewall by requiring all apps to contain a specified label. 1.1.4 Standard
pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations Ensures requirements for network-controls by requiring all apps to contain a specified annotation. 1.1.5, 2.4 Standard
pci-dss-v3.2.1-require-default-deny-network-policies Requires that every namespace defined in the cluster have a default deny NetworkPolicy for egress. 1.2, 1.3, 2.2.2 Extended
pci-dss-v3.2.1-block-all-ingress Restricts the creation of ingress objects. 1.2, 1.3 Extended
pci-dss-v3.2.1-require-valid-network-ranges Restricts CIDR ranges permitted for use with ingress and egress. 1.2, 1.3.2 Extended
pci-dss-v3.2.1-require-namespace-network-policies Requires that every namespace defined in the cluster has a NetworkPolicy. 1.2 Standard
pci-dss-v3.2.1-enforce-managed-by-configmanagement-label Requires a valid app.kubernetes.io/managed-by= label on RoleBinding resources. 1.2.2, 8.1.2 Standard
pci-dss-v3.2.1-block-creation-with-default-serviceaccount Restricts the creation of resources using a default service account. 2.1 Standard
pci-dss-v3.2.1-restrict-default-namespace Restricts pods from using the default namespace. 2.1 Standard
pci-dss-v3.2.1-asm-peer-authn-strict-mtls Enforce all PeerAuthentications cannot overwrite strict mMTLS. 4.1 Standard
pci-dss-v3.2.1-require-av-daemonset Requires the presence of an Anti-Virus daemonset. 5.1.1, 5.3 Standard
pci-dss-v3.2.1-enforce-config-management Enforce the presence and enablement of Config Sync. 5.3, 6.1, 6.4 Standard
pci-dss-v3.2.1-enforce-cloudarmor-backendconfig Enforce Cloud Armor configuration on BackendConfig resources. 6.5, 6.6 Standard
pci-dss-v3.2.1-restrict-rbac-subjects Restricts the use of names in RBAC subjects to permitted values. 8.1, 8.1.5 Extended
pci-dss-v3.2.1-block-secrets-of-type-basic-auth Restricts the use of basic-auth type secrets. 8.1.5, 8.2.3, 8.5 Standard
pci-dss-v3.2.1-nodes-have-consistent-time Ensures consistent and correct time on Nodes by ensuring the usage of COS as the OS image. 10.4.1, 10.4.3 Standard

Standard vs Extended bundle constraints

The PCI-DSS v3.2.1 bundle implements an opinionated set of policy requirements to achieve some aspects of the PCI-DSS v3.2.1 controls. In addition to modification on your workload to fit the Standard bundle's requirements, an optional set of extended constraints is also available which require customization for your environment.

Before you begin

  1. Install and initialize the Google Cloud CLI, which provides the gcloud and kubectl commands used in these instructions. If you use Cloud Shell, Google Cloud CLI comes pre-installed.
  2. Install Policy Controller v1.14.3 or higher on your cluster with the default library of constraint templates. You must also enable support for referential constraints as this bundle contains referential constraints.

Configure Policy Controller for referential constraints

  1. Save the following YAML manifest to a file as policycontroller-config.yaml. The manifest configures Policy Controller to watch specific kinds of objects.

    apiVersion: config.gatekeeper.sh/v1alpha1
    kind: Config
    metadata:
      name: config
      namespace: "gatekeeper-system"
    spec:
      sync:
        syncOnly:
          - group: "apps"
            version: "v1"
            kind: "DaemonSet"
          - group: "networking.k8s.io"
            version: "v1"
            kind: "NetworkPolicy"
    
  2. Apply the policycontroller-config.yaml manifest:

    kubectl apply -f policycontroller-config.yaml
    

Configure your cluster's workload for PCI-DSS v3.2.1

Standard Bundle

  1. All apps (ReplicaSet, Deployment, StatefulSet, and DaemonSet) must include a pci-dss-firewall-audit label with the schema of pci-dss-[0-9]{4}q[1-4].
  2. All apps (ReplicaSet, Deployment, StatefulSet, DaemonSet) must include a network-controls/date annotation with the schema ofYYYY-MM-DD.
  3. Every namespace defined in the cluster must have a NetworkPolicy.
  4. The use of Config Sync for configmanagement.gke.io is required by default, however the permitted app.kubernetes.io/managed-by values can be customized in the pci-dss-v3.2.1-enforce-managed-by-configmanagement-label constraint.
  5. Resources cannot be created using the default service account.
  6. The default namespace cannot be used for pods.
  7. If using Anthos Service Mesh, ASM PeerAuthentication must use strict mTLS spec.mtls.mode: STRICT.
  8. An antivirus solution is required. The default is the presence of a daemonset named clamav in the pci-dss-av namespace, however the daemonset's name and namespace can be customized to your implementation in the pci-dss-v3.2.1-require-av-daemonset constraint.
  9. The presence and enablement of Config Sync is required.
  10. All BackendConfig must be configured for CloudArmor.
  11. The use of basic-auth type secrets is not permitted.
  12. All nodes must use Google Container-Optimized OS for their image for consistent time.

Extended Bundle (optional with customization required)

  1. Every namespace defined in the cluster have a default deny NetworkPolicy for egress, permitted exceptions can be specific in pci-dss-v3.2.1-require-namespace-network-policies.
  2. Only permitted Ingress objects (Ingress, Gateway, and Service types of NodePort and LoadBalancer) can be created, these can be specified in pci-dss-v3.2.1-block-all-ingress.
  3. Only permitted IP ranges can be used for Ingress and Express, these can be specified in pci-dss-v3.2.1-require-valid-network-ranges.
  4. Only permitted subjects can be used in RBAC bindings, your domain name(s) can be specified in pci-dss-v3.2.1-restrict-rbac-subjects.

Audit PCI-DSS v3.2.1 policy bundle

Policy Controller lets you enforce policies for your Kubernetes cluster. To help test your workloads and their compliance with regard to the PCI-DSS v3.2.1 policies outlined in the preceding table, you can deploy these constraints in "audit" mode to reveal violations and more importantly give yourself a chance to fix them before enforcing on your Kubernetes cluster.

You can apply these policies with spec.enforcementAction set to dryrun using kubectl, kpt, or Config Sync.

kubectl

  1. (Optional) Preview the policy constraints with kubectl:

    kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
    
  2. Apply the policy constraints with kubectl:

    kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
    

    The output is the following:

    asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls created
    k8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount created
    k8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth created
    k8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-cloudarmor-backendconfig created
    k8senforceconfigmanagement.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-config-management created
    k8srequirecosnodeimage.constraints.gatekeeper.sh/pci-dss-v3.2.1-nodes-have-consistent-time created
    k8srequiredaemonsets.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-av-daemonset created
    k8srequirenamespacenetworkpolicies.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-namespace-network-policies created
    k8srequiredannotations.constraints.gatekeeper.sh/pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations created
    k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-managed-by-configmanagement-label created
    k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-resources-have-required-labels created
    k8srestrictnamespaces.constraints.gatekeeper.sh/pci-dss-v3.2.1-restrict-default-namespace created
    
  3. Verify that policy constraints have been installed and check if violations exist across the cluster:

    kubectl get -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
    

    The output is similar to the following:

    NAME                                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls   dryrun               0
    
    NAME                                                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount   dryrun               0
    
    NAME                                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth   dryrun               0
    
    NAME                                                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-cloudarmor-backendconfig   dryrun               0
    
    NAME                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8senforceconfigmanagement.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-config-management   dryrun               0
    
    NAME                                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8srequirecosnodeimage.constraints.gatekeeper.sh/pci-dss-v3.2.1-nodes-have-consistent-time   dryrun               0
    
    NAME                                                                                 ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8srequiredaemonsets.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-av-daemonset   dryrun               0
    
    NAME                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8srequirenamespacenetworkpolicies.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-namespace-network-policies   dryrun               0
    
    NAME                                                                                                        ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8srequiredannotations.constraints.gatekeeper.sh/pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations   dryrun               0
    
    NAME                                                                                                   ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-managed-by-configmanagement-label   dryrun               0
    k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-resources-have-required-labels              dryrun               0
    
    NAME                                                                                        ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
    k8srestrictnamespaces.constraints.gatekeeper.sh/pci-dss-v3.2.1-restrict-default-namespace   dryrun               0
    

kpt

  1. Install and setup kpt. kpt is used in these instructions to customize and deploy Kubernetes resources.

  2. Download the PCI-DSS v3.2.1 policy bundle from GitHub using kpt:

    kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
    
  3. Run the set-enforcement-action kpt function to set the policies' enforcement action to dryrun:

    kpt fn eval pci-dss-v3.2.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \
      -- enforcementAction=dryrun
    
  4. Initialize the working directory with kpt, which creates a resource to track changes:

    cd pci-dss-v3.2.1
    kpt live init
    
  5. Apply the policy constraints with kpt:

    kpt live apply
    
  6. Verify that policy constraints have been installed and check if violations exist across the cluster:

    kpt live status --output table --poll-until current
    

    A status of CURRENT confirms successful installation of the constraints.

Config Sync

  1. Install and setup kpt. kpt is used in these instructions to customize and deploy Kubernetes resources.

Operators using Config Sync to deploy policies to their clusters can use the following instructions:

  1. Change into the sync directory for Config Sync:

    cd SYNC_ROOT_DIR
    

    To create or append .gitignore with resourcegroup.yaml:

    echo resourcegroup.yaml >> .gitignore
    

  2. Create a dedicated policies directory:

    mkdir -p policies
    
  3. Download the PCI-DSS v3.2.1 policy bundle from GitHub using kpt:

    kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1 policies/pci-dss-v3.2.1
    
  4. Run the set-enforcement-action kpt function to set the policies' enforcement action to dryrun:

    kpt fn eval policies/pci-dss-v3.2.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
    
  5. (Optional) Preview the policy constraints to be created:

    kpt live init policies/pci-dss-v3.2.1
    kpt live apply --dry-run policies/pci-dss-v3.2.1
    
  6. If your sync directory for Config Sync uses Kustomize, add policies/pci-dss-v3.2.1 to your root kustomization.yaml. Otherwise remove the policies/pci-dss-v3.2.1/kustomization.yaml file:

    rm SYNC_ROOT_DIR/policies/pci-dss-v3.2.1/kustomization.yaml
    
  7. Push changes to the Config Sync repo:

    git add SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
    git commit -m 'Adding PCI-DSS v3.2.1 policy audit enforcement'
    git push
    
  8. Verify the status of the installation:

    watch gcloud beta container fleet config-management status --project PROJECT_ID
    

    A status of SYNCED confirms the installation of the policies.

View policy violations

Once the policy constraints are installed in audit mode, violations on the cluster can be viewed in the UI using the Policy Controller Dashboard.

You can also use kubectl to view violations on the cluster using the following command:

kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'

If violations are present, a listing of the violation messages per constraint can be viewed with:

kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'

Change PCI-DSS v3.2.1 policy bundle enforcement action

Once you've reviewed policy violations on your cluster, you can consider changing the enforcement mode so the Admission Controller will either warn on or even deny block non-compliant resource from getting applied to the cluster.

kubectl

  1. Use kubectl to set the policies' enforcement action to warn:

    kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
    
  2. Verify that policy constraints enforcement action have been updated:

    kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1
    

kpt

  1. Run the set-enforcement-action kpt function to set the policies' enforcement action to warn:

    kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
    
  2. Apply the policy constraints:

    kpt live apply
    

Config Sync

Operators using Config Sync to deploy policies to their clusters can use the following instructions:

  1. Change into the sync directory for Config Sync:

    cd SYNC_ROOT_DIR
    
  2. Run the set-enforcement-action kpt function to set the policies' enforcement action to warn:

    kpt fn eval policies/pci-dss-v3.2.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
    
  3. Push changes to the Config Sync repo:

    git add SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
    git commit -m 'Adding PCI-DSS v3.2.1 policy bundle warn enforcement'
    git push
    
  4. Verify the status of the installation:

    gcloud alpha anthos config sync repo list --project PROJECT_ID
    

    Your repo showing up in the SYNCED column confirms the installation of the policies.

Test policy enforcement

Create a non-compliant resource on the cluster using the following command:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: wp-non-compliant
  labels:
    app: wordpress
spec:
  containers:
    - image: wordpress
      name: wordpress
      ports:
      - containerPort: 80
        name: wordpress
EOF

The admission controller should produce a warning listing out the policy violations that this resource violates, as shown in the following example:

Warning: [pci-dss-v3.2.1-restrict-default-namespace] <default> namespace is restricted
pod/wp-non-compliant created

Remove PCI-DSS v3.2.1 policy bundle

If needed, the PCI-DSS v3.2.1 policy bundle can be removed from the cluster.

kubectl

  • Use kubectl to remove the policies:

    kubectl delete constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1
    

kpt

  • Remove the policies:

    kpt live destroy
    

Config Sync

Operators using Config Sync to deploy policies to their clusters can use the following instructions:

  1. Push changes to the Config Sync repo:

    git rm -r SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
    git commit -m 'Removing PCI-DSS v3.2.1 policies'
    git push
    
  2. Verify the status:

    gcloud alpha anthos config sync repo list --project PROJECT_ID
    

    Your repo showing up in the SYNCED column confirms the removal of the policies.