[jira] [Updated] (HDDS-14804) [STS] Part 3 - IAM Session Policy and List Bucket Improvements
[ https://issues.apache.org/jira/browse/HDDS-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabian Morgan updated HDDS-14804: - Resolution: Not A Problem Status: Resolved (was: Patch Available) > [STS] Part 3 - IAM Session Policy and List Bucket Improvements > -- > > Key: HDDS-14804 > URL: https://issues.apache.org/jira/browse/HDDS-14804 > Project: Apache Ozone > Issue Type: Sub-task >Reporter: Fabian Morgan >Assignee: Fabian Morgan >Priority: Major > Labels: pull-request-available > > We need to be able to tell whether an S3 STS call is authorized for listing > files in a bucket only vs being able to download a file, because those are > different actions in S3 (ListBucket vs GetObject). To differentiate, use > *LIST* at key/object level for listing permission and use *READ* at > key/object level for downloading permission. Currently, the > *OmMetadataReader* authorizes only *READ* at key level for the listing > operations. In order to not break existing functionality, have STS-specific > checks that authorize against *LIST* permission instead. Further, because of > how shallow listing works, in some cases (ex. root listing with a delimiter), > it loses the context of what the original prefix was on the S3 request. For > STS authorization, we need this original prefix, so introduce an optional > listPrefix in the protocol to support this. > Here are a quick summary of the total requisite changes: > 1. Support passing list prefix on root listing so STS can authorize against > it. > 2. Filter out non-ListBucket actions (ex GetObject, PutObject, > ListBucketMultipartUploads, etc) when Conditions are present since we only > support s3:prefix Condition and s3:prefix is only applicable for ListBucket > and ListBucketVersions (we don't support this). > 3. Keep track of the operator (i.e. StringEquals or StringLike) when using > conditions. If the operator is StringEquals and a wildcard (* or ?) is used, > ignore that condition since Ranger can’t authorize against literal asterisk > or question mark. > 4. Change ListBucket to validate LIST permission on the object instead of > READ so we can determine if we should allow listing the object or downloading > the object (READ would be for downloading). > This part 3 is to change the IAM Session Policy Resolver to validate LIST > permission on the key for ListBucket action instead of READ. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
[jira] [Updated] (HDDS-14804) [STS] Part 3 - IAM Session Policy and List Bucket Improvements
[ https://issues.apache.org/jira/browse/HDDS-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HDDS-14804: -- Labels: pull-request-available (was: ) > [STS] Part 3 - IAM Session Policy and List Bucket Improvements > -- > > Key: HDDS-14804 > URL: https://issues.apache.org/jira/browse/HDDS-14804 > Project: Apache Ozone > Issue Type: Sub-task >Reporter: Fabian Morgan >Assignee: Fabian Morgan >Priority: Major > Labels: pull-request-available > > We need to be able to tell whether an S3 STS call is authorized for listing > files in a bucket only vs being able to download a file, because those are > different actions in S3 (ListBucket vs GetObject). To differentiate, use > *LIST* at key/object level for listing permission and use *READ* at > key/object level for downloading permission. Currently, the > *OmMetadataReader* authorizes only *READ* at key level for the listing > operations. In order to not break existing functionality, have STS-specific > checks that authorize against *LIST* permission instead. Further, because of > how shallow listing works, in some cases (ex. root listing with a delimiter), > it loses the context of what the original prefix was on the S3 request. For > STS authorization, we need this original prefix, so introduce an optional > listPrefix in the protocol to support this. > Here are a quick summary of the total requisite changes: > 1. Support passing list prefix on root listing so STS can authorize against > it. > 2. Filter out non-ListBucket actions (ex GetObject, PutObject, > ListBucketMultipartUploads, etc) when Conditions are present since we only > support s3:prefix Condition and s3:prefix is only applicable for ListBucket > and ListBucketVersions (we don't support this). > 3. Keep track of the operator (i.e. StringEquals or StringLike) when using > conditions. If the operator is StringEquals and a wildcard (* or ?) is used, > ignore that condition since Ranger can’t authorize against literal asterisk > or question mark. > 4. Change ListBucket to validate LIST permission on the object instead of > READ so we can determine if we should allow listing the object or downloading > the object (READ would be for downloading). > This part 3 is to change the IAM Session Policy Resolver to validate LIST > permission on the key for ListBucket action instead of READ. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
[jira] [Updated] (HDDS-14804) [STS] Part 3 - IAM Session Policy and List Bucket Improvements
[ https://issues.apache.org/jira/browse/HDDS-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabian Morgan updated HDDS-14804: - Summary: [STS] Part 3 - IAM Session Policy and List Bucket Improvements (was: [STS] - Part 3 IAM Session Policy and List Bucket Improvements) > [STS] Part 3 - IAM Session Policy and List Bucket Improvements > -- > > Key: HDDS-14804 > URL: https://issues.apache.org/jira/browse/HDDS-14804 > Project: Apache Ozone > Issue Type: Sub-task >Reporter: Fabian Morgan >Assignee: Fabian Morgan >Priority: Major > > We need to be able to tell whether an S3 STS call is authorized for listing > files in a bucket only vs being able to download a file, because those are > different actions in S3 (ListBucket vs GetObject). To differentiate, use > *LIST* at key/object level for listing permission and use *READ* at > key/object level for downloading permission. Currently, the > *OmMetadataReader* authorizes only *READ* at key level for the listing > operations. In order to not break existing functionality, have STS-specific > checks that authorize against *LIST* permission instead. Further, because of > how shallow listing works, in some cases (ex. root listing with a delimiter), > it loses the context of what the original prefix was on the S3 request. For > STS authorization, we need this original prefix, so introduce an optional > listPrefix in the protocol to support this. > Here are a quick summary of the total requisite changes: > 1. Support passing list prefix on root listing so STS can authorize against > it. > 2. Filter out non-ListBucket actions (ex GetObject, PutObject, > ListBucketMultipartUploads, etc) when Conditions are present since we only > support s3:prefix Condition and s3:prefix is only applicable for ListBucket > and ListBucketVersions (we don't support this). > 3. Keep track of the operator (i.e. StringEquals or StringLike) when using > conditions. If the operator is StringEquals and a wildcard (* or ?) is used, > ignore that condition since Ranger can’t authorize against literal asterisk > or question mark. > 4. Change ListBucket to validate LIST permission on the object instead of > READ so we can determine if we should allow listing the object or downloading > the object (READ would be for downloading). > This part 3 is to change the IAM Session Policy Resolver to validate LIST > permission on the key for ListBucket action instead of READ. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
[jira] [Updated] (HDDS-14804) [STS] - Part 3 IAM Session Policy and List Bucket Improvements
[ https://issues.apache.org/jira/browse/HDDS-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabian Morgan updated HDDS-14804: - Status: Patch Available (was: In Progress) > [STS] - Part 3 IAM Session Policy and List Bucket Improvements > -- > > Key: HDDS-14804 > URL: https://issues.apache.org/jira/browse/HDDS-14804 > Project: Apache Ozone > Issue Type: Sub-task >Reporter: Fabian Morgan >Assignee: Fabian Morgan >Priority: Major > > We need to be able to tell whether an S3 STS call is authorized for listing > files in a bucket only vs being able to download a file, because those are > different actions in S3 (ListBucket vs GetObject). To differentiate, use > *LIST* at key/object level for listing permission and use *READ* at > key/object level for downloading permission. Currently, the > *OmMetadataReader* authorizes only *READ* at key level for the listing > operations. In order to not break existing functionality, have STS-specific > checks that authorize against *LIST* permission instead. Further, because of > how shallow listing works, in some cases (ex. root listing with a delimiter), > it loses the context of what the original prefix was on the S3 request. For > STS authorization, we need this original prefix, so introduce an optional > listPrefix in the protocol to support this. > Here are a quick summary of the total requisite changes: > 1. Support passing list prefix on root listing so STS can authorize against > it. > 2. Filter out non-ListBucket actions (ex GetObject, PutObject, > ListBucketMultipartUploads, etc) when Conditions are present since we only > support s3:prefix Condition and s3:prefix is only applicable for ListBucket > and ListBucketVersions (we don't support this). > 3. Keep track of the operator (i.e. StringEquals or StringLike) when using > conditions. If the operator is StringEquals and a wildcard (* or ?) is used, > ignore that condition since Ranger can’t authorize against literal asterisk > or question mark. > 4. Change ListBucket to validate LIST permission on the object instead of > READ so we can determine if we should allow listing the object or downloading > the object (READ would be for downloading). > This part 3 is to change the IAM Session Policy Resolver to validate LIST > permission on the key for ListBucket action instead of READ. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
