|
|
# Kea Security
|
|
|
|
|
|
This page discusses various aspects related to the Kea software security. This is a living document. This page will eventually be merged into [Kea ARM](https://kea.readthedocs.io).
|
|
|
|
|
|
The sections below are not listed in any particular order. This is not a recommendation for any specific practices. Many topics here are simply something to consider. In many cases, there's a trade-off between convenience and higher security. It is up to the administrator to make those choices.
|
|
|
|
|
|
## Cryptography in Kea
|
|
|
|
|
|
- TSIG
|
|
|
|
|
|
## Database connection
|
|
|
|
|
|
## Running as non-root
|
|
|
|
|
|
## TLS connection to Control Agent
|
|
|
|
|
|
## Security of control channel
|
|
|
|
|
|
## CA authentication
|
|
|
|
|
|
|
|
|
# Future improvements
|
|
|
|
|
|
This is a list of improvements that are planned in the future. Please contact ISC if any of them are of particular importance for you:
|
|
|
|
|
|
- **Implement TLS support in CA**. CA exposes REST API over HTTP interface. The Kea ARM explains how to set up a reverse proxy, e.g. using apache or nginx to provide HTTPS transport for it. However, setting up the whole reverse proxy is a nuisance from maintenance perspective, especially if the number of servers is large. We are planning to implement a more lightweight solution.
|
|
|
|
|
|
- **Role Based Access Control**. As of Kea 1.9.3, there' is basic HTTP authentication available. It can be used to authenticate users who send API commands. However, the access is basic right now - it's all or nothing. A more fine grained access control is needed. There is a work in progress to provide this capability.
|
|
|
|
|
|
- **Block signals**. Since its early days, Kea is able to react to POSIX signals. This simple, but very reliable mechanism is very popular. By sending a HUP signal to Kea, it can be told to reload its configuration. This is frequently used to trigger reconfiguration event in Kea, without restarting the whole service. However, there is a deficiency from accountability perspective. The signal mechanism does not provide any information about its sender. In general, only the process owner or root are able to send signals and that is enforced by the kernel. In the future, we may provide a configuration parameter to disable HUP and TERM signals. This would improve accountability as, together with configured authentication, it would eliminate the potential for a root user to reconfigure Kea. This is only a minor improvement, though, as root can always edit the local config file, kill the process and restart it. However, this is a much more intrusive process, so it would be much harder to hide in case of bad actor trying to plant unauthorized changes. |
|
|
\ No newline at end of file |