AWS CLI S3 Une erreur du client (403) s'est produite lors de l'appel de la HeadObject opération: Interdit

Je suis en train de configurer un AMI Linux Amazon(ami-f0091d91) et avoir un script qui exécute une commande de copie de copie à partir d'un compartiment S3.

 aws --debug s3 cp s3://aws-codedeploy-us-west-2/latest/codedeploy-agent.noarch.rpm .

Ce script fonctionne parfaitement sur ma machine locale, mais échoue avec l'erreur suivante sur l'Amazone de l'Image:

2016-03-22 01:07:47,110 - MainThread - botocore.auth - DEBUG - StringToSign:
HEAD


Tue, 22 Mar 2016 01:07:47 GMT
x-amz-security-token:AQoDYXdzEPr//////////wEa4ANtcDKVDItVq8Z5OKms8wpQ3MS4dxLtxVq6Om1aWDhLmZhL2zdqiasNBV4nQtVqwyPsRVyxl1Urq1BBCnZzDdl4blSklm6dvu+3efjwjhudk7AKaCEHWlTd/VR3cksSNMFTcI9aIUUwzGW8lD9y8MVpKzDkpxzNB7ZJbr9HQNu8uF/st0f45+ABLm8X4FsBPCl2I3wKqvwV/s2VioP/tJf7RGQK3FC079oxw3mOid5sEi28o0Qp4h/Vy9xEHQ28YQNHXOBafHi0vt7vZpOtOfCJBzXvKbk4zRXbLMamnWVe3V0dArncbNEgL1aAi1ooSQ8+Xps8ufFnqDp7HsquAj50p459XnPedv90uFFd6YnwiVkng9nNTAF+2Jo73+eKTt955Us25Chxvk72nAQsAZlt6NpfR+fF/Qs7jjMGSF6ucjkKbm0x5aCqCw6YknsoE1Rtn8Qz9tFxTmUzyCTNd7uRaxbswm7oHOdsM/Q69otjzqSIztlwgUh2M53LzgChQYx5RjYlrjcyAolRguJjpSq3LwZ5NEacm/W17bDOdaZL3y1977rSJrCxb7lmnHCOER5W0tsF9+XUGW1LMX69EWgFYdn5QNqFk6mcJsZWrR9dkehaQwjLPcv/29QcM+b5u/0goazCtwU=
/aws-codedeploy-us-west-2/latest/codedeploy-agent.noarch.rpm
2016-03-22 01:07:47,111 - MainThread - botocore.endpoint - DEBUG - Sending http request: <PreparedRequest [HEAD]>
2016-03-22 01:07:47,111 - MainThread - botocore.vendored.requests.packages.urllib3.connectionpool - INFO - Starting new HTTPS connection (1): aws-codedeploy-us-west-2.s3.amazonaws.com
2016-03-22 01:07:47,151 - MainThread - botocore.vendored.requests.packages.urllib3.connectionpool - DEBUG - "HEAD /latest/codedeploy-agent.noarch.rpm HTTP/1.1" 403 0
2016-03-22 01:07:47,151 - MainThread - botocore.parsers - DEBUG - Response headers: {'x-amz-id-2': '0mRvGge9ugu+KKyDmROm4jcTa1hAnA5Ax8vUlkKZXoJ//HVJAKxbpFHvOGaqiECa4sgon2F1kXw=', 'server': 'AmazonS3', 'transfer-encoding': 'chunked', 'x-amz-request-id': '6204CD88E880E5DD', 'date': 'Tue, 22 Mar 2016 01:07:46 GMT', 'content-type': 'application/xml'}
2016-03-22 01:07:47,152 - MainThread - botocore.parsers - DEBUG - Response body:

2016-03-22 01:07:47,152 - MainThread - botocore.hooks - DEBUG - Event needs-retry.s3.HeadObject: calling handler <botocore.retryhandler.RetryHandler object at 0x7f421075bcd0>
2016-03-22 01:07:47,152 - MainThread - botocore.retryhandler - DEBUG - No retry needed.
2016-03-22 01:07:47,152 - MainThread - botocore.hooks - DEBUG - Event after-call.s3.HeadObject: calling handler <function enhance_error_msg at 0x7f4211085758>
2016-03-22 01:07:47,152 - MainThread - botocore.hooks - DEBUG - Event after-call.s3.HeadObject: calling handler <awscli.errorhandler.ErrorHandler object at 0x7f421100cc90>
2016-03-22 01:07:47,152 - MainThread - awscli.errorhandler - DEBUG - HTTP Response Code: 403
2016-03-22 01:07:47,152 - MainThread - awscli.customizations.s3.s3handler - DEBUG - Exception caught during task execution: A client error (403) occurred when calling the HeadObject operation: Forbidden
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/awscli/customizations/s3/s3handler.py", line 100, in call
    total_files, total_parts = self._enqueue_tasks(files)
  File "/usr/local/lib/python2.7/site-packages/awscli/customizations/s3/s3handler.py", line 178, in _enqueue_tasks
    for filename in files:
  File "/usr/local/lib/python2.7/site-packages/awscli/customizations/s3/fileinfobuilder.py", line 31, in call
    for file_base in files:
  File "/usr/local/lib/python2.7/site-packages/awscli/customizations/s3/filegenerator.py", line 142, in call
    for src_path, extra_information in file_iterator:
  File "/usr/local/lib/python2.7/site-packages/awscli/customizations/s3/filegenerator.py", line 314, in list_objects
    yield self._list_single_object(s3_path)
  File "/usr/local/lib/python2.7/site-packages/awscli/customizations/s3/filegenerator.py", line 343, in _list_single_object
    response = self._client.head_object(**params)
  File "/usr/local/lib/python2.7/site-packages/botocore/client.py", line 228, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python2.7/site-packages/botocore/client.py", line 488, in _make_api_call
    model=operation_model, context=request_context
  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 226, in emit
    return self._emit(event_name, kwargs)
  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 209, in _emit
    response = handler(**kwargs)
  File "/usr/local/lib/python2.7/site-packages/awscli/errorhandler.py", line 70, in __call__
    http_status_code=http_response.status_code)
ClientError: A client error (403) occurred when calling the HeadObject operation: Forbidden
2016-03-22 01:07:47,153 - Thread-1 - awscli.customizations.s3.executor - DEBUG - Received print task: PrintTask(message='A client error (403) occurred when calling the HeadObject operation: Forbidden', error=True, total_parts=None, warning=None)
A client error (403) occurred when calling the HeadObject operation: Forbidden

Cependant, quand je le lance avec le --no-sign-request option, il fonctionne parfaitement:

 aws --debug --no-sign-request s3 cp s3://aws-codedeploy-us-west-2/latest/codedeploy-agent.noarch.rpm .

Quelqu'un peut-il expliquer ce qui se passe?

ressemble vous êtes (peut-être implicitement) à l'aide de l'exemple du rôle IAM pour faire la demande (qui pourrait expliquer x-amz-security-token -- temporaire les informations d'identification du rôle) et votre rôle refuse l'accès à S3... ou le seau (pas le vôtre, je le prendre?) ne pas permettre l'accès à des informations d'identification -- si si c'est public, c'est étrange. Comme toujours, assurez-vous que l'horloge de votre système est correct, car avec HEAD l'erreur corps est toujours supprimé.
Salut, merci pour la réponse rapide. Le seau que je suis en train de l'accès est, en effet, du public. Pas sûr pourquoi elle se plaint d'une demande signée ensuite. Il échoue avec l'erreur similaire sur mon propre seau aussi bien sans l'option --no-signe-demande d'option.
Vous avez un rôle IAM sur cette instance, à droite? Il semble que ce rôle peut limiter les choses, peut-être de façon inattendue.

OriginalL'auteur MojoJojo | 2016-03-22

13

J'ai tout compris. J'ai eu une erreur dans ma formation de nuages modèle qui a été la création de l'instance EC2. En conséquence, les instances EC2 qui tentaient d'accéder au code ci-dessus déployer des seaux, étaient dans les différentes régions (et non à nous-ouest-2). Il semble que les politiques d'accès sur les seaux (détenue par Amazon) ne permettre l'accès de la région ils appartiennent.
Quand j'ai corrigé l'erreur dans mon template (c'était une erreur de paramètre de la carte), l'erreur a disparu

Vous avez écrit: "les politiques d'accès sur les seaux (détenue par Amazon) ne permettre l'accès de la région à laquelle ils appartiennent." Seaux de ne pas "appartenir à une région". Elles sont Mondiales. Souhaite que je compris ce qui a résolu votre erreur.
Seaux en fait, sont définis dans une région.
En passant le seau de la région en tant que paramètre a fonctionné pour moi.
J'ai été faire quelque chose de similaire sur boto3 dans une inter-région demande de, et de découvrir un bug dans ma politique dans le processus. dans cette réponse. Peut pas dire que c'est le même correctif ici, mais c'est peut-être un indice? @LeslieK
J'ai vérifié pour savoir si us-west-2a serait différente de us-west-2b et il s'avère qu'il fonctionne de toute façon. Il n'est pas en contradiction avec votre réponse, mais il ajoute à elle. Merci.

OriginalL'auteur
10

J'obtenais l'erreur A client error (403) occurred when calling the HeadObject operation: Forbidden pour mon aws cli commande de copie aws s3 cp s3://bucket/file file. J'ai été en utilisant un rôle IAM qui avait S3 complète de l'accès à l'aide d'un Inline Policy.
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}
```
Si je lui donne le plein S3 accès à partir de la Managed Policies au lieu de cela, la commande fonctionne. Je pense que ce doit être un bug de la part d'Amazon, car les politiques dans les deux cas étaient exactement les mêmes.

Btw, j'ai essayé d'utiliser goofys pour le montage d'un compartiment s3 dans mon ubuntu serveur de système de fichiers par le biais d'un utilisateur IAM attaché à une politique similaire à celle ci-dessus mais avec Resource: "example" ensemble (au lieu de *), et qui a causé l'incapacité de créer des fichiers (question). J'ai juste changé le managed policy de AmazonS3FullAccess
C'est une mauvaise réponse, vous ne devriez jamais permettre à des politiques qui permettent d'accéder à tout l'
C'est une solution aussi longtemps que l'original bug n'est pas résolu

OriginalL'auteur
5

J'ai eu ce problème, l'ajout de --recursive à la commande d'aide.

À ce stade, il n'est pas tout à fait le sens comme vous (comme moi) ne sont que d'essayer de copier un seul fichier, mais il ne le tour!

Il ressemblait à succès, mais le téléchargé en local "fichier" était en fait un répertoire vide

OriginalL'auteur
4

L'une des raisons, c'est peut-être si vous essayez d'accéder à des seaux d'une région qui exige V4-Signature. Essayez de prévoir expressément que la région, comme --region cn-north-1

OriginalL'auteur
4

dans mon cas, le problème était le Resource énoncé dans le manuel de la politique d'accès.

Nous avons d'abord eu "Resource": "arn:aws:s3:::BUCKET_NAME",
mais afin d'avoir accès aux objets dans un seau vous avez besoin d'un /* à la fin:
"Resource": "arn:aws:s3:::BUCKET_NAME/*"

OriginalL'auteur
4

Essayer de résoudre ce problème moi-même, j'ai découvert qu'il n'y a pas de HeadBucket autorisation. Il semble qu'il y est, parce que c'est ce que le message d'erreur vous indique, mais en fait les HEAD opération nécessite la ListBucket autorisation.
J'ai aussi découvert que mon politique IAM et mon seau de la politique ont été contradictoires. Assurez-vous de vérifier.

OriginalL'auteur
3

Dans mon cas, j'ai eu cette erreur en essayant de prendre un objet sur un compartiment S3 dossier. Mais dans ce dossier, mon objet n'était pas là (j'ai mis le mauvais dossier), donc S3 envoyer ce message. Espérons qu'il pourrait vous aider aussi.

OriginalL'auteur
0

J'ai eu cette erreur avec un mal configuré test de l'événement. J'ai changé la source de seaux d'ARN, mais j'ai oublié de modifier la valeur par défaut S3 seau nom.

I. e. assurez-vous que dans le seau de la section de l'épreuve à la fois l'ARN et d'un seau nom sont correctement définies:
```
"bucket": {
  "arn": "arn:aws:s3:::your_bucket_name",
  "name": "your_bucket_name",
  "ownerIdentity": {
    "principalId": "EXAMPLE"
  }
```
OriginalL'auteur
0

Je recevais ce message d'erreur à cause de mon instance EC2 de l'horloge de synchronisation.

J'ai pu réparer sur Ubuntu à l'aide de ceci:
```
sudo ntpdate ntp.ubuntu.com
sudo apt-get install ntp
```
OriginalL'auteur

J'ai été prendre une 403 sur la TÊTE des demandes, tandis que les requêtes GET. Il s'est avéré être de la SCRO config dans s3 autorisations. J'ai dû ajouter de la TÊTE

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

OriginalL'auteur

0

J'ai aussi eu ce comportement. Dans mon cas, j'ai trouvé que si la politique IAM n'a pas accès à la lecture de l'objet (s3:GetObject), la même erreur est générée.

Je suis d'accord avec vous que l'erreur de console aws & cli n'est pas vraiment bien expliqué, et peut causer de la confusion.

OriginalL'auteur
0

J'ai aussi vécu ce scénario.

J'ai un seau avec politique qui utilise AWS4-HMAC-SHA256. S'avère que mon awscli n'est pas mis à jour vers la dernière version. Le mien était aws-cli/1.10.8. La mise à niveau à avoir résolu le problème.

pip install awscli --upgrade --user

https://docs.aws.amazon.com/cli/latest/userguide/installing.html

OriginalL'auteur
-3

Il vous manque un HeadBucket autorisation.

autant que je sache, cela ne résout pas le problème. et il n'était pas nécessaire dans mon cas, pour résoudre le problème.
il n'y a pas de HeadBucket autorisation. Le CHEF d'opération nécessite la ListBucket autorisation.
Si vous validez ce qu'une réponse, je vais +1 vous. C'est ce qui me manquait! (Souhaitez-messages d'erreur mentionné la permission.. rendrait sooo beaucoup plus facile de créer à peu de stratégies d'accès par essai et erreur!)
Il semble qu'il y est un HeadBucket l'opération: docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketHEAD.html et si vous allez à la politique de simulateur, il montre aussi un HeadBucket autorisation: policysim.aws.amazon.com

OriginalL'auteur

Vous devez vous connecter pour publier un commentaire.