Qu'est-ce qui cause l'accès refusé lors du téléchargement de aws cli à partir d'Amazon S3?


57

AWS essaie vraiment de comprendre ce qui me manque ici. Je voudrais faire en sorte qu'un utilisateur IAM puisse télécharger des fichiers à partir d'un compartiment S3 - sans simplement les rendre totalement publics - mais l'accès me est refusé. Si quelqu'un peut voir ce qui se passe, je serai ravi.

Ce que j'ai fait jusqu'à présent:

  • Créé un utilisateur appelé my-user (par exemple)
  • Généré des clés d'accès pour l'utilisateur et les mettre dans ~ / .aws sur une instance EC2
  • Création d'une stratégie de compartiment que j'espérais accorder un accès à mon utilisateur
  • A exécuté la commande aws s3 cp --profile my-user s3://my-bucket/thing.zip .

Politique de seau:

{
  "Id": "Policy1384791162970",
  "Statement": [
    {
      "Sid": "Stmt1384791151633",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:user/my-user"
      }
    }
  ]
}

Le résultat est A client error (AccessDenied) occurred: Access Deniedbien que je puisse télécharger en utilisant la même commande et les clés d'accès par défaut (compte root?).

J'ai également essayé d'ajouter une stratégie utilisateur. Bien que je ne sache pas pourquoi cela serait nécessaire, je pensais que cela ne ferait pas de mal, alors j'ai attaché cela à mon utilisateur.

{
  "Statement": [
    {
      "Sid": "Stmt1384889624746",
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Même résultat.

Réponses:


39

Je me débattais aussi avec ce problème, mais j’ai trouvé une réponse ici https://stackoverflow.com/a/17162973/1750869 qui a permis de résoudre ce problème. Reposting réponse ci-dessous.


Vous n'êtes pas obligé d'ouvrir les autorisations à tout le monde. Utilisez les stratégies de compartiment ci-dessous sur la source et la destination pour copier d'un compartiment d'un compte à un autre à l'aide d'un utilisateur IAM.

Bucket à copier depuis - SourceBucket

Bucket à copier dans - DestinationBucket

ID de compte AWS source - XXXX – XXXX-XXXX

Utilisateur IAM source - src – iam-user

La stratégie ci-dessous signifie - l'utilisateur IAM - XXXX – XXXX-XXXX: src – iam-user a les privilèges s3: ListBucket et s3: GetObject sur SourceBucket / * et s3: ListBucket et s3: PutObject sur DestinationBucket / *.

Sur le SourceBucket, la politique devrait être la suivante:

{
"Id": "Policy1357935677554",
"Statement": [
    {
        "Sid": "Stmt1357935647218",
        "Action": [
            "s3:ListBucket"
        ],
        "Effect": "Allow",
        "Resource": "arn:aws:s3:::SourceBucket",
        "Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
    },
    {
        "Sid": "Stmt1357935676138",
        "Action": ["s3:GetObject"],
        "Effect": "Allow",
        "Resource": "arn:aws:s3::: SourceBucket/*",
        "Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
   }
]
}

Sur le DestinationBucket la politique devrait être:

{
"Id": "Policy1357935677554",
"Statement": [
    {
        "Sid": "Stmt1357935647218",
        "Action": [
            "s3:ListBucket"
        ],
        "Effect": "Allow",
        "Resource": "arn:aws:s3::: DestinationBucket",
        "Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
    },
    {
        "Sid": "Stmt1357935676138",
        "Action": ["s3:PutObject"],
        "Effect": "Allow",
        "Resource": "arn:aws:s3::: DestinationBucket/*",
        "Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
   }
]
}

commande à exécuter est s3cmd cp s3://SourceBucket/File1 s3://DestinationBucket/File1


1
Oh mon dieu, tu es mon héros. Il me manquait tout simplement l'autorisation ListBucket au niveau du compartiment. Je ne sais toujours pas pourquoi il faut que je lève le seau pour pouvoir en extraire un objet, mais ce n'est pas grave. Peut-être que c'est seulement une bizarrerie d'utiliser la commande aws?
Josh Gagnon

Ouais, c'est assez étrange. On pourrait penser qu’une politique unique de s3: * (aussi incertaine qu’elle puisse être) serait suffisante pour un test de cohérence.
Sergio

fml, 2 jours perdus pour cette autorisation ListBucket. bonne prise
chaqke

Passé beaucoup de temps .. C'était la réponse nécessaire. ListBucket - bucketname, GetObject - bucketname / *
rsmoorthy

12

Lorsque j'ai rencontré le même problème, il s'est avéré qu'AWS devait activer le chiffrement côté serveur. Donc, la commande suivante a fonctionné avec succès pour moi:

aws s3 cp test.txt s3://my-s3-bucket --sse AES256

3
Merci! Dans mon cas, c'était --sse aws:kmsd'utiliser le seau "par défaut" ...
Michael Yoo

Si vous utilisez une clé KMS autre que celle par défaut, vous devez également transmettre cette information. --sse-kms-key-id 0123-abc-etc Toutefois, la partie qui n'est pas claire est que pour utiliser votre propre clé KMS, vous devez disposer de l'autorisation IAM sinon l' kms:GenerateDataKeyaccès sera refusé.
digarok

La question concerne le téléchargement .. vous effectuez un téléchargement sur un S3 chiffré, d’où la nécessité de la clé.
Ilhicas

4

Je ne recommanderais pas l'option "Tout utilisateur AWS authentifié" mentionnée par James.

Cela ajoute une liste de contrôle d'accès au niveau du compartiment qui permet à tout compte AWS (pas uniquement à vos utilisateurs IAM) de répertorier / supprimer / modify-acls pour ce compartiment.

c'est-à-dire public en lecture / écriture pour toute personne ayant un compte aws.


Avez-vous testé cela? J'avais l'impression que compte AWS désigne en réalité toute entité avec mon organisation, c'est-à-dire un utilisateur, une instance EC2, un rôle IAM, mais pas une personne d'un autre compte. Je peux me tromper, je vais éditer ma contribution et auditer rapidement mes compartiments si tel est le cas. Merci.
James Dunmore

1
Ouaip. Le bénéficiaire "utilisateur authentifié" dans les ACL S3 désigne tous les comptes AWS. Il applique les demandes signées, mais rien de plus. Voici une référence: lien
Andrew

3

J'ai réussi à résoudre ce problème sans avoir à écrire de politiques - à partir de la console S3 (interface Web), j'ai sélectionné le compartiment et dans l'onglet autorisations, choisissez "Tout utilisateur AWS authentifié" et envoyez un ticket à toutes les cases.

UPDATE: comme indiqué dans les commentaires, "Tout utilisateur AWS authentifié" ne se limite pas aux utilisateurs de votre compte, mais à tous les utilisateurs authentifiés AWS. Veuillez les utiliser avec prudence.


J'imagine que cela crée une politique pour vous. En cochant toutes les cases, vous obtiendrez ListBucket, etc., etc.
Josh Gagnon

Je suis sûr que c'est - je sais juste que les politiques d'écriture peuvent être une douleur, ces cases à cocher peuvent vous donner un peu plus, mais une solution rapide agréable
James Dunmore

2

Même si vos stratégies IAM sont correctement configurées, vous pouvez toujours obtenir une erreur en An error occurred (AccessDenied) when calling the <OPERATION-NAME> operation: Access Deniedraison des exigences de MFA (Authentification à plusieurs facteurs) sur vos informations d'identification. Cela peut vous prendre au dépourvu, car si vous êtes déjà connecté à la console AWS, vos informations d'identification semblent bien fonctionner et le message d'erreur d'autorisation refusée de aws cli n'est pas particulièrement utile.

Il existe déjà de bonnes instructions sur la configuration de MFA avec aws cli:

Fondamentalement, vous devez connaître l'adresse de votre périphérique MFA et l'envoyer avec le code de votre périphérique pour obtenir un jeton temporaire.


Tu as sauvé ma journée mon frère!
Shintaroïd

Yas, c'est la raison! Pourquoi AWS n'a pas montré cette raison dans la sortie?
tommy.qichang

0

Je suis simplement allé sur l'interface Web, puis j'ai cliqué sur le compartiment, puis sur les autorisations, puis sur la stratégie. Quand je l'ai ouvert je viens de cliquer sur Supprimer. Je l'ai fait car je pense que c'était aussi la configuration.

Je suis retourné à la page s3 principale, puis j'ai cliqué sur le seau et essayé de le supprimer et cela a fonctionné.

même quand je l'ai fait par aws-cli en utilisant

$ aws s3 rb s3://bucket-name --force  

En tout cas, c'est la chose qui a fonctionné pour moi. La stratégie sur les autorisations vous empêche de supprimer le compartiment.


0

Une fois que j'ai eu cette erreur en essayant simplement de courir:

aws s3 cp s3://[bucketName]/[fileName] .

dans un dossier où je n'avais pas les autorisations. C'est idiot, mais assurez-vous que vous êtes le propriétaire du dossier dans lequel vous vous trouvez avant de poursuivre!


0

Le problème se pose lorsque vous insérez des noms d'objet ou de ressource non valides. J'avais le même problème avec boto3 (dans mon cas, il s'agissait d'un nom de compartiment non valide).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.