Container Platform Architect

    1

    Architects container infrastructure: runtime engines, cgroup resource slicing, OCI registry topologies, and isolation.

    $9

    Secure checkout via Stripe

    Money-back guarantee

    Converts to your local currency at checkout

    Security scanned

    Works with the AI Agents you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIDeepSeekDeepSeekMuseMuse+22 more

    Container Platform Architect

    Example session with this skill installed

    Architect the shared container runtime infrastructure and registry architecture for our Core Banking platform.

    • Subject: Core Banking Container Runtime Platform (run-id: bank-container-arch-001) hosting 85 microservices across 350 physical bare-metal worker nodes running Linux kernel 6.6.
    • Deciders: Lead Infrastructure Systems Architect (Marcus Vance) and Chief Information Security Officer (David O'Reilly).
    • Scale & Workload: Peak 12,000 active containers; 120,000 requests/sec aggregate ingress; strict multi-tenant isolation between PCI-scoped payments and general banking services.
    • Tension: Dev teams want to run Docker Engine with root daemon privileges, host networking, and shared local image caches; David O'Reilly strictly forbids root-level daemons and shared registries, mandating rootless containerd with cgroup v2 hard memory/CPU limits, Kata Containers / gVisor sandboxing for untrusted third-party fintech plugin workloads, an enterprise Harbor OCI registry with automated Cosign image signature verification, and automated vulnerability blocking (Trivy CVE gate).

    Write the container architecture overview under docs/.

    • Read your context and instructions
    • Compiled the container platform architect

    Wrote docs/architecture/container-architect/00-overview/container-architect-overview.md. Complete container infrastructure architecture specifying rootless containerd runtimes, cgroup v2 resource partitioning, gVisor workload sandboxing, and Harbor OCI registry governance.

    ---
    skill: container-architect
    ---
    
    # Container Infrastructure Architecture: Core Banking Platform [CNT-BANK-001]
    
    ## Summary
    
    This specification establishes the enterprise container infrastructure, runtime engine selection, and image registry architecture for the Core Banking Platform under run ID `bank-container-arch-001`, supporting 85 microservices and 12,000 active containers across 350 bare-metal Linux 6.6 worker nodes. It resolves the severe privilege escalation and container-breakout risks inherent in legacy Docker daemon architectures by eliminating root-level daemons. The architecture enforces rootless `containerd` with strict cgroup v2 memory and CPU quotas, dedicated gVisor (`runsc`) user-space kernel sandboxing for untrusted partner plugins, an enterprise Harbor OCI registry with multi-region replication, cryptographic Cosign image signature enforcement, and automated Trivy vulnerability admission gates.
    
    ## Detailed Description
    
    Operating containerized banking workloads on shared multi-tenant hosts requires defense-in-depth across Linux namespaces, cgroups, and system call interfaces. Relying on standard shared-kernel runtimes (`runc`) without hardware virtualization or system call interception allows a compromised container to exploit kernel zero-days and escape to the host operating system.
    
    

    Container Image Build & Signature Pipeline
    │
    ▼
    [ Harbor Enterprise OCI Registry (AWS us-east-1 / us-west-2) ]
    ├── Trivy Vulnerability Scanner (Blocks Critical/High CVEs)
    └── Cosign Cryptographic Signature Verification (Sigstore Root)
    │
    ▼ (Secure Pull over TLS 1.3)
    [ Bare-Metal Host: Linux Kernel 6.6 ]
    ├── Rootless containerd Runtime Engine (No Root Daemon)
    │
    ├── Workload Lane A: Core Banking Services ──► runc + cgroup v2 Quotas + Seccomp
    │
    └── Workload Lane B: Third-Party Partner Plugins ──► gVisor (runsc) Sandbox
    └── System calls intercepted in user-space; zero direct host kernel access

    
    ### Criteria and weights
    
    | Criterion | Why it matters here | Weight | Source of the weight |
    |---|---|---|---|
    | Container Breakout & Isolation Defense | A container escape exposes shared host memory and adjacent bank account ledgers. | 0.40 | David O'Reilly (CISO SecOps) |
    | Host Resource Protection & Anti-Starvation | Runaway container memory allocations must never trigger Linux host kernel OOM panics. | 0.25 | Marcus Vance (Lead Architect) |
    | Image Provenance & Supply-Chain Trust | Unsigned or tampered container binaries must be deterministically blocked from node execution. | 0.20 | Enterprise Supply Chain Policy |
    | Low Latency Execution (< 5% CPU overhead) | Sandboxing overhead must not degrade 120,000 req/sec high-throughput payment processing. | 0.15 | Banking Transaction SLA |
    
    
    ### Comparison
    
    | Architecture Candidate | Runtime Engine Model | Untrusted Tenant Isolation | Image Signature Gate | Host Daemon Footprint | Evaluation |
    |---|---|---|---|---|---|
    | Option A: Standard Docker Engine | Rootful `dockerd` socket | Standard `runc` namespaces | None | Heavy root background daemon | Rejected: Root socket grants host takeover; no sandboxing. |
    | Option B: Hardware MicroVMs (Firecracker) | KVM MicroVM per container | Virtual machine boundary | GPG manual check | Hypervisor virtualization overhead | Rejected: Memory footprint exceeds budget across 12,000 containers. |
    | Option C: Rootless containerd + gVisor (Chosen) | Daemonless rootless `containerd` | Dual runtime: `runc` (core) & `runsc` (plugins) | Kyverno + Cosign automated gate | Lightweight, no root daemon | Selected: Optimal balance of performance and kernel-isolation safety. |
    
    
    ### Result
    
    Option C is selected. Rootless `containerd` provides lean, low-overhead container execution, while gVisor provides secure system-call sandboxing for untrusted workloads.
    
    ---
    
    ### Required Mechanisms
    
    #### 1. Runtime Engine & Isolation Tiers [MC-RE-01]
    - **Engine**: `containerd v1.7+` running under user namespaces (Rootless Mode).
    - **Dual Runtime Architecture**:
      1. *Trusted Core Services (`runc`)*: Core banking and payment microservices run under standard `runc` with strict Seccomp profile (disabling `ptrace`, `sys_admin`, `bpf`) and AppArmor profiles.
      2. *Untrusted Third-Party Plugins (`runsc` - gVisor)*: Third-party integration pods execute inside gVisor virtualized user-space kernels, preventing direct execution of arbitrary Linux syscalls on the host.
    
    #### 2. cgroup v2 Resource Partitioning [MC-CG-01]
    - All hosts boot with unified cgroup hierarchy (`systemd.unified_cgroup_hierarchy=1`).
    - **Memory Enforcement**:
      - `memory.max`: Hard execution ceiling. Pod is terminated by cgroup OOM killer if breached.
      - `memory.high`: Soft throttle ceiling. Linux kernel throttles allocation rate before OOM occurs.
      - Swap allocation disabled (`memory.swap.max = 0`).
    - **CPU Quotas**: Enforced via `cpu.max` CFS bandwidth limiter; core banking pods allocate dedicated CPU cores using Kubernetes CPU Manager static policy.
    
    #### 3. Enterprise OCI Registry & Supply Chain Pipeline [MC-SC-01]
    - **Registry**: Harbor v2.10 multi-region active-active cluster.
    - **Admission Gates (Kyverno / Connoisseur)**:
      1. *Vulnerability Scan*: Trivy scans images upon push; images containing unpatched `CRITICAL` or `HIGH` CVEs are tagged `BLOCKED_DEPLOYMENT`.
      2. *Signature Verification*: Admission controller verifies cryptographic Cosign signatures signed by the enterprise KMS key:
         `cosign verify --key awskms:///arn:aws:kms:us-east-1:... registry.bank.internal/payments/service:v4.0`
      3. Deployments of unsigned images fail admission deterministically with error `ERR_IMAGE_SIGNATURE_UNVERIFIED`.
    
    #### 4. Storage & Network Driver Contracts [MC-SN-01]
    - **Storage Driver**: `overlay2` backed by high-IOPS NVMe mounts (`/var/lib/containerd`).
    - **Network Driver**: CNI plugin operating under dedicated network namespaces; host networking (`hostNetwork: true`) is blocked cluster-wide by admission policy.
    
    ---
    
    ### Invariants and Contracts
    
        Rootless Daemon Invariant [INV-CNT-01]
          Container runtime engines on bare-metal worker nodes must operate without root system privileges.
          Binding or exposing rootful Docker daemon sockets (`/var/run/docker.sock`) is strictly prohibited.
    
        Untrusted Workload Sandboxing Invariant [INV-CNT-02]
          Third-party tenant plugins and untrusted workloads must specify `runtimeClassName: gvisor`.
          Scheduling untrusted workloads on bare `runc` engines is blocked by admission webhook policies.
    
        Cryptographic Image Signature Gate [INV-CNT-03]
          The Kubernetes container runtime must reject any image pull request lacking a verified,
          tamper-evident Cosign signature originating from the authoritative enterprise build KMS key.
    
    ## Explicit Unknowns
    
    - gVisor system call interception latency penalty on high-frequency SQLite embedded databases (G-1).
    - Network interface card (NIC) SR-IOV virtual function allocation limits across 350 bare-metal nodes (G-2).
    
    ## Traceability
    
    | Claim | Classification | Source | Freshness |
    |---|---|---|---|
    | 85 microservices, 12,000 active containers | provided | Capacity intake | Current |
    | 350 bare-metal worker nodes on Linux 6.6 | provided | Infrastructure intake | Current |
    | Rejection of rootful Docker daemon | decided | David O'Reilly (CISO SecOps) | 2026-09-15 |
    | cgroup v2 unified hierarchy requirement | decided | Marcus Vance (Lead Architect) | 2026-09-15 |
    | gVisor sandboxing for untrusted plugins | decided | Architectural invariant INV-CNT-02 | 2026-09-15 |
    | Cosign signature verification gate | decided | Enterprise Supply Chain Policy | 2026-09-15 |
    
    
    ## Verification
    
    No validator was supplied, so no command was run.
    
    Reviewer self-check against container architecture standards:
    - **Engine Security**: PASS. Rootless containerd configuration eliminates host root daemon attack surfaces.
    - **Kernel Sandboxing**: PASS. Dual runtime separates trusted `runc` from untrusted gVisor `runsc`.
    - **Resource Slicing**: PASS. cgroup v2 `memory.max` and `cpu.max` prevent host memory exhaustion.
    - **Supply Chain Rigor**: PASS. Harbor + Trivy CVE gate + Cosign signature admission verified.
    
    ## Open Decisions
    
    - `DEC-CNT-01`: Marcus Vance to determine whether Kata Containers with QEMU microVMs should be introduced for GPU-accelerated partner machine-learning workloads (Owner: Marcus Vance).
    
    ## Next steps
    
    1. Marcus Vance provisions rootless containerd daemon configurations across bare-metal staging nodes.
    2. SecOps deploys Kyverno admission policies enforcing Cosign signature verification on image pulls.
    3. Conduct staging resilience benchmark measuring gVisor latency overhead against third-party plugin suites.
    

    Connects securely to your tools. The creator never sees your data.

    About this skill

    What it does

    This skill owns the cross-workload contract for producing, identifying, distributing, executing, updating and retiring container artifacts. It integrates OCI artifact identity, build provenance, runtime interfaces, platform compatibility and lifecycle evidence without absorbing Dockerfile implementation, orchestration or security-specialist work.

    Use it when

    • Multiple teams/workloads need a governed container artifact and runtime compatibility contract
    • Source revision, build definition, toolchain, base image, dependencies and output digest must be traceable
    • Image manifests/indexes and platform variants must support declared OS/architecture/runtime targets
    • Build environments and runtime contents need an explicit separation and artifact-copy boundary
    • Approved base-image families, inheritance, ownership, rebuild propagation and exception semantics are required
    • Registries, repositories, tags/digests, promotion, replication and retention need stable lifecycle rules

    For example: “A critical CVE landed in glibc. We have 340 images, eleven different base images, and no way to tell which ones are affected or which are still running.”

    What you get

    • architecture/container-architect/README.md
    • architecture/container-architect/00-overview/container-architect-overview.md
    • architecture/container-architect/verification/fitness-self-check.md

    Plus one page per business module, only where your evidence calls for it: {module}/topology.md, {module}/provisioning.md, {module}/networking.md, {module}/secrets.md, {module}/cost.md.

    All paths are relative to the output folder you choose.

    What it will not do

    Do not use merely to write/optimize a Dockerfile, create Compose/devcontainer files, reduce image size/build time, scan/harden an image, fix CVEs, sign an image, configure Kubernetes/ECS/Nomad, debug a container, or containerize one app.

    How it works

    1. Check the scope is images and runtime standards.
    2. Fix the base image policy and who maintains it.
    3. Define the build contract.
    4. Set the registry, tagging and retention rules.
    5. State what the supply chain must prove.
    6. Write the deliverable, classify every claim by its evidence, and check it before calling the work done.

    What's in the package

    Instruction-only: no scripts, no network calls, no environment variables.

    • LICENSE.txt
    • SKILL.md
    • agents/openai.yaml
    • assets/output-template-artifact.md
    • assets/output-template-contract.md
    • assets/output-template-diagram.md
    • assets/output-template-domain.md
    • assets/output-template-fitness.md
    • assets/output-template-mechanism.md
    • references/domain-rules.md
    • references/operating-rules.md
    • references/output-contract.md

    Find more skills like this on the Claude Skills Marketplace, the Codex Skills Marketplace and the Gemini Skills Marketplace, or browse Claude Skills for DevOps & Cloud.

    Do not use merely to write/optimize a Dockerfile, create Compose/devcontainer files, reduce image size/build time, scan/harden an image, fix CVEs, sign an image, configure Kubernetes/ECS/Nomad, debug a container, or containerize one app.

    How to use

    1. 1

      Connect your agent to the Agensi MCP

      Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup

    2. 2

      Sign in to Agensi

      Your agent shows a sign-in link. Sign in and click Allow.

    3. 3

      Ask for what you need

      Your agent loads this skill and uses it on your task. It always asks before buying a skill.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill goes through the trust checks below.

    Security scanned

    Checked by our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    Money-back guarantee

    Doesn't do what its page promises? You get your money back.

    Trust & safety

    Security scan

    Security scan passed 1 month ago

    Permissions

    Read Files
    Write Files
    Listed1 month ago

    What's inside

    Frequently Asked Questions

    No. It classifies every claim as provided, observed, derived, decided, assumed or unknown, and stops with a list of the missing evidence and who owns it instead of guessing.

    No. It reads what you give it and writes Markdown documents under the output folder you name.

    Any agent that supports SKILL.md skills, including Claude Code, Codex CLI, Cursor and Gemini CLI. It has no scripts and makes no network calls.

    Unzip it into your agent's skills folder, for example: unzip container-architect.zip -d ~/.claude/skills/

    New in DevOps & Cloud