accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Kerberos and the Accumulo Proxy
Date Tue, 26 Jan 2016 04:08:36 GMT
Hi Tristen,

I'm glad you found that issue. As much as I griped about it, I had 
completely forgotten about the issue. Sadly, it looks like that fix is 
already contained in 2.3.2.0[1] Your client code does look correct as 
well (compared to the tests for this[2]). There are some good Kerberos 
tests in the codebase if you know to look for 'em.

The error message is a bit confusing since it's a client (your python) 
talking to a client (the proxy) talking to the servers (Accumulo 
services). I think this error message is saying that the Proxy is 
failing to authenticate to Accumulo. This is about to get lengthy.

A little bit of background on how this is supposed to work which hinges 
on this fact: A Kerberos client's "secret" information is not made 
available to the server. This means that your client keytab is not made 
available to the Proxy server. The implications this creates for the use 
case you outline is that the Proxy server *cannot* make a connection to 
Accumulo on your behalf because Kerberos knows that the Proxy isn't 
actually you! (this is actually cool if you think about it).

This is where the Proxy impersonation configuration that Russ recently 
asked about comes into play. The common approach (e.g. Hive, HBase) is 
to configure Accumulo to "trust" the Proxy (identified by the Kerberos 
principal) to "act" as a different user. In other words, impersonation 
allows a client to authenticate to Accumulo as a different user than the 
client's Kerberos credentials says it is.

So, client <-> Proxy works like a normal connection. However, proxy <-> 
{tserver,master} has the connection set up as the Proxy's Kerberos 
identity, but Accumulo *allows* the Proxy to actually say that it is 
your client.

As such, your code is 100% correct, but it isn't going to work in the 
way you're trying to use it. If you want a centralized Proxy server 
instance, you'll need to set up impersonation. The other option is 
(which, I think it better since we don't have a good multi-tenancy story 
for the Proxy) is to run a Proxy server instance with your client 
Kerberos credentials instead of the "accumulo" principal. This gets 
around the problem because both the client and the Proxy act as "client" 
and you don't get the mismatch.

This got really long, and I'm sorry for that :). Let me know, I'd be 
happy to put some of this into the user manual if it's lacking.

- Josh

[1] 
https://github.com/hortonworks/accumulo-release/blob/HDP-2.3.2.0-tag/proxy/src/main/java/org/apache/accumulo/proxy/Proxy.java#L245-L248
[2] 
https://github.com/hortonworks/accumulo-release/blob/HDP-2.3.2.0-tag/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java

Tristen Georgiou wrote:
> I'm using Ambari 2.1.2.1, HDP 2.3.2 (so Accumulo 1.7.0) and I'm trying
> to get a Kerberized Accumulo proxy up and running; I can successully
> start the proxy, but I am having trouble connecting with it.
>
> Here is my Accumulo proxy properties file (I've censored my actual FQDN's):
>
> useMockInstance=false
> useMiniAccumulo=false
> protocolFactory=org.apache.thrift.protocol.TCompactProtocol$Factory
> tokenClass=org.apache.accumulo.core.client.security.tokens.KerberosToken
> port=42425
> maxFrameSize=16M
> thriftServerType=sasl
> kerberosPrincipal=accumulo/mas3.example.com@EXAMPLE.COM
> <mailto:mas3.example.com@EXAMPLE.COM>
> kerberosKeytab=/etc/security/keytabs/accumulo.service.keytab
> instance=agile_accumulo
> zookeepers=mas1.example.com:2181
> <http://mas1.example.com:2181/>,mas2.example.com:2181
> <http://mas2.example.com:2181/>,mas3.example.com:2181
> <http://mas3.example.com:2181/>
>
> The proxy starts up fine, and then via Python I am doing the following:
>
> transport =
> TTransport.TSaslClientTransport(TSocket.TSocket('mas3.example.com
> <http://mas3.example.com/>', 42425), 'mas3.example.com
> <http://mas3.example.com/>', 'accumulo', QOP='auth')
> protocol = TCompactProtocol.TCompactProtocol(transport)
> client = AccumuloProxy.Client(protocol)
> transport.open()
> login = client.login('central@EXAMPLE.COM <mailto:central@EXAMPLE.COM>', {})
>
> Where I've created the principal central@EXAMPLE.COM
> <mailto:central@EXAMPLE.COM> and have run kinit on the server where I am
> trying to connect to the proxy from (not from mas3)
>
> The proxy log responds with this:
>
> 2016-01-25 21:42:01,294 [proxy.ProxyServer] ERROR: Failed to login
> org.apache.accumulo.core.client.AccumuloSecurityException: Error
> BAD_CREDENTIALS for user Principal in credentials object should match
> kerberos principal. Expected 'accumulo/mas3.example.com@example.COM' but
> was 'central@EXAMPLE.COM <mailto:central@EXAMPLE.COM>' - Username or
> Password is Invalid
> at
> org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:63)
> at
> org.apache.accumulo.core.client.impl.ConnectorImpl.<init>(ConnectorImpl.java:67)
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getConnector(ZooKeeperInstance.java:248)
> at org.apache.accumulo.proxy.ProxyServer.getConnector(ProxyServer.java:232)
> at org.apache.accumulo.proxy.ProxyServer.login(ProxyServer.java:1574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:39)
> at org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy14.login(Unknown Source)
> at
> org.apache.accumulo.proxy.thrift.AccumuloProxy$Processor$login.getResult(AccumuloProxy.java:5723)
> at
> org.apache.accumulo.proxy.thrift.AccumuloProxy$Processor$login.getResult(AccumuloProxy.java:5707)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.UGIAssumingProcessor.process(UGIAssumingProcessor.java:102)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:225)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: ThriftSecurityException(user:Principal in credentials object
> should match kerberos principal. Expected
> 'accumulo/mas3.example.com@EXAMPLE.COM
> <mailto:mas3.example.com@EXAMPLE.COM>' but was 'central@EXAMPLE.COM
> <mailto:central@EXAMPLE.COM>', code:BAD_CREDENTIALS)
> at
> org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_result$authenticate_resultStandardScheme.read(ClientService.java:15613)
> at
> org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_result$authenticate_resultStandardScheme.read(ClientService.java:15591)
> at
> org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_result.read(ClientService.java:15535)
> at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
> at
> org.apache.accumulo.core.client.impl.thrift.ClientService$Client.recv_authenticate(ClientService.java:500)
> at
> org.apache.accumulo.core.client.impl.thrift.ClientService$Client.authenticate(ClientService.java:486)
> at
> org.apache.accumulo.core.client.impl.ConnectorImpl$1.execute(ConnectorImpl.java:70)
> at
> org.apache.accumulo.core.client.impl.ConnectorImpl$1.execute(ConnectorImpl.java:67)
> at
> org.apache.accumulo.core.client.impl.ServerClient.executeRaw(ServerClient.java:98)
> at
> org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:61)
> ... 22 more
>
> I've tried to update my configuration for impersonation but have had no
> luck; my colleague did send out an email to this list about questions to
> do with impersonation, so perhaps that is the problem.
>
> Otherwise, anyone see anything obviously wrong with what I'm doing?
> Could it be related to this:
> https://issues.apache.org/jira/browse/ACCUMULO-3849

Mime
View raw message