New Kubernetes PCI DSS Compliance Packs, And More
As enterprises adopt cloud-first or cloud-native strategies, Kubernetes is by far the most important strategic consideration. At the same time, for the large subset of these enterprises which take payment from consumers, PCI DSS has never been more critical. More than ever, enterprises have to pay attention to data security (and their commitment to improving security posture) in order to meet compliance requirements. So what has to change to meet compliance in a Kubernetes-based environment?
At Styra, our solutions have always focused on early risk prevention, by providing security guardrails for the desired state model of Kubernetes. We work with the Kubernetes APIs to prevent security drift and eliminate errors—before they can occur. We’re building upon our proven foundation of Kubernetes guardrails with the new set of features we are proudly announcing today:
Compliance Packs: a cohesive set of Kubernetes admission control policies which provide guardrails in compliance with regulatory standards (firstly, PCI DSS 3.2)
Policy Stacks: a simple way for enterprises to efficiently manage a uniform set of policies across multiple clusters that perform similar functions (e.g., all production clusters, or all clusters regulated by PCI)
Apart from the above, other notable new features include:
On-premises deployment option for Styra DAS management console
Integrations with prometheus for monitoring
Extension to RBAC controls to include system owners
PCI DSS 3.2 Compliance Pack
Kubernetes is an open and flexible infrastructure, and security was never the intended benefit of the platform, since deployments and implementation can vary so widely. But for enterprises who are running customer-facing applications on Kubernetes, achieving PCI compliance is a completely organic, manual effort. Additional layers of technical controls must be applied with careful consideration of all operational details to achieve (and prove!) the goals of PCI.
Some of the challenges are:
None of the PCI DSS concepts or controls directly correlate to the containerized/K8s environments.
For auditors, it’s an extremely technical subject area to verify, with few (if any) familiar security controls.
For enterprises, it is hard to prove that the controls are in place to satisfy the requirements, since so much is delivered “as-code” and not in legacy black-box type infrastructure controls.
DevOps and Security Teams face challenges in enforcing a consistent and auditable policy for a Kubernetes environment subject to PCI DSS requirements, including:
How do we build and maintain secure data flows across ephemeral workloads, and maintain a secure control plane and data plane throughout our clusters?
How do we protect sensitive cardholder data at rest in Volumes and in transit between Nodes and Pods?
How do we manage vulnerabilities in the software supply chain in a DevOps Continuous Integration and Continuous Deployment (CI/CD) environment?
How do we implement robust and auditable Access Control policies in Kubernetes, including managing role permissions and bindings?
How can we test policies before deployment?
How do we produce detailed and useful audit reports, allowing the tracing of all pertinent events to each of the above goals?
Today we are announcing the first Styra Compliance Pack in our solution – with dozens of Kubernetes security policies focused on PCI DSS 3.2. Styra has mapped each of the relevant PCI DSS requirements to a set of controls that are:
Defined by parameterized Rego
Delivered as Policy-as-code
Enforced by Styra interfacing with Kubernetes Admission Control
Styra’s innovative and intuitive UI allows DevSecOps teams to deploy the PCI compliance pack, and then customize and test these rules quickly and simply. This of course eases Day 1, but also greatly speeds Day 2 initiatives like security reviews and compliance audits.
Examples of relevant policies include:
Network Policy and Ingress resources
(Supports PCI DSS Requirements 1.1 – 1.2)
Kubernetes NetworkPolicies and Ingress resources, which control how data flows in and out of a cluster, become highly complex and impossible to manage at scale. Styra provides very clear and auditable gitops policies for ensuring that only specific namespaces and pod labels are allowed for ingress traffic, similar to how legacy firewalls would partition and isolate traffic.
Enforce auditable and compliant encryption and key management.
(Supports PCI DSS Requirements 3.5 – 3.6)
Encryption of cardholder data is essential for any merchant, and Styra provides policies that ensure that a robust and compliant Key Management Server is used in production by requiring consistent configuration and specific approved KMS endpoints in the EncryptionConfiguration resources.
Enhance RBAC with consistent and clearly defined roles and responsibilities
(Supports PCI DSS Requirement 7.2)
Styra policies augment default Kubernetes RBAC roles by prohibiting roles from being abused and requiring a consistent and well defined structure that can be traced to detailed human job classifications and responsibilities; thus implementing a “least privileged” control plane.
Deploying Compliance Packs:
To add a PCI compliance pack, Styra customers simply navigate to the appropriate Kubernetes system, click “Compliance Packs” and toggle “PCI DSS 3.2”. This kicks of a simple wizard to walk through the rules available within the pack, and what PCI DSS controls each satisfies.
When it comes to PCI DSS and Kubernetes, there are many variables to consider, and one size will never fit all—That’s why our PCI DSS Compliance Pack is the perfect starting point for a customized journey to PCI certification. By adding relevant guardrails before resources go into run-time, teams can ensure that checks and balances are in place from inception. Early prevention is better than scattershot attempts at run-time cures.
Policy Stacks:
We are also enhancing multi-cluster policy management with our new Policy Stacks feature. Policy Stacks allow you to create a set of rules for multiple systems so that these rules don’t need to be specified repeatedly one system at a time. You can group systems that share common traits example: production/staging or PCI, and apply a stack of rules to them.
Policy Stacks also serve as an authoritative set, so the individual systems have to abide. Additionally, Policy Stacks enable teams to monitor groups of related systems as one, to ensure consistency, and to easily identify any anomalies early.
Creating a Policy Stack:
Customers can create a new Policy Stack easily by clicking the + to the right of Stacks, and simply giving it a name and a description to know the purpose of it. Then it’s easy to add existing library rules, Compliance Packs, or custom rules. Setting the Selectors allows a stack to discover the systems it should manage.
On Premises Deployment Option:
Our customers can also now deploy the entire DAS Solution as an on-premise deployment. In the hybrid cloud world, it’s typical to extend SaaS offerings with an on-premise deployment option. We have heard this request from many of our customers and added support for it. It is essential for those enterprises where regulations, policies, or legal liabilities and indemnification issues require on-premises solutions rather than SaaS options. Our On-Premises deployment supports Kubernetes provided by any of the public cloud providers (GKE, AKS, EKS, or OpenShift) or vanilla Kubernetes running in the private cloud.
Integration with Prometheus:
Prometheus monitoring is often deployed alongside Kubernetes and other cloud-native technologies. We added support for Prometheus and added the capability to export two types of metrics in the Prometheus format: decisions and system metrics.
Decision Metrics: Report the accumulated number of decisions, denies, errors, advice, unknowns, and violations per system (K8s cluster)
System Metrics: Report the accumulated number of errors and warnings per systems (K8s cluster)
Once Prometheus is setup to scrape Styra metrics, AlertManager can be used to set up alerts for violations or service related errors to popular services like Slack.
Extension to RBAC to include system owners
We have extended our management control to support owners at the individual System level. A system owner has full control over their system, but can’t modify labels or features. Only an administrator has the right to do so – so the system owner cannot circumvent policies that are enforced from a stack.
See for yourself
These features were built based on feedback from our users, so if you have any ideas you’d like us to implement, please let us know at info@styra.com!
The Styra team is showcasing these new features at KubeCon San Diego, booth S75, so stop by if you’re at the show! You can also see more in our live demo – register now!