Coming soon Not available today.
Follow a container from its image identity into the Pod that runs it. Examine execution identity, Linux capabilities, writable paths and deployment controls without confusing a manifest with an observed runtime.
The examples below describe planned scope. Contact us to discuss your requirements; this capability is not currently available for evaluation.
Images & orchestration
Docker
KubernetesAn image’s settings are only one input. Inspect the Pod defaults, container overrides and runtime assumptions together.
apiVersion: v1
kind: Pod
metadata:
name: review-example
spec:
os: { name: linux }
securityContext:
runAsNonRoot: true
runAsUser: 10001
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: example.invalid/app:review
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
readOnlyRootFilesystem: true
spec.securityContextcontainers[].securityContextContainer settings override overlapping Pod defaults.
runAsUser overrides image USER; runAsNonRoot makes kubelet reject UID 0 at startup. Admission policies inspect the manifest, not a running process. A non-root UID does not settle group membership, volume permissions or application authorization.
allowPrivilegeEscalation: false prevents gaining privileges beyond the parent process. Dropping ALL capabilities removes another source of privilege. Review every container, including init and ephemeral containers; these fields do not replace a full admission policy.
A read-only root filesystem does not make mounted volumes read-only. Applications that write need explicitly configured writable mounts and permissions. RuntimeDefault selects the runtime’s seccomp profile; support and filtering depend on the Linux node and runtime. Windows controls differ.
This example uses a placeholder image and omits workload-specific mounts. It is not a deployment recipe, a runtime observation or a complete hardening baseline.
Reference: Kubernetes security contexts Pod Security Standards
A useful evaluation agrees the input, context and decision record before measuring the result.
Image digest, platform and available build evidence
Dockerfile, repository revision and image inventory
Declared or admitted Pod, including every container
Bound observations, gaps and the applied policy
Name the registries, platforms and workload sources in scope. Separate Dockerfile/build metadata, SBOM or scanner evidence, manifests and optional read-only cluster observations.
Resolve mutable tags to digests and retain the platform for multi-architecture images. Include init and ephemeral containers and account for admission-time mutation.
Keep image digest, source revision, workload identity and configuration evidence together so a result for one artifact cannot silently describe another.
A package report does not prove runtime isolation. Review does not imply registry or cluster write access, admission enforcement or a live runtime-protection agent.
Three evidence sources, each answering a different question.
A mutable tag is not a stable artifact reference. Keep the image digest and platform with package or scanner evidence. A report for one digest cannot establish the posture of a different image deployed under the same tag.
Defaults, admission policy and mutation can affect the Pod that reaches the cluster. Preserve namespace, workload revision and observation time when comparing declared security settings with cluster context.
Imported image evidence, repository manifests and authorized cluster observations have different collection and permission requirements. Existing supply-chain report ingestion is a separate workflow; a package report alone does not establish runtime isolation or Kubernetes policy enforcement.
Discuss your stack, access model and review requirements with the TraceMint team.
Discuss planned scope Explore the platform