Use a Deny with no action

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::122610500691:user/john"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::test.test-devops.kitboga.s3"
        },
        {
            "Sid": "DenyAllOtherActions",
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::122610500691:user/john"
            },
            "NotAction": "s3:GetObject",
            "Resource": "arn:aws:s3:::test.test-devops.kitboga.s3/*"
        }
    ]
}

Bob is able to list objects in the bucket.

Bob is able to get objects from the bucket.

Key takeaways

By default, all requests are implicitly denied (the AWS account root user has full access by default).

An explicit allow in an identity-based or resource-based policy overrides the default.

If a permissions boundary, AWS Organizations SCP, or session policy is present, it might override the allow with an implicit deny.

An explicit deny in any policy overrides any allows.

If the requested resource has a resource-based policy that allows the requested action, then AWS returns a final decision of allow. If there is no resource-based policy or if the policy does not include an Allow statement, then the evaluation continues.

If there is a session policy present and it does not allow the requested action, then the request is implicitly denied.

Principals

Account

When you use an AWS account identifier as the principal in a policy, you delegate authority to the account. Within that account, the permissions in the policy statement can be granted to all identities, including IAM users and roles in that account. When you specify an AWS account, you can use the Amazon Resource Name (ARN) arn:aws:iam::AWS-account-ID:root or a shortened form that consists of the aws: prefix followed by the account ID.

For example, given an account ID of 123456789012, you can use either one of the following methods to specify that account in the Principal element.

Principal element arn:aws:iam and account number.

IAM User

You can specify an individual IAM user (or array of users) as the principal, as in the following examples. When you specify more than one principal in the element, you grant permissions to each principal. This is a logical OR and not a logical AND because you are authenticated as one principal at a time. In a Principal element, the user name is case-sensitive. When you specify users in a Principal element, you cannot use a wildcard (*) to mean “all users.” Principals must always name a specific user or users.

Example of Principal with the arn:aws:iam account number and username.

Federated users

If you already manage user identities outside 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 AWS and give these external user identities permissions to use AWS resources in your account. IAM supports SAML-based IdPs and web identity providers, such as Login with Amazon, Amazon Cognito, Facebook, or Google.

Here are examples of a Principal element used for federated web identity users and for federated SAML users.

Example of Principal when federated using SAML or web identity provider.

IAM Roles

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. The entity that assumes the role will lose its original privileges and gain the access associated with the role.

AWS Services
AM roles that can be assumed by an AWS service are called service roles. Service roles must include a trust policy, which are resource-based policies that are attached to a role that define which principals can assume the role. Some service roles have predefined trust policies. However, in some cases, you must specify the service principal in the trust policy. A service principal is an identifier that is used to grant permissions to a service.

The identifier includes the long version of a service name and is usually in the long_service-name.amazonaws.com format. The following example shows a policy that can be attached to a service role. The policy enables two services—Amazon EMR and AWS Data Pipeline—to assume the role.

Example of AWS service role for Amazon EMR and AWS Data Pipeline.

Condition keys for passing roles

To pass a role to an AWS service, a user must have the proper permissions. This helps to ensure that only approved users can configure a service with a role that grants permissions. In order to allow a user to pass a role to an AWS service, you must first add the iam:PassRole action to its IAM policy. You may also add IAM condition keys to your policies to further control how roles are passed. Review the two IAM condition keys below that have to do with passing roles.

SAML-Based Federation

You can enable federated access to AWS accounts using IAM and AWS STS, which allows you to enable a separate SAML 2.0-based IdP for each AWS account and use federated user attributes for access control. With IAM, you can pass user attributes, such as cost center or job role, from your IdPs to AWS, and implement fine-grained access permissions based on these attributes. IAM helps you define permissions once and then grant, revoke, or modify AWS access by simply changing the attributes in the IdP.

The AssumeRoleWithSAML request

Before your application can call AssumeRoleWithSAML, you must configure your SAML IdP to issue the claims that AWS requires. Additionally, you must use IAM to create a SAML provider entity in your AWS account that represents your identity provider. You must also create an IAM role that specifies this SAML provider in its trust policy.

For more information, see the following resources:

About SAML 2.0-based federation in the IAM User Guide
Creating SAML identity providers in the IAM User Guide
Configuring a relying party and claims in the IAM User Guide
Creating a role for SAML 2.0 federation in the IAM User Guide

The AssumeRoleWithWebIdentity request

Before your application can call AssumeRoleWithWebIdentity, you must have an identity token from a supported identity provider and create a role that the application can assume. The role that your application assumes must trust the identity provider that is associated with the identity token. In other words, the identity provider must be specified in the role’s trust policy.

Calling AssumeRoleWithWebIdentity does not require the use of AWS security credentials. Therefore, you can distribute an application (for example, on mobile devices) that requests temporary security credentials without including long-term AWS credentials in the application. You also don’t need to deploy server-based proxy services that use long-term AWS credentials. Instead, the identity of the caller is validated by using a token from the web identity provider.

For more information, see the following resources:

Using web identity federation API operations for mobile apps and federation through a web-based identity provider.
Web Identity Federation Playground: Walk through the process of authenticating through Login with Amazon, Facebook, or Google; getting temporary security credentials; and then using those credentials to make a request to AWS.

Amazon Cognito for mobile applications

The preferred way to use web identity federation for mobile applications is to use Amazon Cognito. Amazon Cognito lets you add user sign-up, sign-in, and access controls to your web and mobile apps. You can define roles and map users to different roles so that your app can access only the resources that are authorized for each user. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Apple, Facebook, Google, and Amazon, and enterprise identity providers via SAML 2.0. User sign-in can also be done directly via Amazon Cognito.

The following diagram shows a simplified flow for how this might work using Login with Amazon as the IdP. Choose each icon for more information.

Diagram of a user logging into AWS with a web identity provider, being authenticated with Amazon Cognito, receiving an STS token, and gaining access to resources.

Amazon Cognito authentication workflow

The authentication workflow with Amazon Cognito starts by having the user log in to a web IdP. Then, the user device sends a GetId API call to establish a new identity in Amazon Cognito or return the identity already associated with that particular device.

The device will send the token received by the web IdP to Amazon Cognito to validate with the provider and ensure that the token:

Is valid and from the configured provider.
Is not expired.
Matches the application identifier created with that provider.
Matches the user identifier.

Workflow of the Amazon Cognito authorization process.

Then, after you establish an Amazon Cognito identity ID, the GetCredentialsForIdentity API can be called. Amazon Cognito will once again validate the web IdP token before making the AssumeRoleWithWebIdentity API call to AWS STS for the temporary security credentials.

AWS IAM Identity Center for User Federation

So far, you have seen how IAM can help federate users from your organization into AWS accounts and applications. Another AWS service and a great choice to help you define federated access permissions for your users based on their group memberships in a single centralized directory is AWS IAM Identity Center (successor to AWS Single Sign-On) . IAM Identity Center makes it easy to centrally manage federated access to multiple AWS accounts and business applications and provide users with single sign-on access to all their assigned accounts and applications from one place. You can use IAM Identity Center for identities in the Identity Center directory, your existing Microsoft Active Directory, or external IdP.

IAM Identity Center provides the following benefits:

bulletBuilt-in integrations with business cloud applications, such as Salesforce, Box, GitHub, and Office 365.
bulletBuilt-in directory for user and group management to serve as an IdP to authenticate users to IAM Identity Center enabled applications, the AWS Management Console, and SAML 2.0 compatible cloud-based applications.
bulletIntegration with AWS services, such as AWS Organizations.
bulletLog in CloudTrail of all sign-in and administrative activities for auditing. You can send these logs to SIEM solutions such as Splunk and Sumo Logic to analyze them.
bulletAWS Access portal for users to sign in with their existing corporate credentials and access all of their assigned accounts and applications from one place.
bulletAbility to use AWS CLI v2 to access AWS resources via IAM Identity Center. This has the benefit of providing short-term credentials to your users to more safely access your resources. You can automatically or manually configure a profile for the CLI to access resources in your AWS accounts (see demo below).

For more information on getting started with AWS IAM Identity Center, see https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html.

For more information on service-linked roles, see https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role.

AWS access via permission sets

An IAM Identity Center permission set is a collection of administrator-defined policies that IAM Identity Center uses to determine a user’s effective permissions to access a given AWS account. Permission sets can contain either AWS-managed policies or custom policies. Permission sets are provisioned to the AWS account as IAM roles and are presented to users as such. You can assign more than one permission set to a user. Users who have multiple permission sets must choose one of the roles when they sign in to the AWS access portal.

Diagram of policies with permission sets that allow the users to see and choose different roles.

It is important to note that permission sets are used for only AWS accounts. Permission sets are not used to manage access to cloud applications. Permission sets ultimately get created as IAM roles in a given AWS account, and trust policies allow users to assume the role through IAM Identity Center.

IAM Access Analyzer

IAM Access Analyzer continuously monitors policies for changes where you no longer need to rely on intermittent manual checks in order to catch issues as policies are added or updated. Using IAM Access Analyzer, you can proactively address any resource policies that violate their security and governance best practices around resource sharing and protect their resources from unintended access. IAM Access Analyzer delivers comprehensive, detailed findings through the IAM, Amazon S3, and AWS Security Hub consoles and also through its APIs. Findings can also be exported as a report for auditing purposes.

IAM Access Analyzer findings provide definitive answers of who has public and cross-account access to AWS resources from outside an account.

How does it work?

When you enable IAM Access Analyzer, you create an analyzer for your AWS account or your entire organization if it is using AWS Organizations. The organization or account you choose is known as the zone of trust for the analyzer. You can create only one analyzer per Region in an account. Choose each icon below to learn more about the tool.

Diagram of an account with resource-based policies sending IAM Access Analyzer findings to the security team.

IAM Access Analyzer supports the following resource types:

IAM roles – Trust policies are analyzed and findings are generated for roles within the zone of trust. These findings are accessible by an external entity that is outside your zone of trust.
Amazon S3 buckets – Findings are generated when an Amazon S3 bucket policy, ACL, or access point applied to a bucket grants access to an external entity.
AWS KMS keys – Findings are generated if a key policy or grant allows an external entity to access the key.
AWS Lambda functions – Findings are generated for policies that grant access to the function to an external entity.
Amazon SQS queues – Findings are generated for policies that allow an external entity to access a queue.

Viewing Access History

As an administrator, you might grant permissions to IAM users or roles beyond what they require. Because of this, IAM provides last accessed information to help you identify unused permissions, refine your policies, and allow access to only the services and actions that your IAM entities use. This information helps you to better adhere to the best practice of least privilege. You can view last accessed information for entities or policies that exist in IAM or AWS Organizations.

Last accessed information types

You can view two types of last accessed information for IAM entities using the AWS Management Console, AWS CLI, or AWS API. The two types are allowed AWS service information and allowed action information. The information includes the date and time when the attempt was made. Action last accessed information is available only when Amazon S3 management actions, such as creation, deletion, and modification actions, are used.

You can view information for each IAM resource below. In each case, the information includes allowed services for the given reporting period:

User – View the last time that the user tried to access each allowed service.
Group – View information about the last time that a group member attempted to access each allowed service. This report also includes the total number of members that attempted access.
Role – View the last time that someone used the role in an attempt to access each allowed service.
Policy – View information about the last time that a user or role attempted to access each allowed service. This report also includes the total number of entities that attempted access.

Access Advisor tab

To view last accessed information using the console, navigate to the IAM dashboard, and choose the desired IAM resource on the left. Then, select the resource, and choose the Access Advisor tab to view the information.

You can also view last accessed information using the AWS CLI or the AWS API.

AWS CloudTrail log contents

There can be dozens or even hundreds of events like the one covered in the above example in one CloudTrail log file. The body of a CloudTrail log file contains multiple fields that help you determine the requested action as well as when and where the request was made. Here are the important fields you need to be aware of:

eventTime	The date and time of the event reported in UTC.
eventType	There can be three types of event: AwsConsoleSignin – A user in your account (root, IAM, federated, SAML, or SwitchRole) signed in to the AWS Management Console.AwsServiceEvent – The called service generated an event related to your trail. For example, this can occur when another account made a call with a resource that you own.AwsApiCall – A public API for an AWS resource was called.
eventSource	The service that the request was made to. This name is typically a short form of the service name without spaces plus .amazonaws.com. For example:AWS CloudFormation is cloudformation.amazonaws.com.Amazon EC2 is ec2.amazonaws.com.Amazon Simple Workflow Service is swf.amazonaws.com.This convention has some exceptions. For example, the eventSource for Amazon CloudWatch is monitoring.amazonaws.com.
eventName	The requested action, which is one of the actions in the API for that service.
sourceIPAddress	The IP address where the request came from. If one AWS service calls another service, the DNS name of the calling service is used.
userAgent	The tool or application through which the request was made, such as the AWS Management Console, an AWS service, the AWS SDKs, or the AWS CLI. The following are example values:signin.amazonaws.com – The request was made by an IAM user with the AWS Management Console.console.amazonaws.com – The request was made by a root user with the AWS Management Console.lambda.amazonaws.com – The request was made with AWS Lambda.aws-sdk-java – The request was made with the AWS SDK for Java.aws-sdk-ruby – The request was made with the AWS SDK for Ruby.aws-cli/1.3.23 Python/2.7.6 Linux/2.6.18-164.el5 – The request was made with the AWS CLI installed on Linux.
errorMessage	Any error message returned by the requested service.
requestParameters	The parameters that were sent with the API call, which can vary depending on the type of resource or service called. For example, in an Amazon S3 API call, you could have the bucketName and location sent as parameters.
resources	List of AWS resources accessed in the event. This can be the resource’s ARN, an AWS account number, or the resource type.
userIdentity	A collection of fields that describe the user or service that made the call. These fields can vary based on the type of user or service. The following values are possible types of identity:Root – The request was made with your AWS account credentials. If the userIdentity type is Root and you set an alias for your account, the userName field contains your account alias. IAMUser – The request was made with the credentials of an IAM user.AssumedRole – The request was made with temporary security credentials that were obtained with a role via a call to the AWS STS AssumeRole API call. This can include roles for Amazon EC2 and cross-account API access.FederatedUser – The request was made with temporary security credentials that were obtained via a call to the AWS STS GetFederationToken API. The sessionIssuer element indicates if the API was called with root or IAM user credentials.AWSAccount – The request was made by another AWS account.AWSService – The request was made by an AWS account that belongs to an AWS service. For example, AWS Elastic Beanstalk assumes an IAM role in your account to call other AWS services on your behalf.