Support IAM Identity Center (SSO) authentication

[jamesbornholt]

Mountpoint doesn't currently support authenticating with IAM Identity Center (SSO or Legacy SSO) credentials. This was only recently added to the CRT (awslabs/aws-c-auth#189) but isn't in the default credentials provider yet.

[isaacrayAZ]

Would be very interested to know if there is any status on this enhancement, it is very important to a use case we are currently working on. Thanks!

[jaanli]

+1!

[plurch]

Is there any known workaround for this issue?

I am trying to locally test running a docker container that uses mountpoint to mount an S3 bucket.

I tried:

1. Mounting a docker volume with .aws directory - docker run -v ~/.aws:/root/.aws:ro ...

mount-s3 1.3.2
Error: Failed to create S3 client

Caused by:
    0: initial ListObjectsV2 failed for bucket ... in region us-east-1
    1: Client error
    2: No signing credentials found
Error: Failed to create mount process

2. Setting AWS ENV var credentials AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN

mount-s3 1.3.2
Error: Failed to create S3 client

Caused by:
    0: invalid AWS credentials
    1: CRT error 44: aws-c-common: AWS_ERROR_FILE_INVALID_PATH, Invalid file path.
Error: Failed to create mount process

It would be nice if there is some temporary approach of providing credentials for a quick local test.

[passaro]

Hi @plurch, are you following the suggestions here: https://github.com/awslabs/mountpoint-s3/blob/main/docker/README.md#running-the-container?

If so, and you still see the errors, could you please raise a separate issue with more information? E.g. logs, Mountpoint command, Dockerfile, docker command.

[plurch]

Thanks for the link, @passaro - that was helpful.

My issue with the approach of using ENV vars was that the docker run --env-file option was keeping quotes in the env var values, which I didn't expect to occur. There is an open issue with docker here - docker/cli#3630

This was causing the following error:

A client error (InvalidAccessKeyId) occurred when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records.

For anyone else who might want to workaround IAM Identity Center (SSO) not being currently supported with mountpoint, I was able to get it working in docker by:

1. Get AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN values from the AWS console and selecting "Command line or programmatic access"

2. Save the values to a .env file WITHOUT quotes, and run your docker container like this:

docker run --env-file ./.env --cap-add SYS_ADMIN --device /dev/fuse ...

[benkehoe]

You can get the credentials as environment variables directly from the command line using aws configure export-credentials --format env (docs)

[jamesbornholt]

I looked at this a bit more carefully. It needs two more pieces of work on the CRT side:

1. The blocker right now is that the CRT's SSO provider doesn't support automatic refresh of tokens: https://github.com/awslabs/aws-c-auth/blob/534b4451e41493ab1dc50bd06f0cf9614209beb0/source/token_provider_sso_session.c#L56.
2. Then we'll need to add SSO to the CRT default credentials chain.

We'll also need to figure out how to write tests for it.

[misteralvis]

You can get the credentials as environment variables directly from the command line using aws configure export-credentials --format env (docs)

I wrote a bash utility to do just this using a specified profile in ~/.aws/config. Naturally, this requires the user to be logged in their SSO session, and to have a profile defined for the specific account with the S3 that they want to mount. The syntax, then, is :

mount-s3-sso.sh -b <bucket> -m <mount_point> -p <profile>
or
mount-s3-sso.sh <bucket> <mount_point> <profile>

This is here : https://github.com/misteralvis/mount-s3-sso

[enr0c]

Once supporting SSO (AWS Identity Center) it would be great to also achieve trusted identity propagation (TIP).

Maybe it can be achieved by leveraging https://github.com/aws/boto3-s3-access-grants-plugin or ideas from here: https://aws.amazon.com/blogs/security/access-aws-services-programmatically-using-trusted-identity-propagation/