You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by "Johny Rufus (JIRA)" <ji...@apache.org> on 2015/03/05 06:00:40 UTC

[jira] [Updated] (FLUME-2631) End to End authentication in Flume

     [ https://issues.apache.org/jira/browse/FLUME-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johny Rufus updated FLUME-2631:
-------------------------------
    Attachment: FLUME-2631-2.patch

Updated the file in the review request, uploading here as well

> 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-1.patch, FLUME-2631-2.patch, 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)