IAM, Accounts, and AWS Organizations Flashcards
IAM Policies
Grants or denies access to identities
Policy Document
Written in JSON to tell what is allowed or denied.
(T/F) An individual can have multiple IAM Policies
True
SEAR
Statement ID, Effect, Action, Resource
IAM Policy Document Statements
SEAR or SARE - Statement ID or SID (optional), ex. Full Access; Action can be very specific and then the service : and can be specific or * ex. Action: [“s3:&”]; Resource specifies the resources, can be specific or wildcard ex Resource: [“*”]; Effect is to either allow or deny
DAD
Priority of IAM Policy Statements - Deny, Allow, Deny
Priority of IAM Policy Statements
First is explicit deny. If a resource is denied, it cannot be accessed.
Second is explicit allow. If a resource is allowed and there is no explicit deny, it is allowed.
Third is implicit deny. If there is not statement allowing a service, it is denied implicitly.
Two types of IAM Policies
Inline and Managed
Inline Policy
applying JSON to each account individually. Not best practice. Got to make changes to each individual JSON policy. Usually used for special or exceptional allow or deny.
Managed Policy
created as its own object and attach it to any policy that wants to gain those access rights. They are RESUABLE and LOW MANAGEMENT OVERHEAD
Two types of Managed Policies
AWS Managed Policies and Custom Policies
IAM Users
an identity used for anything requiring LONG-TERM AWS access e.g. HUMANS, APPLICATIONS or SERVICE ACCOUNTS
Authenticated Identity
U&P and Access Keys (services); proves identity
Authorization
IAM checking the authentication and allowing or denying access
Exam Alert: (T/F) Internet scale apps and large organizations with more than 5,000 users should use IAM Users.
False. 5,000 IAM users PER ACCOUNT; IAM User can be a member of 10 GROUPS; This has design impacts – remember the limits for the exam which may discuss large organizations or Internet scale apps that have more than 5,000 users then IAM will not be the right choice.
IAM Groups
containers for USERS; solely for organizing users
(T/F) You can log into a group
False. You CANNOT log into a group – no credentials, etc.
(T/F) An IAM user can only be a member of one IAM Group.
False. An IAM user can be a member of multiple IAM Groups
IAM Group Policies
Two kinds of Group Policies both Inline or Managed and have permissions from each group plus whatever permissions for the user.
(T/F) There isn’t a built in all users group in IAM
True. There isn’t a built in all users group in IAM – you can create one but it isn’t native.
(T/F) There is no nesting in groups
True. You can not nest one group inside another group.
Total groups per account
300 Groups per accounts but can be increased with support tickets
Reference Policy
controls access to a specific resource and allows or denies identities to that resource; reference through ARN
(T/’F) Groups are a true identity of a user
False. Groups are NOT a TRUE IDENTITY. They can’t be referenced as a PRINCIPAL in a resource policy.
IAM Roles
exists in AWS account. Best suited for an unknown number or multiple principals. Can be internal or external.
(T/F) IAM roles are ASSUMED. YOU BECOME that role.
IAM roles are ASSUMED. YOU BECOME that role. Generally short term. Think about a mobile app that gains access through a role and become an identity in an AWS account for a short period of time.
Two types of policies attached to IAM Roles
Trust policy and permissions policy
Trust Policies
says what identities can access that role – reference identities in the same account or services and can reference other identities in other AWS accounts, even anonymous, or SSO via Google, Facebook, etc.