In my company, we have a series of scripts/apps/build servers that interact with Octopus using the Octopus API, Octopus CLI and the Octopus.Client.dll. We are required to provide an API key to the API/Client.dll/Build Server/CLI. Up until this point, we have been using API keys from user accounts. Once a person leaves the company, and their credentials are disabled, we have to go through the dance of frantically updating the API key on various external tooling. In one case our build server stopped pushing packages to Octopus Deploy after a person left.
What are some recommendations around API key management?
Leverage the service account feature in Octopus Deploy. Service accounts can only log in via the API/CLI/OctopusClient.dll. They do not have passwords. Their only access is provided via an API key.
Create a unique service account for each build server, external tool, or custom script. Assign that service account to a specific team which has permissions to perform a specific action only. In the event a service account’s API key is compromised, you can immediately delete the key and/or disable the account without affecting other apps or people.
For example, a build server service account only has access to push packages to Octopus and create and deploy a release to Dev. It does not have permission to promote releases to Test, Staging or Production. It does not have permission to add/remove/modify projects.
As for the storage of the API keys, it depends on the tooling/application. Most build servers provide the ability to save secrets/sensitive variables. Use the built in tooling when possible. When that is not possible, look into storing those keys in a centralized secret store (Azure Key Vault for example).
Finally, create a process to rotate the API keys. For example, once a month, have a process create a new API key, update the appropriate app. A central location makes this much easier to manage as only one spot will need to be updated.
The final point I’ll make is using API keys is okay when building/working on a script or an app or trying out something with the CLI. But once the script/app/whatever moves beyond a POC the key should be swapped out for a service account.