Open
Description
We know that configuring TLS can be difficult. Although the simplest cases are not too hard, as soon as there are additional constraints (e.g. local site policies, dynamic addressing) things get trickier.
It is often the case that the person configuring Elasticsearch has only a high level understanding of TLS, and is unsure how to chose between various configuration options that we offer, or the security consequences of certain choices.
When a configuration fails, it can be extremely difficult to debug because it is exceptionally rare for the error messages to provide sufficient details to allow the ES admin to understand the changes that are needed.
As a result we see:
- TLS being a source of frustration for ES admins
- Unintentional security weaknesses being introduced by admins in their efforts to make the cluster work (lax verification modes, overly permissive CA trust)
- Fragile configurations that interfere with the proper use of other ES features (e.g. TLS configurations that prevent Watcher from calling external services)
We should take steps to make this easier to set up, while recognising
- The ES admin may not know much about low level TLS details or certificate/key types/formats
- The JVM's TLS error messages are pretty much indecipherable to the average user.
- Local sites may have special requirements about tooling, CAs and certificate generation
- Container based deployments change some assumptions around network access and addressing
- Automated deployments (puppet, ansible, etc) should be encouraged, but are likely to change the constraints & expectation around tooling.
- TLS for the transport interface is required for production deployments (if security is enabled)
- TLS for the Rest (HTTP) interface should be encouraged, and potentially enforced in future versions.