smengcl commented on PR #4538: URL: https://github.com/apache/ozone/pull/4538#issuecomment-1689853668
> > The impact on tenant getsecret could be a deal-breaker. See: > > [#4538 (comment)](https://github.com/apache/ozone/pull/4538#discussion_r1161453347) > > The best course of action in this PR is to allow `tenant user getsecret` to behave as-is by checking whether the `accessId` belongs to a tenant. (And maybe tackle that later on in another PR if necessary @prashantpogde ) > > IMO, it's preferred to keep the behaviour consistent across both `getsecret` requests. As tenant user getsecret always returns a pre-existing secret, can we remove TenantGetSecretHandler instead? Problem is, removing `ozone tenant user getsecret` will break _part of_ the existing Ozone tenant user assign flow. Here's how tenant user assignment is supposed to work right now: 1. Ozone (tenant) admin `alice` assign a new user `bob` to a tenant. **Secret is generated** for user `bob` in this tenant **already** at this point. Also see: https://ozone.apache.org/docs/1.3.0/feature/s3-tenant-commands.html#assign-a-user-to-a-tenant ```bash bash-4.2$ ozone tenant user assign testuser --tenant=tenantone export AWS_ACCESS_KEY_ID='tenantone$testuser' export AWS_SECRET_ACCESS_KEY='<GENERATED_SECRET>' ``` 2. If user `bob` is able to authenticate via Kerberos, he would do `kinit`, then use `ozone tenant user getsecret` command to get his tenant secret to be used in S3 Gateway. As you can see, removing `ozone tenant user getsecret` prevents `bob` or any Kerberos user from getting his own S3 secret after an admin assigns him to the tenant. If we remove it, the only option left would be to ask admin `alice` to send the secret to `bob` over some third-party channels (email / Slack / whatever). -- 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: issues-unsubscr...@ozone.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org For additional commands, e-mail: issues-h...@ozone.apache.org
