- Newest
- Most votes
- Most comments
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 :
- Inheritance for service control policies - https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_auth.html
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 :
- 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
- 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.
Ok so I managed to resolve my own issue removed the member account from organizations and re-added it again boom it works.
wtf?
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
Relevant content
- Accepted Answerasked 8 months ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a month ago
Can you share your scp?
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": "*" } ] }