AWS CLI S3 Une erreur client (403) s'est produite lors de l'appel de l'opération HeadObject: Interdit
J'essaie d'installer une AMI Amazon Linux (ami-f0091d91) et de disposer d'un script qui exécute une commande de copie pour copier à 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 mon ordinateur local mais échoue avec l'erreur suivante sur Amazon 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, lorsque je le lance avec l'option --no-sign-request, cela fonctionne parfaitement:
aws --debug --no-sign-request s3 cp s3://aws-codedeploy-us-west-2/latest/codedeploy-agent.noarch.rpm .
Quelqu'un peut-il s'il vous plaît expliquer ce qui se passe?
Je l'ai compris. Une erreur s'est produite dans mon modèle de formation dans le cloud lors de la création des instances EC2. Par conséquent, les instances EC2 qui tentaient d'accéder aux compartiments de déploiement de code ci-dessus se trouvaient dans différentes régions (pas us-west-2). Il semble que les règles d'accès sur les compartiments (appartenant à Amazon) n'autorisent l'accès qu'à partir de la région à laquelle elles appartiennent.
J'obtenais l'erreur A client error (403) occurred when calling the HeadObject operation: Forbidden pour ma commande de copie aws cli aws s3 cp s3://bucket/file file. J'utilisais un rôle IAM avec un accès S3 complet utilisant un Inline Policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
Si je lui donne l'accès S3 complet à partir du Managed Policies à la place, la commande fonctionne. Je pense que cela doit être un bogue d'Amazon, car les politiques étaient exactement les mêmes dans les deux cas.
En essayant de résoudre ce problème moi-même, j'ai découvert qu'il n'y avait pas de permission HeadBucket. Cela semble être le cas, car c'est ce que le message d'erreur vous indique, mais en réalité, l'opération HEAD nécessite l'autorisation ListBucket .. J'ai également découvert que mes règles IAM et de compartiment étaient en conflit. Assurez-vous de vérifier les deux.
J'ai eu ce problème, ajouter --recursive à la commande aidera.
À ce stade, cela n’a pas vraiment de sens puisque vous (comme moi) essayez seulement de copier un seul fichier, mais c’est tout!
dans mon cas, le problème était l'instruction Resource dans la stratégie d'accès de l'utilisateur.
Nous avons d’abord eu "Resource": "arn:aws:s3:::BUCKET_NAME", Mais pour avoir accès aux objets d’un compartiment, vous avez besoin d’un /* à la fin: "Resource": "arn:aws:s3:::BUCKET_NAME/*"
Une des raisons de ceci pourrait être si vous essayez d'accéder aux compartiments d'une région qui nécessite V4-Signing. Essayez de fournir explicitement la région, sous la forme --region cn-north-1
Dans mon cas, j'ai eu cette erreur en essayant d'obtenir un objet sur un dossier de compartiment S3. Mais dans ce dossier, mon objet n'était pas là (j'ai mis le mauvais dossier), donc S3 envoie ce message. J'espère que cela pourrait vous aider aussi.
Je recevais ce message d'erreur car l'horloge de mon instance EC2 était désynchronisée.
J'ai été capable de réparer Ubuntu en utilisant ceci:
Sudo ntpdate ntp.ubuntu.com
Sudo apt-get install ntp
Je recevais un 403 sur des demandes HEAD pendant que les demandes GET fonctionnaient. Il s’est avéré que c’est la configuration CORS dans les autorisations s3. Je devais ajouter HEAD
<?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>
J'ai eu cette erreur avec un événement de test mal configuré. J'ai changé l'ARN des compartiments sources, mais j'ai oublié de modifier le nom du compartiment S3 par défaut.
C'est à dire. Assurez-vous que dans la section de compartiment de l'événement test, l'ARN et le nom du compartiment sont correctement définis:
"bucket": {
"arn": "arn:aws:s3:::your_bucket_name",
"name": "your_bucket_name",
"ownerIdentity": {
"principalId": "EXAMPLE"
}
J'ai aussi vécu ce scénario.
J'ai un compartiment avec une stratégie qui utilise AWS4-HMAC-SHA256. Il s'avère que mon awscli n'est pas mis à jour à la dernière version. Le mien était aws-cli/1.10.8. La mise à niveau a résolu le problème.
pip install awscli --upgrade --user
https://docs.aws.Amazon.com/cli/latest/userguide/installing.html
Si vous travaillez dans un environnement où les informations d'identification/le rôle ne sont pas clairs, assurez-vous que vous avez inclus l'indicateur --profile=yourprofile afin que le CLI sache quelles informations d'identification utiliser. Par exemple:
aws s3 cp s3://yourbucket destination.txt --profile=yourprofile
va réussir alors que ce qui suit a donné l'erreur HeadObject
aws s3 cp s3://yourbucket destination.txt
Les paramètres de profil référencent les entrées de vos fichiers config et credentials.
J'ai aussi expérimenté ce comportement. Dans mon cas, j'ai constaté que si la stratégie IAM n'a pas accès à lire l'objet (s3:GetObject), la même erreur est générée.
Je conviens avec vous que l'erreur générée par aws console & cli n'est pas vraiment bien expliquée et peut être source de confusion.