By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

AWS Organizations SCP policies and member root accounts

0

I have a AWS organization with 2 member accounts, applied a SCP at the root OU allowing allow actions on all resources. However I’m having an issue accessing IAM from the root account of one of the member accounts receiving error: no service control policy allows the iam:ListUsers action

it seems that all IAM actions are blocked.

If I add a SCP to the account or management account specifically allowing all IAM actions on all resources then it seems I am able to perform IAM actions from the member account root user.

So, I am confused as to why I need to explicitly allow IAM actions when there is the Default "FullAWSAccess" SCP that allows all actions on all resources.

I add a SCP to the account or management account specifically allowing all IAM actions on all resources then it seems I was able to perform IAM actions from the member account root user.

Edit: This is the SCP policy applied to the Root OU and inherited by the member OU and accounts

FullAWSAccess SCP { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }

CloudTrail SCP

{ "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Deny", "Action": "cloudtrail:StopLogging", "Resource": "*" } ] }

Edit 11/28/23

It seems that the "FullAWSAccess" SCP that I have attached at the Root OU doesn't have an effect because i have to add a explicit SCP allowing actions to specific services I will try to just delete my "FullAWSAccess" SCP and re-add it again see if maybe there is a glitch somewere.

  • Gary Mclean EXPERT
    5 months ago

    Can you share your scp?

  • Anesu M
    5 months ago

    Ok i thought i had this issue resolved but now it's happening when trying to access a S3 bucket or creating a CF stack. Here is the SCP attached at the root OU

    FullAWSAccess SCP

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }

    CloudTrail SCP

    { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Deny", "Action": "cloudtrail:StopLogging", "Resource": "*" } ] }

Topics
Management & GovernanceSecurity, Identity, & Compliance
Tags
AWS OrganizationsIAM PoliciesService Control Policy
Language
English
Anesu M
asked 5 months ago412 views
2 Answers
1
Accepted Answer

Policy evaluation within Organization SCPs works such that the intersection of the inherited policies and directly attached policies to the account. SCP inheritance works such that the effective permission at each level (OU/Account) is an INTERSECTION OF PERMISSIONS inherited from its top and the permissions currently attached to that level.

Inherited Policies+ (intersection) + Attached Policies = Resultant Allow

For more information on this, please refer below documentation :

If the account is under organization unit, then the FullAWSAccess should also be given explicitly on each level of the organization (Root, Organization Unit and Account) despite of being it inherited from the levels of organization (Root/OU) because the resultant of the permissions on the specific account under organization will be the intersection of the FullAWSAccess permissions attached to the Root, OU and the account itself.

For example :

  1. Root (FullAWSAccess) + OU (Inherited from Root + FullAWSAccess) + Account (Inherited from Root + Inherited from OU + FullAWSAccess) ---> Resultant (FullAWSAccess for Account resources)

Suppose, you gave FullAWSAccess explicitly as well beside being inherited from each level of the organization as mentioned in the above example , resultant permission would allow all resources, action to be performed in the account

  1. Root (FullAWSAccess) + OU (inherited + No FullAWSAccess permissions attached ) + Account (FullAWSAccess) ----> Resultant (Deny for all Account resources)

Suppose, you gave FullAWSAccess explicitly on root but didn't gave on OU. Also, you gave it explicitly on account then the resultant permission would be deny for all resources in the account.

I can see that you have FullAWSAccess as an SCP therefore, please check if you applied it at each level explicitly, as it will only work when allow has been given explicitly at each level.

AWS
Sakshi M
answered 4 months ago
0

Ok so I managed to resolve my own issue removed the member account from organizations and re-added it again boom it works.

wtf?

Anesu M
answered 5 months ago
  • Sakshi M
    3 months ago

    The possible reason for this could be that : You checked the SCP applied to your account by navigating to the SCP section of your organization console. There you must have found 2 SCPs which are "FullAWSAccess" and "CloudTrail" SCP attached to your account.

    The "FullAWSAccess" which would be displayed there, must be the inherited one, which might have been inherited from the root and OU. So, the managed policy "FullAWSAccess" that we apply explicitly must not be present and therefore as an intersection of the permissions the calls must have denied. Since "FullAWSAccess" was not attached explicitly at the account level.

    But, when you removed account from the organization and joined that back again then Organization must have attached an AWS managed policy called FullAWSAccess by default. Due to which "FullAWSAccess" permissions were found at each level of the organization, been give explicitly, and hence would have worked.

    "By default, AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts." [1] [1] https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content