You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
This seems valuable. There are at least a couple ways we could do it, and I'm curious which one fits your needs best:
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 ....
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:
@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.
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 asgithub
andk8schain
.The text was updated successfully, but these errors were encountered: