La Estancia Azul

Inicio serie de posts con los resumenes más importarntes de cara al SAA - C03 (AWS Certificed Solutions Architect). En esta primera entrega vemos IAM.

IAM - Identity And Access Management: define who (users) or what (services) can access servicesa and resources. Users/Groups/Roles (we assign permissions to roles, then roles to either services or users / groups). Understand what trusted entities (IAM roles or users or services acting on your behalf), trusted resources (resources owned by your AWS accounts or by AWS services acting on your behalf), expected networks (on-premises data centers and VPCs acting on your behalf)

IAM Policies: json documents to define permission assigments. Usually atached to groups via roles. Users directly attached policies are called inline policies. Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:Describe*",
                "ssm:Get*",
                "ssm:List*"
            ],
            "Resource": "*"
        }
    ]
}

IAM Advanced policies:

• Advanced conditions: aws:SourceIp, aws:RequestedRegion, ec2:ResourceTag, aws:MultiFactorAuthPresent
• Resource Policies & aws:PrincipalOrgID: can be use to restrict access to acounts members of an AWS Organizations.

IAM Password Policy: set min password length, required character types, define expiration rules and prevent it from re-use passwords. MFA is also a must.

IAM Security Tools:

• IAM Credentials Report (account-levelt): list all user accounts and status of their credentials. 
• IAM Access Advisor (user-level): service permissions granted to a user and when last accessed.

Guidelines and Best Practices:

1. Don't use root account except for initial setup
2. One AWS user = One physical user
3. Use groups and roles. Assign users to groups
4. Strong password policy
5. Enforce use of MFA
6. Use roles for AWS services
7. Use access keys for CLI/SDK
8. Audit permissions with Credentials Report and Access Advisor
9. Never share IAM users & access keys

Access Keys and Cli: three options to access AWS: Console, CLI and SDK. An alternative (not available in every region) is CloudShell (terminal within the AWS Console).

AWS Organizations: manage multiple AWS accounts at once: one management account with consolidated billing across all accounts (pricing benefits such as reserved instances, saving plans, etc.), central loggin (cloudwatch, cloudtrail).

• Service Control Policies (SCPs): IAM policies attached to OU or accounts to restrict users and roles. Must haev an explicit allow. Denies are inherited from the SCP hierarchy.

IAM Roles vs Resource Based Policies: assume role you give-up your original permissions termporarily, with resource-based policies not. Resourcer-based policies are attached to resources (S3 buckets, SQS, KMS...)

VPC Endpoint policies: attached to VPC endpoints to control which principals, actions, and resources can be accessed by using a VPC endpoint.

IAM Permission Boundaries: defined maximum amount of IAM permissions user or roles can have. Can be used in combination with AWS Organization SCPs.

IAM Identity Center (successor of AWS SSO): one log-in for all your AWS accounts in ORganizations, Business cloud applications, SAML 2.0, EC2 windows instances... IDP can be 3rd party (AD...), or Identity Store or IAM identity center.

AWS Directory Services: 

1. AWS Managed Microsoft AD: create your own AD in AWS. And/Or connect two on-premises AD with a two-way trust relationship.
2. AD Connector: directory gateway (proxy) to redirect to on-premises AD (supports MFA). Users are managed on-premises AD. 
3. Simple AD: ad-compatible managed directory on AWS which cannot be joined with on-premises.

AWS Control Tower: easy way to set up and govern a secure an compliant multi-account AWS env. Guardrails provides governance by using preventive guardrails (trough SCPs) and detective guardarils (with AWS Config).