I've recently come across an issue assuming a role from an ECS container.
The task role of my ECS task had the policy to assume the role in the destination account and I also followed steps and troubleshootings from AWS documentation (See here) However I was still unable to assume the role.
My main problem was that the process wasn't able to see the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI variable so it couldn't get the credentials from the role.
As per AWS doc:
The environment variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is available only to PID 1 processes within a container. If the container is running multiple processes or init processes (such as wrapper script, start script, or supervisord), the environment variable is unavailable to non-PID 1 processes.
To set your environment variable so that it's available to non-PID 1 processes, export the environment variable in the .profile file. For example, run the following command to export the variable in the Dockerfile for your container image:
RUN echo 'export $(strings /proc/1/environ | grep AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)' >> /root/.profileNow additional processes can access the environment variable.
As suggested I tried add the command in the Dockerfile but .... didn't help. I also tried to add the same in the docker entypoint script ... the same. I tried different things but still nothing.
My container was running as part of a gitlab pipeline (see the Gitlab Runner Job) and the only way I made it working was to export AWS_CONTAINER_CREDENTIALS_RELATIVE_URI in the pipeline job.
For ex.
test-job1:
stage: test
script:
- export $(strings /proc/1/environ | grep AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)
- aws s3 ls --profile cross-account-role
At the moment this is the only way I could get the credentials from the task role. It's not elegant but it's working.
If anyone hade the same issue and managed to find a better solution I'll be happy to hear from you and if I helped even a bit to fix your problem then I am even happier.
CIAO!
Top comments (0)