flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-3930) Implement Service-Level Authorization
Date Wed, 19 Oct 2016 23:31:58 GMT

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

ASF GitHub Bot commented on FLINK-3930:
---------------------------------------

Github user vijikarthi commented on the issue:

    https://github.com/apache/flink/pull/2425
  
    Thanks @mxm for the review. I will incorporate your feedback and attach the patch.
    
    >
    When security is enabled, encryption should also be turned on by default. Otherwise we
will transmit plain-text passwords over the wire.
    
    Yes it makes sense. I will make a conditional check and throw an error if encryption is
not enabled when security is enabled?
    
    >
    Should there be too modes for network transmission, 1) with cookie, one without? Do we
need 32 bits for the cookie length? We should be precise about the maximum length. I saw it
is set to 1024 in other places.
    
    Yes, max cookie length validation is 1024. I will change the code where the buffer length
was allocated to a high value, instead it will use the byte array length read from the message.

    
    > 
    Should we really always send the cookie for every message? The security document mentions
in T2-3 that we only want to authorize upon the first connection.
    
    Yes, we took the approach to pass secure cookie for every message to keep minimal changes
to the current design
    
    >
    Why do we transmit the cookie to the client? This seems like a major security concern.
The client should always provide the cookie.
        edit: I see this has been specified in the document in T2-4. Still, I wonder if it
would make sense to simply add this now because the workaround to fetch the cookie from the
JobManager doesn't look appealing.
    
    Good catch. I forgot to revert the code after the merge and it is not required. Will fix
it. 
    
    >
    You added a Yarn specific cookie option which should be part of the general options instead.
    
    It is added since secure cookie can be supplied when using both Yarn session CLI as well
as Flink CLI. I have provided detailed explanation in one of the comments.
    
    >
    You've introduce a new config file to persist the app state. We already have the Yarn
properties file for that.
    
    I have provided explanation on why we need new config file in one of the comments. Please
take a look.


> Implement Service-Level Authorization
> -------------------------------------
>
>                 Key: FLINK-3930
>                 URL: https://issues.apache.org/jira/browse/FLINK-3930
>             Project: Flink
>          Issue Type: New Feature
>          Components: Security
>            Reporter: Eron Wright 
>            Assignee: Vijay Srinivasaraghavan
>              Labels: security
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> _This issue is part of a series of improvements detailed in the [Secure Data Access|https://docs.google.com/document/d/1-GQB6uVOyoaXGwtqwqLV8BHDxWiMO2WnVzBoJ8oPaAs/edit?usp=sharing]
design doc._
> Service-level authorization is the initial authorization mechanism to ensure clients
(or servers) connecting to the Flink cluster are authorized to do so.   The purpose is to
prevent a cluster from being used by an unauthorized user, whether to execute jobs, disrupt
cluster functionality, or gain access to secrets stored within the cluster.
> Implement service-level authorization as described in the design doc.
> - Introduce a shared secret cookie
> - Enable Akka security cookie
> - Implement data transfer authentication
> - Secure the web dashboard



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

Mime
View raw message