CNAPP & Cloud-Native Runtime Security: A Practical 2026 Guide

What CNAPP means in a practical engineering path

Cloud-native application protection platform, usually shortened to CNAPP, is most useful to a learner when it describes connected security capabilities rather than a shopping category. In this guide, those capabilities are posture, workload protection, entitlement analysis, and code or software-supply-chain security. The engineering challenge is to join their evidence around the same assets and identities without turning uncertain or stale data into false assurance.

Posture asks whether cloud accounts, clusters, nodes, namespaces, workloads, identities, network paths, admission controls, Secrets handling, audit settings, and runtime sensors match intended policy. Workload protection asks what processes actually execute, which files they read or change, which network destinations they contact, which credentials they touch, and whether that behavior differs from the approved workload. Entitlement analysis asks what a human or workload can do directly and through transitive paths. Code and supply-chain security ask what exact artifact was built, which components it contains, who or what produced it, and whether consumer policy authorizes that artifact.

None of these views is complete by itself. A clean posture snapshot does not prove that an application will remain benign after exploitation. A runtime alert without image, owner, entitlement, exposure, and sensor-health context can be impossible to prioritize. A vulnerability finding without reachability, privilege, exposure, or running-deployment context can overwhelm remediation teams. A valid signature from an unexpected identity proves integrity under that identity, not authorization for production.

The eight-week CNAPP and runtime security roadmap therefore begins with a shared threat and asset model, establishes artifact identity and admission, reduces workload authority, adds runtime visibility, builds detections and response, and closes with evidence governance, cost, privacy, projects, and cleanup.

Start with NIST's container system boundaries

NIST SP 800-190 remains a strong foundation because it describes application-container risk across images, registries, orchestrators, containers, and host operating systems. That structure prevents a common mistake: treating container security as only image vulnerability scanning. An image can contain vulnerable or malicious software. A registry can expose or substitute content. An orchestrator can be misconfigured or overprivileged. A running container can be exploited or drift. The host shares a kernel with containers and represents a larger blast radius.

The CNCF Cloud Native Security Whitepaper broadens the lifecycle across building, distributing, deploying, and running cloud-native capabilities. Use these sources to draw trust transitions: developer to source control, source to builder, builder to registry, registry to admission, API request to persisted object, Pod to node kernel, workload identity to Kubernetes and cloud APIs, runtime sensor to host, and event pipeline to analysts or automation.

For each transition, identify the authenticating evidence, authorized action, stored data, failure mode, detection, owner, and cleanup. Include the security system itself. A node sensor may require access to kernel hooks, host filesystems, container runtime metadata, or the BPF filesystem. A collector may read broad Kubernetes metadata. An admission webhook sits on an API write path. An event forwarder can expose sensitive process or identity details. These components need least privilege, isolation, monitoring, upgrades, incident response, and retirement like any other privileged service.

Use stable identity and honest coverage

Multi-cluster security fails quickly when names are treated as global identity. Two clusters can each contain a namespace named payments and a ServiceAccount named reconciler. Pod IPs and container names are ephemeral. Image tags can move. A useful compound identity includes the provider or trust domain, account or project, cluster UID, namespace, workload UID and owner, container ID, image digest, and principal. Names and tags remain useful display fields, but they are not enough for durable joins.

Each evidence record should also preserve a source identifier, source timestamp, ingestion timestamp, collector or sensor version, policy or rule version, and freshness. A disconnected collector must not leave its last green state looking current. Show passing, failing, excepted, unknown, and stale as different conditions. Record why evidence is missing: unsupported platform, provider-managed control, collector failure, permission denial, parsing error, queue loss, or deliberate scope exclusion.

This is the foundation for contextual priority. A critical vulnerability in an isolated workload with no token, no public route, restricted Pod settings, and no observed execution can remain important without automatically outranking a medium vulnerability in a public workload with broad Secret access and an unexpected shell. The priority decision should combine artifact, exploit preconditions, exposure, effective access, runtime behavior, compensating controls, business impact, and evidence confidence.

Build an artifact evidence chain

Begin with immutable image identity. A mutable tag such as stable is a convenient pointer, not evidence of exact content. Build an image once, identify it by digest, and promote that same digest. Associate the SBOM, vulnerability report, signature, provenance, admission decision, running container image ID, and incident evidence with it. If any part refers only to a tag, the chain can silently split when the tag moves.

An SBOM supports component inventory and later impact analysis when vulnerability intelligence changes. It does not prove that every component executes, that every listed vulnerability is exploitable, or that the artifact came from an approved source. Record the SBOM format and generator, artifact subject, time, and coverage. Protect its association with the digest so an attacker cannot substitute a clean SBOM for a different image.

Vulnerability prioritization needs context. Record scanner and vulnerability database versions, scan time, affected component, fix availability, known exploit information where legitimately sourced, and uncertainty. Add deployment reachability, external exposure, runtime execution, privileges, service account and cloud role, writable state, and asset criticality. A risk-based exception should identify the exact digest and workload, owner, rationale, reachability evidence, compensating controls, approval, expiry, and triggers such as a new exploit, changed exposure, or new artifact.

SLSA provides a specification for incrementally improving supply-chain security and describes provenance formats and build requirements. Provenance helps answer which source and builder produced an artifact subject. Verification policy still needs to constrain the subject digest, source repository and revision expectations, builder identity, build type or workflow, and required SLSA properties. The presence of a syntactically valid attestation from an unknown builder should not authorize deployment.

Sigstore offers identity-oriented signing, short-lived certificates in its public model, and transparency evidence. The important security lesson is broader than a command: a valid signature must be checked against the identity and issuer or trust root that policy expects, and against the exact artifact. Any-valid-signer policy is not a deployment policy. Select a public, private, or local test trust model based on organizational privacy, availability, and governance requirements and follow current official documentation.

Enforce the final object at admission

Kubernetes admission runs after authentication and authorization and before persistence. Mutation runs before validation. That sequence matters because review-time policy may approve a manifest that is later changed by a mutating webhook. Rendered checks in a pull request improve feedback, but validating admission must inspect the final object that will be stored. Audit evidence should explain relevant mutations and policy decisions.

Admission is not authorization for reads. Ordinary get, list, and watch requests bypass admission, so Secret protection cannot be solved with a validating webhook. Admission also introduces availability and bypass decisions. Narrow webhook scope, set explicit timeouts, choose failure behavior according to the control's risk, protect service identity and certificates, use minimal RBAC, monitor latency and errors, and test outage and recovery. Side effects require reconciliation because later admission stages can still reject the request.

Artifact admission can require digest references, an approved registry, expected signature identity, valid provenance subject and builder policy, a current scan, and an in-scope exception when risk policy requires one. Workload admission can enforce Pod Security, resource requests, approved RuntimeClass, service account rules, host access, volume types, capabilities, seccomp, read-only filesystem policy, and organizational labels. Avoid a single enormous policy with no owner or test matrix. Version controls and test allowed, denied, exception, timeout, stale-evidence, and rollback paths.

Harden the workload and shared kernel boundary

Kubernetes defines Privileged, Baseline, and Restricted Pod Security Standards. Baseline prevents known privilege escalation while preserving broad compatibility. Restricted follows current hardening practices at greater compatibility cost. On Linux, Restricted includes non-root execution, no privilege escalation, an allowed seccomp profile, dropping all capabilities, and only permitting NET_BIND_SERVICE to be added back where needed. It also builds on host namespace, privileged, hostPath, and other Baseline restrictions.

Pin Pod Security versions so an upgrade does not change enforcement unexpectedly, then plan deliberate updates. Protect namespace labels because a caller able to weaken Pod Security labels can bypass intended controls. Treat exemptions and privileged infrastructure namespaces as high-risk inventory with exact owners, image digests, identities, host mounts, nodes, compensating controls, monitoring, and expiry.

Seccomp filters system calls from userspace into the kernel. Kubernetes recommends runtime defaults as the practical baseline; custom profiles can break with application changes and are difficult to manage at scale. AppArmor and SELinux add mandatory access control over resources using different policy models. These mechanisms provide defense in depth but do not turn a shared kernel into a separate physical host. Privileged containers can override or bypass many of them, which is why privileged sensors and infrastructure agents need special isolation and review.

Model effective entitlements, not only assigned roles

Kubernetes RBAC good practices emphasize namespace scope, minimal verbs and resources, avoiding wildcards, limiting cluster-admin, and periodically reviewing bindings. A CNAPP-style entitlement view must go further by modeling privilege escalation paths. Permission to create Pods in a namespace can allow a principal to mount Secrets, volumes, and ConfigMaps and to run as service accounts already present in that namespace. A role can therefore be dangerous without direct get Secret permission.

Other sensitive paths include bind, escalate, and impersonate; serviceaccounts/token; approval of client certificate requests; control of mutating or validating webhook configuration; broad PersistentVolume creation; and nodes/proxy. Kubernetes warns that get on nodes/proxy can reach privileged kubelet APIs and is not merely read-only. Effective entitlement graphs should preserve the exact rule and path that produced a risk conclusion.

Do not automatically equate unused access with safe removal or observed access with approved need. Usage evidence helps identify candidates, but an owner and policy decide necessity. Stage least-privilege changes, test expected allowed and denied workflows, retain rollback, and use short-lived monitored emergency access. Separate collectors from responders: a fleet inventory identity should not gain write authority merely because a response integration needs containment.

For workload identity, disable ServiceAccount token automount when a Pod does not call the Kubernetes API. When a token is required, use a dedicated ServiceAccount and short-lived, rotating, audience-bound projected tokens. Prefer federated workload identity for external cloud APIs rather than static keys in Secrets. Constrain provider trust to the exact cluster, namespace, ServiceAccount, subject, audience, and minimum role, then monitor both token issuance and use.

Constrain network and Secret blast radius

Kubernetes NetworkPolicy controls layer 3 and layer 4 flows when the selected network implementation enforces it. Ingress and egress isolation are independent. A namespace with default-deny ingress still permits outbound connections unless an applicable egress policy isolates the Pod. When both source egress and destination ingress are isolated, both sides must allow a connection. Policies combine additively rather than by ordered deny rules.

Start with deliberate default deny and explicitly allow DNS, telemetry, platform APIs, dependencies, ingress gateways, and application paths. Test real traffic. A correct-looking resource has no effect when the plugin does not implement NetworkPolicy. Understand limits: the core API does not provide universal layer 7 or TLS controls, service-name targets, blocked-flow logging, node-specific identity policy, explicit deny rules, or predictable hostNetwork behavior across implementations. Address translation can also affect IP-based decisions.

Kubernetes Secrets are base64-encoded, not encrypted by that encoding, and are stored unencrypted in etcd by default unless encryption at rest is configured. Restrict get, list, and watch because list and watch reveal contents. A principal that can create a Pod may be able to expose a Secret by mounting it even without direct read permission. Use separate namespaces for different trust, mount a Secret only into the container that needs it, prefer short-lived values, avoid manifests in source control, protect values after reading, redact logs, and alert on unusual bulk access.

Understand eBPF and runtime visibility honestly

Runtime security observes what occurs after a container starts. Useful signals include process execution and ancestry, users and capabilities, sensitive file reads, executable or startup-file writes, network connections, namespace and cgroup context, container metadata, service account, image digest, node, deployment revision, and control-plane changes. These signals can detect exploitation, credential access, drift, persistence attempts, lateral movement, and policy bypass that artifact checks cannot prove.

eBPF programs attach to kernel hooks according to program type. They receive a type-specific context, can call allowed helper functions, can share data through maps, and can send events through ring or perf buffers. The kernel verifier checks that a program satisfies safety constraints for loading. It does not prove that a detection is accurate, that all behavior is visible, that no event will be dropped, that the loader is least privileged, or that the program's intent is benign.

The loader and runtime sensor are privileged infrastructure. Depending on the program and kernel, loading and attaching can involve capabilities such as CAP_BPF, CAP_PERFMON, or CAP_NET_ADMIN, along with BPF filesystem, kernel and container-runtime metadata. Minimize capabilities and host mounts, protect pinned programs and maps, isolate the sensor from ordinary workloads, verify the artifact and configuration, monitor changes, and include sensor compromise in the threat model.

Kernel and runtime compatibility matters. Hook availability, architecture, BTF, CO-RE behavior, container runtime metadata, buffer sizes, event rates, and managed-node constraints can all affect visibility. Inventory these details per node pool. A dashboard should never treat an unsupported kernel or missing sensor as no findings.

Engineer Falco rules as tested code

Falco evaluates supported event sources using rules and emits outputs. Kernel events provide runtime process and syscall context; plugins can add other event sources when configured and supported. Rule conditions operate over fields exposed by the event source. Macros and lists support reuse, while priority and tags support routing and ownership. Local rules and overrides should be versioned, reviewed, and tested.

A rule for every shell is a useful learning fixture but a poor universal page. Some workloads legitimately invoke shells during initialization or maintenance. Better conditions combine process and parent, container and workload, namespace, image digest, service account, file or destination, and whether the behavior is expected for that workload. Output should include enough safe context to investigate without exporting unbounded process arguments or file content.

Every rule needs at least three kinds of test. A positive synthetic fixture must alert. Representative legitimate behavior must not page or must route to a lower-severity channel. A sensor, rule-loading, or output failure must create a coverage-health signal. Run fixtures across supported kernels, runtimes, and workload forms. A successful test on one node does not prove fleet coverage.

Falco supports rule exceptions, but exceptions must be narrow and governed. Use stable approved context such as exact workload, namespace, digest, parent process, service account, or maintenance identity as the event fields allow. Record owner, rationale, approval, expiry, and regression tests. A permanent global suppression for sh or a package manager creates a broad blind spot.

Monitor dropped syscall events and performance. Event rate can exceed buffer or processing capacity. Output delivery can fail even when capture works. Track driver and engine health, loaded rules, captured and dropped events, output queue and errors, last successful delivery, node coverage, and synthetic health-check results. Absence of an alert is evidence only when the entire path is known to be functioning.

Correlate drift and behavior chains

Runtime drift is a difference between approved or expected state and observed files, processes, identities, network behavior, or configuration. Not every writable-layer change is malicious. A package cache, temporary file, or compiled template may be intended. A new executable, changed startup file, replaced library, added account, altered image digest, host mount, or unexpected service account carries different risk.

Compare changed paths and file types with declared writable mounts and expected processes. Add process ancestry, image digest, deployment revision, user, time, network behavior, and admission or audit changes. A read-only root filesystem and explicit writable volumes reduce ambiguity, although not every application supports them. Preserve relevant evidence before reconciliation because immediately deleting or restoring a workload can destroy the timeline needed to identify the actor and path.

Behavior chains improve confidence. An unexpected shell alone can be maintenance. Reading a projected token path alone can be a framework. A new external connection alone can be a dependency. In close sequence from the same process tree and workload, those events can represent exploitation, credential discovery, and attempted use. Correlation should preserve the individual facts and state confidence honestly; it should not claim data exfiltration when the evidence shows only a connection attempt.

Contain capability while preserving evidence

Response begins before the first alert. Define which team owns the workload, cluster, identity, cloud role, registry, sensor, and evidence. Pre-approve bounded actions such as denying egress, removing a specific binding, revoking a workload identity, scaling one controller to zero, or isolating a node. Keep collectors read-only and use a separate, tightly controlled response identity. Require exact cluster and workload UID, reason, approval, and audit record so same-named resources in another cluster are not affected.

When a likely compromised Pod has broad external permissions, capture enough context to investigate while revoking the authority or network path most likely to cause harm. Useful ephemeral evidence includes Pod UID and owner references, node, image and container IDs, deployment revision, process ancestry, network connections, file activity, Kubernetes audit events, identity issuance and use, and sensor health. Collection must remain proportionate and authorized; blindly collecting all Secret values or memory from unrelated tenants creates additional exposure.

Deleting a Pod does not invalidate a copied credential, remove a modified controller, clean a malicious image, close a cloud session, or remediate a compromised node. Review token lifetime and object binding, rotate or revoke authority, search equivalent images and principals, inspect desired-state changes and persistence, and check sibling workloads. If a container escape is suspected, isolate and replace the node from trusted state rather than assuming in-place cleanup restored trust.

Recovery needs tests. Deploy the approved digest and policy, confirm compromised credentials no longer work, prove known persistence is absent, restore the service objective, verify audit and runtime coverage, and rerun both malicious-like and legitimate fixtures. Convert root cause and containment findings into build, admission, entitlement, detection, and response regression tests.

Build an evidence pipeline that can fail honestly

Kubernetes audit provides chronological security records for API activity. Audit policy rules are ordered, and the first match selects None, Metadata, Request, or RequestResponse. Metadata often answers who performed which verb on which resource without recording bodies. Request and RequestResponse can improve selected investigations but may collect credentials, sensitive configuration, or personal data and increase API-server memory and storage use. Use higher levels only where the value and handling controls justify them.

Monitor audit export as well as policy. Kubernetes exposes audit event and error metrics, and webhook batching can drop events when buffers overflow. Runtime output has similar concerns. Use bounded queues, retry and backpressure, define what happens when capacity is exhausted, and expose source capture, queue depth, dropped records, parse failures, duplicates, and successful downstream delivery separately. Never keep a complete-coverage indicator green during a known outage.

Normalize evidence without erasing provenance. Preserve the source event ID, original timestamp, ingestion timestamp, source version, and raw-record reference under access control. Add stable cluster, workload, digest, principal, policy, rule, and correlation fields. Monitor clock synchronization and ingestion delay because a misleading timeline can reverse cause and response.

Integration credentials are also attack paths. Use per-environment short-lived identity with only required write access to the intended destination. Protect transport and destination identity, rotate and revoke, monitor unusual use, and avoid embedding credentials in images or outputs. Test destination outage and credential expiry without changing to unauthenticated or broadly privileged fallback.

Govern exceptions, metrics, cost, and privacy

Some infrastructure workloads need privileges ordinary applications must not receive. A runtime sensor may require host or kernel access. Create an exact exception: namespace, ServiceAccount, verified image digest, workload kind and name, node placement, capabilities, host mounts, purpose, owner, approval, compensating controls, monitoring, expiry, and revocation. Ensure tenant users cannot modify the namespace labels, assume the identity, change the image, or schedule an arbitrary workload onto the privileged nodes.

Balanced program metrics cover visibility, response, and control quality. Track critical assets with current sensor, admission and audit evidence; unknown and stale coverage; positive detection-test success; dropped events; alert-to-case conversion; confirmed and benign disposition; duplicates; time to triage, contain, recover, and close; prevented high-risk admissions; reduced effective entitlements; expired exceptions; recurrence; and ownerless assets. Avoid rewarding teams merely for finding more issues or suppressing more alerts.

Runtime telemetry can be expensive. Measure raw events before filters, alerts after rules, field and label cardinality, queue bytes, retained storage, ingestion, egress, dashboard queries, and analyst time. Filter near the source when it is safe, but test every change against detection fixtures. Aggregate metrics, use short default retention, and retain richer evidence for high-risk assets or an authorized incident. Sampling without coverage metrics can hide the events a rule needs.

Process arguments, environment values, file paths, network names, Kubernetes audit bodies, and identity claims can contain credentials or personal data. Prefer event type, process identity, hashes, bounded allowlisted fields, and redacted context. Separate access to raw evidence from ordinary dashboards. Define purpose, retention, deletion, legal hold where applicable, and access audit. Escalate sensitive capture only under an authorized incident procedure.

Design multi-cluster and multi-cloud correlation carefully

A fleet dashboard should answer operational questions: Which critical public workloads have broad effective identity and unexpected runtime behavior? Which clusters have stale audit or sensor coverage? Which artifact digests lack approved provenance? Which exceptions expire soon? Which principals can escalate through workload creation? Which response owner and runbook apply?

Do not flatten every platform into one lowest-common-denominator claim. Preserve cluster type, managed responsibility, Kubernetes version, operating system, network plugin, runtime, kernel, Pod Security version, benchmark profile, audit configuration, event source, unsupported controls, and provider-specific identity semantics. A managed control that customers cannot inspect should be labeled as provider-managed or unknown according to available evidence, not automatically passed.

Use the public CIS Kubernetes Benchmark overview to select the applicable benchmark and version. CIS publishes distinct benchmarks for Kubernetes and managed distributions. Record automated versus manual checks and exact applicability. Do not copy marketplace summaries or treat benchmark conformance as proof that applications, identities, or runtime behavior are secure. Posture is one part of the risk model.

When cloud-provider-native security controls are used, rely on current official provider documentation and record shared responsibility, supported cluster types, regions, data handling, identity permissions, export behavior, cost, and cleanup. This practical path does not require provider services; synthetic external roles and local evidence keep the projects reproducible and vendor-neutral.

Three projects that connect the full lifecycle

Hardened container build and admission pipeline

The first CNAPP runtime security project creates a tiny synthetic service and one immutable image. It generates digest-linked SBOM and vulnerability evidence, signs the digest, creates SLSA provenance, and defines verification policy for artifact subject, signer identity, issuer or trust root, source, builder, and workflow. Review-time policy renders manifests, while cluster admission validates the final object after mutation.

The project enforces restricted workload settings, a dedicated ServiceAccount, no unnecessary token, minimal Secrets, default-deny ingress and egress, and tested DNS and application paths. It injects tag mutation, altered evidence, unauthorized signing, admission outage, certificate failure, policy regression, and executable drift. It measures build minutes, registry and evidence storage, admission latency, and retention, then deletes all workloads, policies, registry content, attestations, identities, keys, logs, and the cluster.

Falco runtime detection and response lab

The second project documents the exact kernel, runtime, Falco and driver versions and hardens the sensor's capabilities, host mounts, placement, identity, and BPF access. Local rules detect an unexpected shell, dummy token-like file access, inert executable creation, package activity, and connection to a local canary. Positive and benign fixtures validate rule behavior. A maintenance Job drives narrow, expiring exception design rather than global suppression.

A bounded local receiver tracks source capture, dropped events, output queue, delivery, duplicates, and case creation. Failure injection removes a sensor, creates event pressure, breaks a rule, stops the receiver, denies response RBAC, and delays ingestion. A human-approved harness contains only the exact lab target, preserves evidence, rolls back, and validates recovery. Cleanup includes DaemonSets, host mounts, rules, BPF objects or pins created by the lab, receivers, evidence, identities, cluster, processes, and ports.

Multi-cluster evidence dashboard and incident tabletop

The third project creates three disposable cluster contexts representing development, production, and a second trust domain. Read-only collectors gather inventory and posture without Secret contents. An entitlement graph models direct RBAC, sensitive verbs, workload creation, namespace service accounts, projected tokens, and synthetic external roles. Admission, audit, runtime and sensor-health records retain source provenance and join through stable compound identities.

The dashboard displays pass, fail, exception, unknown, and stale states. It prioritizes findings using asset criticality, exposure, effective access, artifact evidence, runtime behavior, and compensating controls. It tracks coverage, dispositions, response time, duplicate rate, exceptions, drift, retention, and cost. The tabletop correlates a safe shell, dummy token-path read, novel local egress, broad identity, and public synthetic Service, then records hypotheses, confirmed facts, approved containment, fleet scope, trusted redeployment, regression, and cleanup.

An eight-week implementation plan

1. Week 1: Read NIST and CNCF guidance; define trust boundaries, responsibilities, stable inventory keys, evidence states, and safety rules.
2. Week 2: Build once by digest; generate SBOM and vulnerability evidence; sign; create SLSA provenance; write exact verification and exception policy.
3. Week 3: Implement review checks and final-object admission; enforce Pod Security, least-privilege ServiceAccounts, Secrets controls, and tested NetworkPolicy.
4. Week 4: Build direct and transitive RBAC and workload-identity graphs; normalize three cluster contexts; map applicable CIS benchmark versions and coverage.
5. Week 5: Learn eBPF hooks and verifier scope; deploy and harden Falco; create positive and benign runtime fixtures; monitor event loss and output health.
6. Week 6: Build behavior chains, evidence preservation, human-approved containment, node and credential response, and recovery regression tests.
7. Week 7: Design audit and runtime pipelines for bounded failure, privacy, stable joins, exceptions, coverage, detection quality, response metrics, and cost.
8. Week 8+: Complete all 50 original checks, review 40 flashcards, build all three projects, publish limitations, and verify teardown.

Common cloud-native runtime security mistakes

• Buying before modeling. Define assets, threats, responsibilities, evidence, and response questions first.
• Using names as global identity. Join with provider, account, cluster UID, namespace, workload UID, container and digest.
• Leaving stale posture green. Missing current evidence is unknown or degraded, not secure.
• Ranking only by vulnerability severity. Add exploit preconditions, exposure, effective access, behavior, controls, and impact.
• Trusting mutable tags. Bind artifact, policy, evidence and runtime state to the digest.
• Accepting any signature. Verify expected identity, issuer or trust root, source, builder, workflow, and subject.
• Checking only CI manifests. Enforce final mutated objects at admission.
• Assuming admission protects reads. Secret reads require authorization, isolation and audit.
• Calling namespaces complete isolation. The kernel, nodes, control plane and network remain shared boundaries.
• Looking only for direct RBAC. Model workload creation, service accounts, bind, escalate, proxy, token and webhook paths.
• Creating ingress-only default deny. Egress remains open until independently isolated.
• Calling base64 encryption. Protect Secret storage, access, delivery, use, logs and rotation.
• Calling eBPF automatic security. The verifier does not prove detection quality, coverage or least privilege.
• Tuning by global process name. Use narrow workload context with owner, expiry and regression tests.
• Ignoring dropped events. Sensor, capture, rule and delivery health are security signals.
• Deleting the Pod and closing. Revoke authority, inspect persistence and equivalent scope, restore trusted state and validate recovery.
• Collecting everything forever. Minimize sensitive fields, cardinality and retention according to threat and investigation needs.
• Calling a dashboard compliance. Dashboards summarize evidence and gaps; they do not attest to complete security or legal compliance.

Present portfolio evidence honestly

A strong portfolio starts with the problem and trust model. Include asset and identity schema, threat boundaries, responsibility matrix, artifact evidence chain, admission and Pod policy, RBAC escalation graph, network reachability tests, Secret decisions, Falco rules and fixtures, sensor-health and dropped-event evidence, normalized event schema, exception workflow, incident timeline, containment approval, recovery tests, metrics, cost and privacy model, and cleanup report.

State what the projects do not prove. A local cluster does not prove fleet-scale reliability or managed-provider integration. A synthetic role graph does not prove every provider entitlement semantic. A successful Falco rule does not prove all kernels and workloads are observable. A signed test image does not prove organization-wide identity governance. A short tabletop does not replace practiced production incident response. Honest boundaries make the demonstrated work more credible.

Relevant roles include cloud security engineer, Kubernetes security engineer, container security engineer, detection engineer, DevSecOps engineer, platform security engineer, cloud incident responder, software supply-chain engineer, and security-focused SRE. Explore cloud and security roles, but treat the projects as discussion evidence rather than a hiring or compensation guarantee.

Primary official references

• NIST SP 800-190 — Application Container Security Guide
• CNCF Cloud Native Security Whitepaper
• CNCF Cloud Native Security Map
• Falco documentation
• Falco rules concepts
• Falco dropped syscall events
• eBPF on Linux documentation
• eBPF verifier documentation
• Kubernetes Pod Security Standards
• Kubernetes RBAC good practices
• Kubernetes NetworkPolicy
• Kubernetes Secrets good practices
• Kubernetes admission control
• Kubernetes auditing
• Kubernetes Linux kernel security constraints
• CIS Kubernetes Benchmark public overview
• OpenSSF SBOM Everywhere guide
• SLSA specification v1.2
• Sigstore documentation
• CISA Kubernetes hardening guidance

Continue the practical path

• CNAPP & Cloud-Native Runtime Security eight-week roadmap
• All PrepKloud practical roadmaps
• 50 original CNAPP and runtime security knowledge checks
• 40 CNAPP and runtime security flashcards
• Three complete hands-on projects
• Cloud-Native Platform Engineering roadmap
• Software Supply-Chain Security guide
• GitOps with Argo CD and Flux guide
• OpenTelemetry Observability Engineering guide
• Cloud, Kubernetes, security, DevSecOps, and SRE roles
• PrepKloud editorial policy

Frequently asked questions