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.
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
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.
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:
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.
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.
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.
Allows usage of
Hostportsonly 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.
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.
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.
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.
Ensure that workloads only use an approved
FlexVolumedriver. This rule requires the list of approved flex volume drivers. An empty list means there is no restriction.
This policy ensures that types of volumes from an approved whitelist are only allowed to be attached to a workload.
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.
Ensure containers use an approved
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.
Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with forbidden and unsafe
Sysctlsare 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.
Ensures that containers can not be run as root (
MustRunAsNonRoot). Requires that the pod be submitted with a non-zero runAsUser or have the
userdirective 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.
Ensures that containers can be created with whitelisted approved
Seccompcan be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel.
Ensures that containers can be created with approved
AppArmorprofiles only. AppArmor can be configured for any application to reduce its potential attack surface and provide a greater in-depth defense.
Ensures that containers can be run with an approved
runAsUseronly. This policy allows the administrator to better control the privileges granted to a user in a container.
Ensures that containers can be run with an approved
runAsGrouponly. This policy allows the administrator to better control the privileges granted to a user in a container.
Ensures that pods can be created with an approved
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.
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.