IAM Best Practices:
- Secure the root account
- Create individual IAM users
- Use groups to assign permissions
- Enable MFA for privileged users
- Rotate credentials often
- Use IAM roles whenever possible
- IAM works across all regions
IAM POLICY NINJA
1st Case: Limit AWS EC2 instances by type
- Goal: Limit a user from starting an instance unless the instances is t1, t2 and m3
- Create a policy and attach it to the user
- Use the policy generator to make life easier, generates the JSON automatically. But this was a fail!
Policy specification basics
PARC Model: Principle, Action, Resource and Condition
- Principal: Actor, entity, something that is going to be allowed or denied access to a resource. Indicated by ARN (Amazon Resource Name). Policies are two types. Those are attached to a user, group or roles aka called IAM policies. Those are attached to a specific resource; i.e. bucket, as known as resource based policies
- Action: What you want that principle be able to do. Action and API can be used interchangeably because they are highly correlated.
- NotAction: Let’s you specify an exception to a list of actions. This could result in shorter policies than using Action and denying many actions. For example: let’s say you want to allow everything but IAM APIs. Below is not a Deny. A user could still have a separate policy that grants IAM:* . However if you write two actions within one statement with one being explicitly Deny to IAM, then you are able to prevent the user from ever being able to call IAM APIs
- Resources: Objects that you allow the actor to request.
- Conditions: Optional criteria to be added, can contain multiple conditions. How do you evaluate it? If a single condition includes multiple values for one key, the condition is evaluated using logical OR. Multiple conditions or multiple keys in a single condition, and in that case, conditions are evaluated using logical AND. For example below means the time is after 12pm on 8th Oct AND the time is before 15pm on 8th Oct AND the request comes from one of those CIDR blocks OR All these conditions must be MET in order for the statement to evaluate to TRUE
- Lifesavers for creating lighter smaller policies. They are based on existing keys (aws:SourceIP, aws:CurrentTime etc).
- Principal-specific keys (aws:username, aws:userid, aws:principaltype)
- Provider specific keys (graph.facebook.com:id, www.amazon.com:user_id)
- SAML keys (saml:aud, saml:iss)
- Managed Policies are the newer way to make use of IAM policies. They can be attached to multiple users, groups and roles
- Customer managed policies: These are created and maintained by you and you can attach 10 managed policies per user, group or role. You can also limit who can attach which roles
- Inline Policies (older way). The way it works is to copy and paste to the user group or role
- Resource-based policies are the policies that live with the resource which are bucket policies for S3, vault for Glacier and topic for SNS and queue policies for SQS
Creating a home directory with S3
- Goal is to allow users to use S3 as a file storage/document. 100s of users. You cannot create a bucket for user. Create a managed policy that limits access to a prefix in an S3 bucket. Example is arn:aws:s3:::my_bucket/home/Bob/*
Creating a limited IAM administrator
- Goal is to create a limited admin who can use the IAM console to manage users, but only using certain managed policies. This will examine group policies that use variables to. Grant full admin access to DynamoDB and read/write access to an S3 bucket. Grant admin access to the IAM console to be able to create users and generate access keys. Limit the admin to a well-defined set of managed policies
EC2 policies after resource-level permissions
- You can assign policies per EC2 instance basis now. You can also have a tag on the instance and limit user to access to a specific instance within a region
AD Federation Services
- If you wanna create users and groups with AWS SSO, you can do that. However, if you are using Managed AD (Active Directory) or AD Connector you cannot as users/groups are coming from the on-prem AD.
- AWS SSO is all about workforce, meaning your internal users and groups whereas Cognito is more about customer focused/facing platform.