# Walkthroughs that use policies to manage access to your Amazon S3 resources
This topic provides the following introductory walkthrough examples for granting access to Amazon S3 resources. These examples use the AWS Management Console to create resources (buckets, objects, users) and grant them permissions. The examples then show you how to verify permissions using the command line tools, so you don't have to write any code. We provide commands using both the AWS Command Line Interface (AWS CLI) and the AWS Tools for Windows PowerShell.
+ [Example 1: Bucket owner granting its users bucket permissions](example-walkthroughs-managing-access-example1.md)
The IAM users you create in your account have no permissions by default. In this exercise, you grant a user permission to perform bucket and object operations.
+ [Example 2: Bucket owner granting cross-account bucket permissions](example-walkthroughs-managing-access-example2.md)
In this exercise, a bucket owner, Account A, grants cross-account permissions to another AWS account, Account B. Account B then delegates those permissions to users in its account.
+ **Managing object permissions when the object and bucket owners are not the same**
The example scenarios in this case are about a bucket owner granting object permissions to others, but not all objects in the bucket are owned by the bucket owner. What permissions does the bucket owner need, and how can it delegate those permissions?
The AWS account that creates a bucket is called the *bucket owner*. The owner can grant other AWS accounts permission to upload objects, and the AWS accounts that create objects own them. The bucket owner has no permissions on those objects created by other AWS accounts. If the bucket owner writes a bucket policy granting access to objects, the policy doesn't apply to objects that are owned by other accounts.
In this case, the object owner must first grant permissions to the bucket owner using an object ACL. The bucket owner can then delegate those object permissions to others, to users in its own account, or to another AWS account, as illustrated by the following examples.
+ [Example 3: Bucket owner granting permissions to objects it does not own](example-walkthroughs-managing-access-example3.md)
In this exercise, the bucket owner first gets permissions from the object owner. The bucket owner then delegates those permissions to users in its own account.
+ [Example 4 - Bucket owner granting cross-account permission to objects it does not own](example-walkthroughs-managing-access-example4.md)
After receiving permissions from the object owner, the bucket owner can't delegate permission to other AWS accounts because cross-account delegation isn't supported (see [Permission delegation](access-policy-language-overview.md#permission-delegation)). Instead, the bucket owner can create an IAM role with permissions to perform specific operations (such as get object) and allow another AWS account to assume that role. Anyone who assumes the role can then access objects. This example shows how a bucket owner can use an IAM role to enable this cross-account delegation.
## Before you try the example walkthroughs
These examples use the AWS Management Console to create resources and grant permissions. To test permissions, the examples use the command line tools, AWS CLI, and AWS Tools for Windows PowerShell, so you don't need to write any code. To test permissions, you must set up one of these tools. For more information, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
In addition, when creating resources, these examples don't use root user credentials of an AWS account. Instead, you create an administrator user in these accounts to perform these tasks.
### About using an administrator user to create resources and grant permissions
AWS Identity and Access Management (IAM) recommends not using the root user credentials of your AWS account to make requests. Instead, create an IAM user or role, grant them full access, and then use their credentials to make requests. We refer to this as an administrative user or role. For more information, go to [AWS account root user credentials and IAM identities](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html) in the *AWS General Reference* and [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
All example walkthroughs in this section use the administrator user credentials. If you have not created an administrator user for your AWS account, the topics show you how.
To sign in to the AWS Management Console using the user credentials, you must use the IAM user sign-In URL. The [IAM Console](https://console.aws.amazon.com/iam/) provides this URL for your AWS account. The topics show you how to get the URL.
# Setting up the tools for the walkthroughs
The introductory examples (see [Walkthroughs that use policies to manage access to your Amazon S3 resources](example-walkthroughs-managing-access.md)) use the AWS Management Console to create resources and grant permissions. To test permissions, the examples use the command line tools, AWS Command Line Interface (AWS CLI) and AWS Tools for Windows PowerShell, so you don't need to write any code. To test permissions, you must set up one of these tools.
**To set up the AWS CLI**
1. Download and configure the AWS CLI. For instructions, see the following topics in the *AWS Command Line Interface User Guide*:
[Install or update to the latest version of the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html)
[Get started with the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
1. Set the default profile.
You store user credentials in the AWS CLI config file. Create a default profile in the config file using your AWS account credentials. For instructions on finding and editing your AWS CLI config file, see [Configuration and credential file settings](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
```
[default]
aws_access_key_id = access key ID
aws_secret_access_key = secret access key
region = us-west-2
```
1. Verify the setup by entering the following command at the command prompt. Both these commands don't provide credentials explicitly, so the credentials of the default profile are used.
+ Try the `help` command.
```
aws help
```
+ To get a list of buckets on the configured account, use the `aws s3 ls` command.
```
aws s3 ls
```
As you go through the walkthroughs, you will create users, and you will save user credentials in the config files by creating profiles, as the following example shows. These profiles have the names of `AccountAadmin` and `AccountBadmin`.
```
[profile AccountAadmin]
aws_access_key_id = User AccountAadmin access key ID
aws_secret_access_key = User AccountAadmin secret access key
region = us-west-2
[profile AccountBadmin]
aws_access_key_id = Account B access key ID
aws_secret_access_key = Account B secret access key
region = us-east-1
```
To run a command using these user credentials, you add the `--profile` parameter specifying the profile name. The following AWS CLI command retrieves a listing of objects in *`examplebucket`* and specifies the `AccountBadmin` profile.
```
aws s3 ls s3://examplebucket --profile AccountBadmin
```
Alternatively, you can configure one set of user credentials as the default profile by changing the `AWS_DEFAULT_PROFILE` environment variable from the command prompt. After you've done this, whenever you perform AWS CLI commands without the `--profile` parameter, the AWS CLI uses the profile you set in the environment variable as the default profile.
```
$ export AWS_DEFAULT_PROFILE=AccountAadmin
```
**To set up AWS Tools for Windows PowerShell**
1. Download and configure the AWS Tools for Windows PowerShell. For instructions, go to [Installing the AWS Tools for Windows PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html#pstools-installing-download) in the *AWS Tools for PowerShell User Guide*.
**Note**
To load the AWS Tools for Windows PowerShell module, you must enable PowerShell script execution. For more information, see [Enable Script Execution](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html#enable-script-execution) in the *AWS Tools for PowerShell User Guide*.
1. For these walkthroughs, you specify AWS credentials per session using the `Set-AWSCredentials` command. The command saves the credentials to a persistent store (`-StoreAs `parameter).
```
Set-AWSCredentials -AccessKey AccessKeyID -SecretKey SecretAccessKey -storeas string
```
1. Verify the setup.
+ To retrieve a list of available commands that you can use for Amazon S3 operations, run the `Get-Command` command.
```
Get-Command -module awspowershell -noun s3* -StoredCredentials string
```
+ To retrieve a list of objects in a bucket, run the `Get-S3Object` command.
```
Get-S3Object -BucketName bucketname -StoredCredentials string
```
For a list of commands, see [AWS Tools for PowerShell Cmdlet Reference](https://docs.aws.amazon.com/powershell/latest/reference/Index.html).
Now you're ready to try the walkthroughs. Follow the links provided at the beginning of each section.
# Example 1: Bucket owner granting its users bucket permissions
**Important**
Granting permissions to IAM roles is a better practice than granting permissions to individual users.For more information about how to grant permissions to IAM roles, see [Understanding cross-account permissions and using IAM roles](example-walkthroughs-managing-access-example4.md#access-policies-walkthrough-example4-overview).
**Topics**
+ [Preparing for the walkthrough](#grant-permissions-to-user-in-your-account-step0)
+ [Step 1: Create resources in Account A and grant permissions](#grant-permissions-to-user-in-your-account-step1)
+ [Step 2: Test permissions](#grant-permissions-to-user-in-your-account-test)
In this walkthrough, an AWS account owns a bucket, and the account includes an IAM user By default, the user has no permissions. For the user to perform any tasks, the parent account must grant them permissions. The bucket owner and parent account are the same. Therefore, to grant the user permissions on the bucket, the AWS account can use a bucket policy, a user policy, or both. The account owner will grant some permissions using a bucket policy and other permissions using a user policy.
The following steps summarize the walkthrough:
![\[Diagram showing an AWS account granting permissions.\]](http://docs.aws.amazon.com/AmazonS3/latest/userguide/images/access-policy-ex1.png)
1. Account administrator creates a bucket policy granting a set of permissions to the user.
1. Account administrator attaches a user policy to the user granting additional permissions.
1. User then tries permissions granted via both the bucket policy and the user policy.
For this example, you will need an AWS account. Instead of using the root user credentials of the account, you will create an administrator user (see [About using an administrator user to create resources and grant permissions](example-walkthroughs-managing-access.md#about-using-root-credentials)). We refer to the AWS account and the administrator user as shown in the following table.
| Account ID | Account referred to as | Administrator user in the account |
| --- | --- | --- |
| *1111-1111-1111* | Account A | AccountAadmin |
**Note**
The administrator user in this example is **AccountAadmin**, which refers to Account A, and not **AccountAdmin**.
All the tasks of creating users and granting permissions are done in the AWS Management Console. To verify permissions, the walkthrough uses the command line tools, AWS Command Line Interface (AWS CLI) and AWS Tools for Windows PowerShell, so you don't need to write any code.
## Preparing for the walkthrough
1. Make sure you have an AWS account and that it has a user with administrator privileges.
1. Sign up for an AWS account, if needed. We refer to this account as Account A.
1. Go to [https://aws.amazon.com/s3](https://aws.amazon.com/s3) and choose **Create an AWS account**.
1. Follow the on-screen instructions.
AWS will notify you by email when your account is active and available for you to use.
1. In Account A, create an administrator user **AccountAadmin**. Using Account A credentials, sign in to the [IAM console](https://console.aws.amazon.com/iam/home?#home) and do the following:
1. Create user **AccountAadmin** and note the user security credentials.
For instructions, see [Creating an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) in the *IAM User Guide*.
1. Grant administrator privileges to **AccountAadmin** by attaching a user policy giving full access.
For instructions, see [Managing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) in the *IAM User Guide*.
1. Note the **IAM user Sign-In URL** for **AccountAadmin**. You will need to use this URL when signing in to the AWS Management Console. For more information about where to find the sign-in URL, see [Sign in to the AWS Management Console as an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_how-users-sign-in.html) in *IAM User Guide*. Note the URL for each of the accounts.
1. Set up either the AWS CLI or the AWS Tools for Windows PowerShell. Make sure that you save administrator user credentials as follows:
+ If using the AWS CLI, create a profile, `AccountAadmin`, in the config file.
+ If using the AWS Tools for Windows PowerShell, make sure you store credentials for the session as `AccountAadmin`.
For instructions, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
## Step 1: Create resources in Account A and grant permissions
Using the credentials of user `AccountAadmin` in Account A, and the special IAM user sign-in URL, sign in to the AWS Management Console and do the following:
1. Create resources of a bucket and an IAM user
1. In the Amazon S3 console, create a bucket. Note the AWS Region in which you created the bucket. For instructions, see [Creating a general purpose bucket](create-bucket-overview.md).
1. In the [IAM Console](https://console.aws.amazon.com/iam/), do the following:
1. Create a user named Dave.
For step-by-step instructions, see [Creating IAM users (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) in the *IAM User Guide*.
1. Note the `UserDave` credentials.
1. Note the Amazon Resource Name (ARN) for user Dave. In the [IAM Console](https://console.aws.amazon.com/iam/), select the user, and the **Summary** tab provides the user ARN.
1. Grant permissions.
Because the bucket owner and the parent account to which the user belongs are the same, the AWS account can grant user permissions using a bucket policy, a user policy, or both. In this example, you do both. If the object is also owned by the same account, the bucket owner can grant object permissions in the bucket policy (or an IAM policy).
1. In the Amazon S3 console, attach the following bucket policy to *awsexamplebucket1*.
The policy has two statements.
+ The first statement grants Dave the bucket operation permissions `s3:GetBucketLocation` and `s3:ListBucket`.
+ The second statement grants the `s3:GetObject` permission. Because Account A also owns the object, the account administrator is able to grant the `s3:GetObject` permission.
In the `Principal` statement, Dave is identified by his user ARN. For more information about policy elements, see [Policies and permissions in Amazon S3](access-policy-language-overview.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "statement1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/Dave"
},
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::awsexamplebucket1"
]
},
{
"Sid": "statement2",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/Dave"
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::awsexamplebucket1/*"
]
}
]
}
```
------
1. Create an inline policy for the user Dave by using the following policy. The policy grants Dave the `s3:PutObject` permission. You need to update the policy by providing your bucket name.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionForObjectOperations",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::awsexamplebucket1/*"
]
}
]
}
```
------
For instructions, see [Managing IAMpolicies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_inline-using.html) in the *IAM User Guide*. Note you need to sign in to the console using Account A credentials.
## Step 2: Test permissions
Using Dave's credentials, verify that the permissions work. You can use either of the following two procedures.
**Test permissions using the AWS CLI**
1. Update the AWS CLI config file by adding the following `UserDaveAccountA` profile. For more information, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
```
[profile UserDaveAccountA]
aws_access_key_id = access-key
aws_secret_access_key = secret-access-key
region = us-east-1
```
1. Verify that Dave can perform the operations as granted in the user policy. Upload a sample object using the following AWS CLI `put-object` command.
The `--body` parameter in the command identifies the source file to upload. For example, if the file is in the root of the C: drive on a Windows machine, you specify `c:\HappyFace.jpg`. The `--key` parameter provides the key name for the object.
```
aws s3api put-object --bucket awsexamplebucket1 --key HappyFace.jpg --body HappyFace.jpg --profile UserDaveAccountA
```
Run the following AWS CLI command to get the object.
```
aws s3api get-object --bucket awsexamplebucket1 --key HappyFace.jpg OutputFile.jpg --profile UserDaveAccountA
```
**Test permissions using the AWS Tools for Windows PowerShell**
1. Store Dave's credentials as `AccountADave`. You then use these credentials to `PUT` and `GET` an object.
```
set-awscredentials -AccessKey AccessKeyID -SecretKey SecretAccessKey -storeas AccountADave
```
1. Upload a sample object using the AWS Tools for Windows PowerShell `Write-S3Object` command using user Dave's stored credentials.
```
Write-S3Object -bucketname awsexamplebucket1 -key HappyFace.jpg -file HappyFace.jpg -StoredCredentials AccountADave
```
Download the previously uploaded object.
```
Read-S3Object -bucketname awsexamplebucket1 -key HappyFace.jpg -file Output.jpg -StoredCredentials AccountADave
```
# Example 2: Bucket owner granting cross-account bucket permissions
**Important**
Granting permissions to IAM roles is a better practice than granting permissions to individual users. To learn how to do this, see [Understanding cross-account permissions and using IAM roles](example-walkthroughs-managing-access-example4.md#access-policies-walkthrough-example4-overview).
**Topics**
+ [Preparing for the walkthrough](#cross-acct-access-step0)
+ [Step 1: Do the Account A tasks](#access-policies-walkthrough-cross-account-permissions-acctA-tasks)
+ [Step 2: Do the Account B tasks](#access-policies-walkthrough-cross-account-permissions-acctB-tasks)
+ [Step 3: (Optional) Try explicit deny](#access-policies-walkthrough-example2-explicit-deny)
+ [Step 4: Clean up](#access-policies-walkthrough-example2-cleanup-step)
An AWS account—for example, Account A—can grant another AWS account, Account B, permission to access its resources such as buckets and objects. Account B can then delegate those permissions to users in its account. In this example scenario, a bucket owner grants cross-account permission to another account to perform specific bucket operations.
**Note**
Account A can also directly grant a user in Account B permissions using a bucket policy. However, the user will still need permission from the parent account, Account B, to which the user belongs, even if Account B doesn't have permissions from Account A. As long as the user has permission from both the resource owner and the parent account, the user will be able to access the resource.
The following is a summary of the walkthrough steps:
![\[An AWS account granting another AWS account permission to access its resources.\]](http://docs.aws.amazon.com/AmazonS3/latest/userguide/images/access-policy-ex2.png)
1. Account A administrator user attaches a bucket policy granting cross-account permissions to Account B to perform specific bucket operations.
Note that administrator user in Account B will automatically inherit the permissions.
1. Account B administrator user attaches user policy to the user delegating the permissions it received from Account A.
1. User in Account B then verifies permissions by accessing an object in the bucket owned by Account A.
For this example, you need two accounts. The following table shows how we refer to these accounts and the administrator users in them. In accordance with the IAM guidelines (see [About using an administrator user to create resources and grant permissions](example-walkthroughs-managing-access.md#about-using-root-credentials)), we don't use the root user credentials in this walkthrough. Instead, you create an administrator user in each account and use those credentials when creating resources and granting them permissions.
| AWS account ID | Account referred to as | Administrator user in the account |
| --- | --- | --- |
| *1111-1111-1111* | Account A | AccountAadmin |
| *2222-2222-2222* | Account B | AccountBadmin |
All the tasks of creating users and granting permissions are done in the AWS Management Console. To verify permissions, the walkthrough uses the command line tools, AWS Command Line Interface (CLI) and AWS Tools for Windows PowerShell, so you don't need to write any code.
## Preparing for the walkthrough
1. Make sure you have two AWS accounts and that each account has one administrator user as shown in the table in the preceding section.
1. Sign up for an AWS account, if needed.
1. Using Account A credentials, sign in to the [IAM console](https://console.aws.amazon.com/iam/home?#home) to create the administrator user:
1. Create user **AccountAadmin** and note the security credentials. For instructions, see [Creating an IAM user in Your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) in the *IAM User Guide*.
1. Grant administrator privileges to **AccountAadmin** by attaching a user policy giving full access. For instructions, see [Working with Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) in the *IAM User Guide*.
1. While you are in the IAM console, note the **IAM user Sign-In URL** on the **Dashboard**. All users in the account must use this URL when signing in to the AWS Management Console.
For more information, see [How Users Sign in to Your Account](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_how-users-sign-in.html) in *IAM User Guide*.
1. Repeat the preceding step using Account B credentials and create administrator user **AccountBadmin**.
1. Set up either the AWS Command Line Interface (AWS CLI) or the AWS Tools for Windows PowerShell. Make sure that you save administrator user credentials as follows:
+ If using the AWS CLI, create two profiles, `AccountAadmin` and `AccountBadmin`, in the config file.
+ If using the AWS Tools for Windows PowerShell, make sure that you store credentials for the session as `AccountAadmin` and `AccountBadmin`.
For instructions, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
1. Save the administrator user credentials, also referred to as profiles. You can use the profile name instead of specifying credentials for each command you enter. For more information, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
1. Add profiles in the AWS CLI credentials file for each of the administrator users, `AccountAadmin` and `AccountBadmin`, in the two accounts.
```
[AccountAadmin]
aws_access_key_id = access-key-ID
aws_secret_access_key = secret-access-key
region = us-east-1
[AccountBadmin]
aws_access_key_id = access-key-ID
aws_secret_access_key = secret-access-key
region = us-east-1
```
1. If you're using the AWS Tools for Windows PowerShell, run the following command.
```
set-awscredentials –AccessKey AcctA-access-key-ID –SecretKey AcctA-secret-access-key –storeas AccountAadmin
set-awscredentials –AccessKey AcctB-access-key-ID –SecretKey AcctB-secret-access-key –storeas AccountBadmin
```
## Step 1: Do the Account A tasks
### Step 1.1: Sign in to the AWS Management Console
Using the IAM user sign-in URL for Account A, first sign in to the AWS Management Console as **AccountAadmin** user. This user will create a bucket and attach a policy to it.
### Step 1.2: Create a bucket
1. In the Amazon S3 console, create a bucket. This exercise assumes the bucket is created in the US East (N. Virginia) AWS Region and is named `amzn-s3-demo-bucket`.
For instructions, see [Creating a general purpose bucket](create-bucket-overview.md).
1. Upload a sample object to the bucket.
For instructions, go to [Step 2: Upload an object to your bucket](GetStartedWithS3.md#uploading-an-object-bucket).
### Step 1.3: Attach a bucket policy to grant cross-account permissions to Account B
The bucket policy grants the `s3:GetLifecycleConfiguration` and `s3:ListBucket` permissions to Account B. It's assumed that you're still signed in to the console using **AccountAadmin** user credentials.
1. Attach the following bucket policy to `amzn-s3-demo-bucket`. The policy grants Account B permission for the `s3:GetLifecycleConfiguration` and `s3:ListBucket` actions.
For instructions, see [Adding a bucket policy by using the Amazon S3 console](add-bucket-policy.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Example permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"s3:GetLifecycleConfiguration",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
1. Verify that Account B (and thus its administrator user) can perform the operations.
+ Verify using the AWS CLI
```
aws s3 ls s3://amzn-s3-demo-bucket --profile AccountBadmin
aws s3api get-bucket-lifecycle-configuration --bucket amzn-s3-demo-bucket --profile AccountBadmin
```
+ Verify using the AWS Tools for Windows PowerShell
```
get-s3object -BucketName amzn-s3-demo-bucket -StoredCredentials AccountBadmin
get-s3bucketlifecycleconfiguration -BucketName amzn-s3-demo-bucket -StoredCredentials AccountBadmin
```
## Step 2: Do the Account B tasks
Now the Account B administrator creates a user, Dave, and delegates the permissions received from Account A.
### Step 2.1: Sign in to the AWS Management Console
Using the IAM user sign-in URL for Account B, first sign in to the AWS Management Console as **AccountBadmin** user.
### Step 2.2: Create user Dave in Account B
In the [IAM Console](https://console.aws.amazon.com/iam/), create a user, **Dave**.
For instructions, see [Creating IAM users (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) in the *IAM User Guide*.
### Step 2.3: Delegate permissions to user Dave
Create an inline policy for the user Dave by using the following policy. You will need to update the policy by providing your bucket name.
It's assumed that you're signed in to the console using **AccountBadmin** user credentials.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Example",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
For instructions, see [Managing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_inline-using.html) in the *IAM User Guide*.
### Step 2.4: Test permissions
Now Dave in Account B can list the contents of `amzn-s3-demo-bucket` owned by Account A. You can verify the permissions using either of the following procedures.
**Test permissions using the AWS CLI**
1. Add the `UserDave` profile to the AWS CLI config file. For more information about the config file, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
```
[profile UserDave]
aws_access_key_id = access-key
aws_secret_access_key = secret-access-key
region = us-east-1
```
1. At the command prompt, enter the following AWS CLI command to verify Dave can now get an object list from the `amzn-s3-demo-bucket` owned by Account A. Note the command specifies the `UserDave` profile.
```
aws s3 ls s3://amzn-s3-demo-bucket --profile UserDave
```
Dave doesn't have any other permissions. So, if he tries any other operation—for example, the following `get-bucket-lifecycle` configuration—Amazon S3 returns permission denied.
```
aws s3api get-bucket-lifecycle-configuration --bucket amzn-s3-demo-bucket --profile UserDave
```
**Test permissions using AWS Tools for Windows PowerShell**
1. Store Dave's credentials as `AccountBDave`.
```
set-awscredentials -AccessKey AccessKeyID -SecretKey SecretAccessKey -storeas AccountBDave
```
1. Try the List Bucket command.
```
get-s3object -BucketName amzn-s3-demo-bucket -StoredCredentials AccountBDave
```
Dave doesn't have any other permissions. So, if he tries any other operation—for example, the following `get-s3bucketlifecycleconfiguration`—Amazon S3 returns permission denied.
```
get-s3bucketlifecycleconfiguration -BucketName amzn-s3-demo-bucket -StoredCredentials AccountBDave
```
## Step 3: (Optional) Try explicit deny
You can have permissions granted by using an access control list (ACL), a bucket policy, or a user policy. But if there is an explicit deny set by either a bucket policy or a user policy, the explicit deny takes precedence over any other permissions. For testing, update the bucket policy and explicitly deny Account B the `s3:ListBucket` permission. The policy also grants `s3:ListBucket` permission. However, explicit deny takes precedence, and Account B or users in Account B will not be able to list objects in `amzn-s3-demo-bucket`.
1. Using credentials of user `AccountAadmin` in Account A, replace the bucket policy by the following.
1. Now if you try to get a bucket list using `AccountBadmin` credentials, access is denied.
+ Using the AWS CLI, run the following command:
```
aws s3 ls s3://amzn-s3-demo-bucket --profile AccountBadmin
```
+ Using the AWS Tools for Windows PowerShell, run the following command:
```
get-s3object -BucketName amzn-s3-demo-bucket -StoredCredentials AccountBDave
```
## Step 4: Clean up
1. After you're done testing, you can do the following to clean up:
1. Sign in to the AWS Management Console ([AWS Management Console](https://console.aws.amazon.com/)) using Account A credentials, and do the following:
+ In the Amazon S3 console, remove the bucket policy attached to `amzn-s3-demo-bucket`. In the bucket **Properties**, delete the policy in the **Permissions** section.
+ If the bucket is created for this exercise, in the Amazon S3 console, delete the objects and then delete the bucket.
+ In the [IAM Console](https://console.aws.amazon.com/iam/), remove the `AccountAadmin` user.
1. Sign in to the [IAM Console](https://console.aws.amazon.com/iam/) using Account B credentials. Delete user `AccountBadmin`. For step-by-step instructions, see [Deleting an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting) in the *IAM User Guide*.
# Example 3: Bucket owner granting permissions to objects it does not own
**Important**
Granting permissions to IAM roles is a better practice than granting permissions to individual users. To learn how to do this, see [Understanding cross-account permissions and using IAM roles](example-walkthroughs-managing-access-example4.md#access-policies-walkthrough-example4-overview).
**Topics**
+ [Step 0: Preparing for the walkthrough](#access-policies-walkthrough-cross-account-acl-step0)
+ [Step 1: Do the Account A tasks](#access-policies-walkthrough-cross-account-acl-acctA-tasks)
+ [Step 2: Do the Account B tasks](#access-policies-walkthrough-cross-account-acl-acctB-tasks)
+ [Step 3: Test permissions](#access-policies-walkthrough-cross-account-acl-verify)
+ [Step 4: Clean up](#access-policies-walkthrough-cross-account-acl-cleanup)
The scenario for this example is that a bucket owner wants to grant permission to access objects, but the bucket owner doesn't own all objects in the bucket. For this example, the bucket owner is trying to grant permission to users in its own account.
A bucket owner can enable other AWS accounts to upload objects. By default, the bucket owner doesn't own objects written to a bucket by another AWS account. Objects are owned by the accounts that write them to an S3 bucket. If the bucket owner doesn't own objects in the bucket, the object owner must first grant permission to the bucket owner using an object access control list (ACL). Then, the bucket owner can grant permissions to an object that they don't own. For more information, see [Amazon S3 bucket and object ownership](access-policy-language-overview.md#about-resource-owner).
If the bucket owner applies the bucket owner enforced setting for S3 Object Ownership for the bucket, the bucket owner will own all objects in the bucket, including objects written by another AWS account. This approach resolves the issue that objects are not owned by the bucket owner. Then, you can delegate permission to users in your own account or to other AWS accounts.
**Note**
S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies.
A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md).
In this example, we assume the bucket owner has not applied the bucket owner enforced setting for Object Ownership. The bucket owner delegates permission to users in its own account. The following is a summary of the walkthrough steps:
![\[A bucket owner granting permissions to objects it does not own.\]](http://docs.aws.amazon.com/AmazonS3/latest/userguide/images/access-policy-ex3.png)
1. Account A administrator user attaches a bucket policy with two statements.
+ Allow cross-account permission to Account B to upload objects.
+ Allow a user in its own account to access objects in the bucket.
1. Account B administrator user uploads objects to the bucket owned by Account A.
1. Account B administrator updates the object ACL adding grant that gives the bucket owner full-control permission on the object.
1. User in Account A verifies by accessing objects in the bucket, regardless of who owns them.
For this example, you need two accounts. The following table shows how we refer to these accounts and the administrator users in these accounts. In this walkthrough, you don't use the account root user credentials, according to the recommended IAM guidelines. For more information, see [About using an administrator user to create resources and grant permissions](example-walkthroughs-managing-access.md#about-using-root-credentials). Instead, you create an administrator in each account and use those credentials in creating resources and granting them permissions.
| AWS account ID | Account referred to as | Administrator in the account |
| --- | --- | --- |
| *1111-1111-1111* | Account A | AccountAadmin |
| *2222-2222-2222* | Account B | AccountBadmin |
All the tasks of creating users and granting permissions are done in the AWS Management Console. To verify permissions, the walkthrough uses the command line tools, AWS Command Line Interface (AWS CLI) and AWS Tools for Windows PowerShell, so you don't need to write any code.
## Step 0: Preparing for the walkthrough
1. Make sure that you have two AWS accounts and each account has one administrator as shown in the table in the preceding section.
1. Sign up for an AWS account, if needed.
1. Using Account A credentials, sign in to the [IAM Console](https://console.aws.amazon.com/iam/) and do the following to create an administrator user:
+ Create user **AccountAadmin** and note the user's security credentials. For more information about adding users, see [Creating an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) in the *IAM User Guide*.
+ Grant administrator permissions to **AccountAadmin** by attaching a user policy that gives full access. For instructions, see [Managing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) in the *IAM User Guide*.
+ In the [IAM Console](https://console.aws.amazon.com/iam/) **Dashboard**, note the** IAM User Sign-In URL**. Users in this account must use this URL when signing in to the AWS Management Console. For more information, see [How users sign in to your account](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_how-users-sign-in.html) in *IAM User Guide*.
1. Repeat the preceding step using Account B credentials and create administrator user **AccountBadmin**.
1. Set up either the AWS CLI or the Tools for Windows PowerShell. Make sure that you save the administrator credentials as follows:
+ If using the AWS CLI, create two profiles, `AccountAadmin` and `AccountBadmin`, in the config file.
+ If using the Tools for Windows PowerShell, make sure that you store credentials for the session as `AccountAadmin` and `AccountBadmin`.
For instructions, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
## Step 1: Do the Account A tasks
Perform the following steps for Account A:
### Step 1.1: Sign in to the console
Using the IAM user sign-in URL for Account A, sign in to the AWS Management Console as **AccountAadmin** user. This user will create a bucket and attach a policy to it.
### Step 1.2: Create a bucket and user, and add a bucket policy to grant user permissions
1. In the Amazon S3 console, create a bucket. This exercise assumes that the bucket is created in the US East (N. Virginia) AWS Region, and the name is `amzn-s3-demo-bucket1`.
For instructions, see [Creating a general purpose bucket](create-bucket-overview.md).
1. In the [IAM Console](https://console.aws.amazon.com/iam/), create a user **Dave**.
For step-by-step instructions, see [Creating IAM users (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) in the *IAM User Guide*.
1. Note the user Dave credentials.
1. In the Amazon S3 console, attach the following bucket policy to `amzn-s3-demo-bucket1` bucket. For instructions, see [Adding a bucket policy by using the Amazon S3 console](add-bucket-policy.md). Follow the steps to add a bucket policy. For information about how to find account IDs, see [Finding your AWS account ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingYourAccountIdentifiers).
The policy grants Account B the `s3:PutObject` and `s3:ListBucket` permissions. The policy also grants user `Dave` the `s3:GetObject` permission.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket1"
]
},
{
"Sid": "Statement3",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/Dave"
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*"
]
}
]
}
```
------
## Step 2: Do the Account B tasks
Now that Account B has permissions to perform operations on Account A's bucket, the Account B administrator does the following:
+ Uploads an object to Account A's bucket
+ Adds a grant in the object ACL to allow Account A, the bucket owner, full control
**Using the AWS CLI**
1. Using the `put-object` AWS CLI command, upload an object. The `--body` parameter in the command identifies the source file to upload. For example, if the file is on the `C:` drive of a Windows machine, specify `c:\HappyFace.jpg`. The `--key` parameter provides the key name for the object.
```
aws s3api put-object --bucket amzn-s3-demo-bucket1 --key HappyFace.jpg --body HappyFace.jpg --profile AccountBadmin
```
1. Add a grant to the object ACL to allow the bucket owner full control of the object. For information about how to find a canonical user ID, see [Find the canonical user ID for your AWS account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) in the *AWS Account Management Reference Guide*.
```
aws s3api put-object-acl --bucket amzn-s3-demo-bucket1 --key HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBadmin
```
**Using the Tools for Windows PowerShell**
1. Using the `Write-S3Object` command, upload an object.
```
Write-S3Object -BucketName amzn-s3-demo-bucket1 -key HappyFace.jpg -file HappyFace.jpg -StoredCredentials AccountBadmin
```
1. Add a grant to the object ACL to allow the bucket owner full control of the object.
```
Set-S3ACL -BucketName amzn-s3-demo-bucket1 -Key HappyFace.jpg -CannedACLName "bucket-owner-full-control" -StoredCreden
```
## Step 3: Test permissions
Now verify that user Dave in Account A can access the object owned by Account B.
**Using the AWS CLI**
1. Add user Dave credentials to the AWS CLI config file and create a new profile, `UserDaveAccountA`. For more information, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
```
[profile UserDaveAccountA]
aws_access_key_id = access-key
aws_secret_access_key = secret-access-key
region = us-east-1
```
1. Run the `get-object` CLI command to download `HappyFace.jpg` and save it locally. You provide user Dave credentials by adding the `--profile` parameter.
```
aws s3api get-object --bucket amzn-s3-demo-bucket1 --key HappyFace.jpg Outputfile.jpg --profile UserDaveAccountA
```
**Using the Tools for Windows PowerShell**
1. Store user Dave AWS credentials, as `UserDaveAccountA`, to persistent store.
```
Set-AWSCredentials -AccessKey UserDave-AccessKey -SecretKey UserDave-SecretAccessKey -storeas UserDaveAccountA
```
1. Run the `Read-S3Object` command to download the `HappyFace.jpg` object and save it locally. You provide user Dave credentials by adding the `-StoredCredentials` parameter.
```
Read-S3Object -BucketName amzn-s3-demo-bucket1 -Key HappyFace.jpg -file HappyFace.jpg -StoredCredentials UserDaveAccountA
```
## Step 4: Clean up
1. After you're done testing, you can do the following to clean up:
1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/) using Account A credentials, and do the following:
+ In the Amazon S3 console, remove the bucket policy attached to *amzn-s3-demo-bucket1*. In the bucket **Properties**, delete the policy in the **Permissions** section.
+ If the bucket is created for this exercise, in the Amazon S3 console, delete the objects and then delete the bucket.
+ In the [IAM Console](https://console.aws.amazon.com/iam/), remove the **AccountAadmin** user. For step-by-step instructions, see [Deleting an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting) in the *IAM User Guide*.
1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/) using Account B credentials. In the [IAM Console](https://console.aws.amazon.com/iam/), delete the user **AccountBadmin**.
# Example 4 - Bucket owner granting cross-account permission to objects it does not own
**Topics**
+ [Understanding cross-account permissions and using IAM roles](#access-policies-walkthrough-example4-overview)
+ [Step 0: Preparing for the walkthrough](#access-policies-walkthrough-example4-step0)
+ [Step 1: Do the account A tasks](#access-policies-walkthrough-example4-step1)
+ [Step 2: Do the Account B tasks](#access-policies-walkthrough-example4-step2)
+ [Step 3: Do the Account C tasks](#access-policies-walkthrough-example4-step3)
+ [Step 4: Clean up](#access-policies-walkthrough-example4-step6)
+ [Related resources](#RelatedResources-managing-access-example4)
In this example scenario, you own a bucket and you have enabled other AWS accounts to upload objects. If you have applied the bucket owner enforced setting for S3 Object Ownership for the bucket, you will own all objects in the bucket, including objects written by another AWS account. This approach resolves the issue that objects are not owned by you, the bucket owner. Then, you can delegate permission to users in your own account or to other AWS accounts. Suppose the bucket owner enforced setting for S3 Object Ownership is not enabled. That is, your bucket can have objects that other AWS accounts own.
Now, suppose as a bucket owner, you need to grant cross-account permission on objects, regardless of who the owner is, to a user in another account. For example, that user could be a billing application that needs to access object metadata. There are two core issues:
+ The bucket owner has no permissions on those objects created by other AWS accounts. For the bucket owner to grant permissions on objects it doesn't own, the object owner must first grant permission to the bucket owner. The object owner is the AWS account that created the objects. The bucket owner can then delegate those permissions.
+ The bucket owner account can delegate permissions to users in its own account (see [Example 3: Bucket owner granting permissions to objects it does not own](example-walkthroughs-managing-access-example3.md)). However, the bucket owner account can't delegate permissions to other AWS accounts because cross-account delegation isn't supported.
In this scenario, the bucket owner can create an AWS Identity and Access Management (IAM) role with permission to access objects Then, the bucket owner can grant another AWS account permission to assume the role, temporarily enabling it to access objects in the bucket.
**Note**
S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies.
A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md).
## Understanding cross-account permissions and using IAM roles
IAM roles enable several scenarios to delegate access to your resources, and cross-account access is one of the key scenarios. In this example, the bucket owner, Account A, uses an IAM role to temporarily delegate object access cross-account to users in another AWS account, Account C. Each IAM role that you create has the following two policies attached to it:
+ A trust policy identifying another AWS account that can assume the role.
+ An access policy defining what permissions—for example, `s3:GetObject`—are allowed when someone assumes the role. For a list of permissions you can specify in a policy, see [Policy actions for Amazon S3](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions).
The AWS account identified in the trust policy then grants its user permission to assume the role. The user can then do the following to access objects:
+ Assume the role and, in response, get temporary security credentials.
+ Using the temporary security credentials, access the objects in the bucket.
For more information about IAM roles, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the *IAM User Guide*.
The following is a summary of the walkthrough steps:
![\[Cross-account permissions using IAM roles.\]](http://docs.aws.amazon.com/AmazonS3/latest/userguide/images/access-policy-ex4.png)
1. Account A administrator user attaches a bucket policy granting Account B conditional permission to upload objects.
1. Account A administrator creates an IAM role, establishing trust with Account C, so users in that account can access Account A. The access policy attached to the role limits what user in Account C can do when the user accesses Account A.
1. Account B administrator uploads an object to the bucket owned by Account A, granting full-control permission to the bucket owner.
1. Account C administrator creates a user and attaches a user policy that allows the user to assume the role.
1. User in Account C first assumes the role, which returns the user temporary security credentials. Using those temporary credentials, the user then accesses objects in the bucket.
For this example, you need three accounts. The following table shows how we refer to these accounts and the administrator users in these accounts. In accordance with the IAM guidelines (see [About using an administrator user to create resources and grant permissions](example-walkthroughs-managing-access.md#about-using-root-credentials)), we don't use the AWS account root user credentials in this walkthrough. Instead, you create an administrator user in each account and use those credentials when creating resources and granting them permissions.
| AWS account ID | Account referred to as | Administrator user in the account |
| --- | --- | --- |
| *1111-1111-1111* | Account A | AccountAadmin |
| *2222-2222-2222* | Account B | AccountBadmin |
| *3333-3333-3333* | Account C | AccountCadmin |
## Step 0: Preparing for the walkthrough
**Note**
You might want to open a text editor, and write down some of the information as you go through the steps. In particular, you will need account IDs, canonical user IDs, IAM user Sign-in URLs for each account to connect to the console, and Amazon Resource Names (ARNs) of the IAM users, and roles.
1. Make sure that you have three AWS accounts and each account has one administrator user as shown in the table in the preceding section.
1. Sign up for AWS accounts, as needed. We refer to these accounts as Account A, Account B, and Account C.
1. Using Account A credentials, sign in to the [IAM console](https://console.aws.amazon.com/iam/home?#home) and do the following to create an administrator user:
+ Create user **AccountAadmin** and note its security credentials. For more information about adding users, see [Creating an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) in the *IAM User Guide*.
+ Grant administrator privileges to **AccountAadmin** by attaching a user policy giving full access. For instructions, see [Managing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) in the *IAM User Guide*.
+ In the IAM Console **Dashboard**, note the **IAM User Sign-In URL**. Users in this account must use this URL when signing in to the AWS Management Console. For more information, see [Sign in to the AWS Management Console as an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_how-users-sign-in.html) in the *IAM User Guide*.
1. Repeat the preceding step to create administrator users in Account B and Account C.
1. For Account C, note the canonical user ID.
When you create an IAM role in Account A, the trust policy grants Account C permission to assume the role by specifying the account ID. You can find account information as follows:
1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [Amazon S3 console](https://console.aws.amazon.com/s3/).
1. Choose the name of an Amazon S3 bucket to view the details about that bucket.
1. Choose the **Permissions** tab and then choose **Access Control List**.
1. In the **Access for your AWS account** section, in the **Account** column is a long identifier, such as `c1daexampleaaf850ea79cf0430f33d72579fd1611c97f7ded193374c0b163b6`. This is your canonical user ID.
1. When creating a bucket policy, you will need the following information. Note these values:
+ **Canonical user ID of Account A** – When the Account A administrator grants conditional upload object permission to the Account B administrator, the condition specifies the canonical user ID of the Account A user that must get full-control of the objects.
**Note**
The canonical user ID is the Amazon S3–only concept. It is a 64-character obfuscated version of the account ID.
+ **User ARN for Account B administrator** – You can find the user ARN in the [IAM Console](https://console.aws.amazon.com/iam/).You must select the user and find the user's ARN in the **Summary** tab.
In the bucket policy, you grant `AccountBadmin` permission to upload objects and you specify the user using the ARN. Here's an example ARN value:
```
arn:aws:iam::AccountB-ID:user/AccountBadmin
```
1. Set up either the AWS Command Line Interface (CLI) or the AWS Tools for Windows PowerShell. Make sure that you save administrator user credentials as follows:
+ If using the AWS CLI, create profiles, `AccountAadmin` and `AccountBadmin`, in the config file.
+ If using the AWS Tools for Windows PowerShell, make sure that you store credentials for the session as `AccountAadmin` and `AccountBadmin`.
For instructions, see [Setting up the tools for the walkthroughs](policy-eval-walkthrough-download-awscli.md).
## Step 1: Do the account A tasks
In this example, Account A is the bucket owner. So user AccountAadmin in Account A will do the following:
+ Create a bucket.
+ Attach a bucket policy that grants the Account B administrator permission to upload objects.
+ Create an IAM role that grants Account C permission to assume the role so it can access objects in the bucket.
### Step 1.1: Sign in to the AWS Management Console
Using the IAM user Sign-in URL for Account A, first sign in to the AWS Management Console as **AccountAadmin** user. This user will create a bucket and attach a policy to it.
### Step 1.2: Create a bucket and attach a bucket policy
In the Amazon S3 console, do the following:
1. Create a bucket. This exercise assumes the bucket name is `amzn-s3-demo-bucket1`.
For instructions, see [Creating a general purpose bucket](create-bucket-overview.md).
1. Attach the following bucket policy. The policy grants conditional permission to the Account B administrator permission to upload objects.
Update the policy by providing your own values for `amzn-s3-demo-bucket1`, `AccountB-ID`, and the `CanonicalUserId-of-AWSaccountA-BucketOwner`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "111",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/AccountBadmin"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/*"
},
{
"Sid": "112",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/AccountBadmin"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-grant-full-control": "id=CanonicalUserId-of-AWSaccountA-BucketOwner"
}
}
}
]
}
```
------
### Step 1.3: Create an IAM role to allow Account C cross-account access in Account A
In the [IAM Console](https://console.aws.amazon.com/iam/), create an IAM role (**examplerole**) that grants Account C permission to assume the role. Make sure that you are still signed in as the Account A administrator because the role must be created in Account A.
1. Before creating the role, prepare the managed policy that defines the permissions that the role requires. You attach this policy to the role in a later step.
1. In the navigation pane on the left, choose **Policies** and then choose **Create Policy**.
1. Next to **Create Your Own Policy**, choose **Select**.
1. Enter **access-accountA-bucket** in the **Policy Name** field.
1. Copy the following access policy and paste it into the **Policy Document** field. The access policy grants the role `s3:GetObject` permission so, when the Account C user assumes the role, it can only perform the `s3:GetObject` operation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/*"
}
]
}
```
------
1. Choose **Create Policy**.
The new policy appears in the list of managed policies.
1. In the navigation pane on the left, choose **Roles** and then choose **Create New Role**.
1. Under **Select Role Type**, select **Role for Cross-Account Access**, and then choose the **Select** button next to **Provide access between AWS accounts you own**.
1. Enter the Account C account ID.
For this walkthrough, you don't need to require users to have multi-factor authentication (MFA) to assume the role, so leave that option unselected.
1. Choose **Next Step** to set the permissions that will be associated with the role.
1.
Select the checkbox next to the **access-accountA-bucket** policy that you created, and then choose **Next Step**.
The Review page appears so you can confirm the settings for the role before it's created. One very important item to note on this page is the link that you can send to your users who need to use this role. Users who use the link go straight to the **Switch Role** page with the Account ID and Role Name fields already filled in. You can also see this link later on the **Role Summary** page for any cross-account role.
1. Enter `examplerole` for the role name, and then choose **Next Step**.
1. After reviewing the role, choose **Create Role**.
The `examplerole` role is displayed in the list of roles.
1. Choose the role name `examplerole`.
1. Select the **Trust Relationships** tab.
1. Choose **Show policy document** and verify the trust policy shown matches the following policy.
The following trust policy establishes trust with Account C, by allowing it the `sts:AssumeRole` action. For more information, see [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) in the *AWS Security Token Service API Reference*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Note the Amazon Resource Name (ARN) of the `examplerole` role that you created.
Later in the following steps, you attach a user policy to allow an IAM user to assume this role, and you identify the role by the ARN value.
## Step 2: Do the Account B tasks
The example bucket owned by Account A needs objects owned by other accounts. In this step, the Account B administrator uploads an object using the command line tools.
+ Using the `put-object` AWS CLI command, upload an object to `amzn-s3-demo-bucket1`.
```
aws s3api put-object --bucket amzn-s3-demo-bucket1 --key HappyFace.jpg --body HappyFace.jpg --grant-full-control id="canonicalUserId-ofTheBucketOwner" --profile AccountBadmin
```
Note the following:
+ The `--Profile` parameter specifies the `AccountBadmin` profile, so the object is owned by Account B.
+ The parameter `grant-full-control` grants the bucket owner full-control permission on the object as required by the bucket policy.
+ The `--body` parameter identifies the source file to upload. For example, if the file is on the C: drive of a Windows computer, you specify `c:\HappyFace.jpg`.
## Step 3: Do the Account C tasks
In the preceding steps, Account A has already created a role, `examplerole`, establishing trust with Account C. This role allows users in Account C to access Account A. In this step, the Account C administrator creates a user (Dave) and delegates him the `sts:AssumeRole` permission it received from Account A. This approach allows Dave to assume the `examplerole` and temporarily gain access to Account A. The access policy that Account A attached to the role limits what Dave can do when he accesses Account A—specifically, get objects in `amzn-s3-demo-bucket1`.
### Step 3.1: Create a user in Account C and delegate permission to assume examplerole
1. Using the IAM user sign-in URL for Account C, first sign in to the AWS Management Console as **AccountCadmin** user.
1. In the [IAM Console](https://console.aws.amazon.com/iam/), create a user, Dave.
For step-by-step instructions, see [Creating IAM users (AWS Management Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) in the *IAM User Guide*.
1. Note the Dave credentials. Dave will need these credentials to assume the `examplerole` role.
1. Create an inline policy for the Dave IAM user to delegate the `sts:AssumeRole` permission to Dave on the `examplerole` role in Account A.
1. In the navigation pane on the left, choose **Users**.
1. Choose the user name **Dave**.
1. On the user details page, select the **Permissions** tab and then expand the **Inline Policies** section.
1. Choose **click here** (or **Create User Policy**).
1. Choose **Custom Policy**, and then choose **Select**.
1. Enter a name for the policy in the **Policy Name** field.
1. Copy the following policy into the **Policy Document** field.
You must update the policy by providing the `AccountA-ID`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::111122223333:role/examplerole"
}
]
}
```
------
1. Choose **Apply Policy**.
1. Save Dave's credentials to the config file of the AWS CLI by adding another profile, `AccountCDave`.
```
[profile AccountCDave]
aws_access_key_id = UserDaveAccessKeyID
aws_secret_access_key = UserDaveSecretAccessKey
region = us-west-2
```
### Step 3.2: Assume role (examplerole) and access objects
Now Dave can access objects in the bucket owned by Account A as follows:
+ Dave first assumes the `examplerole` using his own credentials. This will return temporary credentials.
+ Using the temporary credentials, Dave will then access objects in Account A's bucket.
1. At the command prompt, run the following AWS CLI `assume-role` command using the `AccountCDave` profile.
You must update the ARN value in the command by providing the `AccountA-ID` where `examplerole` is defined.
```
aws sts assume-role --role-arn arn:aws:iam::AccountA-ID:role/examplerole --profile AccountCDave --role-session-name test
```
In response, AWS Security Token Service (AWS STS) returns temporary security credentials (access key ID, secret access key, and a session token).
1. Save the temporary security credentials in the AWS CLI config file under the `TempCred` profile.
```
[profile TempCred]
aws_access_key_id = temp-access-key-ID
aws_secret_access_key = temp-secret-access-key
aws_session_token = session-token
region = us-west-2
```
1. At the command prompt, run the following AWS CLI command to access objects using the temporary credentials. For example, the command specifies the head-object API to retrieve object metadata for the `HappyFace.jpg` object.
```
aws s3api get-object --bucket amzn-s3-demo-bucket1 --key HappyFace.jpg SaveFileAs.jpg --profile TempCred
```
Because the access policy attached to `examplerole` allows the actions, Amazon S3 processes the request. You can try any other action on any other object in the bucket.
If you try any other action—for example, `get-object-acl`—you will get permission denied because the role isn't allowed that action.
```
aws s3api get-object-acl --bucket amzn-s3-demo-bucket1 --key HappyFace.jpg --profile TempCred
```
We used user Dave to assume the role and access the object using temporary credentials. It could also be an application in Account C that accesses objects in `amzn-s3-demo-bucket1`. The application can obtain temporary security credentials, and Account C can delegate the application permission to assume `examplerole`.
## Step 4: Clean up
1. After you're done testing, you can do the following to clean up:
1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/) using Account A credentials, and do the following:
+ In the Amazon S3 console, remove the bucket policy attached to `amzn-s3-demo-bucket1`. In the bucket **Properties**, delete the policy in the **Permissions** section.
+ If the bucket is created for this exercise, in the Amazon S3 console, delete the objects and then delete the bucket.
+ In the [IAM Console](https://console.aws.amazon.com/iam/), remove the `examplerole` you created in Account A. For step-by-step instructions, see [Deleting an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting) in the *IAM User Guide*.
+ In the [IAM Console](https://console.aws.amazon.com/iam/), remove the **AccountAadmin** user.
1. Sign in to the [IAM Console](https://console.aws.amazon.com/iam/) by using Account B credentials. Delete the user **AccountBadmin**.
1. Sign in to the [IAM Console](https://console.aws.amazon.com/iam/) by using Account C credentials. Delete **AccountCadmin** and the user Dave.
## Related resources
For more information that's related to this walkthrough, see the following resources in the *IAM User Guide*:
+ [Creating a role to delegate permissions to an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)
+ [Tutorial: Delegate Access Across AWS accounts Using IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial-cross-account-with-roles.html)
+ [Managing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)