Fehler beim Speichern von Docker-Images im AWS S3-Bucket aus der privaten Docker-Registrierung

Question

Ich versuche, eine private Docker-Registrierung einzurichten und Bilder in der AWS S3-Instanz zu speichern. Das Registry scheint gut zu funktionieren - es startet gut und ich kann es über https authentifizieren. Das Problem, das ich habe, ist, dass ich einen Fehler beim Speichern von S3 erhalte, also nehme ich an, dass es ein Berechtigungsproblem mit der S3 IAM Richtlinie gibt.

Der docker run Befehl sieht wie folgt aus:

docker run -p 443:5000 \ 
    --link redis:redis \ 
    -e REGISTRY_STORAGE=s3 \ 
    -e REGISTRY_STORAGE_S3_BUCKET=my-docker-registry \ 
    -e REGISTRY_STORAGE_S3_ACCESSKEY=**** \ 
    -e REGISTRY_STORAGE_S3_SECRETKEY=**** \ 
    -e REGISTRY_STORAGE_S3_REGION=us-east-1 \ 
    -v `pwd`/auth:/auth \ 
    -e REGISTRY_AUTH=htpasswd \ 
    -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \ 
    -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \ 
    -v `pwd`/certs:/certs \ 
    -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/my.com_chain.crt \ 
    -e REGISTRY_HTTP_TLS_KEY=/certs/my.com.key \ 
    -e REGISTRY_STORAGE_CACHE_BLOBDESCRIPTOR=redis \ 
    -e REGISTRY_REDIS_ADDR=redis:6379 \ 
    registry:2.5 

und die S3 IAM Politik sieht wie folgt aus:

{ 
    "Version":"2012-10-17", 
    "Statement":[ 
     { 
     "Effect":"Allow", 
     "Action":[ 
      "s3:ListAllMyBuckets" 
     ], 
     "Resource":"arn:aws:s3:::*" 
     }, 
     { 
     "Effect":"Allow", 
     "Action":[ 
      "s3:ListBucket", 
      "s3:GetBucketLocation" 
     ], 
     "Resource":"arn:aws:s3:::my-docker-registry" 
     }, 
     { 
     "Effect":"Allow", 
     "Action":[ 
       "s3:PutObject", 
       "s3:GetObject", 
       "s3:DeleteObject", 
       "s3:ListMultipartUploadParts", 
       "s3:AbortMultipartUpload" 
     ], 
     "Resource":"arn:aws:s3:::my-docker-registry/*" 
     } 
    ] 
} 

Der Fehlerprotokolleintrag ist:

level=error msg="error resolving upload: s3aws: AccessDenied: Access Denied\n\tstatus code: 403, request id: 2B224..." auth.user.name=my-user go.version=go1.6.3 http.request.host=my.domain.com http.request.id=13b79c07-... http.request.method=PATCH http.request.remoteaddr="xx.xx.xx.xx:41392" http.request.uri="/v2/my-test/blobs/uploads/467d94ea-2a77...?_state=zQd-..." http.request.useragent="docker/1.12.0 go/go1.6.3 git-commit/8eab123 kernel/4.4.15-moby os/linux arch/amd64 UpstreamClient(Docker-Client/1.12.0 \\(darwin\\))" instance.id=8a8db6f1-8fe4 vars.name=my-test vars.uuid=467d94ea-2a77 version=v2.5.0 

Ich habe habe eine ähnliche Richtlinie für Datei-Uploads in anderen Apps verwendet, daher bin ich mir nicht sicher, wo das Problem liegt. Was muss ich in der IAM-Richtlinie ändern, damit die Registrierung im S3-Bucket gespeichert werden kann?

Answer 1

ich es herausgefunden - nicht sicher, ob sich etwas verändert, mit wie Docker speichert Dateien Bild, aber es scheint, dass Sie jetzt s3:ListBucketMultipartUploads auf den heißen Stein-Level-Erlaubnis (Mittelblock unten, IAM gezeigt vollständig auf Vollständigkeit) hinzufügen müssen:

{ 
    "Version":"2012-10-17", 
    "Statement":[ 
     { 
     "Effect":"Allow", 
     "Action":[ 
      "s3:ListAllMyBuckets" 
     ], 
     "Resource":"arn:aws:s3:::*" 
     }, 
     { 
     "Effect":"Allow", 
     "Action":[ 
      "s3:ListBucket", 
      "s3:GetBucketLocation", 
      "s3:ListBucketMultipartUploads" 
     ], 
     "Resource":"arn:aws:s3:::my-docker-registry" 
     }, 
     { 
     "Effect":"Allow", 
     "Action":[ 
       "s3:PutObject", 
       "s3:GetObject", 
       "s3:DeleteObject", 
       "s3:ListMultipartUploadParts", 
       "s3:AbortMultipartUpload" 
     ], 
     "Resource":"arn:aws:s3:::my-docker-registry/*" 
     } 
    ] 
} 

Scheint jetzt gut zu funktionieren.

Die nächsten Schritte bestehen darin, eine Docker-Compose-Datei mit den obigen Argumenten docker run zu erstellen, einen Redis-Container hinzuzufügen und eine vollständige private Registrierungslösung.

Answer 2

Überprüfen Sie, ob die S3 IAM-Rolle dem IAM-Benutzer zugewiesen ist, dessen Zugriffsschlüssel verwendet wird. Sie können diese Rolle auch der EC2-Instanz zuweisen und vermeiden, diesen Zugriffsschlüssel zu verwenden.