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....@example.com
<mailto:mas3.example....@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('cent...@example.com <mailto:cent...@example.com>', {})
Where I've created the principal cent...@example.com
<mailto:cent...@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....@example.com' but
was 'cent...@example.com <mailto:cent...@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....@example.com
<mailto:mas3.example....@example.com>' but was 'cent...@example.com
<mailto:cent...@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