[
https://issues.apache.org/jira/browse/HDDS-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18090905#comment-18090905
]
Emil Kleszcz commented on HDDS-15620:
-------------------------------------
Thanks [~adoroszlai], that makes sense. I agree this may be expected if
read-only admins are intended mainly for object/namespace ACL bypass, for
example, {_}READ{_}, {_}LIST{_}, and {_}READ_ACL{_}, rather than for every
read/status command under {_}ozone admin{_}. One concern I still have is the
naming and operational boundary. From an operator's PoV, commands under _ozone
admin_ look like administrative commands, so it is not obvious that some of
them are available to any authenticated user admitted by the service ACLs.
Maybe we could even consider changing the nomenclature of these commands from
admin to _ozone <command>,_ e.g. _ozone om roles_.
This may be fine, but I think it should be documented explicitly. For example,
the docs could clarify that:
* _ozone.readonly.administrators*_ applies to read-only administrative access
where the server-side code explicitly checks this role, mainly object/namespace
read ACL bypass and selected SCM read-admin RPCs
* some _ozone admin_ read/status commands are intentionally available to
authenticated users allowed by service/protocol ACLs
* state-changing admin commands still require full admin privileges
It may also be useful to classify _ozone admin_ subcommands into:
* available to authenticated cluster users
* read-only admin required
* full admin required
This would avoid confusion for operators trying to validate whether read-only
admin configuration is working as expected.
> Ozone admin read/status commands bypass read-only admin authorization
> ---------------------------------------------------------------------
>
> Key: HDDS-15620
> URL: https://issues.apache.org/jira/browse/HDDS-15620
> Project: Apache Ozone
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Emil Kleszcz
> Priority: Major
>
> In a secure Kerberized Ozone cluster, some {{ozone admin}} read/status
> commands can be executed by an authenticated user that is not configured as a
> full Ozone administrator and is not a member of the configured read-only
> administrator group.
> Example configuration:
> {code:java}
> <property>
> <name>ozone.security.enabled</name>
> <value>true</value>
> </property>
> <property>
> <name>ozone.acl.enabled</name>
> <value>true</value>
> </property>
> <property>
> <name>ozone.acl.authorizer.class&lt;/name>
> <value>org.apache.hadoop.ozone.security.acl.OzoneNativeAuthorizer</value>
> </property>
> <property>
> <name>ozone.administrators</name>
> <value>ozone</value>
> </property>
> <property>
> <name>ozone.readonly.administrators.groups</name>
> <value>ozone-readonly-admins</value>
> </property>
> {code}
> The tested user is authenticated with Kerberos and allowed by the
> service/protocol ACLs, but is not a full admin and is not a member of
> {{{}ozone-readonly-admins{}}}.
> These commands succeed for the non-admin user:
> {code:java}
> ozone admin om roles
> ozone admin scm roles
> ozone admin datanode list
> ozone admin safemode status
> {code}
> The same user is correctly denied for object access and state-changing admin
> operations:
> {code:java}
> ozone sh key list /user/<other-user>
> # PERMISSION_DENIED
> ozone sh volume create /test-volume
> # PERMISSION_DENIED
> ozone admin safemode exit
> # Access denied for user <user>. SCM superuser privilege is required.
> {code}
> So this does not appear to expose full admin privileges. State-changing admin
> operations are denied correctly.
> From checking the source code, these read/status paths do not appear to
> perform method-level checks against either _ozone.administrators_ or
> {_}ozone.readonly.administrators{_}:
> * _ozone admin om roles_
> ** _GetServiceRolesSubcommand_
> ** _OzoneManagerProtocol.getServiceList()_
> ** _OzoneManagerRequestHandler.getServiceList()_
> ** _OzoneManager.getServiceList()_
> * _ozone admin scm roles_
> ** _GetScmRatisRolesSubcommand_
> ** _ScmClient.getScmRoles()_
> ** _SCMClientProtocolServer.getScmInfo()_
> * _ozone admin datanode list_
> ** _ListInfoSubcommand_
> ** _ScmClient.queryNode(...)_
> ** _SCMClientProtocolServer.queryNode(...)_
> * _ozone admin safemode status_
> ** _SafeModeCheckSubcommand_
> ** _ScmClient.inSafeMode()_
> ** _SCMClientProtocolServer.inSafeMode()_
> By contrast, _ozone admin safemode exit_ calls
> {_}SCMClientProtocolServer.forceExitSafeMode(){_}, which checks SCM admin
> privileges and denies the same user.
> I also could not find direct authorization test coverage for these commands.
> There are functional tests for some of them, but not tests asserting the
> expected behaviour for:
> * full admin
> * read-only admin
> * authenticated non-admin
> *Clarification:*
> Is this expected behaviour?
> If yes, it would be useful to clarify in the documentation that some _ozone
> admin_ read/status commands are available to authenticated users admitted by
> the service/protocol ACLs, and are not controlled by
> {_}ozone.readonly.administrators{_}. Ref.
> [https://ozone.apache.org/docs/administrator-guide/configuration/security/administrators/#read-only-ozone-administrators]
> If not, should these commands be protected by explicit full-admin or
> read-only-admin checks?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
