2-iam-accounts-aws-orgs

Prev: 1-aws-fundamentals
Next: 3-simple-storage-service

IAM, Accounts, and AWS Organisations §

IAM Policy §

IAM policies get attached to identities inside AWS. Identities: IAM users, groups, or roles

Stages of understanding policies:

1. Understand architecture and how it work
2. Ability to read and understand policy
3. Ability to write your own policy

IAM identity policy - set of security statement in AWS (grant/ deny access)

Identity policy - created with JSON

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "FullAccess",
			"Effect": "Allow",
			"Action": ["s3:*"],
			"Resource": ["*"]
		}
	]
}

Statement only applies if it matches the action and resource.

Need to handle the overlap, check the priority.

Priority (lower is more priority):

1. Explicit Deny
2. Explicit Allow
3. Default Deny (Implicit)

Two main types of policy:

• Inline policy - applying JSON individually
  • Not best practice, repetitive
  • Special or exceptional allow or deny
• Managed policy - 1 policy for everyone
  • Reusable
  • Low management overhead
  • Should be normal, default policy rights

IAM Users §

IAM Users - identity used for anything requiring long-term AWS access e.g. Humans, Applications, or service accounts

Principal (individual people or group or app) makes an auth request to IAM (identity to be used)

Proof it is the user to get authenticated identity:

• Username and Password (humans)
• Access key (application or through CLI)

Authentication - Principle prove to IAM that it is the identity it claims Authorization - IAM checking statements of identity and to allow or deny access

Amazon Resource Name §

Amazon Resource Name (ARN) - Uniquely identify resource within any AWS accounts

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-id/resource-id
arn:partition:service:region:account-id:resource-id:resource-id

arn:aws:s3:::catgifs -> Bucket
arn:aws:s3:::catgifs/* -> anything in the bucket but not the bucket

Exam powerup:

• 5,000 IAM Users per account
• IAM user can be member of 10 groups
• System design impacts
  • Internet-scale applications
  • Large orgs and organisation merges
  • Potential solution: IAM Roles and Identity Federation

IAM Groups §

IAM Groups - containers for users. Cannot login, no credentials.

Benefits:

1. Effective admin-style management of users
2. Can have policies attached

User can have merged policies

• 2 from groups, 1 inline
• Collect all the groups and merge the allows and denies

Groups:

• Inline policies
• Managed
• No nested groups
• 300 groups per account (can be increased with support ticket)

Groups are not true identity - cannot be referenced as principal in a policy.

• Resource policy can grant access to users, but not groups.

IAM Roles §

Role - one type of identity in AWS used by unknown numbers of users, app, services

Principal - physical person, app, device, or process who wants to authenticate to AWS.

IAM Role - used short term to get the permissions (borrowing). - External identity like mobile app to gain access to AWS services

IAM Role - Trust policy - which identities can assume that role - can identities like users or AWS services inside or outside the account - Permission policy - gains permissions to the users (temp security credentials)

Roles used within AWS org to allow us to login into 1 account and access different accounts - Temporary credentials generated by AWS Service - STS (Secure Token Service). Operations used to get credentials.

When to use IAM Roles §

Common uses:

1. AWS services operates on your behalf and need access rights
   • (ex: AWS Lambda)- gives Lambda some some code, make lambda function, start things like EC2 instance, data backups
   • Rather than hard-coding access key, we can create Lambda Execution Role (IAM Role)
     • Trust policy - trust AWS Lambda (sts:AssumeRole) -> CloudWatch, S3
     • permission policy - gain access to AWS Lambda
     • Hardcoded bad because security risk and problem if rotating key.
     • One AWS Lambda function - can have a lot of copies running
2. Break glass for key - gain role temporarily for additional access to handle emergency situation
3. Adding AWS to existing corporate environment
   • Existing identities active directory - Single sign-on or 5000 identities (not viable to make each IAM user each)
   • External accounts cannot use AWS resources directly
   • Allow IAM role in AWS account to be assumed by the existing identities to access AWS service (s3) - ID federation
     • Small number of roles to manage
4. Designing architecture for popular mobile app
   • Have 1M users to store data in database like DynamoDB
   • Solved using Web identity federation that uses IAM role
     • Assume that role to gain access to DynamoDB
     • No AWS Credentials on the app and uses existing customer logins
     • Scales to 100Ms+ accounts
5. Cross-account access
   • 2 AWS account - yours and partner account
   • Partner org process data in S3 bucket
   • Your account has thousands of identities
   • Use role in partner account. Your users assume that role to access s3 buckets

Service-linked roles §

IAM role linked to specific AWS service

• predefined by service
• providing permissions that a service needs to interact with other AWS services
• might create/ delete role or allow you to during setup
• cannot delete the role until no longer required

Bob use service through service-linked role. Uses preexisting role using passrole permissions.

AWS Organizations §

Without this, they need to manage AWS accounts with pool of IAM users and separate payment methods.

AWS organization created from standard AWS account.

• Used to create the organization with and becomes the management account
• Invites existing accounts to join the organization - becomes member accounts

Organization have only 1 Master account and 0 or more member accounts

• Top of the tree is organization root, not account root user. Just container within AWS organization. Used to manage AWS account within organizations.
• Organizational root can contain other containers (organizational units or OU )

Individual billing methods is removed, pass the billing to the management account of the organization. Consolidated billing to payer account

• Benefits as a whole since it removes financial admin overhead and more usage also cheaper rates
• Consolidation of reservations and volume discounts

Larger enterprises often keep management account clean and separate account to handle login

• Might also have existing identity system or identity federation to access the identityOr your own aws identities using IAM
• AWS allow identity federation so on-premise identity can be used to designated login account. Use role switch to switch into other member accounts -> assumes roles of other AWS account.

Demo: 3 different AWS account in organization (general, prod, dev)

• prod and dev make a role and specify general’s account id
• General then can switch to prod and dev when they specify the account id and name

Service Control Policies §

Services to restrict AWS accounts. Essential in design and implementation in larger AWS platform.

SCP is a policy (json document) and can be attached to one or more units (account, organization) - Attaching to one organizational unit affects the whole, including its nested org childrens - Management account is never affected by any SCP. Security practice to never restrict it.

SCPs are account permission boundaries

• limit what account can do,
• do not grant any permissions
• Default is FullAWSAccess - implicit default deny
  • Allow list architecture - FullAWSAccess writes to allow all (Easy admin overhead)
  • Deny list architecture - No FullAWSAccess (implicit default deny), need to write policy to allow specific service (Bigger admin overhead, but more recommended)

Identity policies and service control policies need to have both allow access to have effect. - Having allow only in either one will be denied

CloudWatch Logs §

• Public service - usable from AWS or on-premises
• Store, monitor, and access logging data
• AWS Integrations - EC2, VPC flow logs, Lambda, CloudTrail, R53
• Can generate metrics based on logs - metric filter

Service

• us-east 1 (region service)
• all logging source injects log events to log streams
• log groups - container for multiple log streams
  • stores config settings, retention settings and permissions
  • also defines metric filters (application error code) - increment metric - can notify alarm

CloudTrail §

• Logs API calls/ activities as clodtrail event
• stores 90 days in event history
• enabled by default and no cost for 90 days history
• Customise service by creating 1 or more trails
• CloudTrail trail - unit of config
  • logs event to aws region
  • can be one region trail (only 1 region) or all regions (collection of trails as 1 logical trail)
  • global services log to us-east-1 (IAM, STS, CloudFront) - needs to be for all regions
• 3 types
  • Management events (default) - provides info about management operations performed on resource in AWS account (control plane operations)
    • Creating/ terminating EC2 instance
  • Data events - extra cost
  • Insight events

Essentials

• Enabled by default - 90 days - no s3
• trails are how to configuse s3 and cw logs
• management events by default
• IAM, STS, CloudFront -> Global Service Events
• Not real time - there is delay

AWS Control Tower §

• Quick and easy setup of multi-account environment
• Orchestrates other AWS services to provide this functionality
• Organizations, IAM Identity Center, CloudFormation, and more
• Landing Zone - multi-account environment
  • …SSO/ ID Federation, Centralised Logging
• Guard Rails - detect/mandata rules/standards across all accounts
• Account factory - Automates and standardises new account creation
• Dashboard - single page oversight of the entire environment

Landing Zone §

• Well architected multi-account environment - Home region
  • built with AWS org, config, Cloud Formation
• Security OU - Log Archive and Audit accounts (CloudTrail and Config logs)
• Sandbox OU - Test/ less rigid security
• IAM Identity Center (AWS SSO) - SSO, multiple-accounts, ID federation

Guard Rails §

• Rules - multi-account governance
• Mandatory, Strongly recommended, or elective
• Preventive - stop you doing things
  • enforced or not enabled
• Detective - compliance checks (config rules)
  • clear, in violation, or not enabled
  • detect CloudTrail enabled or EC2 Public IPv4

Account Factory §

• Automated account provisioning
  • Cloud admins or end users
• Guardrails - automatically added
• Account admin given to a named user (IAM identity center)
• Account and network standard config
• Accounts can be closed or repurposed
• Can be fully integrated with business SDLC

Prev: 1-aws-fundamentals
Next: 3-simple-storage-service