HBASE-17115 Define UI admins via an ACL #936
Conversation
|
Testing I've done:
If admins are set, that will limit who can interact with sensitive endpoints. Setting readonly=true will further restrict the system and disallow anyone (including admins) from modifying hbase via the UI. I think this maintains all of the previous semantics folks would expect, while letting the security-conscious lock things down. |
This comment has been minimized.
This comment has been minimized.
hbase/hbase-http/src/main/java/org/apache/hadoop/hbase/http/HttpServer.java Lines 681 to 683 in 978546b The logs servlet already had the AdminAuthorizedServlet in the chain; it was just ineffective because we weren't configuring/setting an
Good catch! Was missing this, will fix.
I'm not finding this, @busbey . I need to go looking to see if this is a branch-specific feature. |
joshelser
force-pushed
the
17115-webui-acls
branch
from
e64d118
to
987ecd5
Compare
This comment has been minimized.
This comment has been minimized.
|
Turns out I'm still missing the critical bits for everything besides the |
This comment has been minimized.
This comment has been minimized.
|
I just need to write a UT to cover this stuff. Just realized I hadn't done that. |
|
Alright, I think the last commit does this right now. There was a problem in my previous patches in that the API I added -- trying to have I added some more unit tests which show that both the contexts (e.g.
|
|
💔 -1 overall
This message was automatically generated. |
|
Poking around at a local install -- looks like the DumpServlet is now requiring admins even when auth'n for the UI is off :) |
hbase-http/src/main/java/org/apache/hadoop/hbase/http/HttpServer.java
Outdated
Show resolved
Hide resolved
hbase-http/src/main/java/org/apache/hadoop/hbase/http/HttpServer.java
Outdated
Show resolved
Hide resolved
The Hadoop AccessControlList allows us to specify admins of the webUI via a list of users and/or groups. Admins of the WebUI can mutate the system, potentially seeing sensitive data or modifying the system. hbase.security.authentication.spnego.admin.users is a comma-separated list of users who are admins. hbase.security.authentication.spnego.admin.groups is a comma-separated list of groups whose membership are admins. Either of these configuration properties may also contain an asterisk (*) which denotes "anything" (any user or group). To maintain previous semantics, the UI defaults to accepting any user as an admin. Previously, when a user was denied from some endpoint that was designated for admins, they received an HTTP/401. In this case, it is more correct to return HTTP/403 as they were correctly authenticated, but they were disallowed from fetching the given resource. The test is based off of work by Nihal Jain in HBASE-20472. Co-authored-by: Nihal Jain <nihaljain.cs@gmail.com>
* Expand on javadoc for add[Un]PrivilegedServlet method(s) * Expand on the securing the webUI section of the book
Make sure the DumpServlet is protected.
joshelser
force-pushed
the
17115-webui-acls
branch
from
7555d72
to
1733ec1
Compare
|
Rebase'd on top of master and made |
| addServlet("jmx", "/jmx", JMXJsonServlet.class); | ||
| addServlet("conf", "/conf", ConfServlet.class); | ||
| addPrivilegedServlet("jmx", "/jmx", JMXJsonServlet.class); | ||
| addUnprivilegedServlet("conf", "/conf", ConfServlet.class); |
There was a problem hiding this comment.
So /conf can also have secrets potentially? Assuming this picks up all the core-site, hdfs-site confs as well. it could technically have things not secured via hadoop credential stores.
There was a problem hiding this comment.
sure, but in a "properly" secured system they'd all be behind Hadoop Credential Providers right?
There was a problem hiding this comment.
If we add the conf endpoint the privileged list, we should make it optional to keep it unprivileged. I know some systems that rely on reading the conf end point to automate configuring clients.
There was a problem hiding this comment.
Sure but the concerns about jmx/metrics and host/ports/usernames applies to conf.
There was a problem hiding this comment.
host/ports/usernames applies to conf
There's a difference between well-known daemons (what should be in conf/) and HBase clients. We shouldn't be advertising to the world who is talking to HBase.
in a "properly" secured system they'd all be behind Hadoop Credential Providers right?
I agree with Busbey here -- I don't think there's a case where we should expect to have unprotected secrets in the configuration. However, I will concede that folks may do this anyways. I'll add a default-false option to protect the conf endpoint, just in case.
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
Any more requests on this? |
|
HBASE-20950 isn't contained on branch-2.1 which means I have to fix up TestInfoServersAcl. |
|
Submitted to all 2.x branches and master, after getting HBASE-20950 also backported to branch-2.1. 1.x needs some help with precommit before this change can land there. |
The Hadoop AccessControlList allows us to specify admins of the webUI
via a list of users and/or groups. Admins of the WebUI can mutate the
system, potentially seeing sensitive data or modifying the system.
hbase.security.authentication.spnego.admin.users is a comma-separated
list of users who are admins.
hbase.security.authentication.spnego.admin.groups is a comma-separated
list of groups whose membership are admins. Either of these
configuration properties may also contain an asterisk (*) which denotes
"anything" (any user or group).
To maintain previous semantics, the UI defaults to accepting any user as an
admin. Previously, when a user was denied from some endpoint that was
designated for admins, they received an HTTP/401. In this case, it is
more correct to return HTTP/403 as they were correctly authenticated,
but they were disallowed from fetching the given resource.
The test is based off of work by Nihal Jain in HBASE-20472.
Co-authored-by: Nihal Jain nihaljain.cs@gmail.com