fmorg-git commented on PR #9223: URL: https://github.com/apache/ozone/pull/9223#issuecomment-3483085043
> Thanks for writing this up @fmorg-git. Overall looks good, but we should add more details about how the Ranger and Native authorizers fit in with this. > > Additionally, we need to choose how much development can/should happen on master vs. a feature branch. For Ranger integration within the OM, as long as it is not connected to a client facing API, that should be fine to go into the master branch if it helps iterate with Ranger devs quicker. > > Once the endpoint to consume and process tokens is added, that should probably be in a feature branch. We try to keep master releasable and have had issues with security related features being partially developed on master in the past. See [CVE-2024-45106](https://www.cve.org/CVERecord?id=CVE-2024-45106). hi @errose28, thanks for your comments. From our call today, it was decided: 1) All code (even Ranger interface updates) will go into a feature branch - @errose28 already created it called HDDS-13323-sts. The reason is to prevent (potential) security issues from getting out and causing issues before full end-to-test tests are run. @fmorg-git will need to remember to periodically ask a committer to rebase master so the feature branch doesn't get too far out of date. The design doc is fine to go to master. 2) OzoneNativeAuthorizer is not a part of phase 1 and we can take a look at supporting it in a future phase. RangerOzoneAuthorizer has more alignment with IAM policy. Also OzoneNativeAuthorizer doesn't have roles. 3) @errose28 is ok with having a table of revoked tokens as he doesn't see another way to support it currently and customers might not like if we have no way to revoke. Also he mentioned MinIO has revoke as well. Per discussion with @sodonnel, he is not against having table of revoked tokens. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
