Kubebot: Building a Kubernetes-Native Security Testing Platform with Slack and PubSub
Hook
What if every security scan your team ran automatically versioned its results in Git, diffed them against previous runs, and only alerted you to new findings—all triggered from a Slack command?
Context
Security teams face a familiar orchestration problem: they maintain dozens of specialized scanning tools (nmap, subdomain enumerators, secret scanners), each with different installation requirements, output formats, and usage patterns. Running these tools consistently across a team requires either extensive documentation that nobody reads, or building wrapper scripts that inevitably become unmaintainable. Worse, tracking results over time means manually comparing outputs, leading to alert fatigue when teams can’t distinguish between old and new findings.
Kubebot emerged as an architectural answer to this problem: what if security tools ran as ephemeral containers on Kubernetes, orchestrated through a message queue, with results automatically versioned in GitHub? Created by Anshuman Bhartiya, it demonstrates how to build a Slack-native security platform on Google Cloud Platform, though the creator notes the project is no longer actively maintained as work shifts to a v2 rewrite. Despite this status, Kubebot’s architecture offers valuable lessons for anyone building security automation or tool orchestration platforms.
Technical Insight
Kubebot’s core innovation is treating security tools as stateless, ephemeral workloads rather than long-running services. When a user issues a Slack slash command like /runtool nmap|-Pn -p 1-1000|google.com, the request flows through a three-tier architecture that decouples command reception, job queuing, and execution.
The API server—running as a Docker container on Kubernetes—receives the Slack webhook and immediately publishes a message to Google Cloud PubSub. This message contains the tool name, target, and options. Critically, the API server doesn’t execute anything; it just queues work and returns immediately. Subscription workers consume from the PubSub topic, each capable of spawning tool-specific containers. According to the README, the number of these workers can be scaled to handle increased load.
When a subscription worker receives a message, it initiates appropriate tool workers as Docker containers on the Kubernetes cluster. Results are stored temporarily on a local directory of that container, and the tool’s GitHub directory is cloned. Here’s where Kubebot gets interesting: after the scan completes, it checks if a results file for this target already exists and performs a diff operation using a utility container called checkfile.
The GitHub integration enables temporal awareness. If you scan a target today and again next week, Kubebot doesn’t just overwrite the old results—it commits both versions to Git and extracts only the differences. If a result file doesn’t exist, it gets added and changes are pushed to GitHub. If it exists, files are compared, the new file is pushed to GitHub, and only changes are pushed forward to the next step. A webhook from the tool workers then sends back the changes to Slack, and the tool workers are deleted.
Kubebot integrates several security tools including subdomain enumeration (Custom Enumall, Sublist3r, Subbrute), port scanning (nmap), directory bruteforcing (gobuster), and secret detection (TruffleHog, git-secrets, git-all-secrets, gitrob). The README notes that additional tools exist in the tools folder but are still being developed. Each tool runs as a containerized workload with Docker images downloaded from Google Container Registry.
The automation workflow capability extends this pattern into multi-stage pipelines. The documented example runs wfuzz for basic authentication bruteforcing, with a utility called converttobq used to convert tool outputs into BigQuery-ingestable formats. This enables tools to consume each other’s results—the wfuzz workflow queries endpoints from one BigQuery table and credentials from another, automatically attempting authentication across all combinations.
Deployment appears to leverage standard Kubernetes primitives. The /config directory contains configuration files to deploy Kubebot components. The Makefile orchestrates environment building. For local development, the documentation points to running Kubebot using Minikube. The /cronjobs directory contains sample deployment YAML files for setting up cronjobs that run specific tools at intervals with results sent back to Slack via webhook, enabling continuous security monitoring.
One architectural choice deserves scrutiny: the mandatory GitHub dependency. Every scan result gets committed to a repository, which creates both a version history and a potential security risk. Sensitive scan results—discovered credentials, internal infrastructure maps—live in a Git repository that must be carefully access-controlled.
Gotcha
Kubebot’s most significant limitation appears in its opening paragraph: the author is no longer actively maintaining it, with work shifting to a v2 version planned for presentation at upcoming security conferences. For a security tool, lack of active maintenance means vulnerabilities in dependencies won’t be patched, and integration with evolving cloud platforms will break. This isn’t a tool you should deploy in production and forget about.
The platform is tightly coupled to Google Cloud Platform with no apparent abstraction layer. You’re locked into GKE for Kubernetes, PubSub for messaging, and Google Container Registry for images. If your organization runs on AWS or Azure, porting Kubebot would require significant architectural changes. The documentation acknowledges this implicitly by only providing complete setup instructions for local Minikube deployment. The ‘Running Kubebot remote’ section states that remote deployment instructions can’t be provided ‘just yet,’ though the author offers to assist interested users or provide hosting for a monthly subscription fee covering normal VPS costs.
The GitHub integration, while architecturally interesting, becomes a potential bottleneck at scale. Every scan commits and pushes to a repository, meaning high-frequency scanning could create thousands of commits daily. Git isn’t designed as a high-throughput database, and repository size will grow unbounded without maintenance. The README doesn’t mention result retention policies, repository rotation, or cleanup strategies. Additionally, the diff-based change detection described in the data flow works for text-based comparisons—binary results or complex structured outputs would require comparison logic not detailed in the documentation.
The .env.sample file requirement and Makefile-based deployment suggest significant setup complexity even for local deployment. The documentation provides demo videos for installation and usage, but production deployment guidance is explicitly absent.
Verdict
Use Kubebot if you’re building your own security orchestration platform and need a reference architecture for Kubernetes-based tool execution, or if you have a small security team on GCP that wants to democratize tool access through Slack with basic result tracking. It’s particularly valuable as a learning resource—the architecture clearly demonstrates PubSub patterns, ephemeral container orchestration, and Slack integration that you can adapt to your own tools. The GitHub-based versioning approach, while imperfect, offers an interesting method for tracking security posture changes over time. Skip Kubebot if you need production-ready security automation with active maintenance, multi-cloud support, or plan to handle sensitive scan results at scale. The lack of active maintenance and limited remote deployment documentation make it unsuitable for critical infrastructure. Instead, examine its architecture, learn from its patterns, and build your own solution using modern alternatives like Argo Workflows or Temporal for orchestration, or evaluate actively maintained platforms like DefectDojo for security tool aggregation. Kubebot’s value in 2024 is primarily pedagogical—a well-documented example of how to think about security automation on Kubernetes, not a tool you should necessarily deploy as-is without understanding its maintenance status and architectural constraints.
