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
The idea being we use use stdin/out from other binaries as the interface, optionally.
Something like ProviderKind::CredentialHelper which literally just calls format!("teller-credential-{} {}", bin, action)? Albeit without the command injection
This may also allow fancier credential syncing where we may have needed a template before, e.g. if i wanted to setup a docker registry auth where our secret is an arbitrary provider, we may teller put it by essentially calling docker login ${registry:-} -u ${user} --password-stdin. I think before i would have needed docker-temp.t and then overloaded DOCKER_CONFIG locations, or some shell logic.
The text was updated successfully, but these errors were encountered:
So that one may write custom providers of which are 'internal', a good example would be how
docker
does it:{ "credsStore": "ecr-login" }
ecr-login
provider, as written here: https://github.com/awslabs/amazon-ecr-credential-helperSo in teller world that may be:
or more likely:
The idea being we use use stdin/out from other binaries as the interface, optionally.
Something like
ProviderKind::CredentialHelper
which literally just callsformat!("teller-credential-{} {}", bin, action)
? Albeit without the command injectionThis may also allow fancier credential syncing where we may have needed a template before, e.g. if i wanted to setup a docker registry auth where our secret is an arbitrary provider, we may
teller put
it by essentially callingdocker login ${registry:-} -u ${user} --password-stdin
. I think before i would have neededdocker-temp.t
and then overloadedDOCKER_CONFIG
locations, or some shell logic.The text was updated successfully, but these errors were encountered: