IAM, Accounts, and AWS Orgs Flashcards
IAM Policy Architecture
Set of security statements that grant or deny access to services for any identity that uses the policy.
JSON!
Policy doc is 1+ statements.
The ID will authenticate with AWS.
Takes the auth’d ID and reviews statements that apply to the ID, the services being accessed, and how they are being interacted with.
ALWAYS use Sid describes the statement: “FullACCESS”, “NoAccess”
Resource + actions. S3:add object in a bucket or [S3:add, Cloudfront:upload] Can use wildcards.
Effect is allow or deny.
Rules for overlap:
Explicit deny overrides all
Explicit allow
Default deny
Individuals, groups, and resources can have associated policy.
AWS managed, customer managed, & inline policies.
Inline policy - apply JSON to each individual - harder to manage… This is for exceptional cases. Terminations?
Customer Managed policies - Own object. Create the policy and attach to indiviuals/groups/resources. Reuseable! Used for normal access rights.
AWS managed (you don’t have to use these).
IAM Users
The identity is used for long-term AWS access. Humans, apps, or services.
ANY entity can be an IAM. Principal. Authenticated and authorized. Authentication proved that an identity is who they say they are. Username/password or access keys.
Turns into an Authenticated Identity.
AWS looks for applicable identity policies in order to authorize the identity is allowed to do that action.
ARN
Amazon resource names. Identify resources or a group of resources in any AWS account.
Used in IAM policies.
arn:aws:s3:::catgifs JUST the bucket
arn:aws:s3:::catgifs/* ALL OBJECTS in the bucket… not the bucket
Some actions operate at the bucket level… some on the object level. You must use the correct one.
:: means N/A or not needed. * is wildcard
ARN structure
arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id
arn:aws:s3:::catgifs (identifies a bucket)
arn:aws:s3:::catgifs/* (identifies all objects in the bucket)
IAM Groups
Containers for IAM users.
Cannot login to them. NO CREDENTIALS.
Oraganize and manage Users.
IAM User can be a member of more than one group up to 10.
Dev and QA groups.
Groups can have their own inline and managed policies.
AWS merges all individual and group policies.
Collect all of those and apply the deny, allow, deny rules to determine what a user can do.
TRICKERY: All users group is NOT built in. Can create that and add everyone but it is NOT native.
Groups cannot be nested in groups.
300 groups per acct but that’s a soft cap. log ticket past that.
Resource Policies
Can reference identities - an S3 bucket. Allows or denies identified access to the resource. ARN is used to identify a resource.
A resource cannot grant access to itself for a group.
IAM Roles
An identity type. Another type is the user.
Authenticated? Authorized? you can access.
Suited to be used by multiple principles. Users, apps, or services. Can we ID the number of IAM users? No? Use a role. A role represents a level of access. Use the permission of that role then log out and remove permissions.
Roles have two types of policy - trust and permissions.
Trust policy - Grant or deny access to a role. Can reference other roles, users, or services, and even other users in other aws accts.
AWS generates temporary credentials - if still valid, regen new credentials. STS:AssumeRole STS (secure token service)
IF role can access a resource then anything granted trust and permissions can also access.
Roles can be referenced in a resource policy!
When to use IAM Roles?
Most common is for AWS services themselves. EX. Lambda - start stop backups etc.
Has no permissions by default. Component of a service. It will need permissions in order to execute on another service. No hardcoding access keys. Create an IAM role. Execution role. Trusts the service. Permissions allow actions. Temp credentials given to Lanbda. The whole environment can access AWS resources.
ALWAYS better for AWS services to have roles assigned. Unknown number of identities needed - USE ROLE.
EMERGENCY SITUATIONS - Break Glass for Key. Must be intentional. Roles provide the same thing. Additional permissions based on the role trust and permissions.
Adding AWS into existing organization. Using Active Directory. Want to use SSO. Hitting 5000 IAM user limit.
External accounts cannot be used directly to access AWS resources. Allow a role to be assumed by an external ID. Active Directory. Can be hidden so the user does not know (Identity Federation)!
Ride sharing app? Millions of users. Web ID federation. Use signon with facebook, LinkedIn, etc. Can trust these identities, use role, get permissions.
ID FED No AWS creds must be shared.
Uses existing logins
Scales to 1000000 of accts.
CROSS acct access
AWS acct 1 needs access to AWS 2 S3.
Acct1 10000’s of IDs
Add role to AWS acct2!
Can use a role to give access to an entire other AWS acct.
Multi account management.
Service linked roles/PASSROLE
Service linked role - linked to specific service with a predefined set of permissions.
How a service with interact with another service on my behalf. Sometimes the user can define that behavior during setup.
Must be no longer used in order to delete.
In JSON you put the service in the resource key.
Role separation - give on group ability to create resource, another ability to use resource.
ListRoles & PassRole allowed in order to give the user the ability to pass the specific role to a service.
AWS Organizations
Manage Multiple AWS accts. Org root is a container.
Single Standard AWS -> create an org (acct is now mgmt, master, or payer) -> invite other existing standard accts -> they accept invites -> become part of org -> change to a member acct of organization
Hierarchical structure. Root -> OUs (org units) -> OUs (org unit) -> OUs (org unit)
CONSOLIDATED BILLING - passthrough to mgmt acct (payer acct). single monthly bill for mgmt and all members.
CONSOLIDATED USEAGE! - Pooled spending === discount.
Service control policies - restrict what accts In an org can do.
Can create new accts in org as new member. Just need a new, unique email. No invite needed this way. Best practice - single acct used to login to. It can be separate from the mgmt acct. Can setup Identity federation using that single acct too.
Role switch to use other account. Once logged in to IAM acct you can role switch (assume that role) into other accounts.
SCP service control policies
Restrict what accts in an org can do.
MGMT ACCT CANNOT BE RESTRICTED - do not allow access to services from MGMT acct.
Can be attached from org to org unit to individual. These cascade down the tree. Even the acct root user can be limited indirectly by reducing allowed permissions for the entire acct.
Very powerful service restrictions. THEY DO NOT GRANT permission.
Allow list or deny list enabled. Default is deny list with full AWS access to all services.
Allow list - one remove full access. two Add services you want to allow. More secure. Easy to block unintentionally but also more overhead.
If service policy allows and the Identity Policies applied to the account agree that access should be allowed then the account will have access.
CloudWatch Logs
Regional service - public service in aws public zone
VPCs and On-prem or even other cloud platforms
store, monitor, access logging data
info + timestamp
Many native integrations with many aws services
Unified cloudwatch agent is how outside AWS can log data into cloudwatch
Can use the SDKs to directly connect (developer and devops)
Can take log data and generate metrics - datapoints over time.
Step 1: gather data from a source
Step 2: source injects data into Cloudwatch logs
Step 3: Cloudwatch puts this in a log event with date and data blob
Step 4: Log event goes into a Log Stream
Log streams live in a log stream group. Represents a collection of related logs. Single EC2 Log Stream.
Log Group also stores config settings around permissions and retention of loggins. Metric filters are also defined here.
CloudTrail
API logging related to AWS accounts. Account activities are called a cloudtrail event.
User role or service can be source of change.
90 day history. Enabled by default. No cost for management logs. Data logs to cost $
If you want custom trails you can create. Management data and insight.
Management - info about mgmt operations on resources. Control plane operations - create ec2, create s3 bucket. Default on.
data operations on or in a resource - s3 bucket upload. Default off.
Trail is a unit of measurement. Logs events for a region. Trail can operate in 1 region or all regions.
Single region is only ever in the region it is created in. All region is managed as one logical trail (auto updates with new regions).
Few log global - IAM, cloudfront, STS - always log to us-east1 - must be enabled.
ALL GLOBAL LOGS GO TO us-east1
Logs that are stored in S3 are indefinite. Compressed JSON log files. Can be parsed easily!
Cloudtrail can be injected into CloudWatch Logs too! Can use that data for metrics too!
Organizational trail can store all info for all accounts in an organization!
CLOUD TRAIL IS NOT REAL TIME - up to 15 minutes. Not real time.
AWS control tower
Allow easy setup of multi acct environments. It has a home region (can allow or deny use of other regions) Does more than organizations.
Orchestrates. Uses orgs, IAM Identity center (for SSO & IDfed), Cloudformation, config & more. More features, automation, intelligence.
Landing zone - multi acct environment
SSO & ID federation, centralized logging and auditing
Guard rails - detect or mandate rules & standards
Account factory - automates and standardizes new account creation.
Dashboard - oversight of whole organization
Create a tower in an acct - it becomes tower landing zone mgmt acct
AWS Orgs
SSO
Control tower creates two OUs - foundational/security (audit(SNS, cloudwatch)) + log archive(aws config, cloudtrail)) and custom
Account factory can create, modify, delete accounts via console or service catalog. Totally automated. Config handled by Account Factory. Uses cloudformation to do a lot of this. Service control policy. Can include guardrails defined in the creation options. Standard network and account config (Ip addressing in a VPC). Can be tied into SDLC process. Stage of development requires an account. SO COOL.
Guardrails - preventative (stops from doing things) and detective (compliance check (clear, in violation, not enabled)
