Vault.logical.write fails when writing to a path that doesn't support reads

[olly]

I was trying to programatically setup the postgresql secret backend:

Vault.sys.mount('postgresql', 'postgresql')
Vault.logical.write('postgresql/config/connection', value: 'postgresql://localhost/vault_database_connection_test?sslmode=disable')

This raises a Vault::HTTPError:

/usr/local/var/rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/vault-0.1.3/lib/vault/client.rb:278:in `error': The Vault server at `http://127.0.0.1:8200' responded with a 500. (Vault::HTTPError)
Any additional information the server supplied is shown below:

  * unsupported operation

Please refer to the documentation for help.
    from /usr/local/var/rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/vault-0.1.3/lib/vault/client.rb:183:in `block in request'
    from /usr/local/var/rbenv/versions/2.2.0/lib/ruby/2.2.0/net/http.rb:853:in `start'
    from /usr/local/var/rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/vault-0.1.3/lib/vault/client.rb:173:in `request'
    from /usr/local/var/rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/vault-0.1.3/lib/vault/client.rb:59:in `get'
    from /usr/local/var/rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/vault-0.1.3/lib/vault/api/logical.rb:27:in `read'
    from /usr/local/var/rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/vault-0.1.3/lib/vault/api/logical.rb:48:in `write'
    from test.rb:4:in `<main>'

This is caused in logical.rb as it attempts to read from the path after it writes.

I would expect the above to work, but it's possible to work around it with the following:

 client.put('/v1/postgresql/config/connection', JSON.fast_generate(value: 'postgresql://olly@localhost:5432/vault_database_connection_test?sslmode=disable'))

[sethvargo]

Hi @olly

I believe this might have been fixed in #7. Could you please give it a shot? Thanks!

[olly]

I just tested it against master, and #7 hasn't fixed it (it looks like that PR was released in 0.1.13, which IIRC was the version I was using).

The issue is that "postgresql/config/connection" doesn't have a corresponding "read" endpoint. As I see it, the only sensible thing to do is to return nil, in this case. The question then is, do we want to try and read a value and return nil if it fails. Or not attempt to read at all?

I'd favour the later I think. Unless I'm missing something, if you've just written the secret, you shouldn't need to read it again immediately.

[jstremick]

Ran into this while configuring AWS secret backends on 0.1.3. I agree with @olly that not attempting to read makes more sense.