2016-06-14 7 views
0

Я хочу перенести s3 ведро с одного счета на другой счет здесь мое ведро политикаMigrate S3 ошибка ведро

{ 
    "Version": "2008-10-17", 
    "Id": "Policy1335892530063", 
    "Statement": [ 
     { 
      "Sid": "DelegateS3Access", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "arn:aws:iam::xxxxxxxx:root" 
      }, 
      "Action": "s3:*", 
      "Resource": [ 
       "arn:aws:s3:::test123", 
       "arn:aws:s3:::test123/*" 
      ] 
     }, 
     { 
      "Sid": "Stmt1335892150622", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "arn:aws:iam::xxxxxxx:root" 
      }, 
      "Action": [ 
       "s3:GetBucketAcl", 
       "s3:GetBucketPolicy" 
      ], 
      "Resource": "arn:aws:s3:::test123" 
     }, 
     { 
      "Sid": "Stmt1335892526596", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "arn:aws:iam::xxxxxxxxx:root" 
      }, 
      "Action": "s3:PutObject", 
      "Resource": "arn:aws:s3:::test123/*" 
     } 
    ] 
} 

вот мой IAM пользовательская политика

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

Когда я запускаю команду

aws s3 sync s3://test123 s3://abc-test123 

Я получаю сообщение об ошибке

при вызове операции CopyObject Ошибка клиента (AccessDenied) произошло: Access Denied

ответ

0

Ваша политика ведра кажется правильным. Убедитесь, что вы используете учетную запись root, как указано в политике вашего ведра. Также вам может потребоваться проверить, нет ли каких-либо запрещенных политик ведра в вашем целевом ковше.

Если ничего не помогает, вы можете включить временный публичный доступ к вашему ведру в качестве обходного пути. Да, это не безопасно, но должно, вероятно, работать во всех случаях.

+0

Я перекрестно проверял учетную запись root, она настроена надлежащим образом, я также пытаюсь предоставить временный доступ к каждому из добавочного разрешения, но я получаю такую ​​же проблему. Не существует политики, установленной в ведомости назначения, ее вновь созданной. –

0

Убедитесь, что вы предоставили достаточные разрешения как для исходного кода (для чтения), так и для целевого ковша (для записи).

Если вы используете учетные данные Root (обычно не рекомендуются) для учетной записи, которой принадлежит ведро, вам, вероятно, даже не нужна политика в виде ведра. По умолчанию учетная запись root должна иметь необходимый доступ.

Если вы назначаете разрешения для пользователя IAM, вместо создания политики bucket назначьте разрешения самому пользователю IAM. В этой ситуации нет необходимости поставлять Принципала.

Начните с проверки того, что у вас есть права доступа к списку оба ведра:

  • aws s3 ls s3://test123
  • aws s3 ls s3://abc-test123

Затем убедитесь, что у вас есть права, чтобы скопировать файл из источника и назначения :

  • aws s3 cp s3://test123/foo.txt .
  • aws s3 cp foo.txt s3://abc-test123/foo.txt

Если они работают, то команда sync должна работать тоже.

Смежные вопросы