Kea DHCP and Stork - DHCP Server with Web Dashboard

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Overview

Kea is a modern, high-performance open-source DHCPv4 and DHCPv6 server maintained by ISC, with a clean JSON configuration, a full management API, and pluggable back ends. Stork is its companion web dashboard: it monitors one or more Kea servers and surfaces daemons, subnets, shared networks, address pools, host reservations, and lease utilisation from a single screen. This AMI delivers Kea, Stork, the Stork agent, and their PostgreSQL back end installed, wired together, and secured - so an observable DHCP service is operational within minutes of launch.

## Why This AMI

Standing up Kea with Stork by hand means installing pinned ISC packages from two repositories, configuring PostgreSQL, wiring the Kea control channel, seeding the Stork schema, rotating the default admin password, registering the Stork agent, and terminating TLS in front of the dashboard. This image completes every one of those steps at build time. It generates unique per-instance secrets on first boot and ships with a dedicated resizable data volume for the monitoring database.

## Security Hardening

• No default credentials: Stork's default admin/admin login is rotated to a unique password generated on first boot, before the TLS port is reachable
• Per-instance secrets: Stork admin password, PostgreSQL role password, Kea control API credential, and self-signed TLS certificate are all generated per instance and written only to a root-only file
• Network isolation: Stork server, PostgreSQL, and the Kea control socket bind exclusively to loopback; only the nginx TLS reverse proxy is exposed
• Encrypted front door: nginx terminates TLS on port 443 with a per-instance self-signed certificate; port 80 redirects to HTTPS
• Safe-by-default DHCP: Kea serves no network interface out of the box, so the appliance cannot act as a rogue DHCP server on your VPC
• Dedicated data volume: the PostgreSQL cluster lives on its own EBS disk, surviving OS-disk changes and resizable independently

## Concrete Use Cases

• ISP or campus network DHCP: manage tens of thousands of leases across multiple subnets with a high-performance DHCPv4/DHCPv6 server and monitor pool utilisation in real time through the Stork dashboard
• Multi-site enterprise: centrally monitor subnet allocation, shared networks, and lease exhaustion across distributed Kea servers from a single Stork instance
• Hospital or university network administration: maintain static host reservations for medical devices or lab equipment with full audit visibility through the browser UI

## AWS Integration

Deploy on any EC2 instance type; the recommended size is m5.large. Terminate TLS at an Application Load Balancer with your own certificate, or keep the per-instance self-signed certificate. Back up the Stork monitoring database using EBS snapshots or AWS Backup, and resize the dedicated data volume independently as the estate of monitored Kea servers grows.

## Quick-Start Deployment

1. Launch the AMI on m5.large (or larger) with a security group allowing TCP 443 inbound for the dashboard and, if you bind Kea to serve your network, UDP 67-68 for DHCP clients

2. Wait approximately 2 minutes for first-boot secret generation to complete

3. SSH into the instance and retrieve the generated admin credentials from the root-only secrets file

4. Browse to https:// and log in to the Stork dashboard

5. Bind Kea to your target network interface and configure your subnets via the JSON config or API

## Kea Open-Source Ecosystem

Kea is developed by ISC and widely adopted by ISPs, enterprises, and universities worldwide. The open-source community actively contributes to its development, and Stork provides the graphical management layer that makes Kea accessible to operations teams who prefer browser-based administration over CLI configuration.

## cloudimg Support

24/7 technical support by email and chat. Help with deployment, binding Kea to your own network interfaces and subnets, adding further Kea servers to the Stork dashboard, reverse-proxy termination with your own domain and certificate, and backup planning for the monitoring database.