Kubebot: The Slack Security Scanner That Weaponizes Kubernetes Ephemeral Containers

Hook

Most security tools wait in VMs burning money 24/7. Kubebot spins up a fresh Docker container for every scan, runs your pentest, dumps results to GitHub, and vanishes—all triggered from a Slack command.

Context

Security testing in 2017 faced an orchestration problem. DevOps teams lived in Slack, but their security tools lived in scattered VMs, Jenkins jobs, or cron scripts. Running nmap, gobuster, or credential scanners meant SSH-ing into boxes, remembering command syntax, and manually comparing results between runs. Worse, keeping heavyweight scanning infrastructure running 24/7 wasted cloud spend, while ad-hoc VM spinning created security gaps and inconsistent environments.

Kubebot emerged as a ChatOps-native solution: a Slackbot that treats security scans as ephemeral Kubernetes jobs. Type /kubebot nmap target.com and within seconds, a dedicated container spins up on GKE, executes the scan, pushes results to a GitHub repo for version control, diffs against previous runs, and reports only what changed back to your Slack channel. The infrastructure scales to zero when idle and to hundreds of parallel scans under load. It's security testing infrastructure that behaves like serverless functions before "serverless" became the default mental model.

Technical Insight

Kubebot's architecture revolves around three core components: a Flask API server, Google Cloud Pub/Sub for message queuing, and dynamically spawned Kubernetes job containers. When you issue a Slack slash command like /kubebot nmap -A target.com, Slack fires a webhook to the Flask API running in a Kubernetes deployment. This API validates the request, publishes a message to a tool-specific Pub/Sub topic (e.g., nmap-topic), and immediately returns acknowledgment to Slack.

The magic happens in the subscription workers. A Python worker subscribed to nmap-topic receives the message, extracts parameters, and uses the Kubernetes Python client to spawn a job on-demand. Here's the core job creation pattern from the codebase:

from kubernetes import client, config
import json

def create_job_object(tool_name, target, params, job_id):
    container = client.V1Container(
        name=f"{tool_name}-container",
        image=f"gcr.io/your-project/{tool_name}:latest",
        args=[target] + params.split(),
        env=[
            client.V1EnvVar(name="JOB_ID", value=job_id),
            client.V1EnvVar(name="GITHUB_TOKEN", value_from=client.V1EnvVarSource(
                secret_key_ref=client.V1SecretKeySelector(name="github-secret", key="token")
            ))
        ]
    )
    
    job_spec = client.V1JobSpec(
        template=client.V1PodTemplateSpec(
            spec=client.V1PodSpec(
                containers=[container],
                restart_policy="Never"
            )
        ),
        backoff_limit=1
    )
    
    job = client.V1Job(
        api_version="batch/v1",
        kind="Job",
        metadata=client.V1ObjectMeta(name=f"{tool_name}-{job_id}"),
        spec=job_spec
    )
    return job

Each tool runs in a pre-built Docker image hosted on Google Container Registry. The nmap container, for instance, installs nmap, runs the scan with provided arguments, formats output as JSON, and executes a Python script to commit results to a designated GitHub repository under a path like results/nmap/target.com/2024-01-15.json. This Git-as-database approach provides automatic versioning, auditability, and enables the diffing mechanism.

The diffing logic is where Kubebot shines for reducing alert fatigue. After pushing new results, the container fetches the previous scan result from the same path, performs a deep dictionary diff, and only posts changes to Slack. If you scan a target daily and nothing changes, your Slack channel stays silent. When a new port opens or a subdomain appears, you get a concise diff:

🔍 nmap scan complete for target.com
📊 Changes detected:
  + ports.tcp.8080: {"state": "open", "service": "http-proxy"}
  - ports.tcp.8000: {"state": "open", "service": "http"}

Kubebot supports nine security tools out of the box—nmap, gobuster, nikto, gitrob, git-secrets, sublist3r, wpscan, whatweb, and sslscan—each following the same pattern: receive Pub/Sub message, spawn job, execute tool, commit to Git, diff, report. Adding a new tool requires building a Docker image with the tool installed, writing a 50-line wrapper script to handle GitHub integration, and deploying a subscription worker listening to a new Pub/Sub topic.

The platform also supports workflow chaining through BigQuery integration. The gobuster tool discovers endpoints, stores them in BigQuery, then a separate workflow reads those URLs and feeds them to wpscan or credential brute-forcing tools. This enables multi-stage reconnaissance pipelines orchestrated through Slack commands.

Scaling happens at multiple layers. The Flask API runs as a Kubernetes deployment with horizontal pod autoscaling based on CPU. Pub/Sub handles message buffering during traffic spikes. Subscription workers scale independently based on queue depth. And because each scan is an isolated job, hundreds of parallel security tests can run simultaneously without contention, each in its own ephemeral container that disappears after completion.

Gotcha

The biggest limitation is abandonment—Kubebot is explicitly archived, with the author noting work on an incompatible v2 that may never materialize. You're adopting code frozen in 2018, meaning no security patches, no dependency updates, and Python 2.7 compatibility issues in modern environments. Forking and maintaining it becomes your responsibility, which is substantial for a security-critical tool.

The GCP lock-in is total. Kubebot assumes Google Kubernetes Engine for container orchestration, Cloud Pub/Sub for messaging, and Google Container Registry for images. Migrating to AWS would require rewriting the Pub/Sub layer to use SQS/SNS, changing authentication flows, and potentially rethinking job spawning patterns. The author intentionally omitted production deployment documentation, so you'll reverse-engineer GKE configurations, IAM roles, and network policies from the Minikube local setup. Running this in production demands Kubernetes expertise—you need to understand pod security policies, resource limits, network policies to isolate scan containers, and secret management for GitHub tokens and Slack webhooks. There's no Helm chart, no Terraform modules, just raw Kubernetes YAML you'll need to harden yourself.

Verdict

Use if: You're a security team already on GCP with Kubernetes expertise, want a Slack-native security scanning interface, value Git-based audit trails over traditional databases, and are comfortable forking and maintaining archived Python projects. Kubebot's architecture patterns are excellent for learning event-driven security orchestration, and the ephemeral container model remains ahead of its time. It's ideal for mid-sized security teams who can dedicate engineering time to customization and maintenance. Skip if: You need production-ready tooling with active maintenance, want multi-cloud portability, lack Kubernetes operational experience, or expect comprehensive documentation. The abandonment risk is real—Python dependencies are outdated, security patches won't arrive, and you're on your own for production hardening. For modern alternatives, evaluate OWASP SecureCodeBox for actively maintained Kubernetes-native scanning, or DefectDojo if you prioritize vulnerability management over ChatOps. Kubebot is a brilliant proof-of-concept that teaches the right patterns, but production use requires treating it as inspiration rather than a finished product.