agentsclimarketplace

Container security

Skill Amey-Thakur/AI-SKILLS/skills/security/container-security

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill container-security

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Harden container images and runtime specs with minimal bases, non-root users, read-only filesystems, and dropped capabilities. Use when writing image or Kubernetes security settings or reviewing a container for privilege risk.

SKILL.md

2.8 KB, 606 tokens by cl100k_base, as published. Nobody here has run it

Container security

A container shares the host kernel, so a breakout turns a compromised app into a compromised node. What an attacker reaches for after landing is privilege and a place to write, so the job is to take both away before they ever get there.

Method

  1. Build from a minimal base. Prefer distroless, alpine, or scratch over a full OS image: fewer packages mean fewer CVEs and no shell to pivot from. Scan the final image with Trivy or Grype and fail the build on fixable High or Critical findings.
  2. Run as a non-root user. Add a USER directive with a fixed non-zero uid and set runAsNonRoot: true with an explicit runAsUser in the Kubernetes securityContext. A process running as uid 0 in the container is uid 0 against any kernel bug.
  3. Mount the root filesystem read-only. Set readOnlyRootFilesystem: true and grant writable tmpfs or volumes only for the paths that truly need writes (/tmp, a cache dir). An attacker who cannot write cannot drop a binary to run.
  4. Drop all Linux capabilities and add none back by default. Use capabilities: drop: [ALL] in the securityContext. Most services need zero; add one back only with a written reason, such as NET_BIND_SERVICE for a port below 1024.
  5. Forbid privilege escalation and privileged mode. Set allowPrivilegeEscalation: false and privileged: false, and refuse hostPID, hostNetwork, and hostPath unless a specific need is reviewed. A privileged container is effectively root on the host.
  6. Set CPU and memory limits per container. A compromised or runaway workload with no limit can starve every neighbor on the node. Unbounded resources are a denial-of-service condition waiting for a trigger.
  7. Keep secrets out of the image. Mount them as files from the orchestrator's secret store, never bake them into layers or plain environment variables. Anything COPYed in ships to everyone who can pull the image.

Checks

  • Does docker history or a layer scan turn up a shell, package manager, or secret in the final image?
  • Does the container run as non-root with a read-only root filesystem in production?
  • Are all capabilities dropped, with each one added back individually justified?

Boundaries

This hardens the container and its runtime spec. Dockerfile build hygiene and layer caching belong to containerization; cluster-wide enforcement (admission controllers, Pod Security Standards, network policy) is a platform concern this skill feeds rather than owns.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,984. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.