HARBOR CLOUD / 03 / PRACTICE GUIDE
Kubernetes workloads and admission security
A running Pod is not a secure Pod. Inspect effective security context across regular, init and helper containers and the admission policy actually enforced.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
Manifest review desk
Inspect synthetic JSON locally. No cluster connection, application of files or transmission of entered text. Use no real secrets or personal data.
This does not verify full Kubernetes schema/PSS, live admission, signatures or CNI. Extra teaching requirements do not replace organizational policy.
CODE REVIEW DESK
See the decision through the test.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
Is running enough? / Weak code
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>s.runningrunning is a functional signal. Require non-root, no privileged mode and no privilege escalation together; test actual image startup separately.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
User and privilege boundaries
Non-root execution, privileged mode and privilege escalation are separate decisions. Inspect whether containers override Pod security context. Seccomp, capabilities and host namespaces create additional boundaries. Read-only root filesystem is an extra workshop requirement, not a universal Restricted PSS requirement. Design required writable paths through controlled volumes instead of making the entire root writable or enabling privileged mode to resolve errors.
02 / EXPLANATION
Admission and existing workloads
Warn and audit provide visibility; they are not enforce behavior. Record policy version and who can change namespace labels. Do not assume new-Pod admission policy automatically corrects existing workloads. Bind exceptions to a workload, expiry and owner; do not blindly apply an application profile to system add-ons. Verify version-appropriate behavior with allowed and denied synthetic examples against the actual API server.
03 / EXPLANATION
Exact scope of the local inspector
The downloadable tool reads selected fields in apps/v1 Linux Deployment JSON examples. It checks regular, init and ephemeral lists using the same rules and reports host mounts, token automount and container conditions separately. It does not verify full API schema, PSS conformance, signatures, CNI, live admission or whether the image actually starts non-root. Matched means a configuration comparison against this limited teaching profile. No JSON is applied and no cluster credentials are read.
04 / EXPLANATION
Worked example: the overlooked init container
The main web container is constrained, but a setup init container is added without security fields. Do not generalize a green main-container result to the entire Pod. The weak fixture produces separate init findings; the bounded fixture matches nine selected checks. If adding an init container for real, complete its context, filesystem permissions and functional tests separately. Manifest digest, admission response and running image/Pod identity must refer to the same revision; nine local results do not replace that evidence.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.