...
The broader goal is to have the option to authenticate and secure all communication between various components.
Using signed certificates
TLS/SSL provides a way to do that. The way it provides authentication is through signed X.509 certificates. The certificates are signed by a trusted third party, generally a certificate authority. When a new connection is established one or both parties send their certificates to the other party. The other party then verifies the certificate it received as belonging to their peer.
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.
...
Truststores do not contain sensitive information, it is reasonable to create a single trust store for an entire cluster. On a production cluster, such a 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.
...
One way to mitigate this risk is to store all the private keys in a secured storage secure 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 key stores with private data on unsecured nodes.
Shared Secret
Another way to do authentication is to utilize the fact that our components talk to zookeeper to register and discover services. We can store shared secrets in ACL controlled locations that only cdap components can access and use that as a means of authentication.
...
SASL allows users to plug-in the autheication and encyrption system that suilts their needs. Some SASL mechanisms support only authentication while others support use of a negotiated security layer after authentication. The security layer feature is often not used when the application uses some other means, such as SSL/TLS, to communicate securely with the peer.
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.
...
- Security: The connection is secured by symmetric key cryptography. The key for this symmetric encryption is generated at the beginning of a connection and is based on a shared secret between the client and the server.
- Authentication: The communicating parties can optionally be authenticated.
- Integrity: Each message transmitted includes a message integrity check using a message authentication code
The router supports SSL in server mode—external entities can enable SSL for their connection to the router—but the router currently does not have the option to enable SSL in client mode.
...
- Enable app-fabric-server to accept SSL connection requests:
- Needs a key store
- Needs a certificate
Certificates
Certificates are needed for each entity that needs to be uniquely identified. These are generated by the client and provided through configuration. In this case, we need certificates for the router and the app-fabric-server. The same certificate could be used by the client and the server on the router.
...
Plan for 4.0
For 4.0 we are only focussing on encryption and not on authentication. The server will send a generated unsigned certificate on connection initiation and the client will accept that without verification. The client and the server will then continue with SSL handshake and encrypt the resulting connection.
The keystore will be stored in KMS so that it can be accessed securely by the app-fabric-server will be running on an insecure node, we would like to provide a safer option.One way to access the certificate in a safe manner would be to put it in a KMS. The access to a KMS is already over SSL (customer configured). We can then fetch the certificate on server initialization and put it in an in-memory key store. If the customer does not use KMS, we can fall back to the current file-based implementation. We can extend this to include other methods to access the certificate securely in the futureand we won't need to distribute it to all the nodes of the cluster.
Configuration
- SSL.enabled would enable SSL everywhere.
- SSL port for the app-fabric-server.
- SSL port for the router.
- Key store type: KMS or key store file type.
- Key store path: could be a file or KMS URI.
- Key store password: if using a file, the password for the key store file.
- Keystore key password: if using a file, the password for the key in the key store.
- Keystore router key: if using KMS, then the key under which the certificate is stored.
- Keystore app-fabric key: if using KMS, then the key under which the certificate is stored.
Design
...
Performance Impact
We would need to run performance tests to figure out the impact of enabling SSL. Based on current research, the cost should be manageable, adding about 2-5% of CPU overhead. This would need to be verified.
...