Amazon Cybersecurity Engineer (Staff Level) - Comprehensive Interview Preparation Guide

Detection-to-Action Overview

• I design a pipeline: real-time sensor → decision engine → orchestrator → quarantine action. Sensors (eBPF/Falco + runtime telemetry + CNI flow logs + IDS signatures) emit normalized events to Kafka. A rules/ML scoring service (SigStore for provenance, custom anomaly model) scores compromise likelihood and publishes events with confidence and context.

Orchestration & Leader Election

• Per-cluster controller (K8s controller running as Deployment) subscribes to events. Use Kubernetes Lease API for leader election so only one active reconciler performs cluster-level actions. For multi-cluster coordination, a global coordinator uses an external election backed by etcd/Consul with session leases (TTL) so a single region leader orchestrates cross-cluster quarantines.

Safety Checks to Avoid Mass Outages

• Multi-stage gating:
  • Confidence threshold + anomaly correlation across signals (not single-sensor).
  • Impact simulation: check pod replicas, HPA, service endpoints, and health-probes. Block quarantine if quorum of endpoints would drop below SLA.
  • Canary mode: first isolate one pod on a given node/az; observe 1–3 probe intervals.
  • Rate limiting & circuit breaker per-namespace and global; suspend automated actions on error spike.

Quarantine Action & Rollback

• Quarantine steps (idempotent):
  1. Mark Pod with quarantine annotation/label + admission-exclude to stop scheduling new traffic.
  2. Apply NetworkPolicy to deny ingress/egress for pod selector.
  3. Move traffic via Service routing: add header-based routing to redirect to healthy replica or apply weighted routing through Istio/Envoy.
  4. Snapshot pod state, image digest, metadata to immutable store.
• Rollback:
  • Automated rollback if health checks fail (failed readiness > threshold) or false-positive whitelist match; use recorded snapshot to restore labels and remove NetworkPolicy. Reconciliation controller verifies state and retries with exponential backoff.

Audit Trails & Forensics

• Every decision and action is logged to append-only storage (WORM) — e.g., write-ahead events to Kafka + ElasticSearch with signed event blob (SigStore) and SHA256. Include actor, rule IDs, confidence, playbook run, cluster, resourceVersion, leader ID. Store artifacts (core dump, network pcap) in secure object storage with retention policy and access controls.

Handling Race Conditions & High Load

• Idempotency: actions keyed by event ID + resourceVersion. Use optimistic concurrency control: read resourceVersion, patch with precondition; if mismatch, requeue event.
• Dedup & de-bounce: coalesce events by pod ID and time window in the decision service.
• Work queues: controller-runtime RateLimitingInterface with sharded workers per namespace; backpressure via Kafka consumer groups.
• Distributed locks: etcd/Lease or Consul sessions to coordinate cross-cluster operations; leader verifies lease before final destructive action.
• Throttling: global tokens to limit concurrent quarantines; fallback to manual approval when threshold reached.

Validation, Testing & Metrics

• Chaos tests: simulate false positives and network partitions. Create SLOs: time-to-quarantine, false-positive rate, restore time. Expose metrics and alerts for actions blocked by safety checks.

Why this works: combining multi-signal detection, leader-elected orchestration, conservative safety gates, idempotent operations, and strong auditability balances rapid containment with service continuity and forensic integrity.

Direct answer

Removing multi-factor authentication (MFA: requiring a second proof of identity beyond a password) outright trades away real protection against credential-stuffing and phishing for a conversion gain. The better move is usually risk-based step-up authentication: ask for the second factor only when a login looks unusual (new device, new location, impossible travel), not on every login.

Structured elaboration

Always-on MFA: strongest protection against stolen-password takeovers, but friction on every login costs some drop-off.

No MFA: zero friction, but any leaked or guessed password is a full takeover.

Risk-based step-up: most takeover attempts come from a new device, location, or IP, so triggering the second factor only there catches most of the risk while leaving most legitimate logins frictionless, at the cost of building and maintaining a risk-scoring signal.

Worked example

2,000,000 logins a month, 3% historically from a new device or location, a stated assumption for this exercise:

$\text{risky logins} = 2{,}000{,}000 \times 0.03 = 60{,}000$

Always-on MFA adds friction to all 2,000,000 logins; risk-based step-up adds it to roughly 60,000 (3%), while still covering where most takeover attempts land, since an attacker is by definition logging in from a device the real user hasn't used before.

Trade-offs and pitfalls

Risk-based MFA is only as good as its signal: an attacker who steals a session, or reuses the victim's usual IP, evades the trigger entirely. If the fallback for a failed second factor is a weak recovery flow, the vulnerability just moved.

What the interviewer probes next

What signals you'd use to score login risk, how you'd measure whether step-up MFA reduces takeover incidents rather than just complaints, and how you'd keep account recovery from becoming a weaker back door.

Approach summary
I’d build a supervised binary classifier that predicts P(weaponized within 30 days) using heterogeneous features (numeric, text, time-series) and a calibration layer for risk thresholds. Use ensembles (e.g., gradient-boosted trees + temporal neural net) for accuracy and a SHAP-based explainability pipeline.

Features

• CVSS vector: base scores, vectorized metrics (attack vector, complexity, privileges).
• Temporal signals: days since disclosure, vendor advisory lag, patch availability.
• Threat-intel signals: counts/timestamps of exploit mentions on forums, paste sites, GitHub, exploit-db.
• Victim surface: target software popularity (downloads, market share), internet-exposed asset counts (Censys/ZoomEye).
• Historical context: prior-exploit history for same vendor/CVE family, exploit PoC availability.
• Meta: CVE description embeddings, exploit author reputation scores.

Labeling

• Positive if credible exploit observed in 30 days (exploit-db entry, confirmed in telemetry, public PoC) — use multi-source triangulation to reduce noise.
• Negative if no exploit within 30 days; include censoring for later exploitation (use survival-analysis-informed labels).

Evaluation

• Metrics: Precision@k, ROC-AUC, PR-AUC, FDR at operational thresholds, time-to-first-exploit survival curves, calibration (Brier score).
• Use temporal cross-validation (walk-forward) to prevent leakage.

Deployment & concerns

• Data drift: monitor feature distributions, model performance, and retrain periodically; use online learning for fast signal sources.
• Explainability: SHAP + textual rationale for SOC; expose top contributing features and counterfactuals.
• Operational: false-positive cost tuning, latency for near-real-time ingest, provenance and privacy for threat feeds, adversarial robustness (poisoning of forum signals).

Situation & Task
At my previous company we built a new customer data ingestion service (PII at rest) with aggressive time-to-market. I was asked to embed a secure-by-design control to protect PII and meet regulatory requirements without delaying launch.

Action
I influenced the design decision to adopt field-level encryption with envelope encryption (KMS-backed data keys) rather than full-disk or app-level obfuscation. Steps I took:

• Drafted a short threat model (data flow, trust boundaries, attacker goals) and presented risks to product and infra.
• Specified encryption requirements (AES-256-GCM per-field, key rotation every 90 days, access via IAM roles).
• Implemented a lightweight SDK hook in ingestion pipeline to perform encrypt/decrypt with the org KMS; added automated unit tests and local emulator support.
• Automated CI checks to ensure no PII committed in cleartext by scanning builds and running integration tests in a staging environment.

Result / Validation
Validated via:

• Pentest focused on data-at-rest controls (zero findings on key handling).
• Automated test coverage and CI scanning reduced incidents of exposed secrets to zero in the first 12 months.
• Performance impact under load tests: <5% latency increase, acceptable to product.

Lessons Learned

• Early threat modeling accelerates stakeholder buy-in.
• Provide developer-friendly SDKs and local emulation to avoid workarounds.
• Bake automated checks into CI to keep controls enforceable. I applied these patterns to subsequent services, accelerating secure deployments without blocking feature velocity.

Why image/container scanning matters
As a cybersecurity engineer I treat image scanning as an essential control in a defense-in-depth CI/CD and runtime security strategy. Scanning prevents known vulnerabilities, enforces configuration hygiene, reduces blast radius from leaked secrets, and avoids deploying unsupported or outdated base images that carry systemic risk. Automated scans shift-left, provide fast feedback to developers, and enable policy-based blocking or quarantining downstream.

Classes of issues and where to scan

• Vulnerable packages (CVEs): scan at build (fast fail) and registry-on-push (supply-chain gate). Runtime scans (periodic) detect new CVEs discovered after deployment.
• Misconfigurations (e.g., excessive capabilities, unsafe ports, exposed credentials in Dockerfile): detect during build and at admission (Kubernetes admission controller enforces policies before scheduling).
• Embedded secrets (API keys, private keys): detect at build and registry-on-push to prevent artifact storage; also scan CI logs and artifacts. Runtime scanning helps find secrets introduced via image updates.
• Outdated base images (EOL OS, old language runtimes): detect at build and registry-on-push; runtime/periodic scans identify images still running that need rebuilds.

Why stage placement matters

• Build: fastest developer feedback and cheapest remediation.
• Registry-on-push: central enforcement, audit trail, and blocking of non-compliant images.
• Admission: cluster-level enforcement preventing risky images from running.
• Runtime: continuous detection for newly discovered threats or drift.

This combination ensures early detection, supply-chain integrity, and ongoing runtime protection.

Direct answer

When a security or compliance team has the authority to block work and uses it, the goal isn't to overpower them, it's to give them a way to say yes that they would defend to their own leadership. That means understanding the actual concern, proposing controls that address it directly, and building a record that makes the eventual approval easy to justify upward, rather than skipping the concern to hit a deadline.

Structured elaboration

1. Understand the veto, not just the outcome

Ask what specifically drives the block: a known threat pattern, a regulatory obligation, a past incident. A block framed as 'this is too risky' usually decomposes into something concrete once you ask what evidence would change their mind.

2. Propose compensating controls, not blanket reassurance

Bring specific mitigations that map to the stated concern: scoped access, monitoring, a rollback plan, data masking, a smaller blast radius. 'Trust me' rarely moves a team whose job is to not just trust people; a control they can point to in an audit does.

3. Phase the ask so risk and trust build together

Instead of asking for full approval up front, propose a smaller, monitored first step, then expand once it holds up. This gives the blocking team evidence rather than a promise, and it gives you a faster initial yes.

4. When you need executives to sponsor it, not just the compliance team to approve it

Sometimes getting to yes isn't about convincing the blocking team at all, it's about persuading senior executives, without formal authority over them, to sponsor a security or compliance investment that trades short-term revenue for long-term risk reduction. That's a different move: build the case in terms an executive already weighs (the cost of the exposure versus the cost and timeline of the fix), find a credible sponsor who already has their ear, and time the ask to a moment they're already thinking about risk, such as a renewal, an audit, or a near-miss. State the trade-off plainly rather than downplaying either the revenue impact or the risk.

5. When the conflict runs the other direction

The pressure isn't always compliance blocking a launch. Sometimes compliance demands collecting more data for audit purposes, and that request conflicts with the team's own privacy commitments to users. Handle this the same way: scope exactly what the audit requirement needs, then look for a way to satisfy it without violating the privacy commitment, such as aggregating instead of storing per-user data, sampling instead of full capture, or purpose-limited access with automatic expiry. If a genuine conflict remains after that, escalate it as a policy conflict for someone empowered to decide between the two obligations, rather than either side unilaterally overriding the other.

Worked example

A security team initially blocks a new integration on a financial product, citing customer-data exposure risk. Working sessions with security and the app owner map the specific risk to two things: a broad data scope and no kill switch. The team proposes scoped test accounts, data masking, and a remote kill switch, then agrees to a phased rollout: verify the low-risk paths first, escalate to the higher-risk ones only after the first phase holds up under monitoring. Security signs off on the phased plan. Separately, when the same team later wants to expand data collection to satisfy a new audit requirement, they find that a sampled, time-limited collection window satisfies the auditors just as well as full, indefinite collection, so the privacy commitment to users doesn't have to give.

Trade-offs and pitfalls

• Working around a block quietly (shipping a smaller version without telling the blocking team) buys short-term speed and damages the relationship you will need next time; always close the loop even when you find a narrower path.
• Compensating controls that never get revisited become permanent scaffolding; agree upfront on when the phased approach graduates to full trust, not just how it starts.
• On the upward-influence path, leading with fear rather than a clear trade-off tends to get budget approved once and then quietly deprioritized later, because the executive never actually weighed the cost against the risk. Naming the trade-off explicitly is what makes the commitment durable.
• Overriding a genuine policy conflict (audit needs versus privacy commitments) unilaterally, instead of escalating it, tends to resurface as a bigger trust problem with users or regulators later than the original block would have cost in time.

Direct answer

Sequence the 90 days by cost and reversibility, not by theoretical risk alone: week one is discovery and the cheapest, lowest-risk wins (closing overly broad network ingress and dead services nobody will miss), the middle weeks tackle IAM (Identity and Access Management) and registry hardening that needs testing before enforcement, and the final weeks lock in prevention (guardrails that stop the surface from creeping back) rather than just one-time cleanup. Track progress with a single weighted attack-surface score computed from counts across the five categories (network exposure, IAM, unused services, container registries, third-party integrations), so "reduced exposure" is a number that goes down, not a subjective claim.

Structured elaboration

Discovery first (days 1-10, prerequisite to everything else)

Before touching anything, inventory each category with existing tooling: security-group and route-table exports for network exposure, IAM Access Analyzer and policy-simulator output for over-permissive policies, a CloudTrail-based usage query (which resources have zero API calls or traffic in the last 90 days) for unused services, registry access logs for container registries, and the org's vendor/API-key inventory for third-party integrations. This inventory is also what makes the plan's "quick wins" genuinely quick: closing something before confirming nobody depends on it is how a hardening plan turns into an outage.

Days 1-30: quick wins, chosen for low blast-radius

• Network exposure: close security-group rules allowing 0.0.0.0/0 ingress on any port that is not deliberately public (HTTP/HTTPS on a load balancer), replacing them with scoped CIDR ranges or a bastion/VPN path. This is the highest-leverage quick win because a broad ingress rule with zero legitimate traffic in the discovery data is almost always safe to close immediately.
• Unused services: decommission the zero-traffic resources found in discovery (idle EC2 instances, orphaned load balancers, stopped-but-not-terminated instances still holding public IPs). Low risk because "zero traffic for 90 days" is itself the safety check.
• Container registries: require authentication for all image pulls; a registry that allows anonymous or unauthenticated pull is a quick, low-disruption fix since legitimate consumers already have credentials.
• Third-party integrations: revoke API keys and OAuth grants for integrations discovery shows are no longer in active use.

Days 31-60: changes that need validation before enforcement

• IAM policies: this is the category quick wins should NOT touch directly, because a wildcard Action: "*" policy attached to something actively in use will break it the moment it is tightened. The 30-day process is: generate least-privilege policy replacements from IAM Access Analyzer's actual-usage data, deploy them in a non-blocking audit/simulate mode, review what the tightened policy would have denied over a full business cycle (to catch monthly or quarterly jobs discovery's shorter window might miss), then switch to enforcing.
• Container registries, phase two: add image scanning at push time and quarantine images with critical known vulnerabilities, which needs a grace period and a remediation path for teams with existing non-compliant images rather than an immediate hard block.
• Third-party integrations, phase two: for integrations still in active use, move from standing, broadly-scoped credentials to short-lived, narrowly-scoped ones where the vendor's API supports it, coordinated with each integration's owning team since this can require code changes on their side.

Days 61-90: guardrails that prevent the surface from creeping back

A cleanup with no prevention step regresses within a quarter as new resources get provisioned the old way. Close the loop with: a policy-as-code check (for example, an AWS Config rule or a pre-deploy IaC scan) that blocks new 0.0.0.0/0 ingress rules and new wildcard IAM policies from being created at all, an automated 90-day idle-resource report that runs on a recurring schedule instead of a one-time discovery pass, and a lightweight approval gate for any new third-party integration request so standing credentials are scoped correctly from day one instead of retrofitted later.

Applying the same reduction methodology to a heavily-exposed API gateway

The same design-time versus runtime split applies at a finer grain to a gateway exposing several hundred endpoints, which is a common concentrated instance of "network exposure" above: design-time reduction means not exposing more than the client actually needs (deprecating unused endpoint versions, consolidating near-duplicate routes, requiring every route to declare an explicit authentication/authorization requirement rather than defaulting to open, and removing debug/introspection endpoints from production builds); runtime reduction means constraining what a request can do once it reaches an endpoint that must stay exposed (per-route rate limiting, a web application firewall rule set scoped to that route's expected input shape, and request-size/schema validation at the edge before the request reaches application code). Both are attack-surface reduction; the design-time work shrinks the count of things that could go wrong, and the runtime work bounds the damage from the ones that remain exposed by necessity.

Worked example

A weighted attack-surface score makes "reduced exposure" measurable instead of a narrative claim. Assign each finding category a severity weight (illustrative, 1-5 scale, reflecting relative blast radius if that class of finding is abused) and count instances before and after the 90-day plan:

$\text{score} = \sum_{\text{category}} \text{weight} \times \text{count}$

Working the sum out term by term:

$\text{score}_{\text{day 0}} = 40(3) + 15(5) + 25(2) + 3(4) + 10(3) = 120 + 75 + 50 + 12 + 30 = 287$

$\text{score}_{\text{day 90}} = 8(3) + 3(5) + 5(2) + 0(4) + 4(3) = 24 + 15 + 10 + 0 + 12 = 61$

$\text{reduction} = \frac{287 - 61}{287} = 78.7\%$

The same computation as a script, which is the form that matters because the point of scoring this way is rerunning it on a cadence against real counts:

# Weighted attack-surface score. Weights are 1-5 by relative blast radius;
# counts are illustrative planning assumptions, not measurements.
FINDINGS = [
    # (category,                                        weight, day_0, day_90)
    ("Security groups allowing 0.0.0.0/0 ingress",           3,    40,     8),
    ("IAM policies with wildcard actions/resources",         5,    15,     3),
    ("Unused/orphaned running services",                     2,    25,     5),
    ("Container registries allowing unauthenticated pull",   4,     3,     0),
    ("Third-party integrations with standing prod creds",    3,    10,     4),
]

def score(findings, day):
    idx = 2 if day == 0 else 3
    return sum(w * f[idx] for f in findings for w in [f[1]])

d0 = score(FINDINGS, 0)
d90 = score(FINDINGS, 90)

print(f"{'category':52s} {'w':>2s} {'d0':>4s} {'d90':>4s} {'w*d0':>5s} {'w*d90':>6s}")
for name, w, a, b in FINDINGS:
    print(f"{name:52s} {w:2d} {a:4d} {b:4d} {w*a:5d} {w*b:6d}")
print(f"\nscore day 0  = {d0}")
print(f"score day 90 = {d90}")
print(f"reduction    = ({d0} - {d90}) / {d0} = {(d0 - d90) / d0:.3f}  ({(d0 - d90) / d0 * 100:.1f}%)")
print("\nper-category reduction (why the aggregate alone is not enough):")
for name, w, a, b in FINDINGS:
    print(f"  {name:52s} {(a - b) / a * 100:5.1f}%")

Output:

category                                              w   d0  d90  w*d0  w*d90
Security groups allowing 0.0.0.0/0 ingress            3   40    8   120     24
IAM policies with wildcard actions/resources          5   15    3    75     15
Unused/orphaned running services                      2   25    5    50     10
Container registries allowing unauthenticated pull    4    3    0    12      0
Third-party integrations with standing prod creds     3   10    4    30     12

score day 0  = 287
score day 90 = 61
reduction    = (287 - 61) / 287 = 0.787  (78.7%)

per-category reduction (why the aggregate alone is not enough):
  Security groups allowing 0.0.0.0/0 ingress            80.0%
  IAM policies with wildcard actions/resources          80.0%
  Unused/orphaned running services                      80.0%
  Container registries allowing unauthenticated pull   100.0%
  Third-party integrations with standing prod creds     60.0%

Every count in this table is an illustrative planning assumption, not a measured figure from any real environment; what the example demonstrates is the METHOD (a weighted, category-broken-down score that can be recomputed on any real cadence) rather than a specific number to expect. The same formula run monthly turns "we reduced exposure" into a number a security leader can put in front of a board, and the per-category breakdown (rather than one aggregate figure) is what tells engineers which of the five categories still needs work.

Trade-offs and pitfalls

• Sequencing quick wins before validated changes is deliberate, not laziness. Closing broad network ingress and dead services first builds momentum and trust with stakeholders before asking teams to accept the riskier, validation-heavy IAM and credential-rotation work; doing IAM tightening first, before the team has any track record on this plan, is a common way to cause an outage and lose the mandate for the rest of the 90 days.
• "Zero traffic in the discovery window" is not proof of safety, only of no traffic in that window; a resource used quarterly or only during an annual event will look identical to a truly dead one. Extend the observation window for anything about to be deleted (not just closed off) rather than trusting the initial discovery pass alone.
• A single aggregate score can hide a regression in one category behind improvement in another. Report the per-category breakdown alongside the aggregate, since a security leader who only sees "score down 79%" cannot tell that container registries hit zero while third-party integrations, the laggard in the per-category output above, only dropped by 60%, information that changes what gets funded next quarter.
• Guardrails without an exception process get bypassed. A hard policy-as-code block on wildcard IAM with no documented, time-boxed exception path pushes teams toward workarounds (requesting a broader role "temporarily" through a different channel) that undo the whole effort; pair every guardrail with a fast, auditable exception process.

Direct answer

Preserve evidence of what you found without taking any action beyond what your engagement scope authorizes, notify the client immediately through the pre-agreed escalation channel rather than waiting until your engagement's normal reporting cadence, and coordinate directly with their incident response team while being explicit about where your authorized engagement ends and their own response begins.

Structured reasoning

Immediate obligations. The moment you find evidence of a real, unrelated compromise, your engagement's rules of engagement almost certainly don't authorize you to actively respond to it (contain it, remove it, or investigate it further), since that's outside the scope the client agreed to; your obligation shifts to preserving what you've already observed and notifying the client promptly, not continuing to dig deeper into territory you weren't authorized to test.

Legal and ethical responsibilities. Your contract likely has specific language about discovering unrelated findings during an engagement; even without explicit contract language anticipating this exact scenario, the ethical baseline is clear: you don't have standing authorization to act on this finding technically, and continuing to investigate beyond noting what you've already seen risks exceeding your actual authorization, however well-intentioned.

Notification timing and channel. This warrants immediate, out-of-band notification, not a note buried in your final engagement report delivered weeks later; contact the client's designated security or incident contact right away, through whatever emergency escalation path your engagement agreement specifies (or, if none exists, the most direct available channel), since every hour of delay is an hour the client's real incident continues unaddressed.

Coordinating with the client's IR team. Share exactly what you observed, how, and when, being precise about the boundary between your authorized testing activity and the newly-discovered, unrelated finding, so their team can distinguish your legitimate test traffic from the actual attacker's activity during their own investigation; offer to pause your engagement's active testing if it risks confusing their incident response, since continuing normal test activity during their live investigation could contaminate their evidence or trigger false alarms.

Worked example

During an authorized web-application penetration test, the tester discovers an active webshell on a server unrelated to the specific application in scope, clearly indicating a real, ongoing compromise by someone other than the testing team. The tester immediately stops testing activity on that specific server (outside engagement scope to investigate further) and documents exactly what was observed: the file path, timestamp, and how it was discovered. Within the hour, the tester contacts the client's designated security contact directly, rather than waiting for the engagement's weekly status update, explaining the finding and offering to pause broader testing activity if it would help the client's incident response team distinguish real attacker activity from the ongoing authorized test. The client's IR team takes over the technical investigation, and the pentest engagement's own final report separately documents the discovery and notification timeline as a distinct, time-stamped finding.

Trade-offs and pitfalls

Continuing to investigate the unrelated compromise out of professional curiosity or a desire to be more helpful, without explicit authorization to do so, risks exceeding your engagement's legal scope and potentially contaminating evidence the client's own IR team will need. Waiting to report the finding until your engagement's normal reporting cadence, rather than escalating immediately, is the single most damaging mistake here, since it needlessly extends the client's exposure to a real, active attacker.

This admission policy enforces two independent security properties on any container about to run in the cluster: that its image comes from a trusted source, and that it can't run with root privileges.

package kubernetes.admission

import rego.v1

allowed_registries := ["mycompany.registry/", "gcr.io/mycompany/"]

deny contains msg if {
	some container in input_containers
	not image_from_allowed_registry(container.image)
	msg := sprintf("container %q uses image %q from a non-approved registry", [container.name, container.image])
}

deny contains msg if {
	some container in input_containers
	not runs_as_non_root(container)
	msg := sprintf("container %q is not enforced to run as non-root", [container.name])
}

image_from_allowed_registry(image) if {
	some prefix in allowed_registries
	startswith(image, prefix)
}

runs_as_non_root(container) if {
	container.securityContext.runAsNonRoot == true
}

runs_as_non_root(container) if {
	container.securityContext.runAsUser != 0
}

input_containers := input.request.object.spec.containers

The two rules, and why non-root has two paths

The registry rule checks the image reference's prefix against an explicit allowlist, denying anything that doesn't match one of the two approved registries; this closes the same trust gap discussed for the supply-chain capstone elsewhere in this topic, enforced here at the actual point a container is scheduled, not just earlier in the pipeline. The non-root rule accepts EITHER of two ways a Pod spec can express "don't run as root": the explicit runAsNonRoot: true flag, or an explicit runAsUser set to any non-zero UID; a policy that only checked one of these two equivalent expressions would incorrectly deny a container that's actually correctly configured via the other path, which is why both are modeled as alternative ways to satisfy the same underlying rule.

Comments explaining the logic

The input_containers binding pulls directly from the Kubernetes AdmissionReview object's standard shape (request.object.spec.containers), which is the same structure every admission webhook receives regardless of what specific resource triggered the review, as long as it has a pod spec. Each deny rule is independent, meaning a container that fails BOTH checks produces two separate messages, giving the developer full visibility into everything wrong at once rather than surfacing one issue, requiring a fix, then surfacing the next.

Verified

Evaluated with opa eval against two fixture AdmissionReview payloads: a container using an unapproved registry (docker.io/library/nginx) with no non-root enforcement correctly produced both deny messages; a container using an approved registry with runAsNonRoot: true correctly produced an empty result.

Trade-offs

This policy checks only the FIRST container in a pod spec implicitly through the some container in input_containers iteration, which actually does correctly check every container in a multi-container pod (including init containers if they're included in the same array in your admission review shape); the real limitation is that it doesn't separately address initContainers, which live in a different field of the pod spec and would need their own explicit check if your threat model requires equally strict treatment of init containers.

Direct answer: XML External Entity (XXE) attacks exploit XML parsers that, by default, resolve external and internal entity declarations in a document's DOCTYPE, letting an attacker read local files, perform SSRF, or exhaust resources through entity expansion - all before the application's own logic ever processes the "data" the XML was supposed to carry.

How attackers craft them. The XML spec allows a document to declare custom entities in its DOCTYPE, including ones that reference external resources:

<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<root>&xxe;</root>

A parser configured to resolve external entities substitutes &xxe; with the actual file contents before returning the parsed document to the application - the file-read happens silently, inside the parsing step, with no application code involved at all. This is the DEFAULT configuration for some widely-used XML libraries, most notably Java's DocumentBuilderFactory, which resolves external entities by default unless it is explicitly hardened. It is worth being precise about which libraries, though: the common assumption that all XML parsers are vulnerable out of the box is also wrong. Python's standard-library xml.etree.ElementTree and modern lxml are both safe against this exact payload by default: ElementTree.fromstring raises xml.etree.ElementTree.ParseError: undefined entity, and lxml.etree.fromstring with its default parser raises lxml.etree.XMLSyntaxError: Entity 'xxe' not defined; lxml only becomes vulnerable if a caller explicitly opts in with XMLParser(resolve_entities=True). The practical lesson is to verify the specific library and its actual default configuration rather than assuming based on the language.

Vulnerable parser configurations. The vulnerability isn't in the XML format itself; it's in a parser left at its permissive default. Any XML-consuming code path is at risk if the parser hasn't been explicitly hardened: SOAP endpoints, file-upload handlers that accept XML/SVG/DOCX (which are XML internally), and RSS/Atom feed parsers are all common real-world XXE entry points that don't look like "an XML parser" at first glance.

Typical impacts:

• Local file disclosure: reading /etc/passwd, application config files containing secrets, or source code.
• SSRF: an entity referencing http://internal-service/ makes the vulnerable server issue that request, inheriting all the same internal-network-reach risk as classic SSRF.
• Port scanning: timing differences on entity resolution against different internal hosts/ports can map internal network topology.
• Billion-laughs / entity expansion denial of service: nested entity definitions that each reference several copies of the previous one can expand a tiny XML document into gigabytes in memory, exhausting the server.

Mitigations, verified. I confirmed by execution that disabling DOCTYPE processing entirely (disallow-doctype-decl on the parser factory, or an equivalent hardened configuration/library) rejects the exact payload above outright with a parse error, before any entity is ever resolved - a stronger fix than trying to selectively allow "safe" entities, since it removes the whole feature class rather than trying to filter it correctly. Additional layers: prefer data formats with no entity mechanism at all where the use case allows it (JSON has no equivalent construct), and apply egress restrictions as defense in depth against the SSRF variant specifically.

Trade-offs and pitfalls: disabling DTD processing entirely breaks any LEGITIMATE use of custom entities (rare, but it exists in some document-generation pipelines); the practical response when that's a genuine requirement is to use a different, safer mechanism for that specific need rather than leaving entity resolution enabled application-wide.