svn commit: r1527593 - /incubator/knox/site/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html

[lm...@apache.org]

Author: lmccay
Date: Mon Sep 30 14:28:59 2013
New Revision: 1527593

URL: http://svn.apache.org/r1527593
Log:
publishing documentation for wildcards within ip addresses in ACL authorization

Modified:
    incubator/knox/site/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html

Modified: incubator/knox/site/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html
URL: http://svn.apache.org/viewvc/incubator/knox/site/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html?rev=1527593&r1=1527592&r2=1527593&view=diff
==============================================================================
--- incubator/knox/site/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html (original)
+++ incubator/knox/site/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html Mon Sep 30 14:28:59 2013
@@ -394,7 +394,7 @@ ip-10-39-107-209.ec2.internal
 <pre><code>keytool -genkey -keyalg RSA -alias gateway-identity -keystore gateway.jks -storepass {master-secret} -validity 360 -keysize 2048 
 </code></pre><p>Keytool will prompt you for a number of elements used that will comprise this distiniguished name (DN) within your certificate. </p><p><b>NOTE:</b> When it prompts you for your First and Last name be sure to type in the hostname of the machine that your gateway instance will be running on. This is used by clients during hostname verification to ensure that the presented certificate matches the hostname that was used in the URL for the connection - so they need to match.</p><p><b>NOTE:</b> When it prompts for the key password just press enter to ensure that it is the same as the keystore password. Which as was described earlier must match the master secret for the gateway instance.</p><h5><a id="Credential+Store"></a>Credential Store</h5><p>Whenever you provide your own keystore with either a self-signed cert or a real certificate signed by a trusted authority, you will need to create an empty credential store. This is necessary for the current release in order for th
 e system to utilize the same password for the keystore and the key.</p><p>The credential stores in Knox use the JCEKS keystore type as it allows for the storage of general secrets in addition to certificates.</p>
 <pre><code>keytool -genkey -alias {anything} -keystore __gateway-credentials.jceks -storepass {master-secret} -validity 360 -keysize 1024 -storetype JCEKS
-</code></pre><p>Follow the prompts again for the DN for the cert of the credential store. This certificate isn&rsquo;t really used for anything at the moment but is required to create the credential store.</p><h5><a id="Provisioning+of+Keystores"></a>Provisioning of Keystores</h5><p>Once you have created these keystores you must move them into place for the gateway to discover them and use them to represent its identity for SSL connections. This is done by copying the keystores to the {GATEWAY_HOME}/conf/security/keystores directory for your gateway install.</p><h4><a id="Summary+of+Secrets+to+be+Managed"></a>Summary of Secrets to be Managed</h4>
+</code></pre><p>Follow the prompts again for the DN for the cert of the credential store. This certificate isn&rsquo;t really used for anything at the moment but is required to create the credential store.</p><h5><a id="Provisioning+of+Keystores"></a>Provisioning of Keystores</h5><p>Once you have created these keystores you must move them into place for the gateway to discover them and use them to represent its identity for SSL connections. This is done by copying the keystores to the <code>{GATEWAY_HOME}/conf/security/keystores</code> directory for your gateway install.</p><h4><a id="Summary+of+Secrets+to+be+Managed"></a>Summary of Secrets to be Managed</h4>
 <ol>
   <li>Master secret - the same for all gateway instances in a cluster of gateways</li>
   <li>All security related artifacts are protected with the master secret</li>
@@ -487,7 +487,12 @@ ip-10-39-107-209.ec2.internal
     &lt;name&gt;{serviceName}.acl&lt;/name&gt;
     &lt;value&gt;username[,*|username...];group[,*|group...];ipaddr[,*|ipaddr...]&lt;/value&gt;
 &lt;/param&gt;
-</code></pre><p>where <code>{serverName}</code> would need to be the name of a configured Hadoop service within the topology. Note that the configuration without any ACLs defined is equivalent to:</p>
+</code></pre><p>where <code>{serverName}</code> would need to be the name of a configured Hadoop service within the topology.</p><p>NOTE: ipaddr is unique among the parts of the ACL in that you are able to specify a wildcard within an ipaddr to indicate that the remote address must being with the String prior to the asterisk within the ipaddr acl. For instance:</p>
+<pre><code>&lt;param&gt;
+    &lt;name&gt;{serviceName}.acl&lt;/name&gt;
+    &lt;value&gt;*;*;192.168.*&lt;/value&gt;
+&lt;/param&gt;
+</code></pre><p>This indicates that the request must come from an IP address that begins with &lsquo;192.168.&rsquo; in order to be granted access.</p><p>Note also that configuration without any ACLs defined is equivalent to:</p>
 <pre><code>&lt;param&gt;
     &lt;name&gt;{serviceName}.acl&lt;/name&gt;
     &lt;value&gt;*;*;*&lt;/value&gt;