TODO - Complete Host Mapping docs.
That really depends upon how you have your VM configured. If you can hit http://c6401.ambari.apache.org:1022/ directly from your client and knox host then you probably don't need the hostmap at all. The host map only exists for situations where a host in the hadoop cluster is known by one name externally and another internally. For example running hostname -q on sandbox returns sandbox.hortonworks.com but externally Sandbox is setup to be accesses using localhost via portmapping. The way the hostmap config works is that the element is what the hadoop cluster host is known as externally and the is how the hadoop cluster host identifies itself internally.
If necessary you can enable additional logging by editing the log4j.properties
file in the conf
directory. Changing the rootLogger value from ERROR
to DEBUG
will generate a large amount of debug logging. A number of useful, more fine loggers are also provided in the file.
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.
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. We do make some provisions in order to protect the persisted password.
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.
After persisting the secret, ensure that the file at config/security/master 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 if sufficient protection.
A specific user should be created to run the gateway this will protect a persisted master file.
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.
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:
conf/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.conf/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 pass-phrase for accessing the gateway-identity certificate is kept.gateway-identity-passphrase
. This is coordinated with the population of the self-signed cert into the identity-store.Upon deployment of a Hadoop cluster topology within the gateway we:
conf/security/keystores/sample-credentials.jceks
. This topology specific credential store is used for storing secrets/passwords that are used for encrypting sensitive data with topology specific keys.By leveraging the algorithm described above we can provide a window of opportunity for management of these artifacts in a number of ways.
Summary of Secrets to be Managed:
NOTE: the SSL certificate will need special consideration depending on the type of certificate. Wildcard certs may be able to be shared across all gateway instances in a cluster. When certs are dedicated to specific machines the gateway identity store will not be able to be blindly replicated as hostname verification problems will ensue. Obviously, trust-stores will need to be taken into account as well.