Allow SSO User Access to S3 Bucket in Another Account with their identitystore:UserId

0

Greetings,

Need to allow a specific SSO user access to an S3 bucket in another account.

(Ideally only allowing access to the one bucket among many in the target account. )

Using this documentation, I (think) I should be able to use this resource-based policy:

{
   "Version":"2012-10-17",
   "Statement": [
      {
         "Effect":"Allow",
         "Principal":"*",
         "Action": [
            "s3:GetObject",
            "s3:GetObjectVersion"
         ],
         "Resource": [
            "arn:aws:s3:::mybucket/*"
         ],
         "Condition": {
            "StringEquals": {
               "identitystore:UserId": [
                  "<UserId>"
               ]
            }
         }
      }
   ]
}

directly on the bucket, adding the desired user's UserId that is available from the SSO console. However this error always presents when adding the JSON:

Invalid Condition Key: The condition key identitystore:UserId does not exist. Use a valid condition key.

Did some reading and found docs that describe this condition key as global (is it?), and so I have also tried:

"Condition": {
    "StringEquals": {
        "aws:identitystore:UserId": [

However the same error occurs:

Invalid Global Condition Key: The condition key aws:identitystore:UserId does not exist. Use a valid condition key.

Then again I see docs that list the condition keys for S3 and identitystore:UserId is not among them, though I thought as a global condition it would be usable ...

I've also tried having the Resource in the JSON include the region and account id. e.g. "arn:aws:s3:us-east-1:111111111111:mybucket/*", however it seems to have no effect.

Also tried using this policy JSON when creating a new SSO permissions set as an inline policy (without Principal), though again similar issue.

Invalid Service Condition Key: The condition key identitystore:UserId does not exist in the service identitystore. Use a valid condition key.

A bit lost in the documentation - would really like to reference specific SSO users by their id - must be missing something simple here.

Many thanks for any assistance.

3 réponses
0
Réponse acceptée

I tested the policy in my own account and received the same error as you, this would occur whether I supplied a UserID from a IAM Identity Store in the same organization or another organization.

I did some further testing in my own environment to find a workaround and you can potentially make use of the Condition Key "aws:userId" [1] to allow access to the s3 bucket. The condition key "aws:userId" allows you to restrict the access to the Identity Center(IDC) Username and the role it assumes in the other account, see the example policy below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "UserID",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::mybucket/*",
            "Condition": {
                "StringLike": {
                    "aws:userId": "AROAJI4AVV3EXAMPLEID:SSOUserName"
                }
            }
        }
    ]
}

In the above policy GetObject is restricted the specific IAM Role that has been assumed by the IDC User. The aws:userID condition key value has the following format: UNIQUE-ROLE-ID:ROLE-SESSION-NAME.

To obtain the UNIQUE-ROLE-ID, you can use the get-role cli command [2], this will need to be run from the account which is trying to access the s3 bucket in your account. The role name can be found in the IAM console and will be the following format "AWSReservedSSO_PermissionSetID_RandomizedCharectors":

 iam get-role –role-name ROLE-NAME.

From the output, the UNIQUE-ROLE-ID will be the RoleId string, which begins with AROA.

To ROLE-SESSION-NAME will be equal to the username that the user used to sign into AWS Identity Center. You can also confirm the Username by viewing the user in the IAM Identity Center in the other account.

I would also suggest reviewing the following blog post [3] which goes into more detail about using aws:userId with s3 bucket policies.


[1] AWS global condition context keys - aws:userid - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-userid

[2] get-role - https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-role.html

[3] How to Restrict Amazon S3 Bucket Access to a Specific IAM Role - https://aws.amazon.com/blogs/security/how-to-restrict-amazon-s3-bucket-access-to-a-specific-iam-role/

AWS
INGÉNIEUR EN ASSISTANCE TECHNIQUE
répondu il y a un an
  • Hi Michael, many thanks for your response.

    I also connected with AWS business support on this (looks like you are also in support) and they reported the same behavior (i.e. error when attempting to use identitystore:UserId). They did add one note, which is that it seems we can move through the error (i.e. proceed with creating the policy even with the UI-failing JSON) anyway. I haven't had time to test that approach. Zooming out a bit, this does look like a policy validation bug in the AWS console - hopefully it will get resolved soon.

    The information you've provided is excellent and very helpful - appreciate you elaborating on how to obtain the UNIQUE-ROLE-ID - thanks again!

0

Hi

Buy we need to use the federation account to provide the sso access?


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Only permission to Jorge Lopez user",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:/*", #Example
            "Condition": {
                "StringEquals": {
                    "aws:userid": "AWSReservedSSO_" #Example
                }
            }
        }
    ]
}
répondu il y a 5 mois
0

NirvaShare could be a solution, it has capabilities to share folders with users from the AWS identity center or from any other identity stores such as ActiveDirectory, etc

répondu il y a un an

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions