NihalJain commented on code in PR #5606: URL: https://github.com/apache/hbase/pull/5606#discussion_r1443800969
########## src/main/asciidoc/_chapters/hbase-default.adoc: ########## @@ -1949,6 +1949,34 @@ If the DFSClient configuration `simple` +[[hbase.security.authentication.ui.metrics.protected]] +*`hbase.security.authentication.ui.metrics.protected`*:: ++ +.Description + + Controls whether or not metrics endpoints are allowed only for admin. + If true, only users listed on "hbase.security.authentication.spnego.admin.users" + or users in group listed on "hbase.security.authentication.spnego.admin.groups" + are allowed to access metrics endpoints. (e.g. /jmx, /metrics, /prometheus) + ++ +.Default +`false` + + +[[hbase.security.authentication.spnego.kerberos.endpoint.whitelist]] Review Comment: Was going through hadoop PR. This property has been implemented in hadoop to handle any endpoint irrespective of whether it is metrics or something else. Why don't we follow same approach.? Do we really need to handle just metrics endpoint and have the other property `hbase.security.authentication.ui.metrics.protected`? The property name looks redundant. A generic implementation like the one in hadoop sound more useful to me. Also the name of the config will confuse others. As it seems like a generic whitelist. ########## src/main/asciidoc/_chapters/hbase-default.adoc: ########## @@ -1949,6 +1949,34 @@ If the DFSClient configuration `simple` +[[hbase.security.authentication.ui.metrics.protected]] +*`hbase.security.authentication.ui.metrics.protected`*:: ++ +.Description + + Controls whether or not metrics endpoints are allowed only for admin. + If true, only users listed on "hbase.security.authentication.spnego.admin.users" + or users in group listed on "hbase.security.authentication.spnego.admin.groups" + are allowed to access metrics endpoints. (e.g. /jmx, /metrics, /prometheus) + ++ +.Default +`false` + + +[[hbase.security.authentication.spnego.kerberos.endpoint.whitelist]] Review Comment: Was going through hadoop PR. This property has been implemented in hadoop to handle any endpoint irrespective of whether it is metrics or something else. Why don't we follow same approach.? Do we really need to handle just metrics endpoint and have the other property `hbase.security.authentication.ui.metrics.protected`? The property will become redundant. A generic implementation like the one in hadoop sound more useful to me. Also the name of the config will confuse others. As it seems like a generic whitelist. -- 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...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
