KONTROLD: Bridging the Gap Between Ansible and API-Driven Infrastructure

KONTROLD Logo

Why I Started Building KONTROLD

Over the past years, I have spent a significant amount of time designing and operating infrastructure across very different environments: classic Linux systems, Kubernetes platforms, edge and IoT setups, and highly regulated enterprise environments.

One recurring problem kept showing up, regardless of scale or industry:

We have excellent tools for executing configuration, but very few for managing configuration as a lifecycle.

KONTROLD is my attempt to explore and close that gap.

The Gap I Keep Running Into

Configuration management today usually falls into one of two camps:

  • Task-oriented automation, which is easy to adopt and extremely flexible, but fundamentally stateless.
  • Full control planes, which offer reconciliation, lifecycle awareness, and strong guarantees, but come with significant complexity and operational overhead.

In practice, many teams sit right in between.

They want:

  • Declarative configuration
  • Idempotent execution
  • Drift detection
  • Auditable state
  • A real API

But they do not want to:

  • Run a full Kubernetes control plane
  • Maintain etcd clusters
  • Model everything as CRDs
  • Introduce Kubernetes just to manage system-level configuration

This is especially true for classic Linux fleets, edge and IoT environments, security-sensitive systems, and air-gapped deployments.

The Idea Behind KONTROLD

KONTROLD applies proven control-plane patterns to system configuration, without requiring Kubernetes.

Core characteristics:

  • API-first design
  • Declarative objects
  • Reconciliation loop
  • Explicit state tracking
  • No Kubernetes dependency

KONTROLD does not aim to recreate Kubernetes. It selectively reuses architectural ideas where they make sense and leaves out everything else.

Technical Architecture

┌─────────────────────────────────────┐
│     Management Host (Ops)           │
│  ┌───────────────────────────┐      │
│  │  kontroldctl CLI          │      │
│  │  + Client Certificate     │      │
│  └───────────────────────────┘      │
└──────────────┬──────────────────────┘
               │ HTTPS (mTLS)
               │ Port 8443
┌──────────────▼──────────────────────┐
│     Target System (TS)              │
│  ┌──────────────────────────────┐   │
│  │  kontrold-api (API Server)   │   │
│  │  + x509 Verification         │   │
│  │  + RBAC Enforcement          │   │
│  └───────────┬──────────────────┘   │
│              │                      │
│  ┌───────────▼────────────────┐     │
│  │  kontrold-controller       │     │
│  │  + Reconciliation Loop     │     │
│  │  + Module Execution        │     │
│  └───────────┬────────────────┘     │
│              │                      │
│  ┌───────────▼────────────────┐     │
│  │  SQLite Storage            │     │
│  │  + Object States           │     │
│  │  + RBAC Policies           │     │
│  │  + Audit Logs              │     │
│  └────────────────────────────┘     │
└─────────────────────────────────────┘

Core Features

Infrastructure Management

  • 📦 Package Management - apt, yum, dnf support
  • ⚙️ Service Control - systemd service orchestration
  • 📄 File Management - Template-driven configuration files
  • 👤 User Management - Users, groups, and SSH keys
  • 🐳 Container Management - Docker/Podman integration
  • 🔥 Firewall Rules - iptables/nftables/ufw configuration

Security & Operations

  • 🔐 mTLS Everywhere - Certificate-based authentication
  • 🛡️ RBAC Policies - Granular permission control
  • 📊 Prometheus Metrics - Built-in observability
  • 📝 Audit Logging - Complete operation trail
  • 🔄 Drift Detection - Automatic state reconciliation
  • 💾 SQLite Backend - Simple, reliable state storage

Usage Example

Managing packages with KONTROLD:

apiVersion: iac.kontrold.io/v1alpha1
kind: PackageSet
metadata:
  name: webserver-packages
  namespace: system
spec:
  packages:
    - name: nginx
      state: latest
    - name: postgresql
      state: present
  updateCache: true

kontroldctl apply -f packages.yaml

Design Principles

Simplicity Over Completeness

Leaving things out is often a feature.

Explicit State

If something matters operationally or from a compliance perspective, it should be represented explicitly.

Security by Default

mTLS, strong identity, and RBAC are baseline requirements.

Extensibility Without Lock-In

A WASI-based plugin model allows safe extension without runtime lock-in.

Project Roadmap

  • v0.1 (MVP) - Core API, Package/Service/File modules, mTLS auth, SQLite storage
  • v0.2 - User/SSH management, Container support, Firewall rules
  • v0.3 - PlaybookSet orchestration, Template library, WebSocket watch API
  • v0.4 - WASI plugin ABI for custom modules
  • v0.5 - Windows support via SSH+PowerShell (Beta)
  • v1.0 - Production-ready with PostgreSQL support, Web UI

Current Status

KONTROLD currently exists as a private prototype. It is intentionally not released yet to allow conceptual validation and feedback before freezing interfaces.

The source code will be available on GitHub once the MVP reaches a stable state. If you're interested in early access or want to discuss the architecture, feel free to contact me.

Why I'm Sharing This Now

Good infrastructure tools are shaped by discussion, not stealth development. This article is an invitation for feedback and architectural dialogue.

If you've faced similar challenges or have thoughts on the approach, I'd love to hear from you.

KONTROLD: Bridging the Gap Between Ansible and API-Driven Infrastructure - Patrick Paechnatz