Author: buildbot
Date: Tue Dec 2 21:03:57 2014
New Revision: 931421
Log:
Staging update by buildbot for slider
Modified:
websites/staging/slider/trunk/content/ (props changed)
websites/staging/slider/trunk/content/design/ssl_implementation.html
websites/staging/slider/trunk/content/images/agent_am_two_way_ssl.png
Propchange: websites/staging/slider/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Dec 2 21:03:57 2014
@@ -1 +1 @@
-1641948
+1643005
Modified: websites/staging/slider/trunk/content/design/ssl_implementation.html
==============================================================================
--- websites/staging/slider/trunk/content/design/ssl_implementation.html
(original)
+++ websites/staging/slider/trunk/content/design/ssl_implementation.html Tue
Dec 2 21:03:57 2014
@@ -172,8 +172,9 @@ Latest release: <strong>0.60.0-incubatin
<p>As the Slider application master starts up it leverages the certificate
manager to ensure that the resources required to support SSL transport - the
server certificate, the key store, and the truststore - are available. The
certificate manager will create these artifacts if necessary (see figure 1).</p>
<p><img alt="Server Certificate Generation"
src="../images/server_cert_gen.png" /></p>
<p>Figure 1 - Server Certificate and Keystore/Trustore Generation</p>
-<h3 id="agent-https-server">Agent HTTPS Server</h3>
-<p>Once the artifacts necessary for supporting SSL transport are available,
the agent-facing HTTP server instance is created and started. This instance
creates two SSL connectors. The first connector is always configured for
one-way SSL and supports server liveness checks from the agents, the retrieval
of the server certificate, and the creation of signed agent certificates (the
latter two tasks are required for the two-way SSL support). The second
connector provides the port over which agent registration and heart beats are
transmitted. It is configured for one-way SSL by default but can be explicitly
configured for two-way SSL (hence the need for a certificate exchange mechanism
as detailed above). Figure 2 illustrates this startup sequence.</p>
+<p>In addition, if two-way SSL is enabled (more on that later), the Slider
application master will leverage the certificate manager to create client
certificates for every container launched as part of the application. These
certificates, along with the AM's certificate, will subsequently be seeded to
the given container's host machine via Yarn's resource localization
facilities.</p>
+<h3 id="agent-facing-https-server">Agent-facing HTTPS Server</h3>
+<p>Once the artifacts necessary for supporting SSL transport are available,
the agent-facing HTTP server instance is created and started. This instance
creates two SSL connectors. The first connector is always configured for
one-way SSL and supports server liveness checks from the agents. The second
connector provides the port over which agent registration and heart beats are
transmitted. It is configured for one-way SSL by default but can be explicitly
configured for two-way SSL (hence the need for a certificate seeding mechanism
as detailed above). Figure 2 illustrates this startup sequence.</p>
<p><img alt="Agent HTTPS server" src="../images/server_ssl_startup.png" /></p>
<p>Figure 2 - Server Agent-facing HTTP Server Initialization</p>
<h2 id="agent-communication-modes">Agent Communication Modes</h2>
@@ -194,14 +195,7 @@ Latest release: <strong>0.60.0-incubatin
<p><img alt="One-way SSL" src="../images/agent_am_one_way_ssl.png" /></p>
<p>Figure 3 - Agent to AM One-way SSL Communication</p>
<h3 id="two-way-ssl">Two-way SSL</h3>
-<p>The setup for two-way SSL is more involves since both parties must have
each others certificates available to establish the trust required for this
authentication mechanism. Therefore, in between the liveness check and
registration performed in the one-way SSL mode, the agent and application
master perform some additional steps to setup their certificate stores:</p>
-<ol>
-<li>The agent downloads the application master's certificate using the one-way
SSL port</li>
-<li>The agent generates a key</li>
-<li>The agent uploads the key and requests a signed certificate from the
application master</li>
-<li>The application master signs the key, creates a certificate, and returns
it in the response to the client. It also store the certificate in its
keystore/truststore.</li>
-</ol>
-<p>After this exchange of information, the two parties are configured for
communication over the configured two-way SSL port. See Figure 4 for an
illustration of this exchange.</p>
+<p>The setup for two-way SSL is more involved since both parties must have
each other's certificates available to establish the trust required for this
authentication mechanism. Therefore, the Application Master seeds both the
AM's certificate (trust store) and the client's certificate (key store) to the
host machine as the container is being instantiated. Therefore, the two
parties are configured for communication over the configured two-way SSL port.
See Figure 4 for an illustration of this setup.</p>
<p><img alt="Two-way SSL" src="../images/agent_am_two_way_ssl.png" /></p>
<p>Figure 3 - Agent to AM Two-way SSL Communication</p>
<p>Note that two-way SSL is enabled by setting a property
("ssl.server.client.auth") for the slider application master in the application
configuration:</p>
Modified: websites/staging/slider/trunk/content/images/agent_am_two_way_ssl.png
==============================================================================
Binary files - no diff available.
