2012-02-22 2 views

ответ

17

разрешения, которые вы видите в AWS Management Console непосредственно основаны на начальной и сравнительно простой Access Control Lists (ACL) для S3, которая существенно дифференцированы READ и WRITE разрешений см Specifying a Permission:

  • READ - Позволяет получателю перечислить объекты в ковше
  • WRITE - Позволяет грантополучатель создавать, перезаписывать и удалять любой объект в ведра

Этих ограничения были решены путем добавления Bucket Policies (разрешения применяются на уровне ведра) и IAM Policies (разрешения применяются на уровне пользователя), и все три могут использоваться вместе (что может стать довольно сложным, как описано ниже), см. Access Control для всего изображения.

В вашем случае использования, возможно, запрашивается соответствующая политика ведра, которую вы добавляете непосредственно с консоли S3. Нажав на кнопку , добавьте политику в виде ковша открывает редактор Bucket Policy Editor, который содержит ссылки на пару образцов, а также рекомендуемый AWS Policy Generator, который позволяет вам собрать политику, использующую ваш прецедент.

Для иначе заблокированном ведра, простейшая форма может выглядеть так (пожалуйста, убедитесь, чтобы настроить Principal и ресурса для ваших нужд):

{ 
    "Statement": [ 
    { 
     "Action": [ 
     "s3:PutObject" 
     ], 
     "Effect": "Allow", 
     "Resource": "arn:aws:s3:::<bucket_name>/<key_name>", 
     "Principal": { 
     "AWS": [ 
      "*" 
     ] 
     } 
    } 
    ] 
} 

В зависимости от вашего случая использования, вы можете легко составите довольно сложные политики, объединив различные . Разрешите и Запретить действия и т. д. - это также может привести к непреднамеренным разрешениям, поэтому надлежащее тестирование является ключевым, как обычно; соответственно, пожалуйста, позаботьтесь о последствиях при использовании Using ACLs and Bucket Policies Together или IAM and Bucket Policies Together.

Наконец, вы можете посмотреть мой ответ на вопрос Problems specifying a single bucket in a simple AWS user policy, в котором рассматриваются другие часто встречающиеся ловушки с политиками.

5

Вы можете приложить политику no-delete к вашему ведерке s3.Например, если вы не хотите этого IAM пользователю выполнять любую операцию в любых ковшей или каких-либо объектов, вы можете установить что-то вроде этого:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "Stmt1480692207000", 
      "Effect": "Deny", 
      "Action": [ 
       "s3:DeleteBucket", 
       "s3:DeleteBucketPolicy", 
       "s3:DeleteBucketWebsite", 
       "s3:DeleteObject", 
       "s3:DeleteObjectVersion" 
      ], 
      "Resource": [ 
       "arn:aws:s3:::*" 
      ] 
     } 
    ] 
} 

Кроме того, вы можете проверить свою политику с политикой тренажере https://policysim.aws.amazon.com проверить если ваша настройка - то, что вы ожидали или нет.

Надеюсь, это поможет!

2

Это сработало отлично. Благодаря Pung Worathiti Manosroi. объединил указанную выше политику в соответствии с нижеуказанным:

{  

"Statement": [  

    { 
     "Effect": "Allow", 
     "Action": [ 
      "s3:GetObject", 
      "s3:PutObject", 
      "s3:GetObjectAcl", 
      "s3:PutObjectAcl", 
      "s3:ListBucket", 
      "s3:GetBucketAcl", 
      "s3:PutBucketAcl", 
      "s3:GetBucketLocation" 
     ], 
     "Resource": "arn:aws:s3:::mybucketname/*", 
     "Condition": {} 
    }, 
    { 
     "Effect": "Allow", 
     "Action": "s3:ListAllMyBuckets", 
     "Resource": "*", 
     "Condition": {} 
    }, 
    { 
     "Effect": "Deny", 
     "Action": [ 
      "s3:DeleteBucket", 
      "s3:DeleteBucketPolicy", 
      "s3:DeleteBucketWebsite", 
      "s3:DeleteObject", 
      "s3:DeleteObjectVersion" 
     ], 
     "Resource": "arn:aws:s3:::mybucketname/*",  

     "Condition": {}  

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