I recently upgraded from AWS OpenSearch version 2.13 to 2.17, and now I'm hitting a 401 Unauthorized error when I try to run a curl command to update cluster settings. My curl call looks like this:
```bash
curl -u 'dude:sweet' -k -X PUT https://localhost:5601/_cluster/settings -w "%{http_code}"
-H 'Content-Type: application/json'
-d '{
"persistent": {
"cluster.max_shards_per_node": 1000
}
}'
```
The user I'm using, "dude", is the master user set up when creating the domain with Terraform. Fine-grained access controls are enabled, and I can successfully run a GET request on the same endpoint and access the UI without any trouble. Security settings show that "dude" has "all access" permissions. Despite this, the PUT request still returns a 401 error.
Am I incorrectly referencing the setting, or is there something else I should be aware of? Also, for context, we are not using multi-AZ with standby, which is mentioned in the docs as something that could affect this. We do have multi-AZ enabled without any standbys, so according to the documentation, it should be supported. The reason I need to change this setting is to set an alert for when the number of shards approaches the max_shards_per_node limit, but it feels like there's a barrier to doing so. Any insights would be appreciated!
2 Answers
It sounds like your permissions might be the culprit. Even though your user has 'all access,' sometimes the role might not propagate correctly after an upgrade. Try checking if the master user role has been assigned correctly and if there are any new permissions introduced in 2.17 that might affect access. Also, consider validating that the cluster settings you are trying to modify are supported in this configuration, especially since you mentioned not using standby. It's worth double-checking the documentation on this topic too.
Another angle could be the API endpoint for the PUT request. Ensure there are no URL changes or additional requirements specific to the 2.17 version. A lot can change between minor updates, so just reducing the risk of changes in endpoint handling could save you some trouble. Also, if there are any specific logs available on the OpenSearch side, they might provide more insight into the 401 error.
Yeah, if you have access to the logs, that could really help in pinpointing the error. Sometimes, the details can lead you right to the issue.