[
https://issues.apache.org/jira/browse/HDDS-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabian Morgan updated HDDS-15137:
---------------------------------
Description:
In order to restrict STS tokens on a fine-grained basis by action, each S3 api
needs to be associated with an S3 action. For example, both *HeadObject* and
*GetObject* S3 apis are associated with "s3:GetObject" action. The actions
will not have the s3: prefix when used internally in Ozone and Ranger.
Most apis have a 1-1 mapping with api and action like the *HeadObject* and
*GetObject* apis mentioned previously. In order to avoid having to update
multiple call sites, an *S3GActionIamMapper* is introduced to leverage the
already existing api audit functionality and map api names to actions in a
thread local (*S3Authentication.getS3Action()*). Then in
*OmMetadataReader.checkAcls()*, the *maybeAttachS3ActionFromThreadLocal*
function is used to read the thread local and set the s3Action in the
RequestContext if it exists.
However, *CopyObject* and *UploadPartCopy* are special cases. There is no
"s3:CopyObject" nor "s3:UploadPartCopy" action, but rather they both require
"s3:GetObject" action on the source object and "s3:PutObject" action on the
destination object. For these special cases, a helper method
*runWithS3ActionString* is introduced in *EndpointBase.java* so the proper
permissions can be checked on the source and on the destination by temporarily
overriding the value in the thread local while the operation is invoked, then
setting it back to the previous value when done.
Additionally, this ticket contains additional fixes found after testing with
these new changes. For example, since we now have fine-grained actions, we no
longer need to distinguish listing files permission vs download files
permission with LIST acl vs READ acl. Both apis can use READ acl.
was:
In order to restrict STS tokens on a fine-grained basis by action, each S3 api
needs to be associated with an S3 action. For example, both *HeadObject* and
*GetObject* S3 apis are associated with "s3:GetObject" action. The actions
will not have the s3: prefix when used internally in Ozone and Ranger.
Most apis have a 1-1 mapping with api and action like the *HeadObject* and
*GetObject* apis mentioned previously. In order to avoid having to update
multiple call sites, an *S3GActionIamMapper* is introduced to leverage the
already existing api audit functionality and map api names to actions in a
thread local (*S3Authentication.getS3Action()*). Then in
*OmMetadataReader.checkAcls()*, the *maybeAttachS3ActionFromThreadLocal*
function is used to read the thread local and set the s3Action in the
RequestContext if it exists.
However, *CopyObject* and *UploadPartCopy* are special cases. There is no
"s3:CopyObject" nor "s3:UploadPartCopy" action, but rather they both require
"s3:GetObject" action on the source object and "s3:PutObject" action on the
destination object. For these special cases, a helper method
*runWithS3ActionString* is introduced in *EndpointBase.java* so the proper
permissions can be checked on the source and on the destination by temporarily
overriding the value in the thread local while the operation is invoked, then
setting it back to the previous value when done.
Additionally, this ticket contains additional fixes found after testing with
these new changes.
> [STS] Ensure each S3 API has an associated S3 Action
> ----------------------------------------------------
>
> Key: HDDS-15137
> URL: https://issues.apache.org/jira/browse/HDDS-15137
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Fabian Morgan
> Assignee: Fabian Morgan
> Priority: Major
> Labels: pull-request-available
>
> In order to restrict STS tokens on a fine-grained basis by action, each S3
> api needs to be associated with an S3 action. For example, both *HeadObject*
> and *GetObject* S3 apis are associated with "s3:GetObject" action. The
> actions will not have the s3: prefix when used internally in Ozone and
> Ranger.
> Most apis have a 1-1 mapping with api and action like the *HeadObject* and
> *GetObject* apis mentioned previously. In order to avoid having to update
> multiple call sites, an *S3GActionIamMapper* is introduced to leverage the
> already existing api audit functionality and map api names to actions in a
> thread local (*S3Authentication.getS3Action()*). Then in
> *OmMetadataReader.checkAcls()*, the *maybeAttachS3ActionFromThreadLocal*
> function is used to read the thread local and set the s3Action in the
> RequestContext if it exists.
> However, *CopyObject* and *UploadPartCopy* are special cases. There is no
> "s3:CopyObject" nor "s3:UploadPartCopy" action, but rather they both require
> "s3:GetObject" action on the source object and "s3:PutObject" action on the
> destination object. For these special cases, a helper method
> *runWithS3ActionString* is introduced in *EndpointBase.java* so the proper
> permissions can be checked on the source and on the destination by
> temporarily overriding the value in the thread local while the operation is
> invoked, then setting it back to the previous value when done.
> Additionally, this ticket contains additional fixes found after testing with
> these new changes. For example, since we now have fine-grained actions, we
> no longer need to distinguish listing files permission vs download files
> permission with LIST acl vs READ acl. Both apis can use READ acl.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
