4

Я занимаюсь некоторыми исследованиями, использующими S3. То, что я хотел бы получить, в основном контролирует доступ к объектам в ведро S3 таким же образом, как и в файловой системе, но для пользователей с интеграцией IAM.Ограничение доступа к Amazon S3 на уровне объекта для пользователей с интегрированным IAM

Давайте предположим следующий сценарий

Bucket 
    |- File 1.txt -> ACL: Read: User1; Read: User 2 
    |- File 2.txt -> ACL: Read: Everyone; Read, Write: User 2 
    |- File 3.txt -> ACL: Read: Group 1; Read, Write: User 2 

Этот вид конфигурации может быть достигнут с использованием списков контроля доступа и Amazon «родные» пользователей и групп. С другой стороны, для федеративного пользователя, единственного, что я смог найти, было создание временного токена с назначенной политикой ведра.

Если я правильно понимаю, ведро эзотерика работает в обратном направлении, чем ACL (определяет, к которым объекты пользователь имеет доступ, в то время как ACL определяет, кто имеет доступ к объекту)

Мой вопрос есть. Можно ли назначить федеративного пользователя в ACL (или достичь другой цели для всех пользователей федерации)?

Я хотел бы для того чтобы достигнуть такое же поведение, как в файловой системе, где у вас есть пользователи в группах и на объектах вы маркировки, какие группы имеют доступ к ним

Если предположить, что поле «х-АМЗ-мета- seclevels "содержит группы, которые имеют доступ к файлу (Group1, Group2, admin3rdfloor), с представленной политикой (которая не является правильной, но я хотел бы описать, что у меня на уме), прикрепленной к федеративному пользователю IAM, я мог бы предоставить этому пользователю доступ ко всем файлам, которые содержат значение admin3rdfloor в поле x-amz-meta-seclevels.

{ 
'Statement': [ 
    { 
     'Sid': 'PersonalBucketAccess', 
     'Action': [ 
      's3:GetObject' 
      ], 
     'Effect': 'Allow', 
     'Resource': 'arn:aws:s3:::MyBucketName' 
     'Condition':{ 
     'StringLike':{ 
      's3:x-amz-meta-seclevels':'admin3rdfloor' 
     } 
    } 

    } 
] 

}

Является ли это достижимо в любом случае?

Спасибо за помощь!

ответ

2

Если я понимаю нужную конфигурацию правильно, AWS, возможно, только что выпустила функцию, позволяющую этот сценарий, см Variables in AWS Access Control Policies:

AWS Identity and Access Management (IAM) позволяет создавать политики, которые контролируют доступ к API, служб AWS и ресурсов. Сегодня мы расширяем язык политики доступа AWS, чтобы включить поддержку переменных . Policy variables упростить создание и управление общих политик, которые включают индивидуальный контроль доступа.

Вот прилагаемый пример политика для регулярных IAM пользователей:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
     "Action": ["s3:ListBucket"], 
     "Effect": "Allow", 
     "Resource": ["arn:aws:s3:::myBucket"], 
     "Condition":{"StringLike": 
     {"s3:prefix":["home/${aws:username}/*"]}} 
    }, 
    { 
     "Action":["s3:GetObject", "s3:PutObject", "s3:DeleteObject*"], 
     "Effect":"Allow", 
     "Resource": ["arn:aws:s3:::myBucket/home/${aws:username}", 
     "arn:aws:s3:::myBucket/home/${aws:username}/*"] 
    } 
] 
} 

Хотя ${aws:username} включены в данном примере не доступны для федеративных пользователей (или предполагаемых ролей), существует еще одна переменной ${aws:userid}, которая будут заменены на account:caller-specified-name для соответствующих ${aws:principaltype}FederatedUser, - пожалуйста, обратитесь к таблице в пределах Request Information That You Can Use for Policy Variables для получения подробной информации о том, как эти переменные заменяются dependin г по основному типу.

+0

Если я правильно понимаю эту политику, я предоставляю $ {aws: username} доступ ко всем файлам в myBucket/home/$ {aws: username}/*, который не разрешает мою проблему. В моем случае все файлы находятся в одном ведре без папок. Полностью плоская структура. Я хотел бы создать политику для федеративных пользователей, которая позволит такому пользователю получить доступ только к подмножеству файлов на основе либо списков ACL, либо других настраиваемых метаданных, которые могут быть сопоставлены политикой. – Midi

+0

Вы нашли решение? У меня такая же проблема. – Arash

+0

@Arash: На самом деле я закончил с решением с созданием назначенного url каждый раз, когда пользователь обращается к файлу. Мы сохраняем метаданные файлов в SQL и имеем конечную точку, где пользователь запрашивает файл с указанием его метаданных. Мы проверяем, есть ли у него надлежащие права, и если все в порядке, мы перенаправляем его на сгенерированный назначенный URL. – Midi

Смежные вопросы