Open christophermaier opened 3 years ago
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.
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.
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, whiletoken: "ENV:HAB_AUTH_TOKEN"
could mean "read the value from theHAB_AUTH_TOKEN
environment value, andtoken: "FILE:/path/to/the/rotating/token/file"
would indicate that the value should be read from a file. Alternatively, you could perhaps imaginetoken
being a map withtype
andvalue
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.