S3 버킷 정책과 IAM 역할이 충돌 함

Question

S3 버킷 정책을 사용하여 버킷에 일반 액세스를 제공하는 동시에 역할 정책을 사용하여 특정 역할에 액세스를 허용하려고합니다. 역할은 람다 함수가 버킷의 객체를 처리하는 데 사용됩니다. 첫 번째 장애물에서 멈추고 있습니다 - 롤 정책에서 허용되지만 접두사 정책에서 명시 적으로 거부되지는 않았지만 접두사 "incoming /"이있는 항목을 얻을 수 없습니다.

역할 정책 :

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "AllowBucketPut", 
      "Effect": "Allow", 
      "Action": [ 
       "s3:PutObject" 
      ], 
      "Resource": "arn:aws:s3:::bucket-name/*" 
     }, 
     { 
      "Sid": "AllowIncomingGetDelete", 
      "Effect": "Allow", 
      "Action": [ 
       "s3:GetObject", 
       "s3:DeleteObject" 
      ], 
      "Resource": "arn:aws:s3:::bucket-name", 
      "Condition": { 
       "StringLike": { 
        "s3:prefix": "incoming/*" 
       } 
      } 
     } 
    ] 
} 

참고 : ": AWS : * S3 ::: 버킷 이름/수신 ARN"만 방법을 변경 듯 나는 또한 조건을 제거하고 자원을 변경하려 정책 시뮬레이터가 작동했습니다. 또 다른 참고 사항 : "incoming/*"접두사가있는 버킷에서 GET하면 시뮬레이터에서 작동하지만 실제로는 그렇지 않습니다.

나는 무엇이 관련이 있을지 모르므로 아래의 버킷 정책에서 어떠한 진술도 삭제하지 않았습니다. IP 주소가 생략되었습니다.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "AllowPublicList", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:ListBucket", 
      "Resource": "arn:aws:s3:::bucket-name", 
      "Condition": { 
       "StringLike": { 
        "s3:prefix": "public*" 
       } 
      } 
     }, 
     { 
      "Sid": "AllowPublicGet", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:GetObject", 
      "Resource": "arn:aws:s3:::bucket-name/public*" 
     }, 
     { 
      "Sid": "AllowPrivateList", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:ListBucket", 
      "Resource": "arn:aws:s3:::bucket-name", 
      "Condition": { 
       "StringLike": { 
        "s3:prefix": "private*" 
       }, 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "..." 
        ] 
       } 
      } 
     }, 
     { 
      "Sid": "AllowPrivateGet", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:GetObject", 
      "Resource": "arn:aws:s3:::bucket-name/private*", 
      "Condition": { 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "..." 
        ] 
       } 
      } 
     }, 
     { 
      "Sid": "AllowIncomingPut", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:PutObject", 
      "Resource": "arn:aws:s3:::bucket-name/incoming*", 
      "Condition": { 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "..." 
        ] 
       } 
      } 
     } 
    ] 
} 

텍스트의 벽에 사과드립니다.

내 역할이 접두사 "수신 /"으로 된 개체를 가져올 수없는 이유를 모르겠습니다. 할 때

람다 기능은 403 액세스가 거부지고 다음

S3.download_file(bucket, key, localfile) 

Answer 1

당신이 버킷 정책에 아래 문을 추가하려고 할 수 있습니까?

{ 
     "Sid": "AllowIncomingGet", 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "*" 
     }, 
     "Action": "s3:GetObject", 
     "Resource": "arn:aws:s3:::bucket-name/incoming/*", 
     "Condition": { 
      "IpAddress": { 
       "aws:SourceIp": [ 
        "..." 
       ] 
      } 
     } 
    } 

Answer 2

는 문서 (http://docs.aws.amazon.com/AmazonS3/latest/dev/amazon-s3-policy-keys.html)에 따르면, 상기 조건은 s3:prefix ListBucket 동작에 프리픽스를 지정하는 발신자 강제 만 s3:ListBucket API에 적용된다. GetObject API 호출에는 적용되지 않습니다. 당신이 효과적으로되지 않도록, : 그 때문에의

("접두어 S3"이러한 요청이 정책의 키를 포함하지 않기 때문에!) s3:prefix == ... 어떤 GET (객체) 요청과 일치하지 않습니다 조건 GetObject에 당신의 Allow 역할 정책에서 이러한 요청을 허용합니다. 버킷 정책에 대한 요청을 허용하지 않고 어디에서나 Deny 문이 없기 때문에 람다 코드는 이 암시 적으로으로 거부되었습니다.

정책 시뮬레이터에서 설명한대로 "Resource": "arn:aws:s3:::bucket-name/incoming/*"과 같이 Resource을 대신 사용해야합니다.

또한 정책을 정확하게 지정하는 이유가있을 수 있지만 약간 이상한 것으로 보입니다. 일반적으로 접두어를 설명하려는 경우 S3 관련 정책에 "Resource" 요소가 있습니다. 단지 ...incoming* 대신에 ...incoming/*과 같은 것입니다. 이것은 예기치 않은 결과를 예방할 수 있습니다. 예를 들어, incoming/이라는 폴더가 있고 나중에 incoming-top-secret/이라는 폴더를 만들었다 고 가정 해보십시오. 정책을 작성한 방식으로 두 접두사에 모두 액세스 할 수 있습니다. 그러나 다시 한번 - 환경의 정확한 세부 사항을 정확히 알지 못해 진정으로 필요한 것을 말할 수 없습니다. 단지 당신 (그리고이 책을 읽는 다른 누군가)이이 미묘한 (그러나 중요한) 세부 사항을 알고 있는지 확인하고 싶었습니다!

내가 준 설명에 따라 생각해 볼 수 있습니다. 이러한 변경을 시도해도 여전히 작동하지 않으면 시도한 새 정책에 따라 질문을 업데이트하십시오.행운을 빕니다!