accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4421) TraceServer should fall back to GENERIC_KERBEROS_PRINCIPAL when trace specific kerberos settings are not present
Date Thu, 25 Aug 2016 05:17:20 GMT

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

Sean Busbey commented on ACCUMULO-4421:
---------------------------------------

Digging into this, a run through of what happens with some questions

1) we have a means to say how authentication for the tracer should happen, TRACE_TOKEN_TYPE,
which defaults to user/pass and our instructions say to change to KerberosToken when Accumulo
is using Kerberos to handle clients
2) on service start, we look for kerberos configs and  ignore TRACE_TOKEN_TYPE
3) if there is a trace-specific or general keytab, we get the TRACE_USER (without any _HOST
expansion, presumably UGI does this for us?) and try to log in.
4) on just the tracer, we use some UGI side effect to do the renewal thread. on others we
start our own?
5) On TraceServer object init, we check if we have the default TRACE_TOKEN_TYPE and then look
for TRACE_USER and (after a fashion) TRACE_PASSWORD 
6) For non-default TRACE_TOKEN_TYPE (like KerberosToken), then we rely on creation via reflection
of the class and a call to init. KerberosToken is essentially a no-op for “there is a logged
in kerberos user”, which happened in #3 above and presumably we assume downstream applications
would do their own UGI logins (is there a reason the UGI / Login stuff can't happen in the
KerberosToken itself?)
7) If RPC SASL is on, we do _HOST substitution in TRACE_USER before opening our connection;
I presume so it will match the user identified in the KerberosToken. (does this break things
if SASL isn’t using GSSAPI? should this be checking the TRACE_TOKEN_TYPE instead of the
rpc sasl, or maybe in addition to it?)

I think #2 above is the source of my problem, since I have Kerberos on for services like HDFS,
but not for Accumulo clients (e.g. as a step in upgrading Accumulo from 1.6 on a secure HDFS
cluster prior to rolling out kerberos for accumulo clients).

If I change this to check for TRACE_TOKEN_TYPE as kerberos prior to selecting the TRACE_USER
instead of GENERIC_KERBEROS_PRINCIPAL I *think* this will be operationally compatible for
folks already relying on the current behavior.

> TraceServer should fall back to GENERIC_KERBEROS_PRINCIPAL when trace specific kerberos
settings are not present
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-4421
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4421
>             Project: Accumulo
>          Issue Type: Bug
>          Components: trace
>    Affects Versions: 1.7.1, 1.7.2
>            Reporter: Sean Busbey
>            Assignee: Sean Busbey
>            Priority: Blocker
>             Fix For: 1.8.0
>
>         Attachments: ACCUMULO-4421.1.patch
>
>
> Prior to 1.7, the TraceServer always started using the same server utils as the other
daemons. Since a trace server has to talk to Accumulo and that might involve needing a Kerberos
Identity in 1.7+, it was switched to its own setup.
> Currently that setup will default back to GENERIC_KERBEROS_KEYTAB if a keytab isn't specified
for the trace user, but it will simply exit early if there isn't a principal defined for hte
trace user. It should instead default to the GENERIC_KERBEROS_PRINCIPAL.



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

Mime
View raw message