Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

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

Solved Go to solution
Highlighted

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

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

Accepted Solutions
Highlighted

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

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
Highlighted

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

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

Don't have an account?
Coming from Hortonworks? Activate your account here