Author: krisden
Date: Sun Mar 3 21:01:59 2019
New Revision: 1854743
URL: http://svn.apache.org/viewvc?rev=1854743&view=rev
Log:
KNOX-1796 - Update documentation with configurable TLS keystore information
(Robert Levas via Kevin Risden)
Modified:
knox/site/books/knox-1-3-0/user-guide.html
knox/site/index.html
knox/site/issue-management.html
knox/site/licenses.html
knox/site/mailing-lists.html
knox/site/project-info.html
knox/site/team.html
knox/trunk/books/1.3.0/config.md
Modified: knox/site/books/knox-1-3-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-1-3-0/user-guide.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/books/knox-1-3-0/user-guide.html (original)
+++ knox/site/books/knox-1-3-0/user-guide.html Sun Mar 3 21:01:59 2019
@@ -771,11 +771,6 @@ https://{gateway-host}:{gateway-port}/{g
<td><code>JKS</code></td>
</tr>
<tr>
- <td><code>gateway.keystore.type</code></td>
- <td>Indicates the type of keystore for the identity store</td>
- <td><code>JKS</code></td>
- </tr>
- <tr>
<td><code>gateway.jdk.tls.ephemeralDHKeySize</code></td>
<td><code>jdk.tls.ephemeralDHKeySize</code>, is defined to customize the
ephemeral DH key sizes. The minimum acceptable DH key size is 1024 bits, except
for exportable cipher suites or legacy mode
(<code>jdk.tls.ephemeralDHKeySize=legacy</code>)</td>
<td><code>2048</code></td>
@@ -826,16 +821,56 @@ https://{gateway-host}:{gateway-port}/{g
<td><code>false</code></td>
</tr>
<tr>
+ <td><code>gateway.tls.keystore.password.alias</code></td>
+ <td>OPTIONAL Alias for the password to the keystore file holding the
Gateway’s TLS certificate and keypair. NOTE: An alias with the provided
name should be created using <code>knoxcli.sh create-alias</code> inorder to
provide the password; else the master secret will be used.</td>
+ <td><code>gateway-identity-keystore-password</code></td>
+ </tr>
+ <tr>
+ <td><code>gateway.tls.keystore.path</code></td>
+ <td>OPTIONAL The path to the keystore file where the Gateway’s TLS
certificate and keypair are stored. If not set, the default keystore file will
be used - data/security/keystores/gateway.jks.</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td><code>gateway.tls.keystore.type</code></td>
+ <td>OPTIONAL The type of the keystore file where the Gateway’s TLS
certificate and keypair are stored. See
<code>gateway.tls.keystore.path</code>.</td>
+ <td><code>JKS</code></td>
+ </tr>
+ <tr>
+ <td><code>gateway.tls.key.alias</code></td>
+ <td>OPTIONAL The alias for the Gateway’s TLS certificate and
keypair within the default keystore or the keystore specified via
<code>gateway.tls.keystore.path</code>.</td>
+ <td><code>gateway-identity</code></td>
+ </tr>
+ <tr>
+ <td><code>gateway.tls.key.passphrase.alias</code></td>
+ <td>OPTIONAL The alias for passphrase for the Gateway’s TLS
private key stored within the default keystore or the keystore specified via
<code>gateway.tls.keystore.path</code>. NOTE: An alias with the provided name
should be created using <code>knoxcli.sh create-alias</code> inorder to provide
the password; else the keystore password or the master secret will be used. See
<code>gateway.tls.keystore.password.alias</code></td>
+ <td><code>gateway-identity-passphrase</code></td>
+ </tr>
+ <tr>
<td><code>gateway.signing.keystore.name</code></td>
<td>OPTIONAL Filename of keystore file that contains the signing
keypair. NOTE: An alias needs to be created using <code>knoxcli.sh
create-alias</code> for the alias name <code>signing.key.passphrase</code> in
order to provide the passphrase to access the keystore.</td>
<td>null</td>
</tr>
<tr>
+ <td><code>gateway.signing.keystore.password.alias</code></td>
+ <td>OPTIONAL Alias for the password to the keystore file holding the
signing keypair. NOTE: An alias with the provided name should be created using
<code>knoxcli.sh create-alias</code> inorder to provide the password; else the
master secret will be used.</td>
+ <td><code>signing.keystore.password</code></td>
+ </tr>
+ <tr>
+ <td><code>gateway.signing.keystore.type</code></td>
+ <td>OPTIONAL The type of the keystore file where the signing keypair is
stored. See <code>gateway.signing.keystore.name</code>.</td>
+ <td><code>JKS</code></td>
+ </tr>
+ <tr>
<td><code>gateway.signing.key.alias</code></td>
<td>OPTIONAL alias for the signing keypair within the keystore specified
via <code>gateway.signing.keystore.name</code></td>
<td>null</td>
</tr>
<tr>
+ <td><code>gateway.signing.key.passphrase.alias</code></td>
+ <td>OPTIONAL The alias for passphrase for signing private key stored
within the default keystore or the keystore specified via
<code>gateway.signing.keystore.name</code>. NOTE: An alias with the provided
name should be created using <code>knoxcli.sh create-alias</code> inorder to
provide the password; else the keystore password or the master secret will be
used. See <code>gateway.signing.keystore.password.alias</code></td>
+ <td><code>signing.key.passphrase</code></td>
+ </tr>
+ <tr>
<td><code>ssl.enabled</code></td>
<td>Indicates whether SSL is enabled for the Gateway</td>
<td><code>true</code></td>
@@ -1463,7 +1498,7 @@ trustworthiness.
<h4><a id="Java+VM+Options">Java VM Options</a> <a
href="#Java+VM+Options"><img src="markbook-section-link.png"/></a></h4>
<p>TODO - Java VM options doc.</p>
<h4><a id="Persisting+the+Master+Secret">Persisting the Master Secret</a> <a
href="#Persisting+the+Master+Secret"><img
src="markbook-section-link.png"/></a></h4>
-<p>The master secret is required to start the server. This secret is used to
access secured artifacts by the gateway instance. Keystore, trust stores and
credential stores are all protected with the master secret.</p>
+<p>The master secret is required to start the server. This secret is used to
access secured artifacts by the gateway instance. By default, the keystores,
trust stores, and credential stores are all protected with the master secret.
However, if a custom keystore is set, it and the contained keys may have
different passwords. </p>
<p>You may persist the master secret by supplying the <em>-persist-master</em>
switch at startup. This will result in a warning indicating that persisting the
secret is less secure than providing it at startup. We do make some provisions
in order to protect the persisted password.</p>
<p>It is encrypted with AES 128 bit encryption and where possible the file
permissions are set to only be accessible by the user that the gateway is
running as.</p>
<p>After persisting the secret, ensure that the file at
<code>data/security/master</code> has the appropriate permissions set for your
environment. This is probably the most important layer of defense for master
secret. Do not assume that the encryption is sufficient protection.</p>
@@ -1472,18 +1507,24 @@ trustworthiness.
<h4><a id="Management+of+Security+Artifacts">Management of Security
Artifacts</a> <a href="#Management+of+Security+Artifacts"><img
src="markbook-section-link.png"/></a></h4>
<p>There are a number of artifacts that are used by the gateway in ensuring
the security of wire level communications, access to protected resources and
the encryption of sensitive data. These artifacts can be managed from outside
of the gateway instances or generated and populated by the gateway instance
itself.</p>
<p>The following is a description of how this is coordinated with both
standalone (development, demo, etc.) gateway instances and instances as part of
a cluster of gateways in mind.</p>
-<p>Upon start of the gateway server we:</p>
+<p>Upon start of the gateway server:</p>
<ol>
- <li>Look for an identity store at
<code>data/security/keystores/gateway.jks</code>. The identity store contains
the certificate and private key used to represent the identity of the server
for SSL connections and signature creation.
+ <li>Look for a credential store at
<code>data/security/keystores/__gateway-credentials.jceks</code>. This
credential store is used to store secrets/passwords that are used by the
gateway. For instance, this is where the passphrase for accessing the
gateway’s TLS certificate is kept.
+ <ul>
+ <li>If the credential store is not found, then one is created and
encrypted with the provided master secret.</li>
+ <li>If the credential store is found, then it is loaded using the
provided master secret.</li>
+ </ul>
+ </li>
+ <li>Look for an identity keystore at the configured location. If a
configured location was not set, the default location,
<code>data/security/keystores/gateway.jks</code>, will be used. The identity
keystore contains the certificate and private key used to represent the
identity of the server for TLS/SSL connections.
<ul>
- <li>If there is no identity store we create one and generate a
self-signed certificate for use in standalone/demo mode. The certificate is
stored with an alias of gateway-identity.</li>
- <li>If there is an identity store found than we ensure that it can be
loaded using the provided master secret and that there is an alias called
gateway-identity.</li>
+ <li>If the identity keystore was not found, one is created in the
configured or default location.<br/> Then a self-signed certificate for use in
standalone/demo mode is generated and stored with the configured identity
alias or the default alias of “gateway-identity”.</li>
+ <li>If the identity keystore is found, then it is loaded using either
the password found in the credential store under the configured alias name or
the provided master secret. It is tested to ensure that a certificate and
private key are found using the configured alias name or the default alias of
“gateway-identity”.</li>
</ul>
</li>
- <li>Look for a credential store at
<code>data/security/keystores/__gateway-credentials.jceks</code>. This
credential store is used to store secrets/passwords that are used by the
gateway. For instance, this is where the passphrase for accessing the
gateway-identity certificate is kept.
+ <li>Look for a signing keystore at the configured location or the default
location of <code>data/security/keystores/gateway.jks</code>.<br/> The signing
keystore contains the public and private key used for signature creation.
<ul>
- <li>If there is no credential store found then we create one and
populate it with a generated passphrase for the alias
<code>gateway-identity-passphrase</code>. This is coordinated with the
population of the self-signed cert into the identity-store.</li>
- <li>If a credential store is found then we ensure that it can be loaded
using the provided master secret and that the expected aliases have been
populated with secrets.</li>
+ <li>If the signing keystore was not found, the server will fail to
start.</li>
+ <li>If the signing keystore is found, then it is loaded using either the
password found in the credential store under the configured alias name or the
provided master secret. It is tested to ensure that a public and private key
are found using the configured alias name or the default alias of
“gateway-identity”.</li>
</ul>
</li>
</ol>
@@ -1504,33 +1545,46 @@ trustworthiness.
</ol>
<p>See the Knox CLI section for descriptions of the command line utilities
related to the security artifact management.</p>
<h4><a id="Keystores">Keystores</a> <a href="#Keystores"><img
src="markbook-section-link.png"/></a></h4>
-<p>In order to provide your own certificate for use by the gateway, you will
need to either import an existing key pair into a Java keystore or generate a
self-signed cert using the Java keytool.</p>
+<p>In order to provide your own certificate for use by the Gateway, you may
either</p>
+<ul>
+ <li>provide your own keystore</li>
+ <li>import an existing key pair into the default Gateway keystore</li>
+ <li>generate a self-signed cert using the Java keytool</li>
+</ul>
+<h5><a id="Providing+your+own+keystore">Providing your own keystore</a> <a
href="#Providing+your+own+keystore"><img
src="markbook-section-link.png"/></a></h5>
+<p>A keystore in one of the following formats may be specified: </p>
+<ul>
+ <li>JKS: Java KeyStore file</li>
+ <li>JCEKS: Java Cryptology Extension KeyStore file</li>
+ <li>PKCS12: PKCS #12 file</li>
+</ul>
+<p>See <code>gateway.tls.keystore.password.alias</code>,
<code>gateway.tls.keystore.path</code>, <code>gateway.tls.keystore.type</code>,
<code>gateway.tls.key.alias</code>, and
<code>gateway.tls.key.passphrase.alias</code> under <em>Gateway Server
Configuration</em> for information on configuring the Gateway to use this
keystore.</p>
<h5><a id="Importing+a+key+pair+into+a+Java+keystore">Importing a key pair
into a Java keystore</a> <a
href="#Importing+a+key+pair+into+a+Java+keystore"><img
src="markbook-section-link.png"/></a></h5>
<p>One way to accomplish this is to start with a PKCS12 store for your key
pair and then convert it to a Java keystore or JKS.</p>
<p>The following example uses OpenSSL to create a PKCS12 encoded store from
your provided certificate and private key that are in PEM format.</p>
<pre><code>openssl pkcs12 -export -in cert.pem -inkey key.pem > server.p12
</code></pre>
-<p>The next example converts the PKCS12 store into a Java keystore (JKS). It
should prompt you for the keystore and key passwords for the destination
keystore. You must use the master-secret for the keystore password and keep
track of the password that you use for the key passphrase.</p>
+<p>The next example converts the PKCS12 store into a Java keystore (JKS). It
should prompt you for the keystore and key passwords for the destination
keystore. You must use either the master-secret for the keystore password and
key passphrase or choose you own. If you choose your own passwords, you must
use the Knox CLI utility to provide them to the Gateway. </p>
<pre><code>keytool -importkeystore -srckeystore server.p12 -destkeystore
gateway.jks -srcstoretype pkcs12
</code></pre>
<p>While using this approach a couple of important things to be aware of:</p>
<ol>
<li>
- <p>the alias MUST be “gateway-identity”. You may need to
change it using keytool after the import of the PKCS12 store. You can use
keytool to do this - for example:</p>
+ <p>The alias MUST be properly set. If it is not the default value
(“gateway-identity”), it must be set in the configuration using
<code>gateway.tls.key.alias</code>. You may need to change it using keytool
after the import of the PKCS12 store. You can use keytool to do this - for
example:</p>
<pre><code>keytool -changealias -alias "1" -destalias
"gateway-identity" -keystore gateway.jks -storepass {knoxpw}
</code></pre>
</li>
<li>
- <p>the name of the expected identity keystore for the gateway MUST be
<code>gateway.jks</code></p></li>
- <li>the passwords for the keystore and the imported key may both be set to
the master secret for the gateway install. You can change the key passphrase
after import using keytool as well. You may need to do this in order to
provision the password in the credential store as described later in this
section. For example:
+ <p>The path to the identity keystore for the gateway MUST be the default
path (<code>{GATEWAY_HOME}/data/security/keystores/gateway.jks</code>) or MUST
be specified in the configuration using <code>gateway.tls.keystore.path</code>
and <code>gateway.tls.keystore.type</code> </p></li>
+ <li>The passwords for the keystore and the imported key may both be set to
the master secret for the gateway install. If a custom password is used, the
passwords must be imported into the credential store using the Knox CLI
<code>create-alias</code> command. The aliases for the passwords must then be
set in the configuration using
<code>gateway.tls.keystore.password.alias</code> and
<code>gateway.tls.key.passphrase.alias</code>.<br/> If both the keystore
password and the key passphrase are the same, only
<code>gateway.tls.keystore.password.alias</code> needs to be set. You can
change the key passphrase after import using keytool. You may need to do this
in order to provision the password in the credential store as described later
in this section. For example:
<pre><code>keytool -keypasswd -alias gateway-identity -keystore gateway.jks
</code></pre>
</li>
</ol>
-<p>NOTE: The password for the keystore as well as that of the imported key may
be the master secret for the gateway instance or you may set the
gateway-identity-passphrase alias using the Knox CLI to the actual key
passphrase. See the Knox CLI section for details.</p>
-<p>The following will allow you to provision the passphrase for the private
key that you set during keystore creation above - it will prompt you for the
actual passphrase.</p>
-<pre><code>bin/knoxcli.sh create-alias gateway-identity-passphrase
+<p>The following will allow you to provision the password for the keystore or
the passphrase for the private key that was set during keystore creation above
- it will prompt you for the actual password/passphrase.</p>
+<pre><code>bin/knoxcli.sh create-alias <alias name>
</code></pre>
+<p>The default alias for the keystore password is
<code>gateway-identity-keystore-password</code>, to use a different alias, set
<code>gateway.tls.keystore.password.alias</code> in the configuration. The
default alias for the key passphrase is
<code>gateway-identity-keystore-password</code>, to use a different alias, set
<code>gateway.tls.key.passphrase.alias</code> in the configuration.</p>
<h5><a
id="Generating+a+self-signed+cert+for+use+in+testing+or+development+environments">Generating
a self-signed cert for use in testing or development environments</a> <a
href="#Generating+a+self-signed+cert+for+use+in+testing+or+development+environments"><img
src="markbook-section-link.png"/></a></h5>
<pre><code>keytool -genkey -keyalg RSA -alias gateway-identity -keystore
gateway.jks \
-storepass {master-secret} -validity 360 -keysize 2048
@@ -1541,8 +1595,8 @@ trustworthiness.
<p>See the Knox CLI section for descriptions of the command line utilities
related to the management of the keystores.</p>
<h5><a id="Using+a+CA+Signed+Key+Pair">Using a CA Signed Key Pair</a> <a
href="#Using+a+CA+Signed+Key+Pair"><img
src="markbook-section-link.png"/></a></h5>
<p>For certain deployments a certificate key pair that is signed by a trusted
certificate authority is required. There are a number of different ways in
which these certificates are acquired and can be converted and imported into
the Apache Knox keystore.</p>
-<p>The following steps have been used to do this and are provided here for
guidance in your installation. You may have to adjust according to your
environment.</p>
-<p>General steps:</p>
+<h6><a id="Option+#1">Option #1</a> <a href="#Option+#1"><img
src="markbook-section-link.png"/></a></h6>
+<p>One way to do this is to install the certificate and keys in the default
identity keystore and the master secret. The following steps have been used to
do this and are provided here for guidance in your installation. You may have
to adjust according to your environment.</p>
<ol>
<li>
<p>Stop Knox gateway and back up all files in
<code>{GATEWAY_HOME}/data/security/keystores</code></p>
@@ -1582,19 +1636,57 @@ keytool -keystore gateway.jks -storepass
</li>
<li>
<p>Restart Knox gateway. Check <code>gateway.log</code> to check whether
the gateway started properly and clusters are deployed. You can check the
timestamp on cluster deployment files</p>
- <pre><code>ls -alrt {GATEWAY_HOME}/data/deployment
+ <pre><code>gateway.sh start
+ls -alrt {GATEWAY_HOME}/data/deployment
+</code></pre>
+ </li>
+ <li>
+ <p>Verify that clients can use the CA authority cert to access Knox (which
is the goal of using public signed cert) using curl or a web browser which has
the CA certificate installed</p>
+ <pre><code>curl --cacert PATH_TO_CA_CERT -u tom:tom-password -X GET
https://localhost:8443/gateway/sandbox/webhdfs/v1?op=GETHOMEDIRECTORY
+</code></pre>
+ </li>
+</ol>
+<h6><a id="Option+#2">Option #2</a> <a href="#Option+#2"><img
src="markbook-section-link.png"/></a></h6>
+<p>Another way to do this is to place the CA signed keypair in it’s own
keystore. The creation of this keystore is out of scope for this document.
However, once created, the following steps can be use to configure the Knox
Gateway to use it. </p>
+<ol>
+ <li>
+ <p>Move the new keystore into a location that the Knox Gateway can
access.</p></li>
+ <li>
+ <p>Edit the gateway-site.xml file to set the configurations </p>
+ <ul>
+ <li><code>gateway.tls.keystore.password.alias</code> - Alias of the
password for the keystore</li>
+ <li><code>gateway.tls.keystore.path</code> - Path to the keystore
file</li>
+ <li><code>gateway.tls.keystore.type</code> - Type of keystore file (JKS,
JCEKS, PKCS12)</li>
+ <li><code>gateway.tls.key.alias</code> - Alias for the certificate and
key</li>
+ <li><code>gateway.tls.key.passphrase.alias</code> - Alias of the
passphrase for the key (needed if the passphrase is different than the
keystore password)</li>
+ </ul>
+ </li>
+ <li>
+ <p>Provision the relevant passwords using the Knox CLI</p>
+ <pre><code>knoxcli.sh create-alias <alias> --value
<password/passphrase>
+</code></pre>
+ </li>
+ <li>
+ <p>Stop Knox gateway</p>
+ <pre><code>gateway.sh stop
+</code></pre>
+ </li>
+ <li>
+ <p>Restart Knox gateway. Check <code>gateway.log</code> to check whether
the gateway started properly and clusters are deployed. You can check the
timestamp on cluster deployment files</p>
+ <pre><code>gateway.sh start
+ls -alrt {GATEWAY_HOME}/data/deployment
</code></pre>
</li>
<li>
- <p>Verify that clients can use the CA authority cert to access Knox (which
is the goal of using public signed cert) using curl or a web browsers which has
the CA certificate installed</p>
+ <p>Verify that clients can use the CA authority cert to access Knox (which
is the goal of using public signed cert) using curl or a web browsers which
has the CA certificate installed</p>
<pre><code>curl --cacert supwin12ad.cer -u hdptester:hadoop -X GET
'https://$fqdn_knox:8443/gateway/$topologyname/webhdfs/v1/tmp?op=LISTSTATUS'
</code></pre>
</li>
</ol>
<h5><a id="Credential+Store">Credential Store</a> <a
href="#Credential+Store"><img src="markbook-section-link.png"/></a></h5>
-<p>Whenever you provide your own keystore with either a self-signed cert or an
issued certificate signed by a trusted authority, you will need to set an alias
for the <code>gateway-identity-passphrase</code> or create an empty credential
store. This is necessary for the current release in order for the system to
determine the correct password for the keystore and the key.</p>
+<p>Whenever you provide your own keystore with either a self-signed cert or an
issued certificate signed by a trusted authority, you will need to set an alias
for the keystore password and key passphrase. This is necessary for the current
release in order for the system to determine the correct passwords to use 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>
-<p>Keytool may be used to create credential stores but the Knox CLI section
details how to create aliases. These aliases are managed within credential
stores which are created by the CLI as needed. The simplest approach is to
create the <code>gateway-identity-passphrase</code> alias with the Knox CLI.
This will create the credential store if it doesn’t already exist and add
the key passphrase.</p>
+<p>Keytool may be used to create credential stores but the Knox CLI section
details how to create aliases. These aliases are managed within credential
stores which are created by the CLI as needed. The simplest approach is to
create the relevant aliases with the Knox CLI. This will create the credential
store if it does not already exist and add the password or passphrase.</p>
<p>See the Knox CLI section for descriptions of the command line utilities
related to the management of the credential stores.</p>
<h5><a id="Provisioning+of+Keystores">Provisioning of Keystores</a> <a
href="#Provisioning+of+Keystores"><img
src="markbook-section-link.png"/></a></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}/data/security/keystores</code> directory for your gateway
install.</p>
Modified: knox/site/index.html
URL:
http://svn.apache.org/viewvc/knox/site/index.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/index.html (original)
+++ knox/site/index.html Sun Mar 3 21:01:59 2019
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
src/site/markdown/index.md at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
src/site/markdown/index.md at 2019-03-03
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20190301" />
+ <meta name="Date-Revision-yyyymmdd" content="20190303" />
<meta http-equiv="Content-Language" content="en" />
<title>Knox Gateway – Announcing Apache Knox 1.2.0!</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2019-03-01</li>
+ <li id="publishDate">Last Published: 2019-03-03</li>
</ul>
</div>
<div class="row-fluid">
Modified: knox/site/issue-management.html
URL:
http://svn.apache.org/viewvc/knox/site/issue-management.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/issue-management.html (original)
+++ knox/site/issue-management.html Sun Mar 3 21:01:59 2019
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:issue-management
at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:issue-management
at 2019-03-03
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20190301" />
+ <meta name="Date-Revision-yyyymmdd" content="20190303" />
<meta http-equiv="Content-Language" content="en" />
<title>Knox Gateway – Issue Management</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2019-03-01</li>
+ <li id="publishDate">Last Published: 2019-03-03</li>
</ul>
</div>
<div class="row-fluid">
Modified: knox/site/licenses.html
URL:
http://svn.apache.org/viewvc/knox/site/licenses.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/licenses.html (original)
+++ knox/site/licenses.html Sun Mar 3 21:01:59 2019
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:licenses at
2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:licenses at
2019-03-03
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20190301" />
+ <meta name="Date-Revision-yyyymmdd" content="20190303" />
<meta http-equiv="Content-Language" content="en" />
<title>Knox Gateway – Project Licenses</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2019-03-01</li>
+ <li id="publishDate">Last Published: 2019-03-03</li>
</ul>
</div>
<div class="row-fluid">
Modified: knox/site/mailing-lists.html
URL:
http://svn.apache.org/viewvc/knox/site/mailing-lists.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/mailing-lists.html (original)
+++ knox/site/mailing-lists.html Sun Mar 3 21:01:59 2019
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:mailing-lists
at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:mailing-lists
at 2019-03-03
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20190301" />
+ <meta name="Date-Revision-yyyymmdd" content="20190303" />
<meta http-equiv="Content-Language" content="en" />
<title>Knox Gateway – Project Mailing Lists</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2019-03-01</li>
+ <li id="publishDate">Last Published: 2019-03-03</li>
</ul>
</div>
<div class="row-fluid">
Modified: knox/site/project-info.html
URL:
http://svn.apache.org/viewvc/knox/site/project-info.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/project-info.html (original)
+++ knox/site/project-info.html Sun Mar 3 21:01:59 2019
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-site-plugin:3.7.1:CategorySummaryDocumentRenderer
at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-site-plugin:3.7.1:CategorySummaryDocumentRenderer
at 2019-03-03
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20190301" />
+ <meta name="Date-Revision-yyyymmdd" content="20190303" />
<meta http-equiv="Content-Language" content="en" />
<title>Knox Gateway – Project Information</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2019-03-01</li>
+ <li id="publishDate">Last Published: 2019-03-03</li>
</ul>
</div>
<div class="row-fluid">
Modified: knox/site/team.html
URL:
http://svn.apache.org/viewvc/knox/site/team.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/team.html (original)
+++ knox/site/team.html Sun Mar 3 21:01:59 2019
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:team at
2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:team at
2019-03-03
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20190301" />
+ <meta name="Date-Revision-yyyymmdd" content="20190303" />
<meta http-equiv="Content-Language" content="en" />
<title>Knox Gateway – Project Team</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2019-03-01</li>
+ <li id="publishDate">Last Published: 2019-03-03</li>
</ul>
</div>
<div class="row-fluid">
Modified: knox/trunk/books/1.3.0/config.md
URL:
http://svn.apache.org/viewvc/knox/trunk/books/1.3.0/config.md?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/trunk/books/1.3.0/config.md (original)
+++ knox/trunk/books/1.3.0/config.md Sun Mar 3 21:01:59 2019
@@ -124,7 +124,6 @@ Property | Description | Default
`gateway.client.auth.needed`|Indicates whether clients are required to
establish a trust relationship with client certificates|`false`
`gateway.truststore.path`|Location of the truststore for client certificates
to be trusted|`gateway.jks`
`gateway.truststore.type`|Indicates the type of truststore|`JKS`
-`gateway.keystore.type`|Indicates the type of keystore for the identity
store|`JKS`
`gateway.jdk.tls.ephemeralDHKeySize`|`jdk.tls.ephemeralDHKeySize`, is defined
to customize the ephemeral DH key sizes. The minimum acceptable DH key size is
1024 bits, except for exportable cipher suites or legacy mode
(`jdk.tls.ephemeralDHKeySize=legacy`)|`2048`
`gateway.threadpool.max`|The maximum concurrent requests the server will
process. The default is 254. Connections beyond this will be queued.|`254`
`gateway.httpclient.maxConnections`|The maximum number of connections that a
single HttpClient will maintain to a single host:port.|`32`
@@ -135,8 +134,16 @@ Property | Description | Default
`gateway.httpserver.responseBuffer`|The size of the HTTP server response
buffer in bytes|`32768`
`gateway.httpserver.responseHeaderBuffer`|The size of the HTTP server response
header buffer in bytes|`8192`
`gateway.websocket.feature.enabled`|Enable/Disable WebSocket feature|`false`
+`gateway.tls.keystore.password.alias`|OPTIONAL Alias for the password to the
keystore file holding the Gateway's TLS certificate and keypair. NOTE: An alias
with the provided name should be created using `knoxcli.sh create-alias`
inorder to provide the password; else the master secret will be
used.|`gateway-identity-keystore-password`
+`gateway.tls.keystore.path`|OPTIONAL The path to the keystore file where the
Gateway's TLS certificate and keypair are stored. If not set, the default
keystore file will be used - data/security/keystores/gateway.jks.|null
+`gateway.tls.keystore.type`|OPTIONAL The type of the keystore file where the
Gateway's TLS certificate and keypair are stored. See
`gateway.tls.keystore.path`.|`JKS`
+`gateway.tls.key.alias`|OPTIONAL The alias for the Gateway's TLS certificate
and keypair within the default keystore or the keystore specified via
`gateway.tls.keystore.path`.|`gateway-identity`
+`gateway.tls.key.passphrase.alias`|OPTIONAL The alias for passphrase for the
Gateway's TLS private key stored within the default keystore or the keystore
specified via `gateway.tls.keystore.path`. NOTE: An alias with the provided
name should be created using `knoxcli.sh create-alias` inorder to provide the
password; else the keystore password or the master secret will be used. See
`gateway.tls.keystore.password.alias`|`gateway-identity-passphrase`
`gateway.signing.keystore.name`|OPTIONAL Filename of keystore file that
contains the signing keypair. NOTE: An alias needs to be created using
`knoxcli.sh create-alias` for the alias name `signing.key.passphrase` in order
to provide the passphrase to access the keystore.|null
+`gateway.signing.keystore.password.alias`|OPTIONAL Alias for the password to
the keystore file holding the signing keypair. NOTE: An alias with the provided
name should be created using `knoxcli.sh create-alias` inorder to provide the
password; else the master secret will be used.|`signing.keystore.password`
+`gateway.signing.keystore.type`|OPTIONAL The type of the keystore file where
the signing keypair is stored. See `gateway.signing.keystore.name`.|`JKS`
`gateway.signing.key.alias`|OPTIONAL alias for the signing keypair within the
keystore specified via `gateway.signing.keystore.name`|null
+`gateway.signing.key.passphrase.alias`|OPTIONAL The alias for passphrase for
signing private key stored within the default keystore or the keystore
specified via `gateway.signing.keystore.name`. NOTE: An alias with the
provided name should be created using `knoxcli.sh create-alias` inorder to
provide the password; else the keystore password or the master secret will be
used. See `gateway.signing.keystore.password.alias`|`signing.key.passphrase`
`ssl.enabled`|Indicates whether SSL is enabled for the Gateway|`true`
`ssl.include.ciphers`|A comma or pipe separated list of ciphers to accept for
SSL. See the [JSSE Provider
docs](http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider)
for possible ciphers. These can also contain regular expressions as shown in
the [Jetty
documentation](http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html).|all
`ssl.exclude.ciphers`|A comma or pipe separated list of ciphers to reject for
SSL. See the [JSSE Provider
docs](http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider)
for possible ciphers. These can also contain regular expressions as shown in
the [Jetty
documentation](http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html).|none
@@ -812,7 +819,8 @@ TODO - Java VM options doc.
The master secret is required to start the server.
This secret is used to access secured artifacts by the gateway instance.
-Keystore, trust stores and credential stores are all protected with the master
secret.
+By default, the keystores, trust stores, and credential stores are all
protected with the master secret.
+However, if a custom keystore is set, it and the contained keys may have
different passwords.
You may persist the master secret by supplying the *\-persist-master* switch
at startup.
This will result in a warning indicating that persisting the secret is less
secure than providing it at startup.
@@ -835,19 +843,30 @@ These artifacts can be managed from outs
The following is a description of how this is coordinated with both standalone
(development, demo, etc.) gateway instances and instances as part of a cluster
of gateways in mind.
-Upon start of the gateway server we:
+Upon start of the gateway server:
-1. Look for an identity store at `data/security/keystores/gateway.jks`.
- The identity store contains the certificate and private key used to
represent the identity of the server for SSL connections and signature creation.
- * If there is no identity store we create one and generate a self-signed
certificate for use in standalone/demo mode.
- The certificate is stored with an alias of gateway-identity.
- * If there is an identity store found than we ensure that it can be loaded
using the provided master secret and that there is an alias called
gateway-identity.
-2. Look for a credential store at
`data/security/keystores/__gateway-credentials.jceks`.
+1. Look for a credential store at
`data/security/keystores/__gateway-credentials.jceks`.
This credential store is used to store secrets/passwords that are used by
the gateway.
- For instance, this is where the passphrase for accessing the
gateway-identity certificate is kept.
- * If there is no credential store found then we create one and populate it
with a generated passphrase for the alias `gateway-identity-passphrase`.
- This is coordinated with the population of the self-signed cert into the
identity-store.
- * If a credential store is found then we ensure that it can be loaded
using the provided master secret and that the expected aliases have been
populated with secrets.
+ For instance, this is where the passphrase for accessing the gateway's TLS
certificate is kept.
+ * If the credential store is not found, then one is created and encrypted
with the provided master secret.
+ * If the credential store is found, then it is loaded using the provided
master secret.
+2. Look for an identity keystore at the configured location. If a configured
location was not set, the
+ default location, `data/security/keystores/gateway.jks`, will be used. The
identity keystore contains
+ the certificate and private key used to represent the identity of the
server for TLS/SSL connections.
+ * If the identity keystore was not found, one is created in the configured
or default location.
+ Then a self-signed certificate for use in standalone/demo mode is
generated and stored with the
+ configured identity alias or the default alias of "gateway-identity".
+ * If the identity keystore is found, then it is loaded using either the
password found in the
+ credential store under the configured alias name or the provided master
secret. It is tested
+ to ensure that a certificate and private key are found using the
configured alias name or
+ the default alias of "gateway-identity".
+3. Look for a signing keystore at the configured location or the default
location of `data/security/keystores/gateway.jks`.
+ The signing keystore contains the public and private key used for signature
creation.
+ * If the signing keystore was not found, the server will fail to start.
+ * If the signing keystore is found, then it is loaded using either the
password found in the
+ credential store under the configured alias name or the provided master
secret. It is tested
+ to ensure that a public and private key are found using the configured
alias name or
+ the default alias of "gateway-identity".
Upon deployment of a Hadoop cluster topology within the gateway we:
@@ -866,7 +885,22 @@ By leveraging the algorithm described ab
See the Knox CLI section for descriptions of the command line utilities
related to the security artifact management.
#### Keystores ####
-In order to provide your own certificate for use by the gateway, you will need
to either import an existing key pair into a Java keystore or generate a
self-signed cert using the Java keytool.
+In order to provide your own certificate for use by the Gateway, you may either
+
+- provide your own keystore
+- import an existing key pair into the default Gateway keystore
+- generate a self-signed cert using the Java keytool
+
+##### Providing your own keystore #####
+A keystore in one of the following formats may be specified:
+
+- JKS: Java KeyStore file
+- JCEKS: Java Cryptology Extension KeyStore file
+- PKCS12: PKCS #12 file
+
+See `gateway.tls.keystore.password.alias`, `gateway.tls.keystore.path`,
`gateway.tls.keystore.type`,
+`gateway.tls.key.alias`, and `gateway.tls.key.passphrase.alias` under *Gateway
Server Configuration*
+for information on configuring the Gateway to use this keystore.
##### Importing a key pair into a Java keystore #####
One way to accomplish this is to start with a PKCS12 store for your key pair
and then convert it to a Java keystore or JKS.
@@ -875,26 +909,45 @@ The following example uses OpenSSL to cr
openssl pkcs12 -export -in cert.pem -inkey key.pem > server.p12
-The next example converts the PKCS12 store into a Java keystore (JKS). It
should prompt you for the keystore and key passwords for the destination
keystore. You must use the master-secret for the keystore password and keep
track of the password that you use for the key passphrase.
+The next example converts the PKCS12 store into a Java keystore (JKS). It
should prompt you for the
+keystore and key passwords for the destination keystore. You must use either
the master-secret for the
+keystore password and key passphrase or choose you own. If you choose your
own passwords, you must
+use the Knox CLI utility to provide them to the Gateway.
keytool -importkeystore -srckeystore server.p12 -destkeystore gateway.jks
-srcstoretype pkcs12
While using this approach a couple of important things to be aware of:
-1. the alias MUST be "gateway-identity". You may need to change it using
keytool after the import of the PKCS12 store. You can use keytool to do this -
for example:
+1. The alias MUST be properly set. If it is not the default value
("gateway-identity"), it must be
+ set in the configuration using `gateway.tls.key.alias`. You may need to
change it using keytool
+ after the import of the PKCS12 store. You can use keytool to do this - for
example:
keytool -changealias -alias "1" -destalias "gateway-identity"
-keystore gateway.jks -storepass {knoxpw}
-2. the name of the expected identity keystore for the gateway MUST be
`gateway.jks`
-3. the passwords for the keystore and the imported key may both be set to the
master secret for the gateway install. You can change the key passphrase after
import using keytool as well. You may need to do this in order to provision the
password in the credential store as described later in this section. For
example:
+2. The path to the identity keystore for the gateway MUST be the default path
+ (`{GATEWAY_HOME}/data/security/keystores/gateway.jks`) or MUST be specified
in the configuration
+ using `gateway.tls.keystore.path` and `gateway.tls.keystore.type`
+3. The passwords for the keystore and the imported key may both be set to the
master secret for the
+ gateway install. If a custom password is used, the passwords must be
imported into the credential
+ store using the Knox CLI `create-alias` command. The aliases for the
passwords must then be set
+ in the configuration using `gateway.tls.keystore.password.alias` and
`gateway.tls.key.passphrase.alias`.
+ If both the keystore password and the key passphrase are the same, only
`gateway.tls.keystore.password.alias`
+ needs to be set. You can change the key passphrase after import using
keytool. You may need to
+ do this in order to provision the password in the credential store as
described later in this
+ section. For example:
keytool -keypasswd -alias gateway-identity -keystore gateway.jks
-NOTE: The password for the keystore as well as that of the imported key may be
the master secret for the gateway instance or you may set the
gateway-identity-passphrase alias using the Knox CLI to the actual key
passphrase. See the Knox CLI section for details.
-
-The following will allow you to provision the passphrase for the private key
that you set during keystore creation above - it will prompt you for the actual
passphrase.
-
- bin/knoxcli.sh create-alias gateway-identity-passphrase
+The following will allow you to provision the password for the keystore or the
passphrase for the
+private key that was set during keystore creation above - it will prompt you
for the actual
+password/passphrase.
+
+ bin/knoxcli.sh create-alias <alias name>
+
+The default alias for the keystore password is
`gateway-identity-keystore-password`, to use a different
+alias, set `gateway.tls.keystore.password.alias` in the configuration. The
default alias for the key
+passphrase is `gateway-identity-keystore-password`, to use a different alias,
set
+`gateway.tls.key.passphrase.alias` in the configuration.
##### Generating a self-signed cert for use in testing or development
environments #####
@@ -912,10 +965,10 @@ See the Knox CLI section for description
##### Using a CA Signed Key Pair #####
For certain deployments a certificate key pair that is signed by a trusted
certificate authority is required. There are a number of different ways in
which these certificates are acquired and can be converted and imported into
the Apache Knox keystore.
-The following steps have been used to do this and are provided here for
guidance in your installation.
-You may have to adjust according to your environment.
-
-General steps:
+###### Option #1 ######
+One way to do this is to install the certificate and keys in the default
identity keystore and the
+master secret. The following steps have been used to do this and are provided
here for guidance in
+your installation. You may have to adjust according to your environment.
1. Stop Knox gateway and back up all files in
`{GATEWAY_HOME}/data/security/keystores`
@@ -951,18 +1004,60 @@ General steps:
8. Restart Knox gateway. Check `gateway.log` to check whether the gateway
started properly and clusters are deployed. You can check the timestamp on
cluster deployment files
+ gateway.sh start
+ ls -alrt {GATEWAY_HOME}/data/deployment
+
+9. Verify that clients can use the CA authority cert to access Knox (which is
the goal of using public signed cert) using curl or a web browser which has the
CA certificate installed
+
+ curl --cacert PATH_TO_CA_CERT -u tom:tom-password -X GET
https://localhost:8443/gateway/sandbox/webhdfs/v1?op=GETHOMEDIRECTORY
+
+###### Option #2 ######
+Another way to do this is to place the CA signed keypair in it's own keystore.
The creation of this
+keystore is out of scope for this document. However, once created, the
following steps can be use to
+configure the Knox Gateway to use it.
+
+1. Move the new keystore into a location that the Knox Gateway can access.
+
+2. Edit the gateway-site.xml file to set the configurations
+ * `gateway.tls.keystore.password.alias` - Alias of the password for the
keystore
+ * `gateway.tls.keystore.path` - Path to the keystore file
+ * `gateway.tls.keystore.type` - Type of keystore file (JKS, JCEKS, PKCS12)
+ * `gateway.tls.key.alias` - Alias for the certificate and key
+ * `gateway.tls.key.passphrase.alias` - Alias of the passphrase for the key
+ (needed if the passphrase is different than the keystore password)
+
+3. Provision the relevant passwords using the Knox CLI
+
+ knoxcli.sh create-alias <alias> --value <password/passphrase>
+
+4. Stop Knox gateway
+
+ gateway.sh stop
+
+5. Restart Knox gateway. Check `gateway.log` to check whether the gateway
started properly and
+ clusters are deployed. You can check the timestamp on cluster deployment
files
+
+ gateway.sh start
ls -alrt {GATEWAY_HOME}/data/deployment
-9. Verify that clients can use the CA authority cert to access Knox (which is
the goal of using public signed cert) using curl or a web browsers which has
the CA certificate installed
+6. Verify that clients can use the CA authority cert to access Knox (which is
the goal of using
+ public signed cert) using curl or a web browsers which has the CA
certificate installed
curl --cacert supwin12ad.cer -u hdptester:hadoop -X GET
'https://$fqdn_knox:8443/gateway/$topologyname/webhdfs/v1/tmp?op=LISTSTATUS'
+
##### Credential Store #####
-Whenever you provide your own keystore with either a self-signed cert or an
issued certificate signed by a trusted authority, you will need to set an alias
for the `gateway-identity-passphrase` or create an empty credential store. This
is necessary for the current release in order for the system to determine the
correct password for the keystore and the key.
+Whenever you provide your own keystore with either a self-signed cert or an
issued certificate signed
+by a trusted authority, you will need to set an alias for the keystore
password and key passphrase.
+This is necessary for the current release in order for the system to determine
the correct passwords
+to use for the keystore and the key.
The credential stores in Knox use the JCEKS keystore type as it allows for the
storage of general secrets in addition to certificates.
-Keytool may be used to create credential stores but the Knox CLI section
details how to create aliases. These aliases are managed within credential
stores which are created by the CLI as needed. The simplest approach is to
create the `gateway-identity-passphrase` alias with the Knox CLI. This will
create the credential store if it doesn't already exist and add the key
passphrase.
+Keytool may be used to create credential stores but the Knox CLI section
details how to create aliases.
+These aliases are managed within credential stores which are created by the
CLI as needed. The
+simplest approach is to create the relevant aliases with the Knox CLI. This
will create the credential
+store if it does not already exist and add the password or passphrase.
See the Knox CLI section for descriptions of the command line utilities
related to the management of the credential stores.
