This was a flawed test. Previously the test passed in a fixture that
corresponded to a CLI config file, not an actual policy. The test
_should_ have been failing, but it wasn't. This commit adds a new
fixture.
This does NOT apply to the backend config, since each backend config
could have a variation of options that differ based off of the
configured backend itself. This may be an optimization that can be made
in the future, but I think each backend should be responsible for
performing its own configuration validation instead of overloading the
config itself with this functionality.
In some situations, it can be impossible to revoke leases (for instance,
if someone has gone and manually removed users created by Vault). This
can not only cause Vault to cycle trying to revoke them, but it also
prevents mounts from being unmounted, leaving them in a tainted state
where the only operations allowed are to revoke (or rollback), which
will never successfully complete.
This adds a new endpoint that works similarly to `revoke-prefix` but
ignores errors coming from a backend upon revocation (it does not ignore
errors coming from within the expiration manager, such as errors
accessing the data store). This can be used to force Vault to abandon
leases.
Like `revoke-prefix`, this is a very sensitive operation and requires
`sudo`. It is implemented as a separate endpoint, rather than an
argument to `revoke-prefix`, to ensure that control can be delegated
appropriately, as even most administrators should not normally have
this privilege.
Fixes#1135
renew-self endpoint. Otherwise it will use the renew endpoint, even if
the token matches the client token.
Adds an -increment flag to allow increments even with no token passed
in.
Fixes#1150
