Project

General

Profile

Actions

Bug #47809

closed

Cannot perform server-side copy using STS credentials

Added by Christoph Tonsing over 3 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Target version:
-
% Done:

100%

Source:
Community (user)
Tags:
backport_processed
Backport:
octopus pacific
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

When having obtained temporary credentials using STS (AssumeRole), I can use these temp credentials to copy files from local machine to ceph and vice versa, but I cannot copy files within a bucket (server-side copy). When attempting the same server-side copy operation using the permanent credentials which were used in calling the AssumeRole command, it succeeds.

The AssumeRolePolicy document of the role is:

{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"arn:aws:iam:::user/129-9bef358e31a44f85b8a84880c459def9\"},\"Action\":\"sts:AssumeRole\"}]}

The permission policy attached to the role is (I've made this as permissive as possible to try to fix the problem without success):

{\"Version\":\"2012-10-17\",\"Statement\":{\"Effect\":\"Allow\",\"Action\":[\"s3:*\"],\"Resource\":\"arn:aws:s3:::*\"}}

The request and response when attempting the server-side copy are shown here:

2020/09/23 16:26:49 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2020/09/23 16:26:49 DEBUG : HTTP REQUEST (req 0xc0006e8200)
2020/09/23 16:26:49 DEBUG : PUT /129-73b1a5466f424d33b39d5b616fb39166/134/18/68copy/home/test/Documents/Testing/rsyncTestingB/test1/loadings/test1.txt HTTP/1.1
Host: redacted
User-Agent: rclone/v1.52.2-232-gff843516-beta
Content-Length: 0
Authorization: XXXX
X-Amz-Acl: private
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Copy-Source: 129-73b1a5466f424d33b39d5b616fb39166/134/18/68/home/test/Documents/Testing/rsyncTestingB/test1/loadings/test1.txt
X-Amz-Date: 20200923T142649Z
X-Amz-Metadata-Directive: COPY
X-Amz-Security-Token: redacted=
Accept-Encoding: gzip
2020/09/23 16:26:49 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

2020/09/23 16:26:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2020/09/23 16:26:49 DEBUG : HTTP RESPONSE (req 0xc0006e8200)
2020/09/23 16:26:49 DEBUG : HTTP/2.0 403 Forbidden
Content-Length: 250
Accept-Ranges: bytes
Content-Type: application/xml
Date: Wed, 23 Sep 2020 14:26:49 GMT
X-Amz-Request-Id: tx0000000000000000001de-005f6b5b29-442aa9-default

<Error><Code>AccessDenied</Code><BucketName>129-73b1a5466f424d33b39d5b616fb39166</BucketName><RequestId>tx0000000000000000001de-005f6b5b29-442aa9-default</RequestId><HostId>442aa9-default-default</HostId></Error>
2020/09/23 16:26:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In case it helps, as can be seen in the request, I am using rclone for doing the actual transfer.


Related issues 4 (1 open3 closed)

Related to rgw - Bug #53178: Using STS roles, I cannot move an object wtihin a bucket that I have full access to in the roleNewPritha Srivastava

Actions
Has duplicate rgw - Bug #52608: aws s3 sync does not work with sts roles, but works fine with AWSDuplicatePritha Srivastava

Actions
Copied to rgw - Backport #51442: octopus: Cannot perform server-side copy using STS credentialsRejectedActions
Copied to rgw - Backport #52783: pacific: Cannot perform server-side copy using STS credentialsResolvedCory SnyderActions
Actions #1

Updated by Matt Benjamin over 3 years ago

  • Assignee set to Pritha Srivastava
Actions #2

Updated by Pritha Srivastava over 3 years ago

Hi Christoph,

Is it possible for you to provide logs from RGW?

Thanks,
Pritha

Actions #3

Updated by Christoph Tonsing over 3 years ago

Hi Pritha,

yes, I think I should be able to. If you could just provide some guidance regarding which logs you'd like to see and where I should be able to find them. I am not too familiar with this...

It should be there in /var/log/ceph and with the file name radosgw.log or rgw.log. But if you do not have debug log level set to 20 for rgw, then it wont help me. I'll try to reproduce it at my end.

Thanks,
Pritha

Actions #4

Updated by Pritha Srivastava over 3 years ago

  • Pull request ID set to 37866
Actions #5

Updated by Pritha Srivastava over 3 years ago

  • Status changed from New to In Progress
  • Backport set to octopus
Actions #6

Updated by Christoph Tonsing over 3 years ago

Christoph Tonsing wrote:

Hi Pritha,

yes, I think I should be able to. If you could just provide some guidance regarding which logs you'd like to see and where I should be able to find them. I am not too familiar with this...

It should be there in /var/log/ceph and with the file name radosgw.log or rgw.log. But if you do not have debug log level set to 20 for rgw, then it wont help me. I'll try to reproduce it at my end.

Thanks,
Pritha

Sorry Pritha, I never saw that you responded on my question as I didn't get any notification... I'm glad it seems you've managed to find the problem in the meantime!

Actions #7

Updated by Matt Benjamin almost 3 years ago

  • Status changed from In Progress to Pending Backport
Actions #8

Updated by Backport Bot almost 3 years ago

  • Copied to Backport #51442: octopus: Cannot perform server-side copy using STS credentials added
Actions #9

Updated by Pritha Srivastava over 2 years ago

  • Backport changed from octopus to octopus pacific
Actions #10

Updated by Backport Bot over 2 years ago

  • Copied to Backport #52783: pacific: Cannot perform server-side copy using STS credentials added
Actions #11

Updated by Casey Bodley over 2 years ago

  • Has duplicate Bug #52608: aws s3 sync does not work with sts roles, but works fine with AWS added
Actions #12

Updated by Casey Bodley over 2 years ago

  • Related to Bug #53178: Using STS roles, I cannot move an object wtihin a bucket that I have full access to in the role added
Actions #13

Updated by Backport Bot almost 2 years ago

  • Tags set to backport_processed
Actions #14

Updated by Konstantin Shalygin about 1 year ago

  • Status changed from Pending Backport to Resolved
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF