HDDS-15064. [STS] Artifacts for Ranger to Consider S3 Action when Authorizing

[fmorg-git]

Please describe your PR in detail:

• Currently, ACLs used by Ozone and Ranger are not granular enough. For example, read on volume, read on bucket, and write on key can be used by either s3:PutObjectTagging or s3:DeleteObjectTagging. Similarly, because s3:PutObject requires read on volume, read on bucket, and create and write on key, someone with s3:PutObject access can also call s3:PutObjectTagging (as an example). To prevent having more access than requested (or different access than requested), we need a means of restricting the ACL permissions further by S3 actions.
  To do this, we introduce an s3Action field in RequestContext so that if populated, the RangerOzoneAuthorizer would further restrict the permissions according to the S3 action.
  Additionally, the OzoneGrant would contain a Set representing the S3 actions that are allowed for an inline policy. If all actions are allowed, then the Set would be empty (or null).

• This PR is to pull same commit from the master branch (HDDS-15064. [STS] Artifacts for Ranger to Consider S3 Action when Authorizing #10108) into Ozone 2.1 release branch so Ranger team can use it upstream in next Ozone release (2.1.1). It also required a prerequisite separate commit because of the refactoring done: HDDS-14104. Refactor RequestContext creation #9493

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15064

How was this patch tested?

smoke tests in feature branch

[fmorg-git]

hi @ChenSammi @jojochuang - this PR is ready for review. Thanks!

[smengcl]

lgtm pending CI

Note this is a backport of #10108 to the 2.1.x branch.

[smengcl]

Uh-oh, I realized this has two commits. Because upstream PR here only allow squash merging, you need to raise backport for HDDS-14104 first, then this one HDDS-15064 . Otherwise two commits would get squashed into one (when merged via Github UI).

[fmorg-git]

Uh-oh, I realized this has two commits. Because upstream PR here only allow squash merging, you need to raise backport for HDDS-14104 first, then this one HDDS-15064 . Otherwise two commits would get squashed into one (when merged via Github UI).

Hi @smengcl , thanks for explaining (I wasn't sure how to handle the prerequisite commit). I created a PR for the prerequisite commit here: #10319

[smengcl]

Thanks @fmorg-git . Now that #10319 is merged, pls rebase this one (different commit hash might have caused the conflict. you can drop HDDS-14104 from the PR chain and rebase on top of latest ozone-2.1)

[fmorg-git]

Thanks @fmorg-git . Now that #10319 is merged, pls rebase this one (different commit hash might have caused the conflict. you can drop HDDS-14104 from the PR chain and rebase on top of latest ozone-2.1)

hi @smengcl - I just did the rebase. Thanks.

[adoroszlai]

Uh-oh, I realized this has two commits. Because upstream PR here only allow squash merging, you need to raise backport for HDDS-14104 first, then this one HDDS-15064 . Otherwise two commits would get squashed into one (when merged via Github UI).

We usually backport commits in batch to reduce overhead, and push the branch from CLI to avoid squash. See #8211 for example, with instructions on how to push in #8211 (comment).

[smengcl]

Uh-oh, I realized this has two commits. Because upstream PR here only allow squash merging, you need to raise backport for HDDS-14104 first, then this one HDDS-15064 . Otherwise two commits would get squashed into one (when merged via Github UI).

We usually backport commits in batch to reduce overhead, and push the branch from CLI to avoid squash. See #8211 for example, with instructions on how to push in #8211 (comment).

Thanks @adoroszlai .

I thought about that. Since it has only 2 commits I figured it might be good enough to backport one by one.

[smengcl]

lgtm

[fmorg-git]

Thanks all for the review and merge.