Runtime and cloud defense
Review workload identity, cluster boundaries, configuration drift, exposed APIs and incident evidence.
- Separate identity acquisition, workload privilege and business authorization.
- Evaluate effective network/route policies and deployed drift.
- Turn delayed runtime events into bounded investigation and containment evidence.
- Read basic cloud role, Kubernetes and HTTP configuration.
- All guides provide symbolic identities and observations; a cluster or cloud account is not required.
Estimated time: about 6–7 hours across 13 steps, including 3 browser labs.
By the end: A runtime boundary dossier with identity, pod, managed-cluster, network, API, detection and incident decisions plus a tested admission-policy repair.
0 of 13 steps complete
Apply the supplied trust and permission rules separately to each identity and object operation.
Keep: A principal → role → resource decision table.
Complete when: Explain wrong audience, wrong subject, missing allow and explicit deny as distinct causes; follow indirect authority through pipeline changes.
Open guide : Review cloud permissions and role trust togetherCompare pod and service-account repairs against the exact ConfigMap/cache requirements.
Keep: A field-to-requirement map and workload acceptance table.
Complete when: The design removes host/API excess without breaking legitimate startup and the named read; non-root alone is not the whole boundary.
Open guide : Run Kubernetes workloads with only the privileges they needRun the browser lab on ordinary, privileged and alternate-container fixtures. Relate each predicate to the earlier workload contract.
Keep: A repaired policy with actual positive/negative results.
Complete when: The valid workload remains admissible and the lab’s init/ephemeral or privilege bypasses fail; list cluster/runtime checks outside the lab’s scope.
Open lab : Privileged container lab: Reject a privileged workload before deploymentApply the guide's shared-responsibility split to one EKS, AKS or GKE cluster and run kube-bench against that service's CIS benchmark.
Keep: A cluster checklist with kube-bench results and each exception you accept, with its reason.
Complete when: API endpoint access, node updates, pod cloud identity and Pod Security each have an owner and a verified setting.
Open guide : Harden managed Kubernetes on EKS, AKS and GKEEvaluate both network policies, then compare selector intersection with separate alternative peers. Keep image admission separate.
Keep: A source/port connection matrix and signer decision.
Complete when: Remove the broad allow that defeats isolation; an empty rule set cannot subtract another policy’s permission.
Open guide : Prove network and admission policies enforce the intended boundaryClassify the policy fixtures and follow the supplied console-edit timeline.
Keep: A drift record joining source, plan, live rule, time and exception scope.
Complete when: A source pass does not dismiss live public exposure; unknown values and expired exceptions receive explicit non-pass decisions.
Open guide : Test infrastructure policy and detect security-relevant driftTrace the same invoice through the gateway, legacy listener, internal route and shared cache.
Keep: A route/caller inventory and separate identity/cache repairs.
Complete when: DNS removal is not accepted as listener closure, and backend authorization cannot fix a private response already served from shared cache.
Open guide : Maintain an API inventory and prevent gateway bypassCalculate the supplied GraphQL costs and trace role revocation and RPC cancellation.
Keep: A query budget and persistent-operation decision table.
Complete when: Distinguish request count from work, transport identity from current action authority, and client timeout from actual resource release.
Open guide : Apply security limits to GraphQL, WebSocket and gRPC operationsUse the guide's Falco rule example to write a rule for an attack you expect, such as a pod calling the metadata service, and trigger it in a test cluster.
Keep: A rule with the event fields it needs, the command that triggered it and the narrow exceptions you added.
Complete when: The rule fires on the simulated attack, ordinary workload behavior does not trigger it, and no stable rule was switched off to quiet it.
Open guide : Detect container and host threats at runtime with eBPF sensors and cloud servicesOrder the supplied events by their documented time/causal evidence, deduplicate them and compare the permission change with its approval.
Keep: An incident note separating observed effects, inferred risk and missing download evidence.
Complete when: Do not call a started export completed or unknown retrieval absent; closure addresses both authority and the produced object.
Open guide : Turn runtime events into a tested investigation and containment pathRun the NetworkPolicy lab: write a default-deny ingress policy for shop, allow each required flow with namespace and pod selectors in one peer and a named port, and block the database's egress with an explicit Egress policy type.
Keep: The namespace's policy set with the lab's passing connection cases.
Complete when: The four application flows work, while pods in other namespaces, look-alike labels, extra ports and the database's own outbound connections are refused.
Open lab : NetworkPolicy lab: Lock down a shop namespaceRun the IAM trust-policy lab: enforce the Condition keys (sts:ExternalId, aws:SourceArn, aws:SourceAccount) and honour an explicit Deny in a model trust-policy evaluator.
Keep: A repaired trust-policy evaluator with the lab's passing cases.
Complete when: A third party without the external id, a service principal with a foreign SourceArn or SourceAccount, and an explicitly denied principal are all denied, while legitimate assumes still succeed.
Open lab : IAM trust policy lab: Evaluate a role trust policy against the confused deputyClassify the seven records in the guide’s zone export, then order the fixes so no takeover window opens.
Keep: A record-by-record table with the classification, fix and order, plus corrected cookie, CORS and OAuth settings.
Complete when: Explain why NS delegations are the most serious, and how IaC dependencies delete the record before the resource.
Open guide : Prevent subdomain takeover from dangling DNS recordsProve an isolated export worker stays isolated
Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.
Your export worker should read one tenant store and write to one output service. Determine whether the intended policy is actually enforced.
Supplied material
Workload export-worker in namespace jobs uses service account exporter. Required: non-root, no host namespaces, read-only root filesystem, DNS and TCP/443 access to output only.
Manifest requests runAsNonRoot=true but hostPID=true. Admission policy is configured in audit mode.
NetworkPolicy P1 allows only output:443. P2 in the same namespace selects the same worker and allows all egress. Network policies are additive.
Cloud role trust accepts any service account in namespace jobs. Role permissions allow GetObject for every tenant prefix and PutObject for output/*.
Gateway requires an authenticated tenant claim; origin service also has a public listener that trusts X-Tenant sent by callers.
GraphQL export query asks for 20 reports × 30 attachments; each attachment costs one unit and each report costs one. Budget is 500 units.
Logs: 10:00 new worker starts; 10:01 role assumed by jobs/debug; 10:02 direct-origin request with X-Tenant:south; 10:03 unusual object reads. Logs identify actor, request ID and artifact revision but include no credential values.Work through the case
Write an intended-vs-effective boundary table for admission, network, cloud identity, origin access and resource cost.
Calculate the query cost and identify which control denies the request before fan-out.
Design actual allow/deny probes, including a positive output connection and a blocked unapproved destination.
Create a containment and evidence plan from the timeline without claiming the events alone prove all read content.
Decide the fixed cases
These parts of the case have one right answer, taken from the worked assessment. Check them here; the rubric below assesses your written reasoning. The capstone meets the bar when every decision is right and the self-check reaches it.
The GraphQL export query
Is each control effective as configured?
Evidence to retain
- Five-boundary policy diff.
- Cost calculation with enforcing checkpoint.
- Probe plan naming cluster/CNI, identities, endpoints and expected outcomes.
- Timeline, corroborating evidence requests and containment order.
Assess your work
Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.
Score your answer against the anchors
Choose the anchor that matches your answer for each criterion.
Recorded checks stay in this browser only, so you can compare attempts. This is a self-assessment, not a certification.
Compare with the worked assessment
The effective configuration is unsafe: hostPID remains admitted in audit mode; P2 broadens egress despite P1; jobs/debug can assume the role; the origin trusts caller-selected tenancy; the query costs 20+20×30=620 and exceeds 500. Enforce admission, remove or narrow the broad egress selection, bind role trust to the intended workload and permissions to necessary prefixes, and require origin authentication with trusted tenant context. Test against the installed cluster/CNI rather than treating YAML as proof. Preserve role and application event records, revoke the debug path and isolate the public origin while verifying legitimate worker operation. Correlate object access records before stating exact data exposure.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Implementation option: Verify Kubernetes admission and network boundaries
Repair the warning-only admission binding and the overbroad ingress rule until the 12 offline tests pass, then, if you can run Docker and kind, apply them to the disposable cluster and run verify-cluster.mjs.
Keep: Offline test output, and for the live path the tool versions, CNI rollout output and verify-cluster.mjs output showing both allowed and denied probes.
Node.js 22+ offline · kind/Docker/kubectl for live cluster · 45–60 min · 12 tests
Other connected projects
- Repair a real proxy and shared cache — Node.js 22+ · loopback servers · no dependencies
AppSec in practice
Review a system, build a test plan, and carry a finding through to verified remediation.
Your progress, your browser
Progress is stored on this device. Export it to carry it to another browser, or clear it whenever you want. Importing a file adds its completed items to the progress already here; items this site no longer offers are skipped and counted, and nothing else is removed.