Skip to content
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

Add support for filepath-based authn.Keychain #1595

Closed
hasheddan opened this issue Mar 14, 2023 · 2 comments · Fixed by #1603
Closed

Add support for filepath-based authn.Keychain #1595

hasheddan opened this issue Mar 14, 2023 · 2 comments · Fixed by #1603

Comments

@hasheddan
Copy link
Contributor

Currently, it is possible to configure the location of the auth config file in the default keychain, but only if there is not already a config file at the default path. Furthermore, the name of the file (config.json) is hard-coded and cannot be overridden. It would be helpful to support passing an arbitrary path to credentials to be used, perhaps as part of a multi-keychain. This would be straightforward to implement in consume in the same manner as other alternative keychain implementations, such as github and k8schain.

@imjasonh
Copy link
Collaborator

This seems valuable. There are at least a couple ways we could do it, and I'm curious which one fits your needs best:

  1. document an env var that authn.DefaultKeychain will look for before considering ${DOCKER_CONFIG} (e.g., GGCR_DOCKER_CONFIG) which specifies the full path of the file. For example, GGCR_DOCKER_CONFIG=test/cfg.json crane ls ....
  2. implement authn.NewConfigKeychain(filename string) that returns the otherwise normal DefaultKeychain implementation, but pointed at the full filename instead of ${DOCKER_CONFIG}/config.json, for example:
remote.Image(ref,
    remote.WithAuthFromKeychain(authn.NewConfigKeychain("test/cfg.json"))

@jonjohnsonjr might have even better ideas.

@hasheddan
Copy link
Contributor Author

@imjasonh I think both could be implemented as independent functionality, but I was thinking more in the vein of (2) as it allows the natural keychain precedence to be used with potentially multiple config files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants