search

hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
30.89k stars 4.18k forks source link

The `sys/storage/raft/*` APIs OpenAPI documentation cannot be retrieved from `vault server -dev` instance #18872

Open maxb opened 1 year ago

maxb commented 1 year ago

Running a vault server -dev instance briefly, to retrieve OpenAPI documentation from it, is a useful practice when you want the OpenAPI doc for further processing.

This practice is even codified in scripts/gen_openapi.sh in the Vault repo.

An OpenAPI document generated in this way will be missing the sys/storage/raft/* APIs.

This is because these are only actually configured in a running Vault server when it is using Raft storage, and there is no way to make this true with a -dev server.

I propose that we register the sys/raft/* APIs with the URL routing system unconditionally. Most but not all of them already include a further runtime check to error if Raft storage is not in use:

        raftBackend := b.Core.getRaftBackend()
        if raftBackend == nil {
            return logical.ErrorResponse("raft storage is not in use"), logical.ErrInvalidRequest
        }

We would simply extend this to the remaining ones.

I did consider the alternative of adding another flag, such as -dev-raft, to start a dev server that uses Raft storage... however that's a fairly complicated option just to get the correct API definitions, and Raft takes time to initialise. I'm not so fond of this option.

@averche FYI as I know this is relevant for your generated API project.

maxb commented 1 year ago

Also, it seems like Enterprise registers its sys/storage/raft/snapshot-auto/* with the router regardless of whether Raft is enabled or not, so it would be good to be consistent with that behaviour for the rest of sys/storage/raft/*, too.