We have Elasticsearch 7.8.0 cluster which has CVE-2021-44228. Can we somehow patch it without upgrading the Elasticsearch version? If yes, can you please share any relevant thread or documentation?
Search for "Elasticsearch announcement (ESA-2021-31)". There's information about how to mitigate by setting -Dlog4j2.formatMsgNoLookups=true
Thank you for your prompt response @mikewillis. Can you recommend the best way to update this config on a multinode cluster as we have a considerable cluster size and it would be time taking to update the configs on one node at a time and moving the data around?
I'd say the best way do deploy a configuration change to every node is using your configuration management, e.g. Ansible or Puppet, that you used to build the cluster with, but since you're asking the question you presumably don't have configuration management. If you're running it all on Linux and have key auth set up then you could script it. But again, since you're asking… How you deploy configuration changes is really is a systems administration question rather than an Elasticsearch question.
I'm not sure why you're mentioning moving data around. Do you need to move data on your cluster around to reboot a node? Or are you just referring to it can take a significant amount of time to go through the process to rebooting a node, waiting for cluster health to go Green again, reboot another node etc?
Increasing the value of index.unassigned.node_left.delayed_timeout to something greater then the amount of time it takes for a node to be rebooted and rejoin the cluster will reduce the amount of time it takes for cluster health to reach Green by reducing the amount of work the cluster does as a result of a node being rebooted. E.g. If it takes five minutes for a node to reboot and rejoin then setting the value to 6m should mean that the cluster doesn't start recreating missing replica shards before the node rejoins.
Just realised I meant to include link to Delaying allocation when a node leaves | Elasticsearch Guide [7.8] | Elastic
Thank you for sharing this. I have tried applying the setting to increase the time out to delay the shards rebalancing
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
but getting the following error.
{
"error" : {
"root_cause" : [
{
"type" : "security_exception",
"reason" : "no permissions for [] and User [name=<my-email-address>, backend_roles=[admin], requestedTenant=null]"
}
],
"type" : "security_exception",
"reason" : "no permissions for [] and User [name=<my-email-address>, backend_roles=[admin], requestedTenant=null]"
},
"status" : 403
}
Although, I have the following admin permissions assigned to my user.
{
"description": "Allow full access to all indices and all cluster APIs",
"index_permissions": [
{
"index_patterns": [
"*"
],
"fls": [],
"masked_fields": [],
"allowed_actions": [
"*"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"*"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"cluster_permissions": [
"*"
]
}
Am I missing any permissions that are required?
We are using OKTA for user management. Is it possible that I have admin assigned to me in Elasticsearch and different levels of permissions are enforced from the OKTA side?
I have no familiarity with OKTA. Trying to get help for a completely unrelated problem in the replies is generally not the best way to go about things. I advise you make a new post about your new problem so that it gets visibility. Though OKTA appears to to be a third party add on for Elasticsearch so you're probably more likely to get a good response to a question about it somewhere dedicated to support of OKTA.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.