amazon-ecs-local-container-endpoints
amazon-ecs-local-container-endpoints copied to clipboard
awslabs
Support SSO
This does not support "aws configure sso". If I copy the credentials into the ~/.aws/credentials file it works. Can support for sso be added
I have fixed this by upgrading to the latest version of the aws sdk changes. Created new branch with changes, but don't have permission to push
@davidsteed If you have SSO working, can you submit a pull request with the code change?
Yes all I did was the following
go get -u github.com/aws/aws-sdk-go go mod vendor
Then built the code. I had to change the Makefile as it does not work on Windows bash.
I was going to submit the pull request, but can't run the automated tests as the way go genrate works also does not work on windows bash - I get my mac back next week.
The image does appear to work though
On Tue, 9 Feb 2021 at 19:10, Wesley Pettit [email protected] wrote:
@davidsteed https://github.com/davidsteed If you have SSO working, can you submit a pull request with the code change?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/awslabs/amazon-ecs-local-container-endpoints/issues/51#issuecomment-776172866, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECIHJZDWQPGVSW7LRTBNITS6GCDDANCNFSM4XKUNIDA .
I can confirm @davidsteed is correct, and I am also currently struggling with the make generate functionality.
I'll submit a PR (also) if I can get this working and passing tests. For now, it's perfectly functional for our immediate AWS SSO needs.
I just got this working locally with all tests passing, PR incoming.
The root of the issue occurs when running make generate with the vendor/ directory still existing.
Once the vendor directory is removed, then make generate passes, and finally the binary can be built with all current tests passing.
I merged #52
This project isn't super actively maintained so not sure when we will get around to doing a release.
THANK YOU! Even without a formal release, this is a really big feature for us to carry only a custom binary instead of a custom fork + custom binary. I'll be passing the positive feedback along to our TAM, and finally getting our customer commentary for the AWS SSO team.
Hello, is there any planned release including this change?
As an alternative, how can I build the docker image locally? Edit : got it git clone make release
@Kaelten @arnaudmm @masteinhauser I think the latest release should include it: https://github.com/awslabs/amazon-ecs-local-container-endpoints/releases/tag/v1.4.0
Based on the fact that the release was cut after I merged the SSO PR. I checked the commit history.
@Kaelten @arnaudmm @masteinhauser I think the latest release should include it: https://github.com/awslabs/amazon-ecs-local-container-endpoints/releases/tag/v1.4.0
Based on the fact that the release was cut after I merged the SSO PR. I checked the commit history.
I'm still getting the below when I try to use 1.4.0
NoCredentialProviders: no valid providers in chain\ncaused by: EnvAccessKeyNotFound: failed to find credentials in the environment.\nSharedCredsLoad: failed to load profile, staging.\nEC2RoleRequestError: no EC2 instance role found\ncaused by: RequestError: send request failed\ncaused by: Get http://169.254.169.254/latest/meta-data/iam/security-credentials/: dial tcp 169.254.169.254:80: connect: connection refused"
@Kaelten @arnaudmm @masteinhauser I think the latest release should include it: https://github.com/awslabs/amazon-ecs-local-container-endpoints/releases/tag/v1.4.0
Based on the fact that the release was cut after I merged the SSO PR. I checked the commit history.
scratch that, it turns out I wasn't actually using 1.4.0 since I was trying to use latest as the tag. It'd be awesome if this could be updated to support multi-arch tagging so we didn't have to hard code amd/arm into our config files.
A slightly different solution to this and any other credentialing woes is to provide refreshable credentials directly from the host via an IMDS server, which I've elaborated on in #171
