Support Questions

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

Two Way SSL between Ambari Server and Agents

avatar
Rising Star

I am trying to configure and enable two-way ssl communication between the ambari-server and agents. I understand that just enabling the setting ‘security.server.two_way_ssl=true’ in the /etc/ambari-server/conf/ambari.properties will auto generate the certs on the nodes and ambari server acts as a CA to sign it.

We have CA-signed certs for these servers, and I was trying to follow the steps listed in this article: https://community.hortonworks.com/articles/66860/enable-two-way-ssl-between-ambari-server-and-ambar....

The CA-signed certificate I have is just certificate with multiple SAN names for all the nodes in the cluster.

According to the above article, if we want to use CA certs for both the server and agent, I have to copy the .crt and .key file to /var/lib/ambari-server/keys and /var/lib/ambari-agent/keys folder on all the servers and agent nodes.

Though I have secured the Hadoop services in the HDP Cluster using the CA-signed certs, we have the truststore and keystores in the /etc/security/serverKeys folder and the 'private key file' itself is not present on all the nodes. But the two-way ssl requires the private key file to be present on the agent nodes.

My question is, is having the private key file on all the agent nodes is riskier?

Or should I just go with using, the CA-signed cert/ key only for the ambari-server side and have the agents get a auto-generated key pair and cert signed by the Ambari server?

If I do self-signed certs for the this two_way_ssl setup, then we have 2 sets of certificates used and maintained on the cluster ie., one set used by the services and one self-signed auto-generated by the ambari server.

P.S.: The cluster does not have Ranger yet, it is Kerberized with AD and HTTPS enabled for the Hadoop services and Ambari server.

Please advise.

1 ACCEPTED SOLUTION

avatar

@Anitha R,

For SSL, any client or server that wishes to present a certificate needs to have access to the relevant private key to prove that they are the owner of the certificate. Else you could distribute the public key (and certificate) anywhere you want and that identity would be usable willy-nilly - which is rather insecure. That said, any private key needs to be kept secure to ensure only those that need it get access to it, else your security has been compromised.

When enabling "2-way SSL", both the server and agents are required to present certificates during the SSL handshake. As opposed to "1-way SSL", which uses the same SSL-secured channel as the "2-way" feature, but only the Ambari server is required to present a certificate. So the "2-way SSL" option increases the security of the connection in that the client now must be trusted before data is sent or received over that channel.

That said...

My question is, is having the private key file on all the agent nodes is riskier?

The more copies of the private key file that exist, the more chances there are that one of those copies are not secured. However, if you can ensure that the file is secure and that only those that absolute need to have access to it, have access to it; then you should be ok. However, this file must be available for the Ambari agent to use so that it may prove its identity.

Or should I just go with using, the CA-signed cert/ key only for the ambari-server side and have the agents get a auto-generated key pair and cert signed by the Ambari server?

The CA signed certs are more secure that the Ambari-generated ones since they are harder to come by. Ambari will create certs for any agent or client that looks like an agent as long as they know how to properly ask for it. I may have to do more research on why one would use "2-way SSL" where Ambari is signing the client certs, but I tend to ask my self this is useful at all.

View solution in original post

2 REPLIES 2

avatar

@Anitha R,

For SSL, any client or server that wishes to present a certificate needs to have access to the relevant private key to prove that they are the owner of the certificate. Else you could distribute the public key (and certificate) anywhere you want and that identity would be usable willy-nilly - which is rather insecure. That said, any private key needs to be kept secure to ensure only those that need it get access to it, else your security has been compromised.

When enabling "2-way SSL", both the server and agents are required to present certificates during the SSL handshake. As opposed to "1-way SSL", which uses the same SSL-secured channel as the "2-way" feature, but only the Ambari server is required to present a certificate. So the "2-way SSL" option increases the security of the connection in that the client now must be trusted before data is sent or received over that channel.

That said...

My question is, is having the private key file on all the agent nodes is riskier?

The more copies of the private key file that exist, the more chances there are that one of those copies are not secured. However, if you can ensure that the file is secure and that only those that absolute need to have access to it, have access to it; then you should be ok. However, this file must be available for the Ambari agent to use so that it may prove its identity.

Or should I just go with using, the CA-signed cert/ key only for the ambari-server side and have the agents get a auto-generated key pair and cert signed by the Ambari server?

The CA signed certs are more secure that the Ambari-generated ones since they are harder to come by. Ambari will create certs for any agent or client that looks like an agent as long as they know how to properly ask for it. I may have to do more research on why one would use "2-way SSL" where Ambari is signing the client certs, but I tend to ask my self this is useful at all.

avatar
Rising Star

Thank you for clarifying my questions in detail. I switched back to using ambari- server generated certificates for the 'two_way_ssl setup' for now, as the ca-signed certificate we have are SAN certificates i.e.,1 certificate with mulitple SAN for all nodes. When I tried using them, ambari server could not pick up the CA signed agent's cert, because the node name is not present the 'Subject' field of the certificate but instead in the extensions under the SAN names attribute of the certificate. Due to this scenario, I reverted to using the ambari-server signed certificates on all the nodes. Next time, we will get individual certificate for all the nodes with the name in the 'Subject' field to avoid these type of issues.