Remove curl from the Docker image

[jasontedor]

Today the Elasticsearch Docker image contains the curl package and related dependencies. We would like to see curl removed from the Docker image because it's a common source of CVEs. Today, there are two internal dependencies on curl being in the image:

• in the ECK operator, for configuring a readiness probe
• in the Elasticsearch test suites, for docker-compose health checks (e.g., in the Wildyfly tests, among many others)

Removing the dependency on curl from ECK will be addressed by #81168. The purpose of this issue to capture the request to remove curl from the Elasticsearch Docker image, and propose a path forward for the second dependency, the usage of curl within the Elasticsearch test suite.

I propose the introduction of an es_isready CLI application. This would be a simple Java-based application using the native Java HTTP client, that hits the unauthenticated readiness endpoint proposed in #81168. With the introduction of es_isready, the docker-compose health checks that rely on curl could be replaced to use es_isready instead. The behavior of es_isready would be straightforward: if the unauthenticated readiness endpoint from #81168 returns 200, then es_isready returns status code 0, and otherwise returns status code 1.

@pugnascotia, let me know if I'm missing any context from our discussion.

[elasticmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[pugnascotia]

Just a thought - would there be any benefit to providing a simple implementation of the es_isready CLI tool, either just wrapping curl or using Java standard classes, so that we immediately deprecate using curl? Then when #81168 is addressed, we can change the implementation to use the new endpoint instead.

[jasontedor]

It's a good thought, but I don't think there'd be much benefit to that. I assume that as implemented today, the es_isready tool would still need credentials, which presents a challenge already. If we did this intermediate step, we'd end up having three implementations:

• today's implementation to check if ES is ready, with curl and credentials
• a future implementation to check if ES is ready, with es_isready and credentials
• a future implementation to check if ES is ready, with es_isready (without credentials)

I'd rather avoid the intermediate implementation since it doesn't offer many advantages over the first, until we get the long-term solution.

[mark-vieira]

I'd rather avoid the intermediate implementation since it doesn't offer many advantages over the first, until we get the long-term solution.

By long-term solution I presume you are referring to #81168, in which case I've mentioned in that issue that having a tool similar to what @pugnascotia is describing might indeed be quite useful. It would still be backed by some generic endpoint but I can see the benefit in bundling a tool that effectively acts as a client to to that endpoint.

[jasontedor]

The long-term solution is es_isready && not requiring credentials. That was my third bullet in #81177 (comment).

[pugnascotia]

The credentials part is the show-stopper. We could generate credentials at startup, but then we'd need to store them somewhere, etc, and it would rapidly become more effort than it was worth.

[pugnascotia]

The Helm charts also use curl, as does our Iron Bank Docker image, though the latter can use the proposed readiness command.