Does elastic have a healthcheck endpoint that does not require username and password

Problem description: AWS ALB health check does not take in username and password. For elastic search container to attach to ALB and pass its health check, I have to enable the anonymous user in elastic and assign it the superuser role.
xpack.security.authc:
anonymous:
username: anonymous
roles: superuser
authz_exception: false

The problem is that anonymous user role is also inherited by other created users later, so the user role does not work. Any user created, although they are assigned with specific role, they all seem to have superuser role permission. I would like to disable the anonymous user, but also would like to know if there is a way to perform a health check without providing username and password to health check endpoint

@pingz I think you can create your own role with restricted privileges, and not use the superuser role for anonymous access.

Currently there isn't any separate dedicated healthcheck endpoint with different restrictions. https://github.com/elastic/elasticsearch/issues/50187 is open to handle health checks differently in Elasticsearch.

Looking at AWS ALB documentation, it looks like the LoadBalancer has its own healthcheck logic, that can be configured when used through an Ingress resource. I would have expected the healthcheck to be bound to the Pod readiness but apparently that's not the case. I don't see any way to add authentication to the healthcheck.
A workaround could be to setup your own sidecar container in the Elasticsearch podTemplate, that would listen to an unauthenticated HTTP port to perform authenticated Elasticsearch calls.
You can also use a different Ingress implementation.ingress-nginx is a popular one.

@michael.morello rightly pointed out to me that you can also customize the ALB success-code annotation to consider an HTTP 401 status code means the Pod is ready. Far from perfect of course.

I created https://github.com/elastic/cloud-on-k8s/issues/2488 to improve our documentation around this.

Hi Sebgl:

Thanks for your reply. Yes, I am considering using 401 status code as a workaround for elastic. For Kibana I used /login rest api, will need to check its code from 200 to something else as well.