Podセキュリティとイメージスキャン

Ensuring the security of your applications in Kubernetes starts at the very foundation: the Pod itself. Pods run your containers, and if a Pod is compromised, your application is at risk.

Pod Security Standards (PSS) are a set of security guidelines that define different isolation levels for Pods. They help you enforce secure configurations and prevent common attack vectors.

Kubernetes defines three distinct Pod Security Standard profiles, each offering a different level of security and flexibility:

• Privileged: Unrestricted, allowing known privilege escalations. Avoid for most workloads.
• Baseline: Minimally restrictive, preventing known privilege escalations. Good for typical apps.
• Restricted: Highly restrictive, enforcing current hardening best practices. Ideal for critical apps.

These profiles help you choose the right balance between security and functionality for your Pods.

The Restricted PSS profile is the most secure and recommended for most applications. It aims to prevent any action that could grant a Pod excessive privileges or access to the host node.

This includes restrictions like:

• Not running as root.
• Preventing hostPath volumes (access to node filesystem).
• Disallowing privileged containers.
• Limiting Linux capabilities.

Adopting 'Restricted' helps significantly reduce the attack surface.

Kubernetes enforces Pod Security Standards through the Pod Security Admission (PSA) controller. This built-in admission controller inspects incoming Pods against defined PSS policies.

You can configure namespaces to use a specific PSS level (e.g., 'Restricted'). Any Pod attempting to run in that namespace that violates the policy will be rejected.

More advanced policy engines like Kyverno or OPA Gatekeeper can also enforce PSS and custom policies.

Let's look at a Pod definition that would violate the Restricted PSS profile. A common violation is running a container with elevated privileges.

The privileged: true setting grants the container all capabilities, essentially giving it root access to the host node. This is a major security risk.

Even with strong Pod Security Standards, your application can still be vulnerable if the container image itself has flaws. This is where container image scanning comes in.

Image scanning tools analyze your container images for known vulnerabilities, misconfigurations, and outdated software components. It's your first line of defense for application security.

So, how do these scanners work their magic?

• Layer Analysis: They inspect each layer of your Docker image.
• Component Identification: They identify installed packages, libraries, and their versions.
• CVE Database Lookup: They compare identified components against public vulnerability databases (like NVD for CVEs).
• Reporting: They generate a report detailing found vulnerabilities, their severity, and often, remediation steps.

There are many excellent tools available for scanning container images. Some popular choices include:

• Trivy: An open-source, easy-to-use scanner that finds vulnerabilities in OS packages and application dependencies.
• Clair: Another open-source tool, often integrated into container registries, providing comprehensive static analysis.
• Anchore Engine: Offers deep image inspection, policy enforcement, and compliance checks.

Choosing the right tool depends on your specific needs and existing CI/CD setup.

To be truly effective, image scanning should not be a manual, one-off task. Integrate it directly into your CI/CD pipeline – this is known as "shifting left" on security.

You should aim to scan images:

• During build time: Fail builds if critical vulnerabilities are found.
• Before pushing to registry: Ensure only clean images reach your registry.
• Periodically in registry: Continuously monitor images for newly discovered CVEs.

Automation ensures consistent security checks.

Beyond scanning, you can proactively build more secure images:

• Use minimal base images: Alpine Linux is a popular choice for its small footprint.
• Multi-stage builds: Reduce the final image size by discarding build tools and intermediate files.
• Run as non-root: Configure your container to run with a non-root user (e.g., using USER instruction in Dockerfile).
• Keep software updated: Regularly update OS packages and application dependencies.

These practices reduce the attack surface before scanning even begins.

Consider a Kubernetes namespace configured to enforce the Restricted Pod Security Standard profile. Which of the following Pod configurations would LIKELY be rejected by the Pod Security Admission controller?

Great job! In this lesson, we explored crucial aspects of securing your Kubernetes workloads.

You learned about Pod Security Standards (PSS) and their three profiles – Privileged, Baseline, and Restricted – and how they're enforced. You also discovered the importance of container image scanning, how these tools work, and best practices for integrating them into your development pipeline.

By applying PSS and regular image scanning, you build a stronger security posture for your cloud-native applications!