> Instead, its documented approach to running as some other account is to add some of the superuser's privileges to Kea [...]
Not disagreeing, just want to mention that Kea can run fine without privileges, which is also documented at the link provided. Key is to use DHCP relaying, a technique which becomes relevant quickly in larger setups anyways because you cannot (or don't want to) give the DHCP server access to all subnets: Instead of the DHCP server(s) processing local requests, DHCP relaying agents encapsulate and unicast-forward the whole DHCP request-response traffic to centralized DHCP instance(s). Those relaying agents (on switches/routers) do require privileges but potentially posing a smaller attack surface due to being much simpler. Sadly, ISC has not made a successor dhcprelay as part of Kea, but luckily systemd-networkd implements the RelayTarget parameter, adding this capability (at least for IPv4).
Not disagreeing, just want to mention that Kea can run fine without privileges, which is also documented at the link provided. Key is to use DHCP relaying, a technique which becomes relevant quickly in larger setups anyways because you cannot (or don't want to) give the DHCP server access to all subnets: Instead of the DHCP server(s) processing local requests, DHCP relaying agents encapsulate and unicast-forward the whole DHCP request-response traffic to centralized DHCP instance(s). Those relaying agents (on switches/routers) do require privileges but potentially posing a smaller attack surface due to being much simpler. Sadly, ISC has not made a successor dhcprelay as part of Kea, but luckily systemd-networkd implements the RelayTarget parameter, adding this capability (at least for IPv4).