Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created 02-04-2016 08:56 PM
Since JCEKS is a superset of JKS, what is the reason for having two files?
For example, couldn't we use gateway.jceks that stored both gateway-identity and gateway-identity-passphrase, instead of using a separate __gateway-credentials.jceks in addition to gateway.jks?
Created 02-04-2016 09:48 PM
Knox is composed of a number of Gateway Services at its core.
Among these are one for setting up the Jetty SSL listener (JettySSLService) and another for protection of various credentials (AliasService) in order to keep them out of clear text config. These services are able to leverage each other for various things. The JettySSLService has the AliasService injected in order to get to the protected gateway-identity-passphrase. This is a password that is stored at the gateway level as apposed to the topology or cluster level.
While mixing the two concerns would be possible with the functionality of JCEKS, it would inappropriately couple the two services implementations together.
There has always been plans to look for a more central and secure credential store. The addition of the Credential Provider API in Hadoop opens up this possibility. Currently, the primary credential provider in Hadoop is still a JCEKS provider. We need a server to sit over a secure storage that you would need to authenticate to in order to get the protected passwords. Once this is available the current design in Knox will allow us to transition to a central credential server without the JettySSLService even being aware.
Created 02-04-2016 09:48 PM
Knox is composed of a number of Gateway Services at its core.
Among these are one for setting up the Jetty SSL listener (JettySSLService) and another for protection of various credentials (AliasService) in order to keep them out of clear text config. These services are able to leverage each other for various things. The JettySSLService has the AliasService injected in order to get to the protected gateway-identity-passphrase. This is a password that is stored at the gateway level as apposed to the topology or cluster level.
While mixing the two concerns would be possible with the functionality of JCEKS, it would inappropriately couple the two services implementations together.
There has always been plans to look for a more central and secure credential store. The addition of the Credential Provider API in Hadoop opens up this possibility. Currently, the primary credential provider in Hadoop is still a JCEKS provider. We need a server to sit over a secure storage that you would need to authenticate to in order to get the protected passwords. Once this is available the current design in Knox will allow us to transition to a central credential server without the JettySSLService even being aware.