search

cyberark / conjur

CyberArk Conjur automatically secures secrets used by privileged users and machine identities
https://conjur.org
Other
780 stars 124 forks source link

Adds info endpoint for server/follower ID and version for debugging #1519

Open diverdane opened 4 years ago

diverdane commented 4 years ago

Is your feature request related to a problem? Please describe.

When troubleshooting issues in the field or in development, it would be very useful to have an endpoint served on Conjur servers and followers that would allow a quick assessment of: (a) Who is responding (e.g. some unique identifier to identify particular server/follower that is responding) (b) Basic info about the server/follower

In particular, having an endpoint that supports (a) would make it much easier to check on servers/followers that are set up behind a load balancer network. When the topology includes load balancers, it's very difficult and tedious to determine which and how often servers/followers are responding to queries.

An endpoint as described would offer essentially a "who are you" logical ping.

Note that Conjur OSS version 4 used to support an endpoint for a conjur server info CLI command, but this support isn't present in Conjur version 5, AFAICT. (I believe that this endpoint is available on the Conjur enterprise version).

Describe the solution you would like

An endpoint exists that can be used to do a "who are you" logical ping of servers/followers, providing a unique identification, and optionally some basic info (including version).

Describe alternatives you have considered

Additional context

The use case for this is described in this PR: https://github.com/cyberark/dap-wiki/pull/13/files

izgeri commented 4 years ago

@cyberark/conjur-core-team I'd be interested in your feedback on adding this route. In particular, I know DAP also has an /info route and I assume if we add a route to OSS, we'd have to manage conflicts in the appliance routing. Can you please share any thoughts you have on this here? If we have a plan in place, it's possible we could add this in the next couple of weeks.

micahlee commented 4 years ago

Any new routes should not use existing paths, so I would be strongly against adding /info to OSS while it still exists as a standalone service in DAP. That opens a door to confusion that is probably unnecessary.

I get the value in version, but that could make sense to add to the root path (/) with Accepts: application/json, for example, to make this automate-able, rather than just the HTML response with that information.

Where would the "unique identification" come from?

liavyona commented 4 years ago

Maybe we can use /version ? and return json information about the versions (Conjur, maybe postgres and etc..)

micahlee commented 4 years ago

Maybe we can use /version?

We could, but / already returns the version, just in an undesired format (HTML instead of JSON). Updating this endpoint to respect the Accepts header would, IMO, be more appropriate than adding a new endpoint.