Add ability to rotate Builder tokens used by the Supervisor

[christophermaier]

Current Situation

In order for the Supervisor to access private packages in Builder, it needs a Builder token. The only way to provide this currently is through an environment variable. This makes it difficult to change without taking the Supervisor and all its services down to change the token, should that be desired.

Background

There are products on the market that can help with such rotation tasks, such as Akeyless. They have a number of different integration points, but one of the simplest is to simply look for the necessary credentials in a file on disk. An agent is responsible for managing the contents of that file, while your application isn't concerned with rotation at all; it simply knows that to get the credentials it needs, it reads from the file.

The overall point here for us (Habitat) is to find a way to separate the lifecycle of the Builder token from the lifecycle of the Supervisor process. We should be able to have a mechanism where we can easily (preferably automatically) modify the token being used without having to restart the Supervisor or change how it runs.

Plan of Attack

Assuming a file-based approach, we would need to define a file in which the Supervisor could find its token, if necessary. It would be nice if this could be in a general Supervisor configuration file, but that could cause integration issues, since whatever was responsible for changing the value would need some knowledge of such a file's configuration format. One could imagine simple helper scripts that could help manage this, though, or possible indirection schemes. For instance, token: "secrettokenvalue" could be taken to be a literal value, while token: "ENV:HAB_AUTH_TOKEN" could mean "read the value from the HAB_AUTH_TOKEN environment value, and token: "FILE:/path/to/the/rotating/token/file" would indicate that the value should be read from a file. Alternatively, you could perhaps imagine token being a map with type and value keys, which could be a bit more explicit and self-documenting.

We do currently have a configuration file for the Supervisor (see here), as well as an issue (#7243) to make the configuration more dynamic. It seems like tackling that first would be beneficial for implementing this feature.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.