Add GET endpoint to return mirror node version and config

[mshakeg]

Problem

As a developer, I would like to get the mirror node version and config.

This request is similar to that outlined in hashgraph/hedera-json-rpc-relay/issues/1024

Solution

• Add a GET endpoint say with path /api/v1/config that returns the mirror node version and config

Alternatives

No response

[steven-sheehy]

The mirror node already returns the version in the SwaggerUI as you can see in the top left of https://mainnet-public.mirrornode.hedera.com/api/v1/docs/. You can parse this out pretty easily from the xHTML. Of course the payload is not as minimized as a dedicated version JSON endpoint but apps can cache this data for long periods of time. I can see the business value of exposing the version, but I think the current endpoint might suffice for programmatic and non-programmatic needs.

The mirror node is a micro-service architecture with 8 different applications that communicate with each other, consensus nodes, Redis, and PostgreSQL. Each of them have the same version, but entirely different config. It wouldn't be possibly to display the config for all 8 different apps as it would mean the REST API process had to be made aware of the other 7 apps instead of staying decoupled as it is now.

The Java processes do have Spring Boot actuator endpoints that do display its version, config and other info, but the config can contain sensitive secrets that we don't want to accidentally reveal so we don't enable or expose those endpoints by default. It's too risky and complex to expose config info and don't see the business value in doing so.

[mshakeg]

@steven-sheehy config values that are secrets simply do not have to be returned. It's more about consumers of a mirror node to get an idea of the capabilities of that particular mirror node. For example if the max gas limit is configurable then clients that call the /contract/call endpoint will find this useful.

Does the mirror node list all the config variables somewhere like the relay does here? Most of the relay's config variables are not secrets and there's no issue is exposing them and I'm sure many would appreciate and find this data to be very helpful.

[steven-sheehy]

We do have a configuration doc that lists all the available properties. As you can see, there's a lot and there's different processes involved. For example, most REST APIs are served via the node.js based REST API but the /contracts/call is served via the Java based web3 process. It's not feasible to expose a /api/v1/config that could return both the config from the node.js and the java server. And it would be an easy source for leaking secrets regardless of how carefully we craft the endpoint.

[mshakeg]

@steven-sheehy thanks for the reply, though could you elaborate on how:

it would be an easy source for leaking secrets regardless of how carefully we craft the endpoint

If the endpoint is implemented to only return config variables that are explicitly stated I don't see how that would be a possibility.

---

Also if a single /api/v1/config endpoint isn't feasible as the mirror node runs multiple services that don't communicate with each other then multiple endpoints could be implemented e.g. /api/v1/java/config for the java process and /api/v1/node/config for the node.js process.

[steven-sheehy]

If the endpoint is implemented to only return config variables that are explicitly stated I don't see how that would be a possibility.

A whitelisted config may reduce the security concern, but it doesn't eliminate it and quickly becomes a maintenance burden. Users will open tickets for "missing property foo". Developers will have to remember to update this whitelist for every new property. Then there's a risk they just always add new properties and a property gets accidentally whitelisted.

There's a large risk for very little gain. All of our config for every environment is already public in the deploy branch. It also lists the version deployed. Any application defaults won't be listed but they can be looked up from the specific tag's configuration.md.

[mshakeg]

@steven-sheehy hmm, ok, but if it's a maintenance burden that's a large risk for very little gain on the mirror node wouldn't it also be that on the relay?

[steven-sheehy]

I can't speak to the relay. Going to close this as wontfix.