AWS CLI S3 Beim Aufrufen der HeadObject-Operation ist ein Client-Fehler (403) aufgetreten: Verboten
Ich versuche, eine Amazon Linux AMI (ami-f0091d91) einzurichten und habe ein Skript, das einen Kopierbefehl zum Kopieren aus einem S3-Bucket ausführt.
aws --debug s3 cp s3://aws-codedeploy-us-west-2/latest/codedeploy-agent.noarch.rpm .
Dieses Skript funktioniert perfekt auf meinem lokalen Computer, schlägt jedoch mit dem folgenden Fehler im Amazon Image fehl:
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
Wenn ich es jedoch mit der Option --no-sign-request starte, funktioniert es perfekt:
aws --debug --no-sign-request s3 cp s3://aws-codedeploy-us-west-2/latest/codedeploy-agent.noarch.rpm .
Kann jemand bitte erklären, was los ist?
Ich habe es herausgefunden. Ich hatte einen Fehler in meiner Cloud-Formationsvorlage, die die EC2-Instanzen erstellt hat. Als Ergebnis befanden sich die EC2-Instanzen, die auf die oben genannten Code-Implementierungs-Buckets zugreifen wollten, in verschiedenen Regionen (nicht in us-west-2). Es scheint, als würden die Zugriffsrichtlinien für die Buckets (im Besitz von Amazon) nur den Zugriff aus der Region zulassen, in der sie sich befinden. Wenn ich den Fehler in meiner Vorlage behoben habe (es war eine falsche Parameterzuordnung), verschwand der Fehler
Ich habe die Fehlermeldung A client error (403) occurred when calling the HeadObject operation: Forbidden für meinen aws cli copy-Befehl aws s3 cp s3://bucket/file file erhalten. Ich habe eine IAM-Rolle verwendet, die vollen S3-Zugriff mit einem Inline Policy hatte.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
Wenn ich ihm stattdessen den vollständigen S3-Zugriff von Managed Policies gebe, funktioniert der Befehl. Ich denke, dass dies ein Fehler von Amazon sein muss, da die Richtlinien in beiden Fällen genau gleich waren.
Beim Versuch, dieses Problem selbst zu lösen, habe ich festgestellt, dass es keine HeadBucket-Berechtigung gibt. Es sieht so aus, als ob es das ist, was die Fehlermeldung Ihnen sagt, aber tatsächlich erfordert die HEAD-Operation die ListBucket-Berechtigung .. Ich habe auch festgestellt, dass meine IAM-Richtlinie und meine Bucket-Richtlinie in Konflikt miteinander standen. Stellen Sie sicher, dass Sie beide überprüfen.
Ich hatte dieses Problem, das Hinzufügen von --recursive zum Befehl hilft.
An diesem Punkt macht es keinen Sinn, da Sie (wie ich) nur versuchen, eine einzelne Datei nach unten zu kopieren, aber es macht den Trick!
in meinem Fall war das Problem die Anweisung Resource in der Benutzerzugriffsrichtlinie.
Zuerst hatten wir "Resource": "arn:aws:s3:::BUCKET_NAME", Aber um auf Objekte in einem Bucket zugreifen zu können, benötigen Sie am Ende einen /*: "Resource": "arn:aws:s3:::BUCKET_NAME/*"
Ein Grund dafür könnte sein, wenn Sie versuchen, auf Buckets einer Region zuzugreifen, für die V4-Signing erforderlich ist. Versuchen Sie, die Region explizit als --region cn-north-1 anzugeben.
In meinem Fall habe ich diese Fehlermeldung beim Versuch erhalten, ein Objekt in einem S3-Bucket-Ordner abzurufen. Aber in diesem Ordner war mein Objekt nicht hier (ich legte den falschen Ordner ein), also sende S3 diese Nachricht. Ich hoffe es könnte dir auch helfen.
Diese Fehlermeldung wurde angezeigt, weil die Uhr meiner EC2-Instanz nicht synchron war.
Ich konnte Ubuntu mit diesem Problem beheben:
Sudo ntpdate ntp.ubuntu.com
Sudo apt-get install ntp
Ich erhielt eine 403 auf HEAD -Anfragen, während die GET-Anforderungen funktionierten. Es stellte sich heraus, dass es sich um die CORS-Konfiguration in S3-Berechtigungen handelt. Ich musste HEAD hinzufügen
<?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>
Ich habe diesen Fehler mit einem falsch konfigurierten Testereignis erhalten. Ich habe den Quell-Buckets-ARN geändert, aber vergessen, den Standardnamen des S3-Buckets zu bearbeiten.
Das heißt Stellen Sie sicher, dass im Bucket-Abschnitt des Testereignisses sowohl der ARN als auch der Bucket-Name korrekt festgelegt sind:
"bucket": {
"arn": "arn:aws:s3:::your_bucket_name",
"name": "your_bucket_name",
"ownerIdentity": {
"principalId": "EXAMPLE"
}
Ich habe dieses Szenario auch erlebt.
Ich habe einen Eimer mit Richtlinien, die AWS4-HMAC-SHA256 verwenden. Es stellt sich heraus, dass mein awscli nicht auf die neueste Version aktualisiert wurde. Meines war aws-cli/1.10.8. Ein Upgrade hat das Problem gelöst.
pip install awscli --upgrade --user
https://docs.aws.Amazon.com/cli/latest/userguide/installing.html
Wenn Sie in einer Umgebung ausgeführt werden, in der die Anmeldeinformationen/Rollen nicht eindeutig sind, müssen Sie das --profile=yourprofile -Flag angeben, damit die CLI weiß, welche Anmeldeinformationen verwendet werden sollen. Zum Beispiel:
aws s3 cp s3://yourbucket destination.txt --profile=yourprofile
wird erfolgreich sein, während das Folgende den HeadObject-Fehler ergab
aws s3 cp s3://yourbucket destination.txt
Die Profileinstellungen verweisen auf Einträge in Ihren config- und credentials -Dateien.
Ich habe dieses Verhalten auch erlebt. In meinem Fall habe ich festgestellt, dass, wenn die IAM-Richtlinie keinen Zugriff zum Lesen des Objekts (s3:GetObject) hat, derselbe Fehler ausgelöst wird.
Ich stimme mit Ihnen überein, dass der von aws console & cli gemachte Fehler nicht wirklich gut erklärt ist und Verwirrung stiften kann.