Closed brentstrong closed 6 years ago
Using this as a workaround. Invoke Scout2 with the --profile workaround to use the credentials being stored.
mkdir -p /root/.aws
echo '[workaround]' >/root/.aws/credentials
echo "aws_access_key_id=$(curl -s http://169.254.169.254${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI} | jq .AccessKeyId | sed 's/"//g')" >>/root/.aws/credentials
echo "aws_secret_access_key=$(curl -s http://169.254.169.254${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI} | jq .SecretAccessKey | sed 's/"//g')" >>/root/.aws/credentials
echo "aws_session_token=$(curl -s http://169.254.169.254${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI} | jq .Token | sed 's/"//g')" >>/root/.aws/credentials
Might be implemented through https://github.com/nccgroup/opinel/pull/28, will look into it.
This should now be implemented.
Still seeing this issue. Looking at the linked opinel PR, it doesn't seem opinel has had a new release, so if the bug is in opinel that would be expected? :)
(My ideal preferred solution for this would be something like "no, seriously, you have credentials available, just trust me and stop second-guessing boto3" :))
When running Scout2 on ECS it appears to not be able to retrieve the instance credentials provided by the IAM role for the task.
When running Scout2 with no arguments it returns: Error: could not find AWS credentials. Use the --help option for more information.
I suspect that this is due to an updated metadata URL specific to container instances.
EC2 metadata: http://169.254.169.254/latest/meta-data/
ECS metadata: curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI where an example of $AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=/v2/credentials/9f426f92-8cb7-49fe-9353-3284d427a46f
More information about IAM roles with ECS tasks can be found here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html