Skip to main content
Welcome back. This lesson explains platform security in the context of modern platform engineering: how security tools become first‑class citizens of the platform, where they sit in CI/CD and runtime, and common patterns for protecting artifacts, workloads, and the runtime. Expect some repetition — concepts are revisited in different contexts to reinforce how tools fit together.
A presentation slide titled "Modern Platform Engineering – Why Security Tools Matter" for "Sparkle Pony Ranch." It shows three avatars named Swati, Alan, and Phuong with labels highlighting needs: runtime protection, infrastructure security, and security without slowing development.
Platform engineers are commonly responsible for three broad goals:
  • Runtime protection (detecting and responding to threats in running workloads).
  • Infrastructure and supply‑chain security (artifact provenance, signing, SBOMs).
  • Security controls that preserve developer velocity (policy-as-code, automated gating).
CNCF maintains a large ecosystem of security projects across maturity levels. Choose tools appropriate to the risk and required SLAs: prefer graduated projects for critical controls, and evaluate incubating or sandbox projects when they add unique capability.
An infographic titled "CNCF Security Tools by Maturity Level (2024/2025)" showing three columns for Graduated, Incubating, and Sandbox projects. It lists examples like Harbor, TUF, Kubernetes and Linkerd under Graduated; Falco, OPA, SPIFFE/SPIRE and In-toto under Incubating; and Parsec under Sandbox.
Key takeaway: map the tool to the threat and the pipeline stage where enforcement or detection should occur.

​
Container image protection: scanning, signing, and supply‑chain metadata

Core practices for container image protection:
  • Use a registry (for example, Harbor) with integrated vulnerability scanning and RBAC.
  • Scan images at build time (Trivy, Grype) and optionally continuously in the registry.
  • Sign artifacts with tools such as Sigstore / Cosign and verify signatures before deployment.
  • Record provenance and attestations with frameworks like in‑toto and generate SBOMs.
A slide titled "Container Security – Scanning, Signing, and Supply Chain Protection" showing four tools and logos: Harbor, Trivy, Cosign, and in-toto. Each has a short caption describing its role (Harbor: enterprise registry with Trivy scanning; Trivy: vulnerability scanner; Cosign: container signing/verification; in-toto: supply chain metadata and attestations).
Table: Container image protection components Typical CI/CD flow: build → scan → block on high/critical findings → sign → push to registry → verify at deployment. Example GitLab CI snippet demonstrating scanning and a separate signing stage:
Enforce signing and provenance at the registry/admission layer: platform teams should configure registry policies and admission controllers to reject unsigned or unaudited artifacts before they reach production clusters.
Platform teams usually coordinate responsibilities: one team configures registry policies and scan automation, another mandates signature verification, and developers remediate findings surfaced by scans.

​
Runtime protection: Falco

Runtime protection monitors activity inside containers and hosts (system calls, execs, privilege escalation) and triggers alerts or automated responses. Falco is a CNCF project that provides system‑call level monitoring and rule‑based detection for Kubernetes and container runtimes.
A presentation slide titled "Runtime Protection – Falco and Real-Time Threat Detection." It lists four features—System Call Monitoring, Custom Rules, Kubernetes Native, and Real-Time Alerts—each shown with colorful icons.
Falco rules can map to severities and automated responses (alerts, creating incidents, or feeding into enforcement). Rules are typically applied consistently across environments, with environment-specific thresholds or allowlists. Example: concept Falco rule (detect privilege escalation inside a container)
Falco integrates with alerting, SIEMs, and incident response pipelines to automate follow-up actions.

​
Policy-as-code: OPA and Gatekeeper

Policy-as-code lets you declaratively express constraints and enforce them during admission. Open Policy Agent (OPA) uses the Rego language to express policies; Gatekeeper implements an admission controller that applies OPA policies and provides auditing.
An infographic titled "Policy-as-Code – OPA and Gatekeeper for Kubernetes" showing a colorful donut diagram with sections for Rego Language, Admission Control, Continuous Compliance, and Universal Engine. It summarizes how policies are written, validated before cluster admission, audited for compliance, and applied across tools.
Common policy use cases:
  • Block privileged containers and hostPath mounts.
  • Enforce image provenance (require signature or specific registries).
  • Validate resource requests/limits and labels for cost tracking.
Simple Rego example: deny privileged pods
OPA/Gatekeeper also provides audit functionality for continuous compliance and reporting.

​
Workload identity: SPIFFE and SPIRE

SPIFFE defines a standard identity format (SPIFFE ID) for workloads. SPIRE implements an attestation and identity issuance system that provides short‑lived X.509 certificates or JWTs to workloads. Combined with service meshes or TLS tooling, SPIFFE/SPIRE enable mTLS and zero‑trust networking.
A presentation slide titled "Secrets and Identity – SPIFFE/SPIRE With Service Mesh Integration" showing four boxed points: SPIFFE ID (universal workload identity format), SPIRE Server (identity attestation and certificate management), mTLS Everywhere (automatic service-to-service encryption), and Zero Trust (no network-based trust assumptions). The slide is © KodeKloud.
Service meshes (Linkerd, Istio) or CNI/eBPF projects (Cilium) commonly consume SPIFFE identities to perform automatic mTLS between services. Consider Linkerd for simplicity, Istio for richer policies and observability, and Cilium for advanced networking and eBPF‑powered enforcement.

​
Supply‑chain security: SLSA, SBOMs, and attestations

Supply‑chain security answers provenance questions: who built the artifact, what inputs were used, and can we trust the build process? Key concepts:
  • SLSA (Supply‑chain Levels for Software Artifacts) defines increasing levels of assurance.
  • SBOMs (Software Bill of Materials) list components and versions.
  • Attestations and in‑toto record and sign build pipeline steps.
An infographic titled "Supply Chain Security – SLSA, SBOM, and Attestations" showing a four-step staircase of security levels. The steps are Build Provenance, Hosted Build, Hardened Service, and Hermetic Builds, each with a short description and an icon.
Platform teams should provide the capability to generate SBOMs, emit attestations for builds, and integrate signing/verification into deployment pipelines. Hosted CI services (for example, GitHub Actions) can produce certain SLSA‑level assurances such as signed attestations for hosted runs. Supply‑chain tooling examples:
  • in‑toto: capture provenance and pipeline attestations.
  • TUF (The Update Framework): secure distribution of updates.
  • Notary v2 / Cosign: image signing and verification.
A slide titled "Supply Chain Security – SLSA, SBOM, and Attestations" showing three CI/CD security frameworks: in-toto (supply chain metadata framework), TUF (secure update framework), and Notary v2 (container image signing and verification), each illustrated with an icon.
Table: Selected supply‑chain tools

​
Automated compliance, auditing, and posture management

Combine policy engines, runtime monitoring, cloud security posture tools, and audit logging to automate compliance evidence collection and enforcement. These capabilities help demonstrate conformance to frameworks such as SOC 2, PCI‑DSS, FedRAMP, and NIST by codifying controls and collecting audit evidence.
A presentation slide titled "Automated Compliance – Policy Engines and Audit Frameworks" showing four colored compliance layers: OPA/Gatekeeper, Falco, Cloud Security Posture, and Audit Logging. Each block summarizes its role (policy enforcement for Kubernetes, runtime monitoring/violation detection, automated posture scanning, and security event tracking).
A presentation slide titled "Automated Compliance – Policy Engines and Audit Frameworks" showing icons and brief descriptions for multi-framework support: SOC2, PCI‑DSS, FedRAMP, and NIST. It highlights automated compliance and team governance.
Automated evidence collection (audit logs, attestations, scan reports) reduces audit friction and helps SREs and platform teams maintain posture over time.

​
Vulnerability management: Trivy, Grype, Snyk

Use scanners at multiple stages:
  • Build-time SCA/SAST (Trivy, Grype, Snyk).
  • Pre-deployment checks (admission policies).
  • Continuous scanning of running images and registries.
A slide titled "Comprehensive Vulnerability Management – Trivy, Grype, and Snyk" showing four colored branches for Kubernetes manifests, container images, dependencies, and source code with brief descriptions of policy validation, OS/library vulnerability scanning, SCA for third‑party risks, and SAST for code issues.
Table: Vulnerability scanners and focus areas Security belongs across the pipeline: repository policies, build-time scans, signing, admission-time enforcement, runtime detection/response, and continuous post‑deployment monitoring. Include SAST/DAST and security testing in CI to shift left on finding issues. Expect growing use of AI in security (assist triage, predictive detection), increasing focus on edge security, and continued evolution of supply‑chain tools. Core practices that remain essential:
  • Regular container scanning and SBOMs.
  • mTLS and workload identity for zero‑trust.
  • Signed artifacts and attestations for provenance.
A presentation slide titled "Future of Platform Security – AI, Edge, and Emerging Threats" showing four future trends: Runtime AI, AI-Powered Security, Predictive Security, and Edge Security, each paired with colorful icons and brief descriptions.

​
Essential building blocks for a Kubernetes-based platform

  • Runtime protection (Falco) for real‑time detection and response.
  • Workload identity (SPIFFE/SPIRE) for short‑lived identities and mTLS.
  • Vulnerability management (Trivy/Grype/Snyk) for images, dependencies, and manifests.
  • Policy enforcement (OPA/Gatekeeper) and automated compliance pipelines.
  • Supply‑chain protections (SBOMs, in‑toto, TUF, Notary/Cosign) for provenance and signing.
A presentation slide titled "Modern Platform Engineering – Essential Security Tools" showing three boxes: Runtime Protection (04), Workload Identity (05), and Vulnerability Management (06). The Runtime Protection box notes Falco for real-time threat detection and the Workload Identity box references the SPIFFE spec and SPIRE runtime for zero‑trust identity.

​
Summary

This lesson provided a high‑level overview of the main categories of tools used in platform security:
  • Artifact protection (scanning, signing, SBOMs).
  • Runtime protection (Falco and detection).
  • Policy-as-code (OPA/Gatekeeper).
  • Workload identity (SPIFFE/SPIRE).
  • Supply‑chain attestations and SLSA.
  • Automated compliance and vulnerability management.
These topics recur in platform engineering: for example, Trivy scans containers, Falco detects runtime violations, OPA/Gatekeeper enforce admission policies, and SPIFFE/SPIRE provide workload identity. Dive deeper into each tool and practice for operationalizing them in your platform.

Watch Video