2015-10-03 10 views
7

Poznaję używanie S3 z rubinem do przesyłania plików do usługi Amazon Web Service. Niedawno skonfrontowałem się z następującym błędem: AWS::S3::Errors::AccessDenied Access Denied. Podczas pisania w Google znalazłem this post z powodu błędu. Twierdzi, że zasady dotyczące zasobnika nie są wystarczające, aby umożliwić dostęp za pośrednictwem aplikacji internetowej, a także, że użytkownik musi mieć także dostęp administratora.Odmowa dostępu S3 z spinaczem

Podjęłam próbę i działa dobrze, ale mam wrażenie, że to jest wskazówka, że ​​nie robię tego dobrze, biorąc pod uwagę, że dostęp administratora nie jest wymieniony w żadnej innej dokumentacji, którą przeczytałem. Używam klejnotu aws-sdk. Czy ktokolwiek może rozważyć, czy dostęp administracyjny jest konieczny? Wielkie dzięki!

+0

nie należy naprawdę potrzebne 'Admin Access' do osiągnięcia tego celu. Czy masz konfigurację AWS 'access_key_id' i' secret_access_key' w konfiguracji heroku? Musisz tylko upewnić się, że twoje konto użytkownika ma "Zasady dostępu" ustawione w konsoli IAM. Zobacz to, aby uzyskać więcej informacji: https://github.com/thoughtbot/paperclip/wiki/Paperclip-with-Amazon-S3 –

+0

@KMRakibulIslam Dzięki za odpowiedź! Właściwie to nie próbuję tego na Heroku; Właśnie pracuję przy moim localhost. Myślę, że brakuje mi niezbędnej "Polityki dostępu" w konsoli IAM. Jakie zasady powinienem przypisać użytkownikowi? 'AmazonsS3FullAccess?' – neanderslob

+0

tak, to powinno działać. –

Odpowiedz

4

Nie powinieneś naprawdę potrzebować Admin Access, aby to osiągnąć. Upewnij się, że masz konfigurację AWS access_key_id i secret_access_key w swojej konfiguracji heroku. Należy również upewnić się, że konto użytkownika ma zestaw Access Policy w konsoli AWS IAM.

Aby uzyskać więcej informacji, zobacz numer this post.

Domyślnym uprawnieniem dla spinacza jest :public_read, chyba że podasz wiadro jako prywatne.

Zobacz to dla informacji o Module: Paperclip::Storage::S3

+1

Skończyło się ustawienie AmazonS3FullAccess dla użytkownika i działało jak urok. Gdybym był partycjonowany z innymi zasobnikami, sądzę, że mógłbym precyzyjniej doskonalić politykę, tworząc niestandardową, ale to zadziała na razie. Dzięki! – neanderslob

+0

Brzmi świetnie! Dzięki :) –

6

Jak wyjaśniono w przyjętym odpowiedź, nie ma potrzeby „Admin Access”. Jednak typowa polityka udostępniania dostępu do zasobnika, udokumentowana w przykładach podanych przez Amazon, nie mogła wystarczyć na spinacz.

Poniższa polityka pracował dla mnie:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "s3:GetBucketLocation", 
       "s3:ListAllMyBuckets" 
      ], 
      "Resource": "arn:aws:s3:::*" 
     }, 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "s3:ListBucket" 
      ], 
      "Resource": [ 
       "arn:aws:s3:::bucket-name-to-be-set-by-you" 
      ] 
     }, 
     { 
      "Effect": "Allow", 
      "Action": "s3:*", 
      "Resource": [ 
       "arn:aws:s3:::bucket-name-to-be-set-by-you/*" 
      ] 
     } 
    ] 
} 
6

Żadna z istniejących odpowiedzi rzeczywiście stwierdzić, które zasady trzeba przyznać, więc oto one: s3:PutObject, s3:DeleteObject i s3:PutObjectAcl.

Oto pełna polityka S3 wiadro Używam aby umożliwić spinacza umieścić obiekty z pozwoleniem :public_read:

{ 
    "Version": "2008-10-17", 
    "Statement": [ 
     { 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "arn:aws:iam::IAM_USER_ID:user/IAM_USER_NAME" 
      }, 
      "Action": [ 
       "s3:PutObject", 
       "s3:DeleteObject", 
       "s3:PutObjectAcl" 
      ], 
      "Resource": "arn:aws:s3:::S3_BUCKET_NAME/*" 
     } 
    ] 
}