|
|
## Problem statement
|
|
|
|
|
|
As of 1.8.0, Kea does not provide any access control natively. It is possible to establish some access control by deploying a reverse http proxy on each Kea server. This solution is sub-optimal for several reasons. First, deployments with many DHCP servers would have to maintain many web servers, which is a burden and may be outside of scope of DHCP admins. Second, we need more fine grained access control than the reverse proxy can provide. Third, there is a desire to secure remote access to Kea API commands which is not addressed with the reverse proxy.
|
|
|
|
|
|
As of 2.1.3, Kea does provide several enhancements:
|
|
|
|
|
|
- there is basic HTTP authentication that can be used to restrict access, using credentials (username/password). The limitation is that it is boolean - either all or nothing is allowed
|
|
|
- there is TLS support with strong TLS certificates checking. It is much stronger protection than credentials. However, it shares the same limitation - if the cert is valid, everything is allowed.
|
|
|
|
|
|
There are two basic technical issues:
|
|
|
- **Confidentiality**: communication over the network to CA is visible, it can be sniffed by e.g. Wireshark and whole content can be read while there can some sensitive data e.g. location and credentials to lease database;
|
|
|
- **Authentication and access control**: any party may connect to CA (remotely or from localhost) and invoke any API command and e.g. shutdown Kea, change the configuration, or read the whole configuration, including sensitive data.
|
|
|
|
|
|
Use Cases
|
|
|
- Kea administrators would like to secure their DHCP servers from access by random users with access to the Kea server by authenticating users.
|
|
|
- Kea administrators would like to provide differential privileges and access to different users and applications. In particular the ability to limit the scope of configuration changes a user or role can make a very popular feature. In many larger universities and enterprises DHCP administration is by department or administrative realm, with a core team providing the service and local administrators maintaining details associated with their own users.
|
|
|
- Kea administrators may be required to comply with organizational security policies for user authentication and access control. These policies can include: use a specific authentication service, use a specific password complexity policy, avoid sending secrets in cleartext across the network, implement application access logging or even establish change controls.
|
|
|
- Some users may wish to integrate Kea with general purpose monitoring systems such as Nagios or Zabbix, or the ISC Stork system, and to provide read-only data to those systems.
|
|
|
- An integral feature of the access control system is access **logging**. The administrator would like to have a log of all authentication attempts, whether successful or failed, and all commmands executed, with the associated UserID.
|
|
|
|
|
|
For a design that attempts to fulfill those requirements, see [here](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/rbac-tls-design).
|
|
|
|
|
|
## Transport requirements
|
|
|
|
|
|
* [x] T1 - Kea MUST provide a way to connect remotely in a secure way using TLS (https).
|
|
|
|
|
|
## Authentication requirements
|
|
|
|
|
|
* [x] A1 - It MUST be possible to identify and authenticate users.
|
|
|
* [x] A2 - If any PKI (Public Key Infrastructure) external to Kea is supported, such support MUST be optional. In other words, existence of external PKI MUST NOT be required for this access control to function properly.
|
|
|
* [x] A3 - The access MUST also apply to local users. In particular, a local, non-privileged user MUST NOT be able to bypass this access control.
|
|
|
* [ ] A4 - We should specifically consider machine interfaces in the authorization. These may/will be authenticated differently than the human users, but may need to have limited access. For example, it would be ideal if Stork could 'log-in' and provide the userID of the user authenticated in Stork to Kea, so that Stork session would be subject to that user's privilege level.
|
|
|
|
|
|
----
|
|
|
additional authentication requirements (future) below
|
|
|
* [ ] A7 - It must be possible in the future to add authentication realms. Initially this will be local authentication, but we should plan to add authentication via LDAP/AD, possibly also Apache. It should be possible for external developers to add other authentication methods, such as 2FA.
|
|
|
* [ ] A8 - For local authentication it is desirable to be able to configure a set of password requirements (minimum/maximum total length, min/max (letters, uppercase, lowercase, numbers, special characters) and to specify which special characters are allowed. This is so that an organization with a pwd policy can conform to that policy.
|
|
|
* [ ] A9 - For local authentication it should be possible for the administrator to force a pwd reset on next log-in on all, or any specific user.
|
|
|
* [ ] A10 - Authentication attempts should be logged, including both successes and failures.
|
|
|
* [ ] A11 - There should be some concept of a continuous session, wherein the user who has authenticated is still identified and authenticated (e.g. we don't want to require re-authenticate with every command the user tries to perform).
|
|
|
|
|
|
## Authorization requirements
|
|
|
* [ ] Z1 - Privileges consist of a list of content areas with an associated access level.
|
|
|
* [ ] Z2- Initially the 'content area' may be defined as the entire Kea configuration file, but eventually we would like to have more granular controls.
|
|
|
* [ ] Z3 - It MUST be possible to control access to Kea API commands using RBAC (i.e. there must be a way to say that to use command X a user must belong to role Y. We should define groups of similar api calls to simplify administration of API content areas.
|
|
|
* [ ] Z4 - Administering local user accounts is a content area (currently associated with the Admin role). (Or is this determined by file access to a user/pwd file stored outside of Kea??)
|
|
|
* [ ] Z5 - It should be possible to limit access based on areas of the Kea configuration. The primary use case here is restricting access to modify subnets, but it is also reasonable to expect that Kea application secrets (e.g. for communicating with CB) and Kea interface addresses, may have separate access permissions. (It might be acceptable to require use of the configuration backend in order to get the subnet-based restrictions, if that is helpful in implementing this feature.)
|
|
|
* [ ] Z6 - The initial list of access restrictions will be modest (read and write). The design should be reasonably easy to be expanded in the future.
|
|
|
* [ ] Z7 - There MUST be some way to associate privileges with roles, e.g. Admin can read and write the entire configuration and add and remove users. Help desk can use only read-only commands, Dept admin can read-write host reservation data within the subnets assigned to their department and administer users in the Dept admin group, Stork users are all read-only.
|
|
|
* [ ] Z8 - Stork should authenticate with Kea e.g. via a shared secret, and then provide the userID of the use authenticated in Stork. If that user is also defined in Kea, the session can inherit their privileges.
|
|
|
* [ ] Z9 - We should provide some built-in default roles, including the Kea administrator role (the highest level of privileges and access controls)
|
|
|
|
|
|
|
|
|
## Management requirements
|
|
|
* [ ] M1 - The act of adding new users (adding new account or generating new certificate) MUST be reasonably simple and well documented.
|
|
|
* [ ] M2 - It MUST be possible to assign and unassign users to specific roles by an administrator. It is preferable if a user can be associated with multiple roles, meaning that their privileges are the union of the privileges associated with all of those roles.
|
|
|
* [ ] M3 - Alternating user-to-role mapping (i.e. creating user a new role or revoking an existing role) MUST not require changing anything on the client configuration (in particular, if we use certificates, this MUST not require issuing or altering the certificate)
|
|
|
* [ ] M4 - User storage and user-to-role mapping MUST be extensible. The initial implementation can keep this information in a local text file or even in the config file, but it MUST be possible to extend this to other storage types in the future using hooks. In particular, if we implement support for authentication via AD, we can expect that some users will want to manage user roles in AD.
|
|
|
* [ ] M5 - It is essential to create a log of all authentication attempts, whether successful or failed, with the userID. This is the only way to tell if there has been an attempt at brute force password cracking.
|
|
|
* [ ] M6 - It is essential to create a log of remote api calls, indicating which remote user (by authenticated userID or if not available some other id - IP address maybe?) made the call - and if possible, was the api call successful (e.g. a config command could fail)
|
|
|
* [ ] M7 - It is desirable to be able to create a changelog that identifies which user (not group or role) made a particular configuration change and at what time. Presumably this can be captured when the authorization is tested.
|
|
|
|
|
|
|
|
|
## Application Integration
|
|
|
**Nagios, Zabbix, etc** - I am not sure if all of these require a local agent? Or how in the absence of snmp we would integrate with these, but it is likely that we will have users wishing to add Kea to their enterprise-wide monitoring systems. These application would presumably need to be identified and provided with some shared secret to have read-only access for monitoring.
|
|
|
**Stork** - We are recommending that many of our Kea users may wish to use the ISC Stork monitoring utility for Kea. It is desirable to consider the AAA solution as optionally including Stork. So, for example, Kea could provide the Stork application with read-only access. Alternatively, Kea might permit only the super-admin to make Kea configuration changes locally, and require all other users to make changes through Stork, so Stork could provide more fine-grained access controls.
|
|
|
**Prometheus** - Today Prometheus integration is via the Stork Agent, so any authentication relationship would be outside of Kea itself.
|
|
|
**Backends** -
|
|
|
|
|
|
|
|
|
# RBAC-TLS Definitions
|
|
|
|
|
|
`TLS` is Transport Layer Security and it's the secure way how to use http tranport. It's the `s` in `https`.
|
|
|
`RBAC` stands for Role Based Access Control. It's a type of access control, where users are assigned to certain roles and the access privileges (whether someone can do something or not) are based on a role privileges.
|
|
|
We would like to implement those technologies in Kea. This document lists requirements we'd like to fulfill with that implementation.
|
|
|
|
|
|
For preliminary discussion, see [here](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent-discussion). For design that attempts to address those requirements, see [design](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent-solution).
|
|
|
|
|
|
It might be helpful to look at the [Apache project](https://httpd.apache.org/docs/2.4/howto/auth.html) treatment of authentication and access control for a widely acceptable example of application administration controls. |