imgpkg should support iaas pre-authed registries when running on preconfigured vms/cointainers

[cppforlife]

Describe the problem/challenge you have

context: iaas provides (aws, gcp, azure...) have registries that could be made accessible (can auth to) on iaas provided vms via iaas metadata channel (e.g. gke cluster can be allowed to pull content from private gcr).

use case: kapp-controller users want to use iaas provided registry on their kubernetes cluster (cluster is preauthenticated to that registry). since kc runs imgpkg within its controller pod on a iaas provided vm, it should be able to authenticate to iaas provided registry without users having to provide additional credentials.

it should still be possible for imgpkg to be configured with additional credentials but it should also be smart enough to use "iaas registry provided creds" where applicable.

Describe the solution you'd like

imgpkg does not require any additional configuration and just knows when to use additional creds if available.

Anything else you would like to add:

• ggcr has something for this: https://github.com/google/go-containerregistry/tree/main/pkg/authn/k8schain. not sure if we can just directly use it.
  • knative uses above library in its controller pod to resolve tags to digests (might be a good example)
• kubelet has some logic for this as well. pretty sure its not using ggcr.

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[DennisDenuto]

@cppforlife

This looks like a great improvement to imgpkg.

My initial thought is, having an implicit auth mechanism (i.e. configuring imgpkg keychain based on IAAS metadata) adds complexity to the UX specifically around auth (there are currently already multiple ways to provide auth to imgpkg, with a defined priority of which auth mechanism is used when there is overlap).

I'm wondering if we can leverage the already set ways to provide auth to imgpkg. Specifically via env vars

What are your thoughts around providing a helper command imgpkg print-iaas-envs that could render out the export IMGPKG_REGISTRY_HOSTNAME_0 for the consumer to eval. Based on my high level understanding, the IAAS metadata provides dockerconfig files. Sooo I think this should be possible.

[cppforlife]

What are your thoughts around providing a helper command imgpkg print-iaas-envs

im -1 on pushing such logic to clients, since clients have no idea what is possible and not possible. e.g. kapp controller has no idea whether it's running on aws/gcp/etc.

the IAAS metadata provides dockerconfig files.

not sure if that's true (i thought they were dealing with tokens directly), but that's something that only imgpkg could know about.

[DennisDenuto]

since clients have no idea what is possible and not possible

True, the client might not know it is running on an IaaS. In that case the client could always just run eval $(imgpkg print-iaas-envs) and essentially no-op.

However, I do think the above does adds a potentially unnecessary step.

Another reason to have an implicit auth mechanism (and not inject via env variables) would be credential rotation. Specifically, in a long-running environment, if the IaaS creds are rotated, then having imgpkg access the latest creds via metadata service is obviously preferred (and not needing to run the print-iaas-env command before every invocation - just in case).

Also, from an engineering perspective, it will require less effort to just use the k8s_keychain provided by ggcr.

I'm going to accept and prioritize this issue :-)

[DennisDenuto]

Closing. This has been resolved in https://github.com/vmware-tanzu/carvel-imgpkg/releases/tag/v0.18.0