Skip to main content

Deploy Compliance Packs

Styra manages security policies for cloud native and hybrid cloud infrastructure. For Kubernetes clusters, Styra can interoperate with the Kubernetes Admission Controller framework to enforce controls over all resource deployments. Styra also provides a library of policy templates for users requiring complex compliance controls. Payment Card Industry Data Security Standard (PCI DSS) is a requirement for E-commerce merchants conducting credit card transactions. This requires specific and stringent oversight of all aspects of a merchant’s computing infrastructure, human and automated processes, and operating and reporting environment. This page describes how Styra policies map to each specific PCI DSS goal and requirement for cloud native and hybrid cloud Kubernetes compliance.

Styra PCI DSS Pack​

Styra DAS provides 70+ specific control examples of Rego policy that can be used to manage Kubernetes resources subject to the requirements of Payment Card Industry Data Security Standard (PCI DSS), as shown below.

Styra DAS PCI DSS Library PackStyra DAS PCI DSS Library Pack

Deploy Policy Rules​

Styra has mapped each of the PCI DSS requirements to a set of controls that can be implemented by parameterized Rego Policy code and enforced using Styra with Kubernetes Admission Control, specifically a Validating Admission Controller. Styra’s innovative and intuitive UI allows DevSecOps users to quickly customize and test these Rego rules.

The following shows a list of the Styra PCI DSS pack pre-built rules.

NetworkPolicy Guard Rails​

  • Restrict NetworkPolicy Management to Specific Users.

  • Enforce Namespace Restrictions for Robust NetworkPolicy Enforcement.

  • Restrict Namespace and Pod Selectors in NetworkPolicies.

  • Restrict Ingress Traffic Label Selectors in NetworkPolicies.

  • Restrict Ingress Ports in NetworkPolicies.

  • Restrict Ingress IP CIDR Ranges in NetworkPolicies.

  • Restrict Egress Label Selectors in NetworkPolicies.

  • Restrict Egress Ports in NetworkPolicies.

  • Restrict Egress IP CIDR Ranges in NetworkPolicies.

RBAC Guard Rails​

  • Service Accounts: Prohibit Namespaces.

  • Restrict Users who can Manage Roles and Cluster Roles.

  • Prohibit Wildcard Verbs in Roles and ClusterRoles.

  • Prohibit Wildcard Subjects in RoleBindings and ClusterRoleBindings.

  • ClusterRoleBindings: Prohibit Built-in Role Modifications.

Volume and PodSecurityPolicy Controls​

  • Storage Classes: Prohibit Retain Reclaim Policy.

  • Storage Classes: Require Strong Encryption.

  • Require Secret Data to be Encrypted at Rest.

  • Deny Privileged Containers.

CI/CD and Secure Configuration​

  • CI/CD: Require Trusted Image Repository and Hardened Images.

  • CI/CD: Block Latest Image Tag.

  • Pods: Prohibit Unauthorized Host Paths.

  • Pods: Prohibit Host Network.

  • Pods: Prohibit Unauthorized Config Map Volumes.

  • Prohibit Pod Exec Resource.

CIS Pack​

Styra DAS offers the best out-of-the-box rule set to address Center for Internet Security (CIS) benchmarks applicable to Kubernetes Admission Controller. The new CIS benchmarks pack can be found under the Manage Compliance Packs selector in each Kubernetes system’s UI.

The following CIS Benchmarks are addressed by the new CIS Compliance Pack for Kubernetes:

  • 1.2.12 AlwaysPullImages

    This policy forces every new pod to pull the required images every time. You can be assured that your private images are accessed by only those who have the credentials to pull them. Without this, once an image has been pulled to the node, any pod can use it simply by just knowing the image name.

  • 1.2.16 Privileged

    Ensures that no container can enable privileged mode. By default, a container is not allowed to access any devices on the host, but a "privileged" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host.

  • 1.2.16 HostNetwork

    Ensure that pod may not use the node network namespace. This policy provides the pod access to the loopback device, services listening on localhost, and can be used to snoop on network activity of other pods on the same node.

  • 1.2.16 HostPorts

    Allows usage of Hostports only from an approved whitelist. This restricts access to known ports and limits the containers networking capabilities outside of its known function. An empty list means there is no restriction on host ports used.

  • 1.2.16 AllowedHostPaths

    Ensures that only approved whitelisted paths on hosts can be mounted into a pod. Mounting paths on a host gives the pod access to the underlying node file system.

  • 1.2.16 ReadOnlyRootFilesystem

    This ensures that containers run with a read-only root file system. This prevents an attacker from tampering with the local filesystem or writing malicious binaries to disk.

  • 1.2.16 AllowPrivilegeEscalation

    Prohibits privilege escalation so that a container cannot create a child process with more privileges than its parent. Escalated privileges would allow a container to perform more sensitive tasks than would be permitted by the configuration of the container itself.

  • 1.2.16 AllowedFlexVolumes

    Ensure that workloads only use an approved FlexVolume driver. This rule requires the list of approved flex volume drivers. An empty list means there is no restriction.

  • 1.2.16 Volumes

    This policy ensures that types of volumes from an approved whitelist are only allowed to be attached to a workload.

  • 1.2.16 denyHostNamespaceSharing

    Ensure pods may not share the host namespace. Sharing the host namespace allows the processes running in a container to communicate with other processes running on the host.

  • 1.2.16 AllowedProcMountTypes

    Ensure containers use an approved procMount type.

  • 1.2.16 RequiredDropCapabilities

    Ensure pods drop all the Linux capabilities that are not required. Linux Capabilities provide a fine-grained breakdown of privileges traditionally associated with root-user. Some of the capabilities can be used to escalate privileges or for container breakout. All capabilities that are not required must be dropped from a pod.

  • 1.2.16 RestrictSysctls

    Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with forbidden and unsafe Sysctls. Sysctls are used to modify kernel parameters at runtime. Sysctls can be used to disable security mechanisms or interfere with other containers on a host. All sysctls should be disabled except for a safe subset.

  • 1.2.16 MustRunAsNonRoot

    Ensures that containers can not be run as root (MustRunAsNonRoot). Requires that the pod be submitted with a non-zero runAsUser or have the user directive defined (using a numeric UID) in the image. Running a container as root may allow a non-root user to gain elevated access to the host.

  • 1.2.16 SeccompProfiles

    Ensures that containers can be created with whitelisted approved Seccomp profiles only. Seccomp can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel.

  • 1.2.16 AppArmorProfiles

    Ensures that containers can be created with approved AppArmor profiles only. AppArmor can be configured for any application to reduce its potential attack surface and provide a greater in-depth defense.

  • 1.2.16 RunAsUser

    Ensures that containers can be run with an approved runAsUser only. This policy allows the administrator to better control the privileges granted to a user in a container.

  • 1.2.16 RunAsGroup

    Ensures that containers can be run with an approved runAsGroup only. This policy allows the administrator to better control the privileges granted to a user in a container.

  • 1.2.16 FsGroupRule

    Ensures that pods can be created with an approved FSGroup only.

  • 1.2.16 SeLinuxOptions

    Ensures that containers can be created with a set of approved SeLinuxOptions. SELinux defines access controls for the applications, processes, and files on a system. It uses security policies, which are a set of rules that tell SELinux what can or can’t be accessed, to enforce the access allowed by a policy.

  • 5.7.4 NoDefaultNamespace

    Ensures that no container can be deployed in the default Kubernetes namespace. Using a specific namespace allows for better isolation through fine-tuned network policies, resource quotas, and service accounts.