What are the SCP best practices?
Will enabling SCP in AWS Organizations do anything to local users in member accounts?
How to find out which SCP is denying action in an AWS multi-account scenario?
SCP requiring MFA explicitly?
Videos
I lost the count of companies that I talked and have no idea what Service control polices can be used for. Once I explain I have the follow-up question that I don’t have answer yet. What should I set on my SCP?
This is a open question that can go from blocking unused regions to blocking IAM user creation, restrict to just a group to be allowed to delete resources/snapshot, etc.
Usually I share this site for them to start. https://asecure.cloud
What do you think it is a “must have” for any medium/small company that is worried about their security regarding SCP?
I understand the concept of policies and how they are applied but what I can't find out is will simply enabling the service do anything by default?
I am looking at enabling SCP to allow users in management account access to new member accounts but there are already local users in the member accounts. Will enabling SCP affect these?
Answered
No it won't impact anything by enabling the service. SCPs need to be created to make any changes.
Hello everyone, sorry if the question is really dumb, but I can’t figure out how to find out which SCP is denying actions to a role in our AWS accounts.
I’m already using the IAM policy simulator and it tells me the action is blocked by a SCP, but
a) it doesn’t tell me which SCP is blocking b) which account is the one with the SCP linked to.
Also there seems to be no SCP associated with the account where the actions are denied.
Unfortunately the SCPs were already in place before my arrival and I can’t simply detach them all without cyber releasing the hounds.
Thanks for any input/suggestion.
UPDATE: Running the same commands from the CLI works without any issue, so we openend a support request to the AWS team.
UPDATE 2: Turns out we have a SCP blocking all requests on regions outside of the ones where we have our resources. Via CLI we couldn't see the issue because when running aws configure we already set the correct region. Support helped us notice that the application was instead trying to read all resources in all AWS regions, hence the error.