Feature: Add support for "Service Accounts" #545
Merged
+246
−31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Since actions that require "admin" are only applied to session tokens, it means that customers need a means of supplying an session token. This can result in a session token that is stored within a vault service or user input for that given CI run.
This is typically fine in most cases considering admins have a lot of power in the account, however, in the scenario that you want to provide a greater level of automation, supplying a session token becomes cumbersome.
Hence, the idea of a "service account" then allows that increased level of autonomy since a session token can be create on behalf of the service account in the provider.
A service account is purely a user that can authenticate via email/password (meaning it has to be manually added into the org, and can't use an SSO user). This removes the 30d restriction that is applied to session tokens, and any external management that would be needed to be done by the user prior.
Changes
Intended Release
v9.3.0
No breaking changes since this currently extends the current configuration and doesn't change the existing behaviour.