Skip to main content

[[TOC]]

IAM Identity Policies

  • IAM uses JSON, not YAML
  • Consists of 1 or more statements that grants or denies access to AWS

Each statement contains a resource and an action that is performed on that resource.

  • Example: Allow action on the S3 buckets

Resources can be individual resources or lists of multiple resources.

  • If you use a list of multiple resources, use the ARN of the resources.

It is possible that you can be allowed AND denied at the same time.

  1. Explicit deny always takes precedence over anything.
  2. Explicit allows
  3. Implicit Deny (Default)
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "FullAccess",
        "Effect": "Allow",
        "Action": ["s3:*"],
        "Resource": ["*"]
    },


    {


    }

]

Types of Policies​

Managed Policies - normal access rights for lots of people Inline Policies - smaller policies that impact small amounts of people (exceptions)

IAM Users and ARNs

Users​

Principals - user, computer, application A principal needs to be able to authenticate against IAM - The principal proves that it is who it is by authenticating.

  • Username and pw
  • Access Keys

Once this process is done, then the principal becomes an Authenticated Identity. Authorization occurs when IAM understands that the Authenticated Identity is allowed to do whatever it is that it came here to do.

ARNs​

Uniquely identify resources within any AWS Accounts Format: arn:partition:service:region:account-id:resourceid or arn:partition:service:region:account-id:resource-type:resource-id Tips:

  • 5000 IAM users per account
    • Federation and IAM Roles fix this hard limit
  • IAM User can be a member of 10 groups
  • Cannot use one user per IAM identity if you have more than 5000 users.
    • IAM roles and Identity Federation fixes this.

Demo Simple Identity Permissions in AWS

Demo

IAM Groups

NOTE: You cannot log into a group Groups are just containers for users - simple definition. Groups can have both Managed and Inline Policies attached to them. AWS merges all of the policies together and then applies them to the user

  • The same deny allow deny rule applies to the entire collective of permissions.
  • No limit of the # of users in a group
  • Users can be in multiple groups simultaneously
  • There is no "All Users" group but you can create and manage it if needed.
  • Groups cannot be nested. No groups inside groups.
  • Soft limit of 300 groups per account

Groups are not true idenitities.

  • Resource policy cannot reference a group as a principal in a policy

Demo: Permissions Control using IAM Groups

Demo

IAM Roles - The Tech

IAM Roles are identities like IAM Users but for multiple identities IAM Roles have two types of policy

  • Trust Policy - can represent identities in other accounts
  • Permissions Policy

When you assume a role, temporary credentials are created by what is known as the STS (secure token service)

  • this is where you see the sts:AssumeRole

IAM Roles - When to Use

When you don't know the quantity of who is going to use this, use a role.

Example with Lambda:​

AWS Lambda is a function as a service. It does something. You can create a Lambda Execution Role which has a trust policy that trusts AWS Lambda. When the Lambda function runs, it assumes this role and the permissions via the sts:AssumeRole which creates temporary credentials that allows the Lambda function to use to access whatever resources it has permission to.

When a role is assumed, credentials are temporarily given and then when the task is completed, they are discarded.

Break Glass Example​

This is a break glass account elevation when you really need someone who doesn't have the normal permissions needs advanced permissions.

AD SSO Example​

You have 6000 users in your Azure AD or existing identity provider, so you attach your Azure AD to assume a role inside your AWS acct.

User limit Example​

Another example is when you have more than 5000 people (max 5000 users, right?) that need to access AWS resources. Simply allow a role to be assumed by an authenticated identity in an external account such as Azure AD or Facebook or Google. This is called ID federation.

Mobile App Example​

Another example even, is if you create a mobile application and a million or so people create accounts and need to access resources in an S3 bucket. When you sign into this, you use your Google account to assume that role, get the temp credentials and then access the S3 bucket. No credentials are stored in the App or on the device. Can scale to 100's of millions of users.

Cross AWS Account Example​

Even another example is if you have multiple AWS accounts and you need users in one account to access resources in another account. They assume the role in the other account.

AWS Organizations

Multiple accounts that join an AWS organization become member accounts of that organization. There is one management account that handles the billing of all of the accounts. This is called consolidated billing. In our demo so far, we've created a management/general account and a Production account. In theory, you can have a Dev, Dev2, QA, QA2 UAT, Test, Sandbox and then Production accounts or even more. All of these accounts are then added to the AWS Organization and become member accounts.

You can organize these accounts into Organizational Units. Mine looks like this: image.png Organizational Root is the one at the top with 3 OU's, QA, Dev and Prod. Master acct is in the root OU.

Consolidated Billing​

Pool reservations and volume discounts across all accounts All accounts are billed from one account - users can only access the one account for the billing purposes. AWS Roles can be used in the other accounts to allow access from one account to another, allowing for one account to handle the management of the users.

Demo: AWS Organizations Part 1

Demo

Demo: AWS Organizations Part 2

Demo

Service Control Policies - SCPs

SCPs can be attached to accounts, OUS or ORGanizations SCPs are downward facing. If you attach it, then everything under that SCP is affected.

  • if you have nested OU's, then you can apply these to specific OUs and then this affects everything under that OU.

SCPs are account permissions boundaries.

  • Management cannot be restricted using service control policies, so avoid building things in the management account.
  • they limit what the account (including the root user) can do
  • SCPs do not grant any permissions.
  • default deny policy is applied

Allow list vs Deny List​

Default policy is FullAWSAccess. SCPs are a deny list architecture.

  • All are allowed until you deny a specific resource or service.
  • Deny, Allow, Deny rules apply.

Allow lists remove the FullAWSAccess and then explicitly allowing access to whatever resources you want the users to use.

SCPs are different than Identity Policies. Only those that overlap between Identity Policies AND SCPs are allowed.

Demo: Using Service Control Policies

Demo

CloudWatch Logs

Documentation

  • Public service - usable from AWS or on prem
  • Store, monitor, and then access the logging data
  • AWS integrations - EC2, VPC Flow logs, Lambda, CloudTrail, R53 and more.
  • Use the Unified Cloudwatch Agent to log from anything outside of AWS services
  • can generate metrics based on logs. Can then generate alarms based on the metrics.

Logging sources can make log events and pass them into a log stream which are contained by log groups.

  • Settings are applied on the log groups that apply to all log streams
  • Metric filters are also applied on the log groups.

CloudTrail

Documentation

  • Logs API calls or activites as a CloudTrail Event.
  • 90 days are stored by default
  • To customize, create Trails.
  • Management events or Data events
  • CloudTrail is a regional service - only logs in the region that it creates it in.
    • Create an ALL region trail instead.
    • global services event logging needs to be enabled in the Trail.
  • 90 days, but can be stored in S3 buckets.
  • CloudTrail can put into CloudWatch logs to set up metrics and to parse through the logs.
  • AWS organizational trail can also be created to capture data for the entire organization.

Quick Demo: CloudTrail​

  1. Navigate to the CloudTrail console in AWS
  2. Click Event history
  3. Browse the recent logs.
  4. Click View Event to view the JSON.

More tips:

  • 90 days, no s3 by default
  • Trails are how you configure S3 and CloudWatch Logs
  • Management events only by default, data events cost $
  • IAM, STS, CloudFront are Global Service events that log into US-East-1
  • Not real-time logging

Demo: Implementing an Organizational Trail

Demo