2012-02-22 7 views

Répondre

17

Les autorisations que vous voyez dans le AWS Management Console directement reposent sur la formation initiale et relativement simple Access Control Lists (ACL) disponible pour S3, qui essentiellement différencié LIRE et ECRITURE autorisations, voir Specifying a Permission:

  • LIRE - Permet à un bénéficiaire de lister les objets dans le seau
  • WRITE - Permet impétrant de créer, écraser et supprimer tout objet dans le seau

Ces limites ont été prises en compte par l'ajout Bucket Policies (autorisations appliquées au niveau du godet) et IAM Policies (autorisations appliquées au niveau de l'utilisateur), et tous les trois peuvent être utilisés ensemble (ce qui peut devenir assez complexe, comme indiqué ci-dessous), voir Access Control pour l'ensemble de l'image.

Votre cas d'utilisation nécessite probablement une stratégie de compartiment, que vous ajoutez également directement à partir de la console S3. En cliquant sur Ajouter la politique de compartiment ouvre l'éditeur de politique de compartiment , qui comporte des liens vers quelques exemples ainsi que le hautement recommandé AWS Policy Generator, qui vous permet d'assembler une politique répondant à votre cas d'utilisation.

Pour un seau verrouillé sinon vers le bas, la forme la plus simple pourrait ressembler si (s'il vous plaît assurez-vous de régler principal et ressources à vos besoins):

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

En fonction de votre cas d'utilisation, vous pouvez composer facilement des politiques assez complexes en combinant divers Autoriser et Refuser actions etc - cela peut évidemment donner des autorisations par inadvertance ainsi, le bon test est la clé comme d'habitude; en conséquence, s'il vous plaît prendre soin des implications lors de l'utilisation Using ACLs and Bucket Policies Together ou IAM and Bucket Policies Together. Enfin, vous voudrez peut-être jeter un coup d'œil à ma réponse au Problems specifying a single bucket in a simple AWS user policy, qui répond à un autre écueil souvent rencontré avec les politiques.

5

Vous pouvez associer une stratégie sans suppression à votre compartiment s3.Par exemple, si vous ne voulez pas cet utilisateur IAM pour effectuer toute opération de suppression à des seaux ou des objets, vous pouvez définir quelque chose comme ceci:

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

En outre, vous pouvez vérifier votre politique avec le simulateur de politique https://policysim.aws.amazon.com pour vérifier si votre installation est ce que vous attendiez ou non.

Espérons que cela aide!

2

Cela a fonctionné parfaitement. Merci à Pung Worathiti Manosroi. combiné sa politique mentionnée ci-dessous:

{  

"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": {}  

    } 
] 
}