Open AntonBy opened 5 months ago
Hello,
Thanks for reporting this issue. We will look into updating the relevant documentation and let you know once it's updated. We will also check if there is a way for ECS to prefer TES creds
@AntonBy, just curious, what's your use case here? ECS is already an orchestration service, why add Greengrass on top of that?
@jcosentino11 It's a part of our pipeline. We want to have a virtual "gg-device" for integration tests
Ah okay. To make this work in the meantime, you can write your own CredentialsProvider by copying the above, and either switch the order or simply remove the ECS credentials part so that it only attempts to resolve TES. Then pass in your custom provider
https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/credentials-specify.html
Thank you for answer. I used this approach with the custom provider, all worked properly.
All I wanted to offer - is to add a short note in https://docs.aws.amazon.com/greengrass/v2/developerguide/token-exchange-service-component.html with information about a potential conflict between TES credential env-variables and ECS env-variables(+ the link on the custom credentials provider page)
This task was created after 6 hours were spent investigating the access issue. BUT "Greengrass from ECS" could be a quite rare case, so I'm not certain it's worth the effort
Feature description The last version of documentation contains short descrption how TES works. And it really works with using DefaultAWSCredentialsProviderChain(AWS SDK Java). It works as native application, as Docker application, but it doesn't work as ECS Service. Because ECS Service TaskRole credentials will overlap GreengrassTockenExchangeRole credentials from TES. It would be great to have a short comment about this in TES documentation.
Use Case To avoid wasting time on issue
Proposed Solution Upgrade documentation OR/AND suggest solution
Other