I have been working with SCP (security control policies) for a while and still don't like the interface saying explicit deny. Most of the time you can easily trace back to where the deny statement lies, but not always the case (sad..) Today, for example, it took me a while to do so with Aurora.
In the SCP of the organization, the only statement related to RDS states that, it will deny create database instance (CreateDBInstance) if the rds storage is not encrypted. Easy so far right? I clicked on create database and choose Aurora. Even though choosing all kinda " encrypted storage" instance types (r, m, t3) --note free t2.micro instance is not encrypted storage -- I couldn't create the database with explicit deny--what the hell is going on..... (making guess, looking at CloudTrail really helped)
AND the answer is: Once clicking on creating a database, other database types (PostgreSQL...) will create an encrypted instance (if one chooses) - scp working fine. However its not the case for Aurora. For Aurora, creating a database instance means creating a cluster under it --hence use two interface s(CreateDBInstance and CreateClusterInstance)--and the cluster itself is encrypted, not the instance - instance is just like wrapper. So of course Aurora instance is not encrypted... its logical after you understand it right...
Note:
- That is to say its not always straightforward to trace to scp statement, especially when multiple interfaces are involved. Again, CloudTrail really helped me debugging this.
- It is also worth to look into Organization to see which scp are applied to an account. It could be hierarchical, several Scp are involved, and check from there where the error coming from
Just to conclude, do you want to move from IAM policy to SCP?
A quick table of comparision of IAM/SCP
Hông hiểu gì hihi
ReplyDelete