Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The problem with using CA-signed certificates is that we would need one for each component that we want to authenticate and given that we don't know which node most of these components would end up running on, the certificates would need to be distributed to all nodes in the cluster. Getting many certificates signed may not be cost effective. 

 

...

Security considerations for

...

key stores and

...

trust stores

Truststores do not contain sensitive information, it is reasonable to create a single truststore trust store for an entire cluster. On a production cluster, such a truststore trust store would often contain a single CA certificate (or certificate chain), since you would typically choose to have all certificates issued by a single CA.

Keystores, on the other hand, contain private keys and need to be secured. It might not be a good idea to distribute them on all nodes of an unsecured cluster. Generally, keystore on a node only contains the keys for the components running on that to reduce the risk but as we can not pre-determine where various cdap components will run the keystore on all nodes will need to contain keys for all components. This increases the risk.

 

One way to mitigate this is risk this risk is to store all the private keys in a secured storage and provide, as configuration, the keys that various components can use to access their private data. This way when a server component comes up, it can get its private keys from the storage, if configured to do so. This will prevent having to keep keystores key stores with private data on unsecured nodes. 

...

Another way to do authentication is to utilize the fact that our components talk to zookeeper to register and discover services. We can stored shared store shared secrets in ACL controlled locations that only that only cdap components can access and use that as a means of authentication. 

 

With a place to easily store shared secret Java SASL can be used to provide both authentication and encryption to the connections. Simple Authentication and Security Layer, or SASL, is an Internet standard (RFC 2222) that specifies a protocol for authentication and optional establishment of a security layer between client and server applications. SASL defines how authentication data is to be exchanged but does not itself specify the contents of that data. It is a framework into which specific authentication mechanisms that specify the contents and semantics of the authentication data can fit.

 

 

 

TLS/SSL

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols that provide communications security over a computer network.

...