Kea DHCP Stork

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting size. Choose a larger size for bigger deployments.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the dashboard. Stork serves plain HTTP on port 80, so for production, terminate TLS in front of it with your own domain (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Kea DHCP by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:kea-dhcp-stork:default:latest
az vm create \
  --resource-group <your-rg> \
  --name kea-stork \
  --image sac1647283583153:kea-dhcp-stork:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name kea-stork --port 80 --priority 1010

Step 3 - Connect to your VM

Connect to the VM over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

nginx serves the dashboard on port 80 and reverse-proxies to the Stork server on 127.0.0.1:8080. The Stork agent, the Kea control channel and PostgreSQL are all bound to loopback, so only nginx listens on a public address. Confirm that every service is active and check the bindings:

systemctl is-active postgresql isc-kea-dhcp4-server isc-stork-server isc-stork-agent nginx
sudo ss -tlnp | grep -E ':80 |:8080 |:8081 |:8000 |:5432 '

Expected output:

active active active active active LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 4096 127.0.0.1:8000 0.0.0.0:* LISTEN 0 4096 127.0.0.1:8081 0.0.0.0:* LISTEN 0 4096 127.0.0.1:8080 0.0.0.0:* LISTEN 0 200 127.0.0.1:5432 0.0.0.0:*

Step 5 - Retrieve your Stork admin password

On the first boot of every VM, kea-dhcp-stork-firstboot.service generates a unique Stork admin password, a PostgreSQL password and a Kea control API credential. It seeds the Stork database, rotates the default admin login to the unique password before the port is reachable, and registers the local Kea with Stork. It writes the Stork username, password and dashboard URL, plus the Kea control credential, to a root-only file. Read the file with:

sudo cat /root/kea-dhcp-stork-credentials.txt

The image contains no default or shared credential. First boot rotates the built-in Stork admin/admin login to a password unique to this VM, so the well-known default never works. Store the password somewhere safe.

Step 6 - Confirm the versions and health endpoint

nginx serves an unauthenticated /healthz endpoint for load balancer probes. Confirm the Kea and Stork versions and check that the dashboard responds:

kea-dhcp4 -V | head -1 stork-tool --version curl -s http://127.0.0.1/api/version curl -sI http://127.0.0.1/healthz | head -1

Expected output:

3.0.3 (3.0.3 (isc20260313155935 deb)) 2.4.1 {"date":"2026-05-08 13:24","version":"2.4.1"} HTTP/1.1 200 OK

Step 7 - Query the Kea control API

Kea 3.0 exposes an HTTP control channel directly on kea-dhcp4. On this image, the channel is bound to 127.0.0.1:8000, is never public, and is protected with a per-VM basic-authentication credential. The Stork agent uses the same credential to monitor Kea.

Send the core config-get command with the credential from Step 5 to see the sample DHCPv4 subnet that ships with the image. Then confirm that an unauthenticated request is rejected:

KU=$(sudo grep '^KEA_CTRL_USER=' /root/kea-dhcp-stork-credentials.txt | cut -d= -f2-)
KP=$(sudo grep '^KEA_CTRL_PASSWORD=' /root/kea-dhcp-stork-credentials.txt | cut -d= -f2-)
curl -s -u "$KU:$KP" -H 'Content-Type: application/json' -X POST \
  -d '{"command":"config-get"}' http://127.0.0.1:8000/ \
  | python3 -c 'import sys,json; print("demo subnet:", json.load(sys.stdin)[0]["arguments"]["Dhcp4"]["subnet4"][0]["subnet"])'
curl -s -o /dev/null -w 'unauthenticated request: HTTP %{http_code}\n' -H 'Content-Type: application/json' \
  -X POST -d '{"command":"list-commands"}' http://127.0.0.1:8000/

Expected output:

demo subnet: 192.0.2.0/24 unauthenticated request: HTTP 401

Step 8 - Sign in to the Stork dashboard

Browse to http://<vm-public-ip>/. Enter admin and the password from Step 5.

You are now signed in as the per-VM admin user. The first-boot rotation replaces the default password before the dashboard is reachable, so the well-known admin/admin login is already rejected.

Step 9 - Tour the DHCP dashboard

After you sign in, you land on the DHCP Dashboard. It summarizes every Kea server that Stork monitors, including DHCPv4 and DHCPv6 subnets, shared networks, address pool utilization and per-daemon service status. On this image, the local Kea appears immediately, with its DHCPv4 daemon healthy and the sample subnet loaded.

Step 10 - Inspect the registered Kea server

Open Services -> Machines and select the local machine to see its system information and monitored daemons. First boot registers and authorizes the local Kea automatically, so its DHCPv4 daemon appears here with its version and health. No manual agent approval is required.

Step 11 - Review subnets, pools and reservations

Open DHCP -> Subnets to see every subnet that Kea serves, with total and assigned address counts, pool utilization and the owning daemon.

The sample subnet 192.0.2.0/24 ships with an address pool (192.0.2.100 - 192.0.2.200) and a host reservation, so the dashboard has content to explore. The DHCP -> Host Reservations and DHCP -> Leases pages show reservations and live leases in the same way.

Step 12 - Configure Kea to serve your own network

The sample subnet exists only so that the dashboard has content. interfaces-config lists no interface, so the image does not hand out addresses on your network until you configure it. Edit the Kea DHCPv4 configuration to serve your own subnets:

sudo nano /etc/kea/kea-dhcp4.conf

Set "interfaces-config": { "interfaces": [ "eth0" ] } to the interface that Kea should serve. Replace the sample subnet4 entry with your own subnets, pools and options. Then validate and apply the configuration:

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl restart isc-kea-dhcp4-server

Stork picks up the new configuration on its next poll and shows your subnets on the dashboard. For the full configuration syntax, see the Kea Administrator Reference Manual.

Maintenance

• Back up your data. The data of the Stork dashboard lives in the local stork PostgreSQL database. Snapshot the OS disk or use pg_dump stork. The Kea configuration is the file /etc/kea/kea-dhcp4.conf, so keep it in version control.
• Rotate the Kea control credential with care. The Stork agent reads the per-VM Kea control credential from /etc/kea/kea-dhcp4.conf. If you rotate it, restart both isc-kea-dhcp4-server and isc-stork-agent.
• Apply security updates. Unattended security upgrades are enabled, so the OS keeps itself patched. Reboot when a new kernel is installed. Update Kea and Stork with sudo apt update && sudo apt upgrade.
• Add TLS. For production, front the dashboard with your own domain and a TLS-terminating reverse proxy or Azure Application Gateway.
• Add operators. After you sign in, manage additional Stork users and groups from Configuration -> Users.

Support

SecureAnyCloud provides 24/7/365 expert technical support for this image. Contact sales@secureanycloud.com.

ISC Kea and Stork are licensed under the Mozilla Public License 2.0. SecureAnyCloud provides this image, and additional charges apply for build, maintenance and 24/7 support.

Deploy on Azure

Launch Kea DHCP and Stork on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Prerequisites

You need an AWS account, an EC2 key pair in the target Region, and a VPC with a public subnet.

m5.large (2 vCPU / 8 GiB RAM) is the recommended instance type.

Configure the security group to allow inbound 22/tcp from your management network for SSH and 443/tcp for the Stork web UI. You can also allow 80/tcp, which only redirects to HTTPS.

Step 1 - Launch the AMI

Subscribe to the listing in AWS Marketplace, then launch an instance from the AMI into your VPC with the security group described above. Choose the m5.large instance type and attach your EC2 key pair.

First boot rotates the Stork admin login, generates the per-instance secrets and TLS certificate, and registers the local Kea. The dashboard is ready within a couple of minutes of launch.

Step 2 - Connect to your instance

Connect over SSH as the default login user for the operating system variant you launched. The login user differs per OS:

• Ubuntu 24.04: login user ubuntu, for example ssh -i your-key.pem ubuntu@<instance-public-ip>

ssh -i your-key.pem ubuntu@<public-ip>

Step 3 - Read your unique credentials

On first boot, the instance rotates the Stork admin password and generates the Kea control API credential. It writes them, along with the resolved web URL, to a root-only file. Read the file with sudo:

sudo cat /root/kea-dhcp-stork-credentials.txt

The file contains the Stork URL, the admin username, the per-instance STORK_ADMIN_PASSWORD and the Kea control API credentials (KEA_CTRL_USER / KEA_CTRL_PASSWORD). The image contains no default or shared login, and every secret is unique to your instance.

Step 4 - Verify the services and the security model

Confirm every component is running:

systemctl is-active postgresql isc-kea-dhcp4-server isc-stork-server isc-stork-agent nginx

All five report active. Confirm that the TLS front door answers and that plain HTTP redirects:

curl -sk -o /dev/null -w 'healthz(443): %{http_code}\n' https://127.0.0.1/healthz
curl -s -o /dev/null -w 'http(80) redirect: %{http_code}\n' http://127.0.0.1/

The output shows healthz(443): 200 and http(80) redirect: 301. Next, confirm that the Stork server, PostgreSQL and the Kea control channel all bind to the loopback interface only, so that nothing but the TLS front door is exposed:

sudo ss -ltn | awk 'NR>1{print $4}' | grep -E ':5432$|:8000$|:8080$|:8081$' | sort -u

Every product port is bound to 127.0.0.1: 127.0.0.1:5432 for PostgreSQL, 127.0.0.1:8000 for the Kea control socket, 127.0.0.1:8080 for the Stork REST server and 127.0.0.1:8081 for the Stork agent. The only public listeners are 22, 80 and 443.

Step 5 - Confirm the login model over TLS

First boot rotates the default admin / admin login, so the default login is rejected:

curl -sk -o /dev/null -w 'default admin/admin: %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data '{"authenticationMethodId":"internal","identifier":"admin","secret":"admin"}' \
  https://127.0.0.1/api/sessions

The request returns a non-200 status because the default password no longer works. The per-instance admin password authenticates over TLS and returns 200:

curl -sk -o /dev/null -w 'per-instance admin: %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data '{"authenticationMethodId":"internal","identifier":"admin","secret":"<STORK_ADMIN_PASSWORD>"}' \
  https://127.0.0.1/api/sessions

Step 6 - Query the local Kea through its control API

The HTTP control channel of the local Kea is bound to loopback and protected with the per-instance basic-auth credential from your credentials file. Query its running configuration. The response includes the demo subnet 192.0.2.0/24:

KP=$(sudo grep '^KEA_CTRL_PASSWORD=' /root/kea-dhcp-stork-credentials.txt | cut -d= -f2-)
curl -s -u "stork:${KP}" -H 'Content-Type: application/json' \
  -X POST --data '{"command":"config-get"}' http://127.0.0.1:8000/ | grep -o '192.0.2.0/24' | head -1

Without the credential, the same endpoint answers 401. It is also unreachable from outside the loopback interface.

Step 7 - Sign in to the Stork web UI

Open the Stork UI in a browser at https://<instance-public-ip>/. The instance uses a per-instance self-signed TLS certificate, so accept the browser certificate warning, or front the instance with your own domain and certificate. Sign in with the admin username and the STORK_ADMIN_PASSWORD from your credentials file.

The DHCP dashboard shows the monitored Kea, its DHCPv4 daemon, the subnet count and address pool statistics at a glance.

The subnets view lists each subnet with its address pools and utilization. Here it shows the demo 192.0.2.0/24 subnet with its pool 192.0.2.100 - 192.0.2.200.

The machines view shows the local Kea already registered and authorized, with its agent version, monitored DHCPv4 daemon and resource usage.

Step 8 - Point Kea at your own network

Out of the box, the bundled Kea serves no network interface (interfaces-config is empty), so the image cannot act as a rogue DHCP server on your VPC. The demo subnet exists only so that the dashboard shows real content.

To serve your own network, edit the interfaces-config and subnet4 sections of /etc/kea/kea-dhcp4.conf, then restart Kea:

sudo systemctl restart isc-kea-dhcp4-server

Stork reflects the change automatically when the agent next polls Kea. To monitor additional Kea servers, install a Stork agent on each one and register it with this Stork server from Services -> Machines -> Installing Stork Agent on a New Machine.

Step 9 - Data volume

The PostgreSQL data cluster lives on a dedicated data volume mounted at /var/lib/postgresql. Confirm the mount:

df -h /var/lib/postgresql | tail -1

Because this is a separate EBS volume, you can snapshot it with EBS snapshots or AWS Backup. You can also resize it independently of the OS disk as the number of monitored Kea servers grows.

Support

SecureAnyCloud provides 24/7 technical support for this product by email and live chat at sales@secureanycloud.com. We 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 TLS certificate, and backup planning for the monitoring database.

Kea and Stork are trademarks of Internet Systems Consortium. This image is not affiliated with, endorsed by, or sponsored by ISC. The Kea and Stork names and logos are used nominatively to identify the open source software shipped in this image.

Deploy on AWS

Launch Kea DHCP and Stork with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com