Default credentials from environment variables in Docker image

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.

Start by inspecting the Docker image's container bootstrap script and the README for current credential handling. Trace how environment variables could be passed into the SQS client configuration, then verify that local startup uses the supplied credentials without attempting EC2 metadata access.