Docker usage challenges with `credential_process` path to `aws-sso`

[gregbrowndev]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Using aws-sso / aws-sso-profile with Docker/Compose for local development is a little bit challenging because its not clear how to separate tokens managed by the host machine (where aws-sso is installed) and containers that need to access them in a portable/flexible way.

The two options I've tried so far:

1. Pass AWS env vars to the container (I'm just passing everything that aws-sso-profile sets, but imagine not everything is required):

services:
  my-web-app:
    build: .
    environment:
      - AWS_SSO_ROLE_NAME
      - AWS_SSO_SESSION_EXPIRATION
      - AWS_SSO_ROLE_ARN
      - AWS_SSO
      - AWS_SSO_ACCOUNT_ID
      - AWS_SECRET_ACCESS_KEY
      - AWS_SESSION_TOKEN
      - AWS_DEFAULT_REGION
      - AWS_SSO_DEFAULT_REGION
      - AWS_SSO_PROFILE
      - AWS_ACCESS_KEY_ID

The downside here is that AWS_SECRET_ACCESS_KEY token is burnt into the env vars when the container starts, so the container must be completely torn down and re-upped when the token expires.

2. Pass AWS_SSO_PROFILE / AWS_PROFILE to allow the token to be read from disk (bind mounted into the container):

  services:
    my-web-app:
      build: .
    volumes:
      - ~/.aws:/root/.aws
      environment:
        - AWS_SSO_DEFAULT_REGION
        - AWS_SSO_PROFILE

The two problems here are that you need aws-sso installed in the container (I imagine to decrypt the token?), but the more awkward problem is that it doesn't seem possible to change the path to aws-sso generated by aws-sso setup profiles. E.g. my .aws/config looks something like:

[profile MyAccount:MyRole]
credential_process = /Users/gregbrown/.local/share/mise/installs/aws-sso/2.1.0/aws-sso -S "Default" process --arn arn:aws:iam::1234567890:role/MyRole

So I'd need to manually edit the config, or ensure aws-sso is installed in the same location in the container.

Editing the profile e.g. credential_process = aws-sso ... seems like it should work, but quite tedious for dozens of devs to do this in order to run the app.

If there was a way to override this in aws-sso setup profiles that might help.

Describe the solution you'd like
A clear and concise description of what you want to happen.

The one area I think could be in scope for this tool, would be to allow users to override the path to aws-sso in the generated profiles, to make the config file more portable between the host and containers.

Additionally, while I feel this may be out of scope for aws-sso, it would be helpful to provide guidance on how to develop apps in containers requiring AWS SSO, e.g. should they be sharing tokens with the host, or requesting their own tokens at start up somehow, similar to RDS IAM auth? (I guess this doesn't make sense as you always need to login...).

Thank you

Edit: While writing up the question, I found the FAQ: Using aws-sso on remote hosts and ECS Server which looks like it might solve this issue (I skipped reading ECS Server docs initially as it sounds like something to do with AWS ECS, not what I expected).

I chose to submit anyway if it helps future users, so feel free to close the issue. 🙏🏻

[andrewmiskell]

I had a similar problem because I sync my AWS configuration profiles in my dotfiles between my Intel-based Mac Pro and Apple-Silicon based MacBook Pro. Homebrew installs aws-sso in /usr/local/bin on Intel and /opt/homebrew/bin on Apple Silicon so I'd have to run setup profiles every time I sync'd my dot files from git.

You can also set the ConfigProfilesBinaryPath option in the config.yaml for aws-sso similar to below:

ConfigProfilesBinaryPath: aws-sso

This will make aws-sso setup profiles use only aws-sso with no path in each profile so as long as aws-sso is in your shell's PATH, it'll work.

[synfinatic]

Sorry, missed this ticket/question, but this is supported fairly cleanly via the ECS Server emulation.

basically, aws-sso can start a service which runs locally on your laptop and then your code running in the contain can access it by passing in a single (or two for authentication) environment variable to your container. Multiple containers & independent roles is also supported.

[github-actions]

This issue is stale because it has been open for 14 days with no response
from the reporter. It will be automatically closed in 14 days from this message.