Boardwalkd: API service accounts #19
Description
Boardwalk is intended to be able to be used for workflows that run for very long periods of time; weeks or months. Currently all authentication is built around human users authenticating as themselves. The default API token session lifetime is 2 weeks, and if a session token expires, boardwalk will automatically attempt to get a fresh session token by either opening the default web browser to re-authenticate, or by prompting the user to visit an authentication url.
The current API auth model works very well where users are interacting with the CLI on a workstation, but doesn't translate well when the CLI is executed by some kind of headless shared scheduler, such as a cron job, for example. Some concept of "service accounts" is needed for access granted to systems or services that aren't humans.
Service accounts should
- Be be managed via a privileged interface, such as an Admin UI
- Be able to have a longer, possibly variable session lifetime compared to normal users. This lifetime should be visible in the admin interface
- Be able to be identified with individually, such as by the name of the service or system where they are used
- Notify admins when a service account is about to expire. We don't want service account authorization to silently expire, especially with regard to long-running workflows
Service accounts may
- Display in the Admin interface when they were last used
- Be able to be restricted based upon IP address or CIDR range