Override the JVM DNS cache policy #36570
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a security manager is present, the JVM will cache positive hostname lookups indefinitely. This can be problematic, especially in the modern world with cloud services where DNS addresses can change, or environments using Docker containers where IP addresses could be considered ephemeral. This behavior impacts cluster discovery, cross-cluster replication and cross-cluster search, reindex from remote, snapshot repositories, webhooks in Watcher, external authentication mechanisms, and the Elastic Stack Monitoring Service. The experience of watching a DNS lookup change yet not be reflected within Elasticsearch is a poor experience for users. The reason the JVM has this is guard against DNS cache posioning attacks. Yet, there is already a defense in the modern world against such attacks: TLS. With proper certificate validation, even if a resolver falls prey to a DNS cache poisoning attack, using TLS would neuter the attack. Therefore we have a policy with dubious security value that significantly impacts usability. As such we make the usability/security tradeoff towards usability, since the security risks are very low. This commit introduces new system properties that Elasticsearch observes to override the JVM DNS cache policy.
jasontedor
added
>enhancement
release highlight
:Core/Infra/Core
Collaborator
|
Pinging @elastic/es-core-infra |
Member
Author
|
@elasticmachine run gradle build tests 1 |
pickypg
reviewed
Dec 12, 2018
spinscale
approved these changes
Dec 13, 2018
Member
Author
|
@elasticmachine run gradle build tests 1 |
Member
Author
|
@elasticmachine test this please |
jasontedor
added a commit
that referenced
this pull request
Dec 13, 2018
When a security manager is present, the JVM will cache positive hostname lookups indefinitely. This can be problematic, especially in the modern world with cloud services where DNS addresses can change, or environments using Docker containers where IP addresses could be considered ephemeral. This behavior impacts cluster discovery, cross-cluster replication and cross-cluster search, reindex from remote, snapshot repositories, webhooks in Watcher, external authentication mechanisms, and the Elastic Stack Monitoring Service. The experience of watching a DNS lookup change yet not be reflected within Elasticsearch is a poor experience for users. The reason the JVM has this is guard against DNS cache posioning attacks. Yet, there is already a defense in the modern world against such attacks: TLS. With proper certificate validation, even if a resolver falls prey to a DNS cache poisoning attack, using TLS would neuter the attack. Therefore we have a policy with dubious security value that significantly impacts usability. As such we make the usability/security tradeoff towards usability, since the security risks are very low. This commit introduces new system properties that Elasticsearch observes to override the JVM DNS cache policy.
Member
Author
|
Thanks for reviewing @pickypg and @spinscale. |
sebgl
added a commit
to sebgl/cloud-on-k8s
that referenced
this pull request
Jun 10, 2019
Since we only support Elasticsearch 6.8+ and 7.1+, we have the following commit already there in Elasticsearch: elastic/elasticsearch#36570. Hence we do not need to duplicate the fix manually into our own JVM security options file. Since there is now no need for this "default config map" volume in the pod (only used for the jvm security options file so far), this commit also removes it.
sebgl
added a commit
to elastic/cloud-on-k8s
that referenced
this pull request
Jun 10, 2019
* Remove JVM DNS cache policy tweaks Since we only support Elasticsearch 6.8+ and 7.1+, we have the following commit already there in Elasticsearch: elastic/elasticsearch#36570. Hence we do not need to duplicate the fix manually into our own JVM security options file. Since there is now no need for this "default config map" volume in the pod (only used for the jvm security options file so far), this commit also removes it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a security manager is present, the JVM will cache positive hostname lookups indefinitely. This can be problematic, especially in the modern world with cloud services where DNS addresses can change, or environments using Docker containers where IP addresses could be considered ephemeral. This behavior impacts cluster discovery, cross-cluster replication and cross-cluster search, reindex from remote, snapshot repositories, webhooks in Watcher, external authentication mechanisms, and the Elastic Stack Monitoring Service. The experience of watching a DNS lookup change yet not be reflected within Elasticsearch is a poor experience for users. The reason the JVM has this is guard against DNS cache posioning attacks. Yet, there is already a defense in the modern world against such attacks: TLS. With proper certificate validation, even if a resolver falls prey to a DNS cache poisoning attack, using TLS would neuter the attack. Therefore we have a policy with dubious security value that significantly impacts usability. As such we make the usability/security tradeoff towards usability, since the security risks are very low. This commit introduces new system properties that Elasticsearch observes to override the JVM DNS cache policy.