IAM, Accounts and AWS Organizations Flashcards
IAM Identity Policies
Are a type of policies which get attached to identities inside AWS.
-Is a set of security statements to AWS.
- It grants access or denies access to AWS products or features to any identity which uses that policy.
- Created using JSON.
- Policies can have multiple statements.
When an identity attempts to access AWS resources, that identity needs to prove who it is to AWS. Once authenticated, that identity is known as an authenticated identity.
-AWS knows which policies an identity has.
- AWS has a collection of all of the statements which apply to a given identity.
-AWS knows which resources, you’re attempting to interact with, as well as what actions you want to perform.
What makes up a Statement?
- The first part of a statement is a statement ID, or a SID (optional field), which lets you identify a statement and what it does.
Every interaction that you have with AWS, is a combination of two main things, the resource that you’re interacting with, and the actions that you’re attempting to perform.
A statement only applies, if the interaction match the action and the resource.
- Action describes the specific action or actions that will be allowed or denied. Each AWS service has its own set of actions that describe tasks that you can perform with that service.
Single action ====> “Action”: “iam:ChangePassword”
Multiple actions ====> “Action”: [ “sqs:SendMessage”, “sqs:ReceiveMessage”, “ec2:StartInstances”]
You can use a wildcard (*) to give access to all the actions the specific AWS product offers. For example, the following Action element applies to all S3 actions.
“Action”: “s3:*”
You can also use wildcards (*) as part of the action name. For example, the following Action element applies to all IAM actions that include the string AccessKey, including CreateAccessKey, DeleteAccessKey, ListAccessKeys, and UpdateAccessKey.
“Action”: “iam:AccessKey”
- Resource specifies the object or objects that the statement covers. You specify a resource using an ARN. Each service has its own set of resources. Although you always use an ARN to specify a resource, the details of the ARN for a resource depend on the service and the resource.
“Resource”: “arn:aws:sqs:us-east-2:account-ID-without-hyphens:queue1”
“Resource”: “arn:aws:iam::account-ID-without-hyphens:user/Bob”
- Effect is to either allow or deny. Effects controls what AWS does if the action and the resource parts of the statement match the operation that you’re attempting to do with AWS.
“Effect”:”Allow”
Overlap Situation
If there are multiple statements which apply to an operation in AWS, then all of the statements are processed.
RULES
1st Priority - Explicit DENY = It overrules everything else
2nd Priority - Explicit ALLOW = These take effect unless, there is also an explicit deny.
3rd Priority - Default DENY = If neither of those apply, so you’re attempting to do something for which you have no explicit allow or deny, then the default implicit deny takes effect.
With the exception of the Account Root User, AWS identifies start off with NO ACCESS to any AWS resources.
Multiple Policies
When a given identity accesses a resource, it collects all of the statements in ALL of the policies which apply. So the users directly, the groups the users are in, and any resource policies on the resources that they’re attempting to access, it collects all of these together and evaluates them ALL at the same time.
Same rule applies, DENY, ALLOW OR DEFAULT DENY.
Type of Policies
There are two main types of policies, they are both JSON policies but the difference is how they’re managed.
- Inline Policies = Apply the policy to each account/user individually, but changing the access rights would mean changing it, on each and every one of them.
–This is used for exceptions to the normal access rights, so special circumstances.
- Managed Policies = Are created as their own object. First, you’d create the managed policy which is just a piece of JSON with some statements in, and then you would attach that policy to any identities, who you wanted to gain those access rights.
– Reusable
– Low Management Overhead
There are two main types of managed policies:
–AWS managed policies = Which are created and managed by AWS.
–Customer managed policies = Which you can create and manage so you can define them as per the exact requirements of your business.
IAM Users and ARNs
IAM Users are an identity used for anything requiring long-term AWS access e.g. Humans, Applications or service accounts.
IAM Principal
Which represents an entity trying to access an AWS account. Principals can be individual people, computers, services or a group.
For a principal to be able to do anything, it needs to authenticate and be authorized.
- When a principal makes a requests to IAM to interact with Resources, to be able to interact with resources, it needs to authenticate against an identity within IAM.
Authentication is a process where the principal proves to IAM that it is an identity that it claims to be. This is done by either using:
-Username and Password = Human accessing AWS and via the console UI.
- Access Keys = Application or a human accessing through the AWS CLI
These are both examples of long-term credentials.
- Once the principal becomes an authenticated identity, then AWS knows which policies apply to the identity. This is the process of authorization.
Authorization is IAM checking the statements that apply to that identity and either allowing or denying that access.
Amazon Resource Name (ARN)
Uniquely identity resources within any AWS accounts.
-ARN’s allow you to refer to a single resource, if needed, or in some cases, a group of resources using wild cards.
-ARNs are collections of fields split by a colon.
-ARN’s are used in IAM policies.
arn:aws:s3:::catgifs ====> refers to the bucket itself.
arn:aws:s3:::catgifs/* ====> refers to the objects in the bucket but not the bucket.
“*” is a wild card that matches any keys.
“::” when something doesn’t need to be specified.
EXAM POWER UP
- 5000 IAM Users per account.
- IAM User can be a member of 10 groups.
- This has systems design impact…
- Limit for Internet-scale applications
- Limit Large orgs & orgs merges
- We can fix this by using IAM Roles & Identity Federation
IAM Groups
Are containers for IAM Users. They exist to make organizing and management of large sets of IAM users easier.
- Have no credentials of their own.
- You can not login into a group.
-No Nesting. (Groups within groups)
-Limit of 300 groups per account (can be increased)
Groups give us to main benefits:
-They allow effective administration-style management of users
-Groups can have policies attached to them (Inline or Managed)
-There’s no limit for the number of users in a single IAM group.
If an IAM User has multiple policies attached to it or associated with, AWS will merge all of those into a set of permissions and apply the deny-allow-deny rule to them.
There isn’t a built-in all-users group inside IAM, so you don’t have a single group that contains all of the members of that account.
Policies can be attached to resources, these are known as resource policies, they can reference identities. It controls access to an specific resource and it allows or denies identities to access, for example, a bucket. It does this by referencing these identities using an ARN. (Users and Roles can be referenced in this way)
-Groups are not a true identity. They can’t be referenced as a principal in a policy. A resource policy cannot grant access to an IAM group.
IAM Roles
A role is an identity and is generally used by an unknown number or multiple principals, not just one.
This might be multiple AWS users inside the same AWS account, or it could be humans, applications, or services, inside or outside of your AWS account.
-If you can’t identify the number of principals, which use an identity, then it could be a candidate for an IAM role.
-Generally used on a TEMPORARY basis. (something becomes that role for a short period of time and then stops)
-A role is something which represents a level of access inside an AWS account.
What’s the difference between logging into a user and assuming a role?
In both cases, you get the access rights that the identity has.
IAM roles have two types of policies which can be attached:
- Trust Policy = Controls which identities can assume that role. It can reference identities in the same account, so other IAM users, other roles, and even AWS services such as EC2, or identities in other AWS accounts. It can even allow anonymous usage of that role and other types of identities such as Facebook, Twitter, and Google.
If a role gets assumed by something which is allowed to assume it, then AWS generates temporary security credentials (AWS STS) and these are made available to the identity which assumed the role.
-They’re time-limited, once they expire, the identity will need to renew them by reassuming the role.
These temporary credentials will be able to access whatever AWS resources are specified within the permission’s policy. Everytime the security credentials are used the access is checked against this permissions policy. If you change the permissions policy, the permissions of those temporary credentials also change.
-Roles can be referenced within Resource Policies. so if a role can access an S3 bucket because a resource policy allows it or because the role permissions policy allows it, then anything which successfully assumes the role can also access the resource.
-Roles are used within AWS Organizations, to allow us to login to one account in the organization and access different accounts without having to login again.
- Permissions Policy = Control what permissions the identity gets inside AWS. (Inline or Managed)
When to use IAM Roles
*AWS services operate on your behalf and they need access rights to perform certain actions.
Anything that’s not an AWS identity, this might be an application or a script running on a piece of compute hardware somewhere, that you need to give it permissions on AWS using access keys.
Instead of doing that we’re just giving it a IAM role.
*Emergency or out of the usual situations
A person can assume an emergency role when absolutely required. When he does, he’ll gain additional permissions based on the role’s permission policy. Now this access will be logged and the person will know to only use the role under exceptional circumstances.
*When you’re adding AWS into an existing corporate environment.
Remember there’s the 5000 IAM user limit, so for a corporate, with more than 5000 staff, you can’t offer each of them an IAM user. Roles are often used when you want to reuse your existing identities for use within AWS. Why?, because external accounts can’t be used directly to access AWS resources.
How this work, is that you allow an IAM role inside your AWS account to be assumed by one of the external identities, which is in Active Directory (Example). When the role is assumed, security credentials are generated and used to access the resources.
Using a role in this way, so giving permissions to an external identity provider and allowing external identities to assume this role, is called ID Federation.
*If you’re designing the architecture for a popular mobile application.
Ride Sharing App - with 1.000.000 of users
The application needs to store and retrieve data from a database product in AWS, such as DynamoDB.
Since there’s a limit of IAM users, we can fix this with a process called Web Identity Federation, which uses IAM role. Most mobile applications, allow you to sign in using a web identity (Google, Twitter, Facebook), if you utilize this architecture for our web application, we can trust these identities and we can allow these identities to assume an IAM role. (Based on the role’s Trust Policy)
This has many advantages:
–No AWS credentials stored in the application = From a security point of view, if the application is exploited, there’s no change credentials being leaked and it uses an IAM role, which you can directly control from your AWS account.
–Uses existing customer logins = So they don’t need yet another account
–It can scale to 100.000.000’s of accounts
*Cross-account access. (AWS Organizations)
Two AWS accounts, yours and a partner account.
Let’s say your partner organization offers an application which processes scientific data and they want you to store any data inside an S3 bucket, that’s in their account.
Your account has 1000’s of identities and the partner IT team don’t want to create IAM users, in their account for all of your staff. The best approach is to use a role in the partner account, your users can assume that role, get temporary security credentials and use those to upload objects.
–You can use orles to give access to a whole account.
Service-Linked Roles
Service-Linked role is an IAM role linked to a specific service.
-They provide a set of permissions which is predefines by a service
-Provide permissions that a single AWS service needs to interact with other AWS service on your behalf.
-Service-Linked roles might be created by the service itself or the service might allow you to create the role during the setup process of that service or within IAM.
-You must configure permissions for an IAM entity (user or role) to allow the user or role to create or edit the service-linked role.
The key difference between service-linked roles and normal roles:
- Is that you can’t delete a service-linked role, until it’s no longer required. (Means that is no longer used within that AWS service)
Service Roles vs Service-Linked Roles
Remember that service roles are different than service-linked roles. A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM.
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
Role Separation & PassRole
*Role Separation is where you might give one group of people the ability to create roles and another group of people the ability to use them.
So in this case, we might want ot give “Bob”, the ability to use a service-linked role with an AWS service. So being able to take a service-linked role and assign it to a service, and if you wanted to give “Bob” the ability to use a preexisting role with a service but not create that role or edit it, then you need to provide “Bob”, with the PassRole permissions.
*PassRole
Is a method inside AWS which gives you the ability to implement role separation, and it’s something which you can also use with service-linked roles.
-The ability to pass an existing role into a service. It means that “Bob” could configure a service with a role which is already being created by a member of the security team. He would just need the “ListRole” and “PassRole” permissions on that specific role.
-Some AWS services allow you to pass an existing role to the service, instead of creating a new service-linked role. To do this, a user must have permissions to pass the role to the service.
ListRoles = allows the entity to view a list of roles from which they can choose the role to pass.
AWS Organizations
Is a product which allows larger business to manage multiple AWS accounts in a cost-effective way.
-Without AWS Organizations, many large businesses would face a situation where they need to manage many AWS accounts. Without it, these accounts would each have their own pool of IAM users as well as separate payment methods.
A standard AWS account = Not within an organization.
With an standard AWS account you create an AWS Organization, the organization isn’t created IN the account, you’re just using the account to create the organization. This standard AWS account then becomes the Management Account for the organization (Previously Master).
*You can invite other existing standard AWS accounts into the organization, and they’ll need to aprove the invite.
When Standard AWS accounts join the organization then they change from being Standard to beign Member accounts of that organization.
*You can create a structure of AWS accounts within an organization.
This is useful if you have lots of accounts and you need to group them by things such as business units, function, or even development stage of an application.
The structure within AWS Organizations is hierarchical, so it’s an inverted tree, at the top of this tree is the root container of the organization.
Root container = A container within an AWS Organization, which can contain AWS accounts, and this means Member accounts or the Management account. It can also contain other containers, and these are known as organizational units (OUs), and these can contain AWS accounts or other OUs.
