5

I'm trying to configure permissions for CloudTrail > S3 > SQS > Splunk workflow.

https://docs.splunk.com/Documentation/AddOns/released/AWS/ConfigureAWSpermissions

  1. I created a role, attached a policy to grant permissions for S3, SQS etc.
  2. I went to Trust Relation policy and added the same account number and the user because the user will be in the same account.
  3. I then go to the user and attach a policy to assumeRole and provided the role name and full ARN.
  4. I then launch an EC2 instance, go to aws configure, provided access, secret keys and region.
  5. Then I run aws s3 ls or aws s3 list-queues and I get an error below. Not sure what I'm doing wrong here.

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied.

Splunk policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueAttributes",
                "sqs:ListQueues",
                "sqs:ReceiveMessage",
                "sqs:GetQueueUrl",
                "sqs:DeleteMessage",
                "s3:Get*",
                "s3:List*",
                "s3:Delete*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Trust Relation:

 {   "Version": "2012-10-17",   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "AWS": "arn:aws:iam::XXXXXXXXXXXX:user/username"
       },
       "Action": "sts:AssumeRole",
       "Condition": {}

Username policy:

 "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/roleforsplunk"
3

You don’t need TrustRelation when assuming role from the same account. Delete it and it should work.

By the way do not use access and secret keys on EC2 instances. Instead use EC2 Instance Role that will give the required perms to your Splunk process.

Also there is probably no need to assume another role from the EC2 Instance Role - simply give that role the required policy / permissions.

Hope that helps :)

| improve this answer | |
0

Step 3 is not required as an IAM role that is going to be assumed by an IAM user within the same AWS account won't need an explicit allow of sts:AssumeRole permission attached to the user.

I guess the reason you got AccessDenied on ListBuckets operation inside your EC2 instance is because the credential used to invoke the ListBuckets operation is actually your IAM user, not the role itself. Simply configured Access Key ID/Secret Access Key of the user in step 4 doesn't mean it will automatically assume the role for you. You have to issue command like aws sts assume-role to get a temporary security token representing the role credential to be used, or configure AWS CLI to assume role.

As @MLu stated, using IAM User's Access Key ID/Secret Access Key directly in your EC2 instance is not a good practice. Consider using Instance Profile instead.

| improve this answer | |
0

To clarify some information in the other answers regarding assumption of roles across accounts:

  • For assuming a role in a different account, you need both an IAM Policy in the from account allowing sts:AssumeRole on the destination role AND a Trust Policy on the destination role trusting the "source account" (the "root" user)
  • For assuming a role in the same account, you can either do the same thing as the cross-account situation, OR simply add the from role to the Trust Policy of the to role

From the AWS Documentation:

A user who wants to access a role in a different account must also have permissions that are delegated from the user account administrator. The administrator must attach a policy that allows the user to call AssumeRole for the ARN of the role in the other account. If the user is in the same account as the role, then you can do either of the following:

  • Attach a policy to the user (identical to the previous user in a different account).
  • Add the user as a principal directly in the role's trust policy.

In this case, the trust policy acts as an IAM resource-based policy. Users in the same account as the role do not need explicit permission to assume the role. For more information about trust policies and resource-based policies, see IAM Policies in the IAM User Guide.

Of course, once you have created a role that you are capable of assuming, you need to actually "Assume" that role. Assuming a role gives you a set of "temporary" credentials, which you can then use to perform actions with the new set of permissions.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.