AWS re:Invent 2019 Getting started with AWS identity

I recently watched a 2019 talk from re:Invent that covered getting started with AWS identity. Here are my learning notes from watching this talk —

• AWS IAM stands for Identity and Access Management, and that name perfectly describes what it does. It identifies accessors (humans or computers) and manages how those accessors are able to operate on resources.
• Amazon has a bunch of services to manage security: IAM, Amazon VPC, Key Management (KMS), Certificate Manager (ACM) etc… But at the base of all of these they are all using IAM.
• When you first login to AWS and pay for an account you get an AWS account with an accountID. This account serves as a container for the resources within your account. You might have some EC2 instances, some Dynamo instances and maybe some Lambda functions in your account. Once you become much larger you will want to have several accounts across your organization. For this Amazon offers something called an organization which bundles together several accounts.
• A simple example of when you would want multiple accounts within the same organization is for separate environments. You would want a separate account for QA, Staging and Prod environments. By having separate accounts you create an isolation boundary between these environments.
• IAM is just another resource within an AWS account, like an EC2 container. An account has a bunch of resources some of which are IAM policies.
• Whenever anyone or anything operates on resources within an AWS account they are operating on those resources as some IAM role.
• An AWS role is similar to an AWS user in that they are both identities that are assumed within an account to operate and control access to resources within that account. However, unlike a user, a role is meant to be assumed by multiple people, whereas an AWS user maps onto a single person. Additionally, roles do not have long term credentials or passwords, instead when something or someone assumes an AWS role, they get a temporary session during which they are granted access to the resources within the AWS account specified by the IAM roles that are granted via assuming said role.
• IAM roles are not just used by humans. Resources within an AWS account will need to interact with other resources in that account via APIs. In order to manage identity and access permissions for these interactions, each resource within an AWS account must assume an IAM role that will mediate this interaction.
• AWS IAM policies work in terms of resources and actions. So for example a policy of Action: * && Resource: * means that if you are operating as a role which has access to this policy you can do anything on any resource within the account.
• Every account should at a minimum have an admin role which can do anything within the account and a read only role.
• The principle of least privilege within security means that people/computers should operate on resources with the minimum set of privileges they need in order to successfully achieve what they intend.
• You can you can use the Terraform aws_iam_policy resource to provision and manage AWS IAM policies.
• The first step in validating a request is to do Authentication. Authentication, AuthN, is the process of checking that someone, or something, is actually who they claim to be. The way this works is that every AWS client will include a header on every API call. This header will include a public identifier of the role that is being claimed as the caller and a signature. This is basically just public/private key encryption. The signature will be generated by the client as a function of the payload and the private key. Then the server will use the public key to verify that the the caller is actually who they claim to be and that the payload has not been changed, in other words the signature matches the payload. If this step is successful then the call has been authenticated.
• But, after authentication, we still have not checked the second step yet of Authorization. Authorization, AuthZ, is the process of checking if some actor can do some action on some resource. The way this is done is actually pretty simple. First IAM will find all policies which are relevant to to the request. Next, IAM will iterate over all the policies to evaluate if the policy should allow or deny the request. This evaluation is done by string matching the request to the policies’ actions and resources. Finally, a request is denied if any policy explicitly denies it or if there are no matching policies; a request is allowed if there is at least one policy which allows the request and no policies which deny the request.
• Every IAM policy includes a list of resources. This list of resources is specified using ARNs (Amazon Resource Names). Every resource within AWS has an ARN which uniquely identifies that resource across all of AWS. These ARNs are structurally similar for all resource types and additionally include a piece that is specific to the resource type. For example the ARN for an AWS Aurora DB instance looks arn:aws:<region>:<account>:db:<name> for example arn:aws:rds:us-east-2:123456789012:db:mysql-mysql-instance-1. When you specify resources within an IAM policy you do this by specifying matching patterns on ARNs. So for example arn:aws:rds:us-east-2:123456789012:db:* would match all RDS databases in us-east-2 for account 123456789012.
• In addition to a list of resources every IAM policy specifies a list of actions that can be taken on the resources. For example if you want to enable an actor to put and get objects from Dynamo you would include actions of GetItem and PutItem.
• While the meat of policies is the list of resources and list of actions, you can also specify an effect which is either allow or deny and a condition which enables more fine grained matching.