{"id":3030,"date":"2015-05-05T07:02:08","date_gmt":"2015-05-05T07:02:08","guid":{"rendered":"http:\/\/blog.cloudthat.com\/?p=3030"},"modified":"2024-06-25T11:13:48","modified_gmt":"2024-06-25T11:13:48","slug":"iam-authorization-hierarchy","status":"publish","type":"blog","link":"https:\/\/www.cloudthat.com\/resources\/blog\/iam-authorization-hierarchy","title":{"rendered":"IAM Authorization Hierarchy"},"content":{"rendered":"<p style=\"text-align: justify;\">Identity and Access Management (IAM) is the service that provides a authentication and authorization control for users and resources in ones AWS account. Although authentication has been quite simple and straightforward, viz. one can create groups, users and credentials for the users and share the same, authorization is quite a trick on IAM. Also, S3 Bucket policies and Bucket ACLs, SNS Topic Policies and SQS Policies are other resource level permissions which work in tandem with IAM permission. While IAM is from a users perspective, others are from a resource perspective.<\/p>\n<p style=\"text-align: justify;\">Many a time, I get questions like \u201c<i>Which permission gets higher priority?\u201d or \u201cUser is in two groups with contradicting permissions, what would be effective?\u201d or \u201cWhat happens when no permissions are given?\u201d. <\/i>This blog is to clear these kind of ambiguity while using IAM, S3 bucket policies or any other mode of permission on AWS for that matter.<\/p>\n<p style=\"text-align: justify;\">AWS has always been adopting <i>least permission<\/i> policy across all the services. Meaning, if no permission about a specific resource is \u00a0specified, it would be a \u201cDeny\u201d. Post the initial deny decision, the final decision of deny or allow would be based on \u201cExplicit\u201d allows and denies specified in the permissions. Below is simple flowchart which should give you an idea of what would the decision be, based on given conditions. This works across all the permissions present in AWS currently.<\/p>\n<p><a href=\"https:\/\/content.cloudthat.com\/resources\/wp-content\/uploads\/2022\/11\/iam_permissions.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-3031\" src=\"https:\/\/content.cloudthat.com\/resources\/wp-content\/uploads\/2022\/11\/iam_permissions.jpg\" alt=\"iam_permissions\" width=\"785\" height=\"262\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify;\">Now, what are these <i>Explicit <\/i>allow and deny conditions? One can guess that any policy with <i>Effect <\/i>as <i>Allow <\/i>is an explicit Allow and of course with <i>Effect <\/i>as <i>Deny <\/i>\u00a0is an explicit Deny. But there are also permissions on aws which are not a JSON document like S3 Bucket ACLs. These are inherently <i>Explicit Allows<\/i>. Default would be complete Deny and you would be given option to authorize using specific conditions. For example, in S3 ACLs, you explicitly allow either <i>Everyone\/AWS Authenticated Users <\/i>to <i>Read\/Write <\/i>the bucket\/object.<\/p>\n<p style=\"text-align: justify;\">Let\u2019s consider an IAM user with below two policies and guess what would be the overall effect. Would the user be allowed to use EC2 if the source IP is 111.111.111.111?<\/p>\n<p><a href=\"https:\/\/content.cloudthat.com\/resources\/wp-content\/uploads\/2022\/11\/iam_policy_example.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-3032\" src=\"https:\/\/content.cloudthat.com\/resources\/wp-content\/uploads\/2022\/11\/iam_policy_example.jpg\" alt=\"iam_policy_example\" width=\"824\" height=\"436\" \/><\/a><\/p>\n<p style=\"text-align: justify;\">If your guess is \u201cAllow\u201d, you have the right idea. In both the above policies, there is no explicit deny for source ip 111.111.111.111 and both are explicit allows. Although <i>Policy 2 <\/i>explicitly allows the users to login only from 102.102.102.102 and not from 111.111.111.111, <i>Policy 1 <\/i>explicitly allows the all EC2 actions from anywhere. According to our flowchart, as the answers would be <i>No <\/i>\u00a0for the first explicit deny condition, the execution would move on to the next explicit allow condition which would return to <i>Yes<\/i> as <i>Policy 1<\/i> explicitly allows access without any condition.<\/p>\n<p style=\"text-align: justify;\">So, I hope you have a better idea on how the authorization works on IAM now. One advice would be to always work with explicit denies. If a user is allowed to use a service, try to make sure all the restrictions on the services would be explicit denies, which gives a finer control. Please leave your queries and ideas in the comments section below.<\/p>\n","protected":false},"author":219,"featured_media":0,"parent":0,"comment_status":"open","ping_status":"open","template":"","blog_category":[3606,3607,3665],"user_email":"prarthitm@cloudthat.com","published_by":"324","primary-authors":"","secondary-authors":"","acf":[],"_links":{"self":[{"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/blog\/3030"}],"collection":[{"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/users\/219"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/comments?post=3030"}],"version-history":[{"count":1,"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/blog\/3030\/revisions"}],"predecessor-version":[{"id":45622,"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/blog\/3030\/revisions\/45622"}],"wp:attachment":[{"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/media?parent=3030"}],"wp:term":[{"taxonomy":"blog_category","embeddable":true,"href":"https:\/\/www.cloudthat.com\/resources\/wp-json\/wp\/v2\/blog_category?post=3030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}