IAM

iam-access-policies
permission guardrails
enforcing least privilege at scale
aligning identity with management and governance frameworks
Non people identities
Mandatory elements in IAM JSON Policy - Effect, Action

https://pages.awscloud.com/awsmp-h2-sec-digital-workspace-iam-ty.html

Gotchas

Make sure to give access like /* for any object that needs access for inside too

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

Best practices

Users-- Create individual users
Groups-- Manage permissions with groups
Permissions-- Grant least privilege
Auditing-- Turn on AWS CloudTrail
Password-- Configure a strong password policy
MFA-- Enable MFA for privileged users
Roles-- Use IAM roles for Amazon EC2 instances
Sharing-- Use IAM roles to share access
Rotate-- Rotate security credentials regularly
Conditions-- Restrict privileged access further with conditions
Root-- Reduce or remove use of root

AWS re:Invent 2018: [REPEAT 1] Become an IAM Policy Master in 60 Minutes or Less (SEC316-R1)

IAM policy language

IAM policies
- Two parts:
  - Specification: Defining access policies
  - Enforcement: Evaluating policies
When you define access policies, you specify which IAM principals are allowed to perform which actions on specific AWS resources and under which conditions
IAM enforces this access by evaluating the AWS request and the policies you defined and returns either yes or no answer
IAM policy structure (PARC model)
- Principal
  - The entity that is allowed or denied access
- Action
  - Type of access that is allowed or denied access
  - Action: s3.GetObject
- Resource
  - The amazon resource(s) the action will act on (arn - amazon resource number)
- Condition
  - The conditions under the access defined is valid
IAM policy evaluation rules

Policy types and how they work together

Policy types
- AWS Organizations

Guardrails to disable service access on the principals in the account

Service Control Policies (SCPs / SCP)

Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines.

An SCP restricts permissions for IAM users and roles in member accounts, including the member account's root user. Any account has only those permissions permitted by every parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an Allow policy statement) or explicitly (by being included in a Deny policy statement), a user or role in the affected account can't use that permission, even if the account administrator attaches the AdministratorAccess IAM policy with permissions to the user.

SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization.

Service control policy (SCP) is one type of policy that you can use to manage your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization’s access control guidelines. SCPs are available only in an organization that has all features enabled. SCPs aren't available if your organization has enabled only the consolidated billing features. Attaching an SCP to an AWS Organizations entity (root, OU, or account) defines a guardrail for what actions the principals can perform.

Service control policy (SCP) does not affect service-linked role
If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable service control policy (SCP), the user or role can't perform that action
Service control policy (SCP) affects all users and roles in the member accounts, including root user of the member accounts

Service control policies (SCPs) - AWS Organizations

AWS Identity and Access Management (IAM)

Grant granular permissions on IAM principals (users and roles) and control the maximum permission they can set

As Permission Policies and Permission Boundaries

Permission Boundaries

AWS supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. Here we have to use an IAM permission boundary. They can only be applied to roles or users, not IAM groups.

Scale and delegate permission management to developers safely. Control the maximum permissions employees can grant

AWS Security Token Service (AWS STS)

Reduce general shared permissions further

Scoped-down policies
Specific AWS services

Cross-account access and to control access from the resource

Resource-based policies
VPC Endpoints

Controls access to the service with a VPC endpoint

Endpoint Policies

AWS global condition context keys

Properties of the principal

aws:PrincipalArn
aws:PrincipalAccount
aws:PrincipalOrgPaths
aws:PrincipalOrgID
aws:PrincipalTag/tag-key
aws:PrincipalIsAWSService
aws:PrincipalServiceName
aws:PrincipalServiceNamesList
aws:PrincipalType
aws:userid
aws:username

Properties of a role session

aws:AssumedRoot
aws:FederatedProvider
aws:TokenIssueTime
aws:MultiFactorAuthAge
aws:MultiFactorAuthPresent
aws:ChatbotSourceArn
aws:Ec2InstanceSourceVpc
aws:Ec2InstanceSourcePrivateIPv4
aws:SourceIdentity
ec2:RoleDelivery
ec2:SourceInstanceArn
glue:RoleAssumedBy
glue:CredentialIssuingService
lambda:SourceFunctionArn
ssm:SourceInstanceArn
identitystore:UserId

Properties of the network

aws:SourceIp
aws:SourceVpc
aws:SourceVpce
aws:VpceAccount
aws:VpceOrgID
aws:VpceOrgPaths
aws:VpcSourceIp

Properties of the resource

aws:ResourceAccount
aws:ResourceOrgID
aws:ResourceOrgPaths
aws:ResourceTag/tag-key

Properties of the request

aws:CalledVia
aws:CalledViaFirst
aws:CalledViaLast
aws:ViaAWSService
aws:CurrentTime
aws:EpochTime
aws:referer
aws:RequestedRegion
aws:RequestTag/tag-key
aws:TagKeys
aws:SecureTransport
aws:SourceAccount
aws:SourceArn
aws:SourceOrgID
aws:SourceOrgPaths
aws:UserAgent

Title Unavailable | Site Unreachable

Policies

AWS Managed Policies

FullAccess
PowerUser
WriteOnly
ReadOnly

One particularly useful category of AWS managed policies are those designed for job functions. These policies align closely to commonly used job functions in the IT industry. The intent is to make granting permissions for these common job functions easy. One key advantage of using job function policies is that they are maintained and updated by AWS as new services and API operations are introduced. For example, the AdministratorAccess job function provides full access and permissions delegation to every service and resource in AWS. We recommend that this policy is used only for the account administrator. For power users that require full access to every service except limited access to IAM and Organizations, use the PowerUserAccess job function.

Customer Managed Policies

You can create standalone policies that you administer in your own AWS account, which we refer to as customer managed policies. You can then attach the policies to multiple principal entities in your AWS account. When you attach a policy to a principal entity, you give the entity the permissions that are defined in the policy.

A great way to create a customer managed policy is to start by copying an existing AWS managed policy. That way you know that the policy is correct at the beginning and all you need to do is customize it to your environment.

Inline Policies

An inline policy is a policy that's embedded in an IAM identity (a user, group, or role). That is, the policy is an inherent part of the identity. You can create a policy and embed it in a identity, either when you create the identity or later.

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

Example Policies

All certain users to access specific bucket path only

{
    "Version": "2012-10-17",
    "Id": "allowAccessToBucketPath",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:user/user1",
                    "arn:aws:iam::123456789012:user/user2"
                ]
            },
            "Action": [
                "s3:PutObject",
                "s3:List*",
                "s3:Get*"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket-name/path/*",
                "arn:aws:s3:::my-bucket-name/path"
            ]
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:user/user1",
                    "arn:aws:iam::123456789012:user/user2"
                ]
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::my-bucket-name",
            "Condition": {
                "StringLike": {
                    "s3:prefix": "path/*"
                }
            }
        }
    ]
}

IAM Roles

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources. For example, you might want to grant users in your AWS account access to resources they don't usually have, or grant users in one AWS account access to resources in another account. Or you might want to allow a mobile app to use AWS resources, but not want to embed AWS keys within the app (where they can be difficult to rotate and where users can potentially extract them). Sometimes you want to give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory. Or, you might want to grant access to your account to third parties so that they can perform an audit on your resources.

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

You might be clueless as to why AWS assume role isn’t working, despite being correctly set up | by Kamal Maiti | Medium

IAM Service Role

A service role is an IAM role that a service assumes to perform actions on your behalf. Service roles provide access only within your account and cannot be used to grant access to services in other accounts. An IAM administrator can create, modify, and delete a service role from within IAM. When you create the service role, you define the trusted entity in the definition.

If you are going to use the role with Amazon EC2 or another AWS service that uses Amazon EC2, you must store the role in an instance profile. An instance profile is a container for a role that can be attached to an Amazon EC2 instance when launched. An instance profile can contain only one role, and that limit cannot be increased. If you create the role using the AWS Management Console, the instance profile is created for you with the same name as the role.

Service-linked roles in IAM Identity Center

Service-linked roles are predefined IAM permissions that allow IAM Identity Center to delegate and enforce which users have single sign-on access to specific AWS accounts in your organization in AWS Organizations. The service enables this functionality by provisioning a service-linked role in every AWS account within its organization. The service then allows other AWS services like IAM Identity Center to leverage those roles to perform service-related tasks. For more information, see AWS Organizations and service-linked roles.

When you enable IAM Identity Center, IAM Identity Center creates a service-linked role in all accounts within the organization in AWS Organizations. IAM Identity Center also creates the same service-linked role in every account that is subsequently added to your organization. This role allows IAM Identity Center to access each account's resources on your behalf. For more information, see Configure access to AWS accounts.

Service-linked roles that are created in each AWS account are named AWSServiceRoleForSSO. For more information, see Using service-linked roles for IAM Identity Center.

Job functions

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html

ManagedPolicies

EC2InstanceConnect

Changes That I Make Are Not Always Immediately Visible

As a service that is accessed through computers in data centers around the world, IAM uses a distributed computing model called eventual consistency. Any change that you make in IAM (or other AWS services) takes time to become visible from all possible endpoints. Some of the delay results from the time it takes to send the data from server to server, from replication zone to replication zone, and from Region to Region around the world. IAM also uses caching to improve performance, but in some cases this can add time: The change might not be visible until the previously cached data times out.

You must design your global applications to account for these potential delays. Ensure that they work as expected, even when a change made in one location is not instantly visible at another. Such changes include creating or updating users, groups, roles, or policies. We recommend that you do not include such IAM changes in the critical, high-availability code paths of your application. Instead, make IAM changes in a separate initialization or setup routine that you run less frequently. Also, be sure to verify that the changes have been propagated before production workflows depend on them.

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

Web Identity Federation

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

Notes

Principle keyword means it's a resource based policy, otherwise identity based policy
Amazon s3 access point for dns names (instead of s3 file path)
No recylebin
CORS available
Can use postman to upload/download data to s3
Multipart upload to s3 (file greater than 100 MB)
Resiliency built in for multi part upload
Amazon s3 transfer acceleration

https://www.freecodecamp.org/news/aws-iam-explained

IAM > Roles > Identity Providers and Federation

If you already manage user identities outside of AWS, you can use IAM identity providers instead of creating IAM users in your AWS account. With an identity provider (IdP), you can manage your user identities outside of AWS and give these external user identities permissions to use AWS resources in your account. This is useful if your organization already has its own identity system, such as a corporate user directory. It is also useful if you are creating a mobile app or web application that requires access to AWS resources.

When you use an IAM identity provider, you don't have to create custom sign-in code or manage your own user identities. The IdP provides that for you. Your external users sign in through a well-known IdP, such as Login with Amazon, Facebook, or Google. You can give those external identities permissions to use AWS resources in your account. IAM identity providers help keep your AWS account secure because you don't have to distribute or embed long-term security credentials, such as access keys, in your application.

To use an IdP, you create an IAM identity provider entity to establish a trust relationship between your AWS account and the IdP. IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0)

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

PIM / PAM

PIM - Privileged Identity Management
PAM - Privileged Access Management

Almost every organization uses identity and access management (IAM) strategies or tools as part of its security practices. IAM is the overarching term to describe how companies manage user identities, authenticate users, and control access to company resources. Privileged identity management (PIM) and privileged access management (PAM) are subsets of IAM.

PIM and PAM address how companies manage who can access a company’s most critical resources, like servers, databases, applications, and Kubernetes clusters. They operate under the principle of least privilege to limit who and how many users can access secure systems and the sensitive data stored within.

PIM

Emphasizes resource management
Focuses on which user identities receive which access rights
Determine the parameters of what access is necessary for each user identity based on certain roles or attributes
May focus on distributing access to prevent superusers or admins from having too much power

PAM

Emphasizes securing resources by ensuring only certain validated identities can access those resources
Focuses on monitoring capabilities to prevent unauthorized access
Determines how to validate user identities, provide secure access to resources, and provision just-in-time escalated access for users that would not normally have access

PIM vs. PAM Security: Understanding the Difference | StrongDM

AWS Organizations

With AWS Organizations, you can consolidate multiple AWS accounts into an organization that you create and centrally manage. You can create member accounts and invite existing accounts to join your organization. You can organize those accounts and manage them as a group. With AWS Account Management you can update the alternate contact information for each of your AWS accounts.

docs.aws.amazon.com/organizations/

Best Practices for AWS Organizations

AWS Control Tower

Set up and govern a secure, multi-account AWS environment

Use AWS Control Tower to set up and operate your multi-account AWS environment with prescriptive controls designed to accelerate your cloud journey. AWS Control Tower orchestrates multiple AWS services on your behalf while maintaining the security and compliance needs of your new or existing organization.

AWS Control Tower provides the easiest way to set up and govern a secure, multi-account AWS environment by establishing a landing zone that follows AWS best practices. It automates the setup of a multi-account structure, centralizes logs, and uses a system of pre-packaged preventive and detective controls (guardrails) to enforce security, compliance, and operational policies. This enables organizations to maintain governance and prevent accounts from deviating from desired standards as they scale their cloud operations.

AWS Control Tower

Others

iam-access-policies

The Next Evolution in AWS Single Sign-On | AWS News Blog

AWS IAM Identity Center

How to Set Up Federated Single Sign-On to AWS Using Google Apps | AWS Security Blog

AWS Account Setup: My 10-Step Checklist After 14 Years - YouTube

Gotchas​

Best practices​

IAM policy language​

Policy types and how they work together​

Service Control Policies (SCPs / SCP)​

AWS Identity and Access Management (IAM)​

Permission Boundaries​

AWS global condition context keys​

Properties of the principal​

Properties of a role session​

Properties of the network​

Properties of the resource​

Properties of the request​

Policies​

AWS Managed Policies​

Customer Managed Policies​

Inline Policies​

Example Policies​

IAM Roles​

IAM Service Role​

Service-linked roles in IAM Identity Center​

Job functions​

ManagedPolicies​

Changes That I Make Are Not Always Immediately Visible​

Web Identity Federation​

Notes​

IAM > Roles > Identity Providers and Federation​

PIM / PAM​

PIM​

PAM​

AWS Organizations​

AWS Control Tower​

Others​

Gotchas

Best practices

IAM policy language

Policy types and how they work together

Service Control Policies (SCPs / SCP)

AWS Identity and Access Management (IAM)

Permission Boundaries

AWS global condition context keys

Properties of the principal

Properties of a role session

Properties of the network

Properties of the resource

Properties of the request

Policies

AWS Managed Policies

Customer Managed Policies

Inline Policies

Example Policies

IAM Roles

IAM Service Role

Service-linked roles in IAM Identity Center

Job functions

ManagedPolicies

Changes That I Make Are Not Always Immediately Visible

Web Identity Federation

Notes

IAM > Roles > Identity Providers and Federation

PIM / PAM

PIM

PAM

AWS Organizations

AWS Control Tower

Others