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

Jonathan Maron commented on YARN-2554:
--------------------------------------

Let me try to address each of these concerns:

- the key-store needs to present on all machine to distribute certificates: AMs 
may come up anywhere.

The client trust store appears to an already defined keystore in the secure 
deployments I've seen so far.

- the key-store used by Hadoop daemons CANNOT be shared with AMs: AMs run 
user-code as the user
- the key-store cannot be shared across AMs of different users: Assuming I am 
running three different Slider apps as three different users, you don't want to 
have a single key-store instance accessible by all Slider AMs.

Your concern about sharing elements between daemon processes and users is 
correct in the context of kerberos - principals are used for authentication and 
authorization and it wouldn't be prudent to have those shared.  When code is 
running within an AM, the identity that is established and governs its 
authorized interactions is done via kerberos.  But SSL is a security offering 
targeted for the transport layer.  Typically with SSL, for client C and server 
S, SSL only establishes that:

C believes S is who it intended to contact
C believes it has a secure connection to S
S believes it has a secure connection to C

In addition, typically SSL ensures authentication of the server alone (the CN 
is generally the host name), so the trust between C and S is more along the 
lines of trusting the C is actually talking to host S.  The session key for the 
RM (C) and AM (S), given the host certificate of the AM, will be unique - it is 
created by the RM, encrypted using the AM cert (using the AM public key), and 
sent to the AM to be decrypted by the AM's private key.  I guess I don't see 
the issue with hadoop applications, whether daemon or AM, using the available 
hadoop keystores.  The tranport layer mechanism doesn't play a role in the 
application level authorization since it has no role to play in establishing 
the user's subject etc.

Having said all that, I may not be aware of some uses of the keystores in a 
hadoop cluster (or perhaps my assumption about the availability of  a client 
trust store is wrong).  In addition, it'd be nice to get the perspective of 
some of the security folks about the role of SSL in the security layers 
provided in a secure cluster.


> Slider AM Web UI is inaccessible if HTTPS/SSL is specified as the HTTP policy
> -----------------------------------------------------------------------------
>
>                 Key: YARN-2554
>                 URL: https://issues.apache.org/jira/browse/YARN-2554
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: webapp
>    Affects Versions: 2.6.0
>            Reporter: Jonathan Maron
>         Attachments: YARN-2554.1.patch, YARN-2554.2.patch, YARN-2554.3.patch, 
> YARN-2554.3.patch
>
>
> If the HTTP policy to enable HTTPS is specified, the RM and AM are 
> initialized with SSL listeners.  The RM has a web app proxy servlet that acts 
> as a proxy for incoming AM requests.  In order to forward the requests to the 
> AM the proxy servlet makes use of HttpClient.  However, the HttpClient 
> utilized is not initialized correctly with the necessary certs to allow for 
> successful one way SSL invocations to the other nodes in the cluster (it is 
> not configured to access/load the client truststore specified in 
> ssl-client.xml).   I imagine SSLFactory.createSSLSocketFactory() could be 
> utilized to create an instance that can be assigned to the HttpClient.
> The symptoms of this issue are:
> AM: Displays "unknown_certificate" exception
> RM:  Displays an exception such as "javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target"



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

Reply via email to