cyberark / conjur-openapi-spec

OpenAPI v3 specification for Conjur / DAP v10+

Home Page:https://conjur.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Determine if we can flag undocumented new routes in the spec automation

izgeri opened this issue · comments

We may be able to flag when new routes are added to Conjur but not documented by auto-generating the spec YAML from the Ruby routes of Conjur and comparing it to the the actual spec.

In this issue, we are going to try this out to see if it could be a useful tool for ensuring Conjur + the spec stay in sync.

It looks like there are two main ways to go about retrieving route information from the conjur server. Rails provides a command rails routes which outputs all of the servers current routes. The main issue with this is that there is no way to get an easily parseable output so a parser would have to be written to handle the output. The other option is to inject a small amount of code into the routes.rb file before running Conjur that will save route information to a file which could then be accessed externally. I was able to achieve this using the following:

output = File.new('output', 'w')
data = ""
Rails.application.routes.routes.map do |n|
  data += n.path.spec.to_s + "\n"
end
output.write data
output.close()

The output could also be JSON or YAML formatted for ease of use. After getting the route information from Conjur we should be able to just read in the main spec files paths object, which is just a list of routes and compare the two. It might get a little tricky to get this fully working because the way we define paths in the spec is not 1 - 1 with Conjur.

It's also worth noting that this type of check wouldn't necessarily catch a new authenticator being added because of the way Conjur handles their routes. As is I don't see a way to reliably check for new authenticators being added.

@izgeri @john-odonnell Do you think we want to move forward with implementing a check like this?

I think we should file a card to implement this but keep it at a low priority. If we can train everyone on updating the spec well, this won't be an issue - but if it starts to become one, we can implement this card.

@telday can you file a follow-up issue and close this card?

@izgeri did you want something beyond #150?