Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Why does Knox use two keystores (JKS & JCEKS) for gateway identity and per topology?

avatar

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?

1 ACCEPTED SOLUTION

avatar
Expert Contributor

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.

View solution in original post

1 REPLY 1

avatar
Expert Contributor

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.