Authenticate using AWS instance role

[jankosecki]

Hi,

I'm wondering if it's possible and if so how to authenticate crane with ECR using AWS instance role the way Kaniko does it.
I've tried to play with it by adding config.json and ecr-helper to my crane:debug image but that didn't seem to work.
Is there a way to avoid having to pass username:password secret to push/pull from ECR?

[jonjohnsonjr]

I've been playing with the idea of making this easier in the next couple months, but I don't have a great solution right now. Where are you running the container?

Some breadcrumbs to other discussions:

ko-build/ko#3
#731

I've tried to play with it by adding config.json and ecr-helper to my crane:debug image but that didn't seem to work.

The opposite approach seemed to work, adding crane to the kaniko images: #731 (comment)

[jankosecki]

Thanks for pointing me to the solution. Despite doing some googling before I asked the question here, I somehow missed this approach. I guess piggybacking on kaniko's image is not a terrible idea and will definitely give it a try tomorrow.

The containers are running in kOps-managed cluster in AWS.
I understand that you don't want to bloat the image but with k8s deprecating docker you might find more people coming and asking these kind of questions. I started looking at crane as I needed an alternative for copying image via docker.

[jonjohnsonjr]

with k8s deprecating docker you might find more people coming and asking these kind of questions

Yep, it's definitely something that's on my radar.

For k8s, I've considered turning k8schain into a credential helper so that image pull secrets work, with optional magic for aws/azure/gcp credential providers.

For other environments, I've considered spinning up a magical registry that injects the appropriate cred helpers and auth config, something like:

image: creds.ggcr.dev/aws/gcr.io/go-containerregistry/crane:debug

This would allow you to have only the cred helpers you need without us having to publish a million different flavors of each image.

Alternatively, we could just publish a single fat image like kaniko that lived alongside the normal ones... but I don't want to be responsible for maintaining every relevant cred helper, at least not in this project.

I'm just staring at the cross-product of every possible image variant and it frightens me :) the magic registry thing intrigues me because it feels like it cleanly separates concerns and doesn't require you to "denormalize" every possible image variant.

[jankosecki]

Great to hear that! I'll be closely watching this repo for those changes.
For now I can confirm that a solution suggested in the linked thread works for me. By piggybacking on kaniko executor image, I'm able to copy images between ECR repos authenticating via IAM role of an EC2 instance running the pod.

Re. magical registry - I'm only used to work with EC2 instances accessing ECR, which is quite an straightforward path, but I understand your concern of all possibles combinations. However, I'd imagine that just providing k8schain as kaniko does will cross out lots of the use-cases where people use the some cloud provider for their CI and repository.

[jonjohnsonjr]

Forgot to ping this issue -- we put a prototype together to do something like this: https:/docker-credential-magic/docker-credential-magic

I haven't had time to hack up a registry version or implement a k8schain helper, but the tool should make it easy to patch the crane images to include the ecr cred helper. Let me know if you have a chance to play with it :)

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.