Default credentials from environment variables in Docker image

[rvanlaak]

When working with the Docker image locally, that allows configuring any sort of key / secret on the client's DSN value.

When not configuring any client, the SQS default policy is to then connect to IAM to retrieve credentials / profile to determine region / credentials. The following notices then will get logged by common loggers (Symfony in this example):

[2023-03-13T15:50:53.777467+01:00] app.INFO: Failed to fetch Profile from Instance Metadata. {"exception":"[object] (Symfony\Component\HttpClient\Exception\TimeoutException(code: 0): Idle timeout reached for "http://169.254.169.254/latest/meta-data/iam/security-credentials". at /application/vendor/symfony/http-client/Chunk/ErrorChunk.php:56)"} [] [2023-03-13T15:50:53.825898+01:00] app.INFO: Try #2 after 2072ms: Idle timeout reached for "http://169.254.169.254/latest/meta-data/iam/security-credentials". {"count":2,"delay":2072} []

Findings

• The queues nicely get "auto setup" (the client initially gets a http 400 error first and then has to retry)
• The events nicely get dispatched / published to the queue
• The events nicely get consumed from the queue

But, when connecting without key/secret credentials in the DSN, the logs will retrieve records of not being able to access 169.254.169.254, which is an on EC2 internally mapped service that is not accessible during local development. This IAM server typically will not be accessible when doing local development.

Suggested changes

1. Allow to configure default key / secret credentials via environment variables
2. Let the container bootstrap script detect these environment variables, and set those as the credentials
3. Option: an extra environment variable to only allow dispatching events with the credentials as provided
4. DX: enhance the documentation / README to mention that SQS typically will connect to IAM to determine credentials, when not providing them through the client's DSN, and that you by default can use any key / secret.

[micossow]

Hi @rvanlaak, is the problem related to elasticmq in any way? It seems like you are not able to connect to elasticmq due to some problem with PHP SDK, which is not a part of this project.

[rvanlaak]

@micossow the PHP SDK actually does nicely connect, and the messages actually do nicely get published and consumed. I've tried to leave these details at the actual outcome section. The part that is related to ElasticMQ would be related to it's Docker image, and whether it would be possible to let it respect default credentials via env vars.

In the meanwhile I've learned that connecting to ElasticMQ through any kind of credential pair will work, so please don't consider the above a bug, but more as an enhancement to become more 12 Factor app compliant.

[micossow]

Ok, so answering your suggestions:

1. As you mentioned, any credentials passed to elasticmq are ignored and we won't change that behavior.
2. This is out of scope of this project. If any SDK performs extra calls to other AWS services, it's a user's responsibility to mock these calls.

[rvanlaak]

Ok, I'll rewrite the TS to remove anything regarding credentials. The focus would be to allow configuring credentials based on environment variables.

Edit: done.

[rvanlaak]

@micossow curious to see the PR via which this ticket was marked as completed, can you possibly reference it here?