AccessDenied for ListObjects for S3 bucket lorsque les autorisations sont s3: *

Je reçois:

Une erreur s'est produite (AccessDenied) lors de l'appel de l'opération ListObjects: Accès refusé

Quand j'essaye d'obtenir le dossier de mon compartiment S3.

En utilisant cette commande:

aws s3 cp s3://bucket-name/data/all-data/ . --recursive

Les autorisations IAM pour le compartiment ressemblent à ceci:

{
"Version": "version_id",
"Statement": [
    {
        "Sid": "some_id",
        "Effect": "Allow",
        "Action": [
            "s3:*"
        ],
        "Resource": [
            "arn:aws:s3:::bucketname/*"
        ]
    }
] }

Que dois-je changer pour pouvoir copyet lsréussir?

Vous avez donné l'autorisation d'exécuter des commandes sur des objets dans le compartiment S3, mais vous n'avez pas donné l'autorisation d'effectuer des actions sur le compartiment lui-même.

Une légère modification de votre politique ressemblerait à ceci:

{
  "Version": "version_id",
  "Statement": [
    {
        "Sid": "some_id",
        "Effect": "Allow",
        "Action": [
            "s3:*"
        ],
        "Resource": [
            "arn:aws:s3:::bucketname",
            "arn:aws:s3:::bucketname/*"
        ]
    }
  ] 
}

Cependant, cela donne probablement plus de permission que nécessaire. Suivre les bonnes pratiques AWS IAM d' octroi du moindre privilège ressemblerait à ceci:

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

Si vous souhaitez copier tous les objets du compartiment s3 à l'aide de la commande "aws s3 cp s3: // nom du compartiment / data / all-data /. --Recursive" comme vous l'avez mentionné, voici une politique sûre et minimale pour le faire:

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Effect": "Allow",
          "Action": [
              "s3:ListBucket"
          ],
          "Resource": [
              "arn:aws:s3:::bucket-name"
          ],
          "Condition": {
              "StringLike": {
                  "s3:prefix": "data/all-data/*"
              }
          }
      },
      {
          "Effect": "Allow",
          "Action": [
              "s3:GetObject"
          ],
          "Resource": [
              "arn:aws:s3:::bucket-name/data/all-data/*"
          ]
      }
  ]
}

La première instruction de cette stratégie permet de répertorier les objets dans le sous-répertoire d'un compartiment spécifique. La ressource doit être l'arn du compartiment S3, et pour limiter la liste à un seul sous-répertoire de ce compartiment, vous pouvez modifier la valeur "s3: prefix".

La deuxième déclaration de cette stratégie permet d'obtenir des objets à l'intérieur du compartiment dans un sous-répertoire spécifique. Cela signifie que tout ce qui se trouve dans le chemin "s3: // nom du compartiment / data / all-data /" que vous pourrez copier. Sachez que cela ne vous permet pas de copier à partir de chemins parents tels que "s3: // nom du compartiment / data /".

Cette solution est spécifique à la limitation de l'utilisation des commandes AWS CLI; si vous devez limiter l'accès S3 via la console ou l'API AWS, d'autres stratégies seront nécessaires. Je suggère de jeter un œil ici: https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/ .

Un problème similaire à celui-ci peut être trouvé ici qui m'a conduit à la solution que je donne. https://github.com/aws/aws-cli/issues/2408

J'espère que cela t'aides!

Vous devez spécifier Resource pour le bucket via "arn: aws: 3 ::: bucketname" ou "arn: aws: 3 ::: bucketname *". Ce dernier est préféré car il permet également des manipulations sur les objets du bucket. Remarquez qu'il n'y a pas de barre oblique!

La liste des objets est une opération sur Bucket. Par conséquent, l'action "s3: ListBucket" est requise. L'ajout d'un objet au Bucket est une opération sur Object. Par conséquent, l'action "s3: PutObject" est nécessaire. Vous souhaiterez certainement ajouter d'autres actions selon vos besoins.

{
"Version": "version_id",
"Statement": [
    {
        "Sid": "some_id",
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket",
            "s3:PutObject"
        ],
        "Resource": [
            "arn:aws:s3:::bucketname*"
        ]
    }
] 
}

Je n'ai pas pu accéder à S3 car

• J'ai d'abord configuré l'accès clé sur l'instance (il était alors impossible d'attacher un rôle après le lancement)
• oublié pendant quelques mois
• rôle attaché à l'instance
• essayé d'accéder. La clé configurée avait une priorité plus élevée que le rôle et l'accès a été refusé car l'utilisateur ne disposait pas des autorisations S3 nécessaires.

Solution:, rm -rf .aws/credentialspuis awsutilise le rôle.

J'ai eu la même erreur lors de l'utilisation de la politique ci-dessous, bien que j'aie "s3: ListBucket" pour l'opération s3: ListObjects.

{
"Version": "2012-10-17",
"Statement": [
    {
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
        ],
        "Resource": [
            "arn:aws:s3:::<bucketname>/*",
            "arn:aws:s3:::*-bucket/*"
        ],
        "Effect": "Allow"
    }
  ]
 }

Ensuite, je l'ai corrigé en ajoutant une ligne "arn: aws: s3 ::: bucketname"

{
"Version": "2012-10-17",
"Statement": [
    {
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
        ],
        "Resource": [
             "arn:aws:s3:::<bucketname>",
            "arn:aws:s3:::<bucketname>/*",
            "arn:aws:s3:::*-bucket/*"
        ],
        "Effect": "Allow"
    }
 ]
}

Je pensais que l'erreur était due à l'action "s3: ListObjects" mais j'ai dû ajouter l'action "s3: ListBucket" pour résoudre le problème "AccessDenied for ListObjects for S3 bucket"

J'ai fait face au même problème. Je viens d'ajouter la configuration des informations d'identification:

aws_access_key_id = your_aws_access_key_id
aws_secret_access_key = your_aws_secret_access_key

dans "~ / .aws / credentials" + redémarrer le terminal pour le profil par défaut.

Dans le cas de profils multiples --profile arg doit être ajouté:

aws s3 sync ./localDir s3://bucketName --profile=${PROFILE_NAME}

où PROFILE_NAME :

.bash_profile ( or .bashrc) -> export PROFILE_NAME="yourProfileName"

Plus d'informations sur la configuration des identifiants et des profils multiples peuvent être trouvées ici

J'ai essayé ce qui suit:

aws s3 ls s3.console.aws.amazon.com/s3/buckets/{bucket name}

Cela m'a donné l'erreur:

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

L'utilisation de ce formulaire a fonctionné:

aws s3 ls {bucket name}

J'ajoute une réponse dans le même sens que la réponse acceptée mais avec de petites différences (importantes) et en ajoutant plus de détails.

Considérez la configuration ci-dessous:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<Bucket-Name>"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::<Bucket-Name>/*"]
    }
  ]
}

La stratégie accorde un accès en écriture-suppression par programme et est séparée en deux parties:
L' ListBucketaction fournit des autorisations au niveau du compartiment et les autres PutObject/DeleteObjectactions nécessitent des autorisations sur les objets à l'intérieur du compartiment.

Le premier élément Resource spécifie arn:aws:s3:::<Bucket-Name>l' ListBucketaction afin que les applications puissent répertorier tous les objets du compartiment.

Le deuxième élément Resource spécifie arn:aws:s3:::<Bucket-Name>/*les actions PutObject, et DeletObjectafin que les applications puissent écrire ou supprimer tous les objets du compartiment.

La séparation en deux «arns» différents est importante pour des raisons de sécurité afin de spécifier des autorisations à granularité fine au niveau du compartiment et au niveau de l'objet.

Notez que si j'avais spécifié juste GetObjectdans le 2ème bloc, ce qui se passerait, c'est que dans les cas d'accès programmatique, je recevrais une erreur comme:

Upload failed: <file-name> to <bucket-name>:<path-in-bucket> An error occurred (AccessDenied) when calling the PutObject operation: Access Denied.

Ran dans un problème similaire, pour moi, le problème était que j'avais différentes clés AWS définies dans mon bash_profile.

J'ai répondu à une question similaire ici: https://stackoverflow.com/a/57317494/11871462

Si vous avez des clés AWS en conflit dans votre bash_profile, AWS CLI les utilise par défaut à la place.

J'ai eu ce problème, je voulais autoriser l'utilisateur à écrire dans un chemin spécifique

{
            "Sid": "raspiiotallowspecificBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<bucketname>/scripts",
                "arn:aws:s3:::<bucketname>/scripts/*"
            ]
        },

et le problème a été résolu avec ce changement

{
            "Sid": "raspiiotallowspecificBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<bucketname>",
                "arn:aws:s3:::<bucketname>/*"
            ]
        },