hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-13772) Replication endpoints should restrict access to a limited set of principals
Date Wed, 27 May 2015 00:07:18 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560141#comment-14560141
] 

Andrew Purtell edited comment on HBASE-13772 at 5/27/15 12:06 AM:
------------------------------------------------------------------

When security is enabled and the AccessController is installed, it mediates replication RPC
- AdminService#replicateWALEntry - and does not allow a sink to _receive_ WAL edits from non-superuser
principals not granted GLOBAL WRITE permissions. We are protected from rogue sources. I went
looking where we could add access control to core even if the AC is not installed. We could
have the core replication code set up a list of allowed principals and restrict connections
to this list (can be done in Replication), but the AC couldn't extend the set of allowed principals
without an API change somewhere. I think it is fine to not add access checks to core here
since the AC does provide coverage. Without the AccessController installed we don't check
 other RPC actions either. 

The other issue is rogue sinks. The RegionCoprocessorHost has a hook for intercepting ReplicationEndpoint
setup post creation (RegionServerObserver#postCreateReplicationEndPoint), but we are lacking
a preCreateReplicationEndPoint hook to make an authoritative decision on whether to allow
the endpoint to be created. We should add this hook (eventually) so random users cannot add
replication peers, but until we fix HBASE-13771 there's no opportunity to make an authoritative
decision. The regionserver reacts to replication peer coordination state in ZK, it doesn't
control it. We are running as the service principal and have no idea who might have added
the ZK state. When replication admin actions go through the master via admin RPC we can mediate
this in the AccessController and refuse to install endpoints for callers not granted sufficient
privileges.

Another possible option for defeating rogue sinks would be a check at connection setup that
the remote principal is in the allowed set. Our RPC doesn't support this, though. Our connection
security model is one way: The server checks if the client's principal is authorized to make
the current request. The client always assumes the server is trusted. The client does learn
the server's principal when setting up connections (and Kerberos mutual auth means the server
has proved it) but we do not expose that information in any API. We only pass this information
on to Java's SASL client. This is a bigger discussion than just replication. We have no support
to check if a server's principal is in an allowed set for a given client request. Another
way to state that is we don't have a client-side AccessController. 

For the purposes of this issue, I propose we fix HBASE-13771 and as part of that work add
a RegionServerObserver#preCreateReplicationEndPoint hook and support for it in the AccessController.
Then only admins could possibly install rogue peers. 


was (Author: apurtell):
When security is enabled and the AccessController is installed, it mediates replication RPC
- AdminService#replicateWALEntry - and does not allow a sink to _receive_ WAL edits from non-superuser
principals not granted GLOBAL WRITE permissions. We are protected from rogue sources. I went
looking where we could add access control to core even if the AC is not installed. We could
have the core replication code set up a list of allowed principals and restrict connections
to this list (can be done in Replication), but the AC couldn't extend the set of allowed principals
without an API change somewhere. I think it is fine to not add access checks to core here
since the AC does provide coverage. Without the AccessController installed we don't check
 other RPC actions either. 

The other issue is rogue sinks. The RegionCoprocessorHost has a hook for intercepting ReplicationEndpoint
setup post creation (RegionServerObserver#postCreateReplicationEndPoint), but we are lacking
a preCreateReplicationEndPoint hook to make an authoritative decision on whether to allow
the endpoint to be created. We should add this hook (eventually) so random users cannot add
replication peers, but until we fix HBASE-13771 there's no no opportunity to make an authoritative
decision. The regionserver reacts to replication peer coordination state in ZK, it doesn't
control it. We are running as the service principal and have no idea who might have added
the ZK state. When replication admin actions go through the master via admin RPC we can mediate
this in the AccessController and refuse to install endpoints for callers not granted sufficient
privileges.

Another possible option for defeating rogue sinks would be a check at connection setup that
the remote principal is in the allowed set. Our RPC doesn't support this, though. Our connection
security model is one way: The server checks if the client's principal is authorized to make
the current request. The client always assumes the server is trusted. The client does learn
the server's principal when setting up connections (and Kerberos mutual auth means the server
has proved it) but we do not expose that information in any API. We only pass this information
on to Java's SASL client. This is a bigger discussion than just replication. We have no support
in core or the AccessController to check if a server's principal is in an allowed set for
a given client request.

For the purposes of this issue, I propose we fix HBASE-13771 and as part of that work add
a RegionServerObserver#preCreateReplicationEndPoint hook and support for it in the AccessController.
Then only admins could possibly install rogue peers. 

> Replication endpoints should restrict access to a limited set of principals
> ---------------------------------------------------------------------------
>
>                 Key: HBASE-13772
>                 URL: https://issues.apache.org/jira/browse/HBASE-13772
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Replication endpoints will accept RPC connections from any Kerberos principal that is
trusted by the endpoint's local KDC. This is far too open and may allow for the establishment
of rogue endpoints (in conjunction with HBASE-13771). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message