Add Authconfig commmand which generates the auth config

[ingwonsong]

This PR proposes to add a new command which generates the auth config by authenticating with "workload identity" mechanism for corresponding platform, such as EKS, GKE, or AKS.

One of the purpose of this proposal is to separate the platform specific auth codes from the common docker related codes.

For example, the following script is analogous to krane $REGISTRY_SERVER/$REPOSITORY/$IMAGE_NAME:$TAG.

AUTH_CONFIG=$(authconfig --server $REGISTRY_SERVER)
echo "{ \"auths\": {\"$REGISTRY_SERVER\":$AUTH_CONFIG}}" > docker_config.json
DOCKER_CONFIG=docker_config.json crane $REGISTRY_SERVER/$REPOSITORY/$IMAGE_NAME:$TAG

[imjasonh]

Hey, this looks cool!

I'm not sure a new command is the right place for this, but maybe it makes sense as a subcommand in krane? That could even automatically update ~/.docker/config.json, sort of like crane auth login does. Taken further, maybe this just means krane login without any other args can detect auth provided by its environment and write to the docker config? 🤔

I'm not sure I understand the goal of "separat[ing] the platform specific auth codes from the common docker related codes" -- can you elaborate on that? The commands in crane/krane that operate on a registry are pretty lightweight in terms of dependencies, at least less than ecr-login code which you necessarily have to depend on for this. Is there another reason you prefer this as a separate command?

In any case, if this is useful to you as a separate tool, there doesn't appear to be any reason you couldn't put this in your own repo.

[ingwonsong]

Hi @imjasonh,

Thank you for quick review.

In short, the reason why I wanted to have a separate tool was the size.

11M authconfig/main  
13M crane/main  
18M krane/main

Let's assume that we already have some implementations - let's say this UserProgram - handling docker/OCI images in common way.
Then, to support the platform specific "workload identity" mechanism, we only need to have "auth" part, not including the generic docker handling codes. Then, we can save about 7MB with authconfig comparing with krane.

This approach can also avoid to link platform specific codes to UserProgram.

[imjasonh]

In short, the reason why I wanted to have a separate tool was the size.

That makes sense.

I think your best path forward will probably be to build and maintain your own tool that's purpose-built for your purposes, and can be maintained and released exactly according to your needs.

That also lets you make whatever changes you want to authconfig without needing my approval 😄

[ingwonsong]

Hi @imjasonh ,

As you commented, I have changed my mind to implement this in get auth command of krane,
and made a different PR: #1413

Please take a look into the PR.

Thanks!