-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Basic auth #2242
Basic auth #2242
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
/retest
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lkingland, matzew The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
close/reopen, as the CI seemed to be stuck in nirvana |
This PR adds HTTP basic auth via CLI arguments to the "host" builder.
Because the Host builder is still behind a feature flag as it is experimental, the newly added flags are currently hidden.
The purpose of this addition is to enable a common use-case of using a third-party credentials management system rather than relying on those provided by the respective registries (docker credentials manager, AWS, etc) or the system. This is especially useful when considering that the "host" builder does not require docker nor podman be installed.
For example the venerable
pass
command line tool, or the recent Bitwarden, 1Password, etc.Simple Example
Here is an example of how this works using the Bitwarden
bw
command, which will prompt the user for the repository master password on each deploy.This workflow is roughly the same for the CLI password management apps.
Caching Credentials Example
While the following is Bitwarden-specific, it may serve to be illustrative on how this paradigm can be used to cache credentials. The above command will prompt the user interactively for the master password. To "cache" the credentials one would us
bw unlock
followed by providing the resultant session key to thebw get
command.Now the same deploy command will have credentials cached:
Future Work
There is a small amount of overlap between the docker pusher's credentials management and this implemention. I would hope to factor out some of these primitives into a shared
creds
package or similar.