[
https://issues.apache.org/jira/browse/FLUME-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14336047#comment-14336047
]
Hari Shreedharan commented on FLUME-2631:
-----------------------------------------
/cc [~mpercy], [~jarcec] - I'd like it if you guys took a look as well. The
implementation seems reasonable, but what I worry about is the hadoop-common
dependency (and its dependencies) getting pulled in.
> End to End authentication in Flume
> -----------------------------------
>
> Key: FLUME-2631
> URL: https://issues.apache.org/jira/browse/FLUME-2631
> Project: Flume
> Issue Type: New Feature
> Components: Sinks+Sources
> Reporter: Johny Rufus
> Assignee: Johny Rufus
> Fix For: v1.6.0
>
> Attachments: FLUME-2631.patch
>
>
> 1. The idea is to enable authentication primarily by using
> SASL/GSSAPI/Kerberos with Thrift RPC. [Thrift already has support for SASL
> api that supports kerberos, so implementing right now for Thrift. For Avro
> RPC kerberos support, Avro needs to support SASL first for its Netty Server,
> before we can use it in flume]
> 2. Authentication will happen hop to hop[Client to source, intermediate
> sources to sinks, final sink to destination].
> 3. As per the initial model, the user principals won’t be carried forward.
> The flume client[ThriftRpcClient] will authenticate itself to the KDC. All
> the intermediate agents [Thrift Sources/Sinks] will authenticate as principal
> ‘flume’ (typically, but this can be any valid principal that KDC can
> autenticate) to each other and the final agent will authenticate to the
> destination as the principal it wishes to identify to the destination
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
