Requirements for monitoring Kea servers

The following settings and specifications are required for IPAM to access your Kea servers.

Base supported Kea version

3.0.0 (first LTS); tested up to 3.1.3.

Configuration

• Setting HTTP/HTTPS Control Socket

  The socket-type must be http or https. When using https, TLS is required. The socket-address and socket-port specify an IP address and port to which the HTTP service will be bound to. For more information check Kea Administrator Reference Manual.

• Authentication

  Although not required, we strongly recommend configuring clients that will have access to the API service. Clients with access are specified in the authentication parameter. It is mandatory to set type to basic as this is currently the only supported authentication mechanism. The real should be set to kea-dhcpv4-server when configuring IPv4 service and kea-dhcpv6-server for IPv6. Client credentials are set in the array under clients parameter.

  Socket and authentication configuration example (depicts IPv4 service configuration; for IPv6, the root parameter must be set to Dhcp6):

  "Dhcp4": {
      "control-sockets": [
          {
              "socket-type": "https",
              "socket-address": "10.10.10.10",
              "socket-port": 8001,
              "http-headers": [
                  {
                      "name": "Strict-Transport-Security",
                      "value": "max-age=31536000"
                   }
              ],
              "trust-anchor": "/path/to/the/ca-cert.pem",
              "cert-file": "/path/to/the/agent-cert.pem",
              "key-file": "/path/to/the/agent-key.pem",
              "cert-required": true,
              "authentication": {
                  "type": "basic",
                  "realm": "kea-dhcpv4-server",
                  "clients": [
                  {
                      "user": "admin",
                      "password": "strong-password"
                  } ]
              }
          },
          {
              "socket-type": "http",
              "socket-address": "10.10.10.11",
              "socket-port": 8002,
              "authentication": {
                  "type": "basic",
                  "realm": "kea-dhcpv4-server",
                  "clients": [
                  {
                      "user": "admin",
                      "password": "strong-password"
                  } ]
              }            
          }
      ],
  
      "subnet4": [
          {
              ...
          },
          ...
      ],
      ...
  }

  Kea changed its configuration in a specific version: it no longer allows client credentials directly in the file. Instead, you must store the username and password in separate files, specified by user-file, password-file, and an additional directory parameter that handles the common file path.

      "control-sockets": [
        {
          "authentication": {
            "directory": "/etc/kea",          
            "clients": [
              {
                "password-file": "pswd-dhcp4",
                "user-file": "user-dhcp4"
              }
            ],
            "realm": "kea-dhcpv4-server",
            "type": "basic"
          },
          "socket-address": "10.10.10.11",
          "socket-port": 8001,
          "socket-type": "http"
        },
      ]

• Hook libraries

  IPAM utilizes hook libraries that were open-sourced by ISC and have been shipped with the Kea package since v3.0. Kea services must be configured to load these libraries.

  Required libraries: libdhcp_subnet_cmds.so, libdhcp_host_cmds.so, libdhcp_lease_cmds.so

  Configuration example:

  "Dhcp4": {
    ...
    "hooks-libraries": [
        {
            "library": "libdhcp_subnet_cmds.so"
        },
        {
            "library": "libdhcp_host_cmds.so"
        },
        {
            "library": "libdhcp_lease_cmds.so"
        }
    ]  
  }

SSL/TLS certificate

When using HTTPS in Kea, the TLS/SSL certificate must include the Kea server IP address in the SAN.

Known limitations

• Hosts reservations are made only in configuration file.

• When removing subnets from Kea using IPAM, neither the leases nor the host reservations associated with a subnet outside the configuration file are removed. This method is the most secure because it ensures the server retains awareness of all leases issued to clients in that subnet. However, deleting the subnet can lead to configuration issues or conflicts. For instance, once the subnet is removed, an administrator might create a new subnet reusing the same ID. In that case, any existing leases or static reservations tied to the old subnet would clash with the new one. Therefore, we advise using this command very carefully.