Boardwalkd: API service accounts

[m4wh6k]

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