Back to browse
GitHub Repository

Static analysis from configs → Kubernetes NetworkPolicies in seconds

15 starsGo

Segspec (CLI) K8s NetworkPolicies from App Configs (Go)

by dormstern·Feb 20, 2026·1 point·1 comment

AI Analysis

●●●BangerBig BrainSolve My Problem

Static analysis beats 30-60 day observation. Generates NetworkPolicies in seconds, not weeks.

Strengths
  • Solves genuine pain: replaces expensive multi-week agent-based workflows with instant static analysis
  • Tested on real production stacks (Sentry 70+ services, PostHog 25+) with concrete benchmarks
  • Optional AI for edge cases keeps core simple; rule-based parsers handle 99% of work offline
Weaknesses
  • Static analysis misses runtime-only dependencies (dynamic discovery, service mesh sidecars)
  • Adoption friction: orgs invested in existing observability platforms may resist rip-and-replace
Target Audience

Platform engineers, DevSecOps teams, Kubernetes operators managing multi-service deployments

Similar To

Cilium Hubble · Istio authorization policies · AWS Security Groups auto-generation tools

Post Description

It reads Docker Compose, Helm charts, K8s manifests, and Spring Boot configs, extracts every network dependency, and generates per-service NetworkPolicies. Tested against real production stacks:

Sentry self-hosted (70+ services): 411 dependencies, 71 policies, 11ms PostHog (25+ services): 23 dependencies, 12 policies, 128ms

Key design decisions:

Static analysis only. No agents, no cluster access, no observation period. Works offline. AI is optional. Rule-based parsers handle the core. --ai adds Ollama (local) or Gemini (cloud) for edge cases. Interactive TUI lets you review every dependency before generating YAML. Per-service output with both ingress AND egress rules.

The thesis: your configs already declare every dependency. Why are we paying for 30-60 day observation periods and runtime agents? Written in Go, MIT licensed. Would love feedback from anyone running NetworkPolicies in production.

Similar Projects

Security●●Solid

Generate baseline Kubernetes NetworkPolicies from rendered manifests

It statically parses rendered manifests and common config files (Helm, Docker Compose, Spring Boot, .env, build files) to emit per-service ingress+egress NetworkPolicies—no cluster access needed. That offline, config-driven approach is smart and practical for PR-based workflows, though it will still need runtime validation for dynamic cases (headless services, service mesh/DNS/egress quirks) before you slam policies into prod.

Niche GemSolve My Problem
dormstern
103mo ago