All Tools View Categories About Contact Privacy

Container Security Context Generator

Build a valid Kubernetes Pod (v1) with pod- and container-level securityContext.

Runs entirely in your browser - nothing is uploaded and no cluster connection is made.
0
pod fields
0
container fields
Your generated Pod YAML will appear here.

About Container Security Context Generator

A securityContext hardens pods and containers. The Container Security Context Generator writes a valid core/v1 Pod with both pod-level and container-level securityContext so you do not have to recall the schema.

You set runAsNonRoot, runAsUser/Group, fsGroup, readOnlyRootFilesystem, allowPrivilegeEscalation, privileged, capabilities (drop/add) and seccompProfile. The resulting YAML is valid core/v1 and matches the Pod Security Standards restricted recommendations.

Names are validated as RFC 1123 labels. Problems are reported in a clear panel. Everything runs locally and nothing is uploaded.

Features

  • Pod + container - both securityContext levels.
  • Non-root - runAsNonRoot, runAsUser/Group, fsGroup.
  • Hardening - readOnlyRootFilesystem, allowPrivilegeEscalation, privileged.
  • Capabilities - drop ALL, add only what is needed.
  • seccompProfile - RuntimeDefault / Localhost / Unmasked.
  • Copy / Download / Print - get pod.yaml wherever you need it.

How to Use

  1. Name the Pod and container.
  2. Set hardening flags (runAsNonRoot, read-only root, drop caps, seccomp).
  3. Watch the preview and export.

Examples

Example 1 - restricted. runAsNonRoot, drop ALL, readOnlyRoot true, seccomp RuntimeDefault.

Example 2 - non-root user. runAsUser 1000, runAsGroup 3000.

Benefits

  • Correct schema - valid core/v1 securityContext.
  • Restricted-ready - matches PSS restricted.
  • Validated - names checked.
  • Clean output - empty fields omitted.
  • Private - everything runs in the browser.
  • Copy, download or print - get the manifest where you need it.

Frequently Asked Questions

What is a securityContext?
A securityContext sets privilege and access control settings for a pod and its containers - such as running as a non-root user, a read-only root filesystem, dropped capabilities and a seccomp profile.
What fields are supported?
Pod-level: runAsNonRoot, runAsUser, runAsGroup, fsGroup, seccompProfile. Container-level: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation, privileged, capabilities (drop/add) and seccompProfile.
Why drop ALL capabilities?
Dropping ALL and adding back only what is needed is the restricted-profile best practice, minimizing what a compromised container can do.
Is the name validated?
Yes. The Pod and container names must be valid RFC 1123 labels.
Does this connect to a cluster?
No. Everything is assembled in your browser and nothing is uploaded.
Can I download it?
Yes. Copy the YAML, download pod.yaml, or print it.