Odmowa dostępu dla ListObjects dla zasobnika S3, gdy uprawnienia to s3: *

Staje się:

Wystąpił błąd (odmowa dostępu) podczas wywoływania operacji ListObjects: odmowa dostępu

Kiedy próbuję pobrać folder z mojego wiadra S3.

Za pomocą tego polecenia:

aws s3 cp s3://bucket-name/data/all-data/ . --recursive

Uprawnienia do zasobnika wyglądają następująco:

{
"Version": "version_id",
"Statement": [
    {
        "Sid": "some_id",
        "Effect": "Allow",
        "Action": [
            "s3:*"
        ],
        "Resource": [
            "arn:aws:s3:::bucketname/*"
        ]
    }
] }

Co muszę zmienić, aby móc copyi lsskutecznie?

Dałeś pozwolenie na wykonywanie poleceń na obiektach wewnątrz zasobnika S3, ale nie udzieliłeś pozwolenia na wykonywanie jakichkolwiek działań na samym zasobniku.

Nieznaczna modyfikacja polityki wyglądałaby następująco:

{
  "Version": "version_id",
  "Statement": [
    {
        "Sid": "some_id",
        "Effect": "Allow",
        "Action": [
            "s3:*"
        ],
        "Resource": [
            "arn:aws:s3:::bucketname",
            "arn:aws:s3:::bucketname/*"
        ]
    }
  ] 
}

Jednak prawdopodobnie daje to więcej uprawnień niż jest to potrzebne. Zgodnie z najlepszą praktyką AWS IAM przyznawania najmniejszych uprawnień wyglądałoby to mniej więcej tak:

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Effect": "Allow",
          "Action": [
              "s3:ListBucket"
          ],
          "Resource": [
              "arn:aws:s3:::bucketname"
          ]
      },
      {
          "Effect": "Allow",
          "Action": [
              "s3:GetObject"
          ],
          "Resource": [
              "arn:aws:s3:::bucketname/*"
          ]
      }
  ]
}

Jeśli chcesz skopiować wszystkie obiekty zasobnika s3 za pomocą polecenia „aws s3 cp s3: // nazwa-zasobnika / dane / wszystkie-dane /. --Recursive”, jak wspomniałeś, oto bezpieczna i minimalna zasada, aby to zrobić:

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Effect": "Allow",
          "Action": [
              "s3:ListBucket"
          ],
          "Resource": [
              "arn:aws:s3:::bucket-name"
          ],
          "Condition": {
              "StringLike": {
                  "s3:prefix": "data/all-data/*"
              }
          }
      },
      {
          "Effect": "Allow",
          "Action": [
              "s3:GetObject"
          ],
          "Resource": [
              "arn:aws:s3:::bucket-name/data/all-data/*"
          ]
      }
  ]
}

Pierwsza instrukcja w tej polityce pozwala na umieszczenie obiektów w podkatalogu określonego zasobnika. Zasób musi być arn segmentu S3, a aby ograniczyć wyświetlanie tylko do podkatalogu w tym segmencie, można edytować wartość „s3: prefix”.

Druga instrukcja w tej polityce umożliwia pobieranie obiektów do zasobnika w określonym podkatalogu. Oznacza to, że wszystko w ścieżce „s3: // nazwa-zasobnika / dane / wszystkie-dane /” będzie można skopiować. Pamiętaj, że nie pozwala to na kopiowanie ze ścieżek nadrzędnych, takich jak „s3: // nazwa-zasobnika / dane /”.

To rozwiązanie jest specyficzne dla ograniczania użycia poleceń AWS CLI; jeśli chcesz ograniczyć dostęp S3 za pośrednictwem konsoli AWS lub interfejsu API, potrzebnych będzie więcej zasad. Proponuję zajrzeć tutaj: https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/ .

Podobny problem do tego można znaleźć tutaj, co doprowadziło mnie do rozwiązania, które podaję. https://github.com/aws/aws-cli/issues/2408

Mam nadzieję że to pomoże!

Musisz określić zasób dla zasobnika za pomocą "arn:aws:s3:::bucketname"lub "arn:aws:3:::bucketname*". Ta ostatnia jest preferowana, ponieważ umożliwia również manipulowanie przedmiotami wiadra. Zwróć uwagę, że nie ma ukośnika!

Lista obiektów to operacja na Bucket. Dlatego "s3:ListBucket"konieczne jest podjęcie działań . Dodanie obiektu do Bucket jest operacją na Object. Dlatego "s3:PutObject"potrzebne jest działanie . Z pewnością możesz chcieć dodać inne akcje, jeśli potrzebujesz.

{
"Version": "version_id",
"Statement": [
    {
        "Sid": "some_id",
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket",
            "s3:PutObject"
        ],
        "Resource": [
            "arn:aws:s3:::bucketname*"
        ]
    }
] 
}

Nie mogłem uzyskać dostępu do S3, ponieważ

• najpierw skonfigurowałem dostęp do klucza na instancji (nie można było wtedy dołączyć roli po uruchomieniu)
• zapomniałem o tym na kilka miesięcy
• dołączona rola do instancji
• próbował uzyskać dostęp. Skonfigurowany klucz miał wyższy priorytet niż rola i odmówiono dostępu, ponieważ użytkownikowi nie przyznano niezbędnych uprawnień S3.

Rozwiązanie: rm -rf .aws/credentialsnastępnie awsużywa roli.

Wystąpił ten sam błąd podczas korzystania z zasad jak poniżej, chociaż mam „s3: ListBucket” dla operacji s3: ListObjects.

{
"Version": "2012-10-17",
"Statement": [
    {
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
        ],
        "Resource": [
            "arn:aws:s3:::<bucketname>/*",
            "arn:aws:s3:::*-bucket/*"
        ],
        "Effect": "Allow"
    }
  ]
 }

Następnie naprawiłem to, dodając jedną linię „arn: aws: s3 ::: bucketname”

{
"Version": "2012-10-17",
"Statement": [
    {
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
        ],
        "Resource": [
             "arn:aws:s3:::<bucketname>",
            "arn:aws:s3:::<bucketname>/*",
            "arn:aws:s3:::*-bucket/*"
        ],
        "Effect": "Allow"
    }
 ]
}

Wydawało mi się, że błąd jest spowodowany akcją „s3: ListObjects”, ale musiałem dodać akcję „s3: ListBucket”, aby rozwiązać problem „Odmowa dostępu do zasobnika ListObjects dla S3”

Miałem ten sam problem. Właśnie dodałem konfigurację poświadczeń:

aws_access_key_id = your_aws_access_key_id
aws_secret_access_key = your_aws_secret_access_key

do "~ / .aws / credentials" + zrestartuj terminal dla profilu domyślnego.

W przypadku wielu profili --profile arg należy dodać:

aws s3 sync ./localDir s3://bucketName --profile=${PROFILE_NAME}

gdzie PROFILE_NAME :

.bash_profile ( or .bashrc) -> export PROFILE_NAME="yourProfileName"

Więcej informacji na temat konfigurowania poświadczeń i wielu profili można znaleźć tutaj

Wypróbowałem następujące:

aws s3 ls s3.console.aws.amazon.com/s3/buckets/{bucket name}

To dało mi błąd:

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Korzystanie z tego formularza zadziałało:

aws s3 ls {bucket name}

Wpadłem na podobne problemy, dla mnie problem polegał na tym, że miałem różne klucze AWS ustawione w moim bash_profile.

Odpowiedziałem na podobne pytanie tutaj: https://stackoverflow.com/a/57317494/11871462

Jeśli masz sprzeczne klucze AWS w swoim bash_profile, interfejs wiersza polecenia AWS domyślnie przyjmuje te.

Miałem ten problem i chciałem, aby użytkownik mógł pisać do określonej ścieżki

{
            "Sid": "raspiiotallowspecificBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<bucketname>/scripts",
                "arn:aws:s3:::<bucketname>/scripts/*"
            ]
        },

i problem został rozwiązany dzięki tej zmianie

{
            "Sid": "raspiiotallowspecificBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<bucketname>",
                "arn:aws:s3:::<bucketname>/*"
            ]
        },

Dodaję odpowiedź w tym samym kierunku, co zaakceptowana odpowiedź, ale z małymi (ważnymi) różnicami i dodaję więcej szczegółów.

Rozważ poniższą konfigurację:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<Bucket-Name>"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::<Bucket-Name>/*"]
    }
  ]
}

Polityka udziela programową zapisu usuwania dostępu i jest podzielony na dwie części: działanie zapewnia uprawnień na poziomie wiadro, a druga
ListBucketPutObject/DeleteObject działania wymagają uprawnienia na obiektach wewnątrz wiadra.

Pierwszy element Resource określa arn:aws:s3:::<Bucket-Name>dlaListBucket działania, dzięki czemu aplikacje mogą wymienić wszystkie obiekty w wiadrze.

Drugi element Resource określa arn:aws:s3:::<Bucket-Name>/*dla PutObjectiDeletObject działania dzięki czemu aplikacje mogą pisać lub usuwać żadnych obiektów w wiadrze.

Rozdzielenie na dwie różne „arny” jest ważne ze względów bezpieczeństwa w celu określenia szczegółowych uprawnień na poziomie zasobnika i obiektu.

Zauważ, że gdybym określił tylko GetObjectw drugim bloku, co by się stało, to w przypadku dostępu programistycznego otrzymałem błąd taki jak:

Upload failed: <file-name> to <bucket-name>:<path-in-bucket> An error occurred (AccessDenied) when calling the PutObject operation: Access Denied.

Podoba mi się to bardziej niż którakolwiek z poprzednich odpowiedzi. Pokazuje, jak używać formatu YAML i umożliwia użycie zmiennej do określenia zasobnika.

    - PolicyName: "AllowIncomingBucket"
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Action: "s3:*"
            Resource:
              - !Ref S3BucketArn
              - !Join ["/", [!Ref S3BucketArn, '*']]