Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 27 May 2015 00:07:18 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12832546.1432574463000.33801.1432685238169@Atlassian.JIRA>
In-Reply-To: <JIRA.12832546.1432574463000@Atlassian.JIRA>
References: <JIRA.12832546.1432574463000@Atlassian.JIRA>
 <JIRA.12832546.1432574463439@arcas>
Subject: [jira] [Comment Edited] (HBASE-13772) Replication endpoints should
 restrict access to a limited set of principals
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)