AWS Identity Federation

IAM Security Token Service (STS) :

• STS allows you to create temporary security credentials that grant trusted users access to you AWS resources.
• These temporary credentials are for short-term use, with a configurable session duration (time)
• Once expired, they can no longer be used to access your AWS resources.
• When requested through an STS API call , a credential object is retured containing :-

1.   - Session Token
2.   - An Access Key ID
3.   - A Secret Access Key
4.   - Expiration Time Stamp

When to Use STS :

- Identity Federation

Enterprise Identity federation ( authenticate through your companies network)

  STS supports SMAL (security Assertion Make up Language) which allows for use of MS Active        Directory of your own solutions.

Web Identity Federation (3rd party identity providers i.e FB google twitter etc)

- Roles for cross-Account Access

  used for organization that have more than one AWS account

- Roles for Amazon EC2 or other AWS services

  grant access to application running on an ec2 instance to access other AWS services without having    to imbed credentials

 

* For mobile applications AWS recommend using Cognito rather than STS directly because it provides additional mobile specific functionality which make the flow easier to manage.

Assume Role :

Using the AssumeRole API call, an IAM user can assume a role in another AWS account to perform specific, allowed actions.

AssumeRoleWithWebIdentity :

Using the AssumeRoleWithWebIdentity API call, our user can assume a role in the target AWS account to perform specific, allowed actions. The user receives an ID Token from Google or any IDP, which is then embedded in the AssumeRoleWithWebIdentity request to AWS. AWS returns our STS credentials.

e.g. User logs into Google, which returns an ID Token for our Application, User then requests temporary credentials to our account, allowing her to assume the S3 role and perform his actions.

AssumeRoleWithSAML :

our enterprise user , who exists in our Active Directory, is able to authenticate against ADFS and use that response with our SSO Page.

The SMAL approach allows you to leverage existing users, avoiding having to create IAM users for each person.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc_cognito.html

AWS Billing Model

AWS provide 3 Billing Model :

On-Demand : is the default AWS billing model. You pay for what you consume. $per hour, $per GB transfered, $ per GB month stored.

On-Demand ideally suited for the ad-hoc usage, where you cant calculate future usage patterns and not ready for interruption or failure.

It provides small discounts on high volume but generally most expensive billing model.


Reserved : this model provides significant reductions in cost & capacity reservations in exchange for commiting to a 12 or 36 month term.

You can pay All Upfront , Partial Upfront or No Upfront - with Full Upfront providing the best cost advantages.

Reservations can be ised for EC2 instances , RDS instances, DynamoDB performance and many other services in AWS.

Reserved terms are useful when your usage is known and steady-state.

You can reserve in a Region and also inside a AV-Zone. AvZone can also give you reserve capacity.


Spot : this is suited for workload where failure and interruption is acceptable but want lowest price.

Spot pricing can be significantly cheaper than on demand but 100% defendant on spare capacity & price can be higher if capacity is constrained.

Resources you choose to allocate using a spot pricing plan can be terminated with very little notice any workloads need to be tolerant of interruption.

Spot resources have the lowest startup priority vs on-demand and reserved.


https://aws.amazon.com/blogs/aws/amazon-ec2-update-streamlined-access-to-spot-capacity-smooth-price-changes-instance-hibernation/
https://aws.amazon.com/blogs/compute/new-amazon-ec2-spot-pricing/
https://github.com/open-guides/og-aws#billing-and-cost-management

AWS Config

AWS Config is a detailed view of the configurations of AWS resources like ec2, EBS, security groups, VPC, S3 etc.


with AWS Config you can :

• Evaluate resource configurations for desired settings 
• Get a snapshot of the current configurations associated with your account
• Retrieve current or historical configurations of resources in your account.
• Receive a notification for creations deletions and modifications
• View relationships between resources e.g. ec2 talking to who or members of security group.

Uses of AWS Config:

• Identity usage/change in congif over time - current & historical
• Helps with architecture planning - shows product or service relationship
• Can generate events on changes
• Can help keep a implementation in compliant state
• Assists security team - changes to SG's and NACl's over time.
• Fault finding & investigation - last know good configuration

Below snippet will give you idea :

for more info check : https://aws.amazon.com/config/faq/

Service Control Policies

Before we understand SCP lets check what AWS Organizations is -

AWS Organization is a service that lets you consolidate multiple AWS accounts into a single organization. This allows you to manage all accounts with in the organization in one place.

AWS Organization makes billing and permissions easier and allows fort the creation of managed accounts. Accounts are organized hierarchically, which provides better security and compliance controls.

This is Free service !! AWS Org.

You can convert standard AWS account into Master account and other AWS account would act as Member accounts. Its a hierarchical structure and at the top we have ROOT container which is created when AWS Organization is created.

There is only one Root container and applying policies at the root level would applicable to all OUs and accounts under it or below.

An OU is an Organizational Unit where you can group AWS accounts under a single OU.
Attaching policies at an OU level which would also apply to all accounts part of OUs.


AWS Organization features :

• Centralized management of all of your AWS accounts.
• Consolidated billing for all member accounts.
• Hierarchical grouping of your accounts to meet your budgetary, security, or compliance needs.(SCP)
• Control over the AWS services and API actions that each account can access.(SCP)
• Integration and support for AWS Identity and Access Management (IAM).
• Integration with other AWS services
• Data replication that is eventually consistent

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html


Switch Role allows management of resources across AWS accounts using single ID and password. you can switch role after AWS admin configures a role and give you the account and role details.

You can use Account Switch role functionality to manage it from same console , you just need to add that by adding account and role (organizationAccountAccessRole).


Now lets talk about SCP Service Control Policies -

Service Control Policies (SCP) :  SCP when applied directly or indirectly to AWS accounts define what actions can be performed on what services within that account. The ACTIONS and SERVICES can NEVER exceed those specified by any applicable SCPs.

SCP act as a way of limiting permissions in member accounts.

SCP do not have any effect on Master account but for all other accounts they impact IAM and the ROOT user.

SCP contain explicit ALLOW or DENY statements but these don't GRANT permissions , they only say those permissions are permitted. Anything not explicitly allowed is denied.

If multiple SCPs apply to an account , only the overlap of those SCPs is permitted & deny always wins.

SCP Policy - we can directly apply to account or root container and it is applicable what all account are inherited in the Hierarchy and It goes downwards.

Master account should be ignored because SCP is not applicable to Master account.

Use Master account for billing purpose only do not put resources in it because no SCP applies to it.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html

AWS IAM Essentials

IAM - Identity Access Management

IAM is where you manage your AWS users, groups, roles and their access to AWS accounts and services.

You can use AWS IAM to securely control individual and group access to your AWS resources. You can create and manage user identities ("IAM users") and grant permissions for those IAM users to access your resources. You can also grant permissions for users outside of AWS ( federated users). 

Common use of IAM is to manage :

• Users
• Groups
• Roles
• IAM Access policies
• Api keys
• Specify a password policy as well as manage MFA requirements on a per user basis

NOTE : By default no new user you create in an AWS accounts has any access to any AWS Service. There is a implicit deny rule set on all new IAM users.

For all users except root user, permissions must be given that grant access to AWS services by IAM policies.

Best Practices For IAM :

• Delete your root access keys
• Activate MFA on your Root Account
• Create and use an IAM with Admin Privileges instead of the Root Account.
• Create individual IAM users
• Use group to assign permissions
• Follow the “Principal of Least Privilege”

Below is the Video for the IAM users and groups :

                           

Few important points on root user :-

The Root User is initially the only principal(identity) that can authenticate to the account and the only principal authorized to do so.

Root User is specific to an account.

Root user can create IAM principals that can also authenticate to the account and can be authorized to act with granular permissions.

Account Domains:
Aws accounts consist of three discrete domains :-

1. Authentication 
2. Authorization 
3. Billing

By default, every AWS account has separate billing, users and permissions. If an account is exploited , the Blast Radius is limited to that specific account.