Orchestrator Container Spawn logo

Orchestrator Container Spawn

CommunityPopular
samugit83
orchestrator-container-spawn

Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling. cap_drop and no-new-privileges were each reverted after breaking real scans. Trigger: editing recon_orchestrator/container_manager.py; changing how a scan container is spawned or hardened; touching _scanner_hardening, sibling_host_path, cap_drop, security_opt, or a bind mount for a spawned container.

Overview

Publishersamugit83
Repositoryredamon
Skill nameorchestrator-container-spawn
Stars
2.5K
Forks
504
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by samugit83 on GitHub. Read the source before you install it.

Installation

Install the Orchestrator Container Spawn AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/samugit83/redamon.git /tmp/redamon
mkdir -p .claude/skills
cp -r /tmp/redamon/skills/orchestrator-container-spawn .claude/skills/orchestrator-container-spawn
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Orchestrator Container Spawn in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Orchestrator Container Spawn on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Orchestrator Container Spawn is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

When to Use

For the no-env_file knob rule, see the recon_orchestrator AGENTS.md CRITICAL RULES (not repeated here).


Critical Rules

  • NEVER add cap_drop: [ALL] to a scan container that writes to a host-owned source bind mount. It strips CAP_DAC_OVERRIDE, so root-in-container can no longer write the host-owned files, and the scan breaks. This was reverted after breaking recon/partial spawns; hardening is deliberately deferred with drop_caps=False at every spawn site (container_manager.py:837, :1798, :2168). Keep it deferred unless the mount is not host-owned.
  • NEVER add security_opt: no-new-privileges to these spawns. It breaks execve for non-root users inside the recon image (reverted once already): container_manager.py:939.
  • NEVER add a tmpfs mount without uid/gid/mode when the container runs as a NON-ROOT user and the mount lands on a path that user must write. Docker mounts a tmpfs root-owned 0755 unless told otherwise (only /tmp gets the 1777 default), and the mount SHADOWS whatever the image built at that path - so a tmpfs added to give a non-root user writable scratch is what takes it away. This shipped: the TruffleHog spawn's /home/trufflehog tmpfs hid the home dir useradd --create-home had given uid 10001, and github_experimental died on "failed to create .trufflehog folder in user's home directory" while the other thirteen sources were fine, because it is the only one that writes to $HOME. Build the spec in _trufflehog_tmpfs(), not inline, and size-cap every entry - an uncapped tmpfs is host RAM a hostile archive can exhaust.
  • ALWAYS apply hardening through _scanner_hardening() (container_manager.py:567), not ad-hoc per spawn, so all three spawn sites stay consistent.
  • ALWAYS keep sibling_host_path() robust to BOTH POSIX (/) and Windows (\) host paths (container_manager.py:53). It derives a sibling source dir's host path for bind mounts; a POSIX-only assumption breaks spawns on Windows hosts. Its two companions parent_host_path() and join_host_path() carry the same POSIX+Windows discipline - never swap in pathlib / Path(...).parent, which collapses a Windows host path on the Linux orchestrator.
  • NEVER assume a scanner source dir is a repo-root sibling. Scanners live two levels deep under scanners/<name>/, so a bind mount to a repo-root sibling (e.g. graph_db) must climb out of scanners/ first: sibling_host_path(parent_host_path(scanner_path), "graph_db"), and a scanners/-nested sibling is reached with join_host_path(parent_host_path(recon_path), "scanners", "supply_chain_common"). The old sibling_host_path(scanner_path, "graph_db") now resolves to a nonexistent scanners/graph_db; Docker silently binds an empty root-owned dir there and graph writes / imports fail with no error. The build context climbs two parents: parent_host_path(parent_host_path(scanner_path)).
  • NEVER bind /app/graph_db directly at a spawn site. Always route it through self._graph_db_mount(<derived>, baked_into_image=...) (container_manager.py:605). Deriving graph_db's host path is a LAST RESORT, not the mechanism: the real path is auto-detected from the orchestrator's own ./graph_db:/app/graph_db:ro mount (GRAPH_DB_PATH, resolved in api.py exactly like RECON_PATH). The derivation is only right when Docker reports the literal repo path - Docker Desktop on Windows/WSL2 reports rewritten bind Source strings whose sibling is nowhere, Docker auto-creates that path EMPTY, and the empty dir shadows the graph_db baked into the scan image. Every spawned scan then dies with cannot import name 'Neo4jClient' from 'graph_db' (unknown location) (issue #169). baked_into_image=True for recon / gvm / github-hunt (they COPY graph_db, so no mount beats a wrong mount); False only for supply-chain, which does not bake it. TruffleHog has NO graph_db mount at all: its container is the dirty half of a dirty/clean split and holds no Neo4j credentials, so the orchestrator ingests its findings afterwards.
  • ALWAYS resolve a new host source path with _get_host_path() + a compose mount, not by string surgery on another path. If a spawn needs host dir X, mount X into the orchestrator so Docker itself reports its source. A missing bind source is not an error to Docker; it silently becomes an empty directory.

Why these flags break here

Scan containers run as root and bind-mount host-owned source (the live working tree) so a .py change is picked up without a rebuild. Standard container hardening (drop all caps, no-new-privileges) assumes the container owns its filesystem and runs unprivileged - neither holds here, so the "secure defaults" a reviewer would add are exactly what broke production twice.

Commands

bash
docker compose restart recon-orchestrator     # container_manager.py is volume-mounted
./redamon.sh test unit                        # recon_orchestrator section

Resources

Frequently asked questions

What does the Orchestrator Container Spawn AI skill do?

Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling. cap_drop and no-new-privileges were each reverted after breaking real scans. Trigger: editing recon_orchestrator/container_manager.py; changing how a scan container is spawned or hardened; touching _scanner_hardening, sibling_host_path, cap_drop, security_opt, or a bind mount for a spawned container.

Why use Orchestrator Container Spawn on TypingMind?

Because you install it once and use it with any model. Orchestrator Container Spawn is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Orchestrator Container Spawn in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/samugit83/redamon/tree/master/skills/orchestrator-container-spawn. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Orchestrator Container Spawn?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Orchestrator Container Spawn?

As many as you like. As long as a model supports skills, you can use Orchestrator Container Spawn with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Orchestrator Container Spawn AI skill free?

Yes. It is published on GitHub by samugit83 under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇