Last month, the PCI Security Standards Council published its new Guidance for Containers and Container Orchestration Tools. This document is full of detailed security recommendations for PCI-compliant organizations to consider when hosting applications on container platforms like Kubernetes. The heart of the document is a 17-page list of specific recommendations covering everything from authentication, certificates, secrets, workload security, network security, monitoring, patching, versioning, and configuration.
It is encouraging to see an actionable list of recommendations for PCI-compliant organizations. However, Kubernetes platform engineers will immediately recognize the significant time and effort they have ahead of them to meet these guidelines. But don’t fret - Chainguard can help harden default Kubernetes configurations, software supply chains, and orchestration tooling to meet these recommendations.
Let’s take a look at some of the key findings in the new guidance, and unpack what the next steps look like for platform engineers and security teams:
Authentication and Authorization: The Council recommends all access to the platform be authenticated, granted the least privilege possible, with individual accountability, and that auth credentials must be revocable. This means:
- Disabling default accounts and system accounts (think TokenRequest API)
- Enabling multi factor authentication (MFA) for users - which requires the use of an external auth provider since Kubernetes does not natively support MFA
- No blanket administrative groups or hard-coded access groups such as cluster-admin or system::masters
Workload Security: The PCI guidance aims to make sure the workloads deployed on a container platform can be trusted, and cannot break out of isolation to attack the underlying platform.
- Workload definitions should target specific, known versions of container images. This means no :latest or other ephemeral tags should be used to pull images, and that images should ideally be cryptographically signed with a tool like cosign
- Signatures should be verified with a tool such as Chainguard Enforce or an admission controller. With Chainguard Enforce, policy enforcement rules can be used out of the box to validate signatures, and organizations can create custom validation rules based on PCI or internal compliance requirements.
- Container images should come from trusted sources. This means not allowing developers to pull images from popular, but untrusted public repositories. Organizations should manage their own registries with trusted images that are built from source, scanned for vulnerabilities, signed, and verified. Chainguard Enforce can monitor your environment to ensure images come from specific, trusted repositories.
Container Builds and Registry Storage: The best practices here are designed to minimize attack surface area for container images.
- Use a minimal base image to reduce attack vectors. Common public base images contain hundreds of unnecessary packages! Chainguard Images are distroless base images with minimal installed packages that reduce CVEs by over 97%.
- Container images should be stored in a secure registry, should be signed cryptopgrahically, and registries should have limited access to prevent malicious modification of built images. Signing images with cosign, and verifying signatures with a solution like Chainguard Enforce, is a good way to mitigate this risk
- Vulnerability scanning: Chainguard Enforce can use the information produced by your vulnerability scanner to verify the CVE status of an image before admitting it to your production environment.
Network Security: These are expected best practice recommendations that should apply to all network infrastructure used by an organization.
- Default deny firewall policy
- Do not expose the Kubernetes API to the public Internet
- API traffic must be encrypted
PKI and Secrets: Guidance is that certificates should be revocable, which is not always the case in Kubernetes systems. Secrets should be stored securely, version controlled, and also revocable. This requirement is also aligned with the requirements for meeting SLSA Level 3.
- Use a secrets management tool external to your Kubernetes cluster
- Do not store secrets in your code repository, your application image, or on the underlying cluster node
Additional Best Practices: The PCI guidance recommends several additional security best practices that operators can implement to mitigate the risk of an attack.
- Logging: should be configured to stream container logs to a central repository for retention and real-time monitoring. Containers are ephemeral, logs need to be captured before the container is evicted from the cluster.
- Always apply the latest security patches to orchestration tools. This is a challenge in Kubernetes due to frequent updates and narrow support windows per version. Organizations should have a defined process to stay up to date.
- Workloads should have defined resource limits to prevent containers from impacting its neighbors or the clusterContainers should run as non-root users
- Again, *NO* secrets should be stored in application images. The application should fetch secrets as needed from an external provider
- Segment and isolate workloads across clusters and dedicated hypervisors according to their criticality
As you can see, this guidance provides a long list of security practices that PCI-compliant organizations should implement when deploying modern containerized applications. Many of these practices will require 3rd-party tools to ensure compliance. Coupling leading open source tools like Sigstore with solutions like Chainguard Enforce (Get a free trial!) and Chainguard Images can be helpful to reduce the risk of attacks on the modern application supply chain for PCI-compliant organizations. Contact us today for more information on how we can help.
.png)
