open-vault/website/pages/docs/concepts/resource-quotas.mdx
2020-08-16 22:09:18 -04:00

73 lines
3.1 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
layout: docs
page_title: Resource Quotas
sidebar_title: Resource Quotas
description: Providing measures against misbehaving applications and users overdrawing resources in Vault.
---
# Resource Quotas
Every single interaction with Vault, whether to put secrets into the key/value
store or to generate new pairs of database credentials for the MySQL database,
needs to go through Vaults API.
One side effect of the API driven model is that applications and users can
misbehave by overwhelming system resources through consistent and high volume API
requests resulting in denial-of-service issues in some Vault nodes or even the
entire Vault cluster. This risk is significantly increased when Vault API endpoints
are exposed to thousands or millions of services deployed across a global infrastructure,
especially in use cases of Vault where Vault is deployed as a service for internal
developers.
Vault provides a feature, resource quotas, that allows Vault operators to specify
limits on resources used in Vault. Specifically, Vault allows operators to create
and configure API rate limits.
## Rate Limit Quotas
Vault allows operators to create rate limit quotas which enforce API rate
limiting using a [token bucket](https://en.wikipedia.org/wiki/Token_bucket) algorithm.
A rate limit quota can be created at the root level or defined on a namespace or
mount by specifying a `path` when creating the quota. The rate limiter is applied
to each unique client IP address on a per-node basis (i.e. rate limit quotas
are not replicated). A client may invoke `rate` requests at any given second,
after which they may invoke additional requests at `rate` per-second.
A rate limit quota defined at the root level (i.e. empty `path`) is inherited by
all namespaces and mounts. It acts as a single rate limiter for the entire Vault
API. A rate limit quota defined on a namespace takes precedence over the global
rate limit quota, and a rate limit quota defined for a mount takes precedence over
the global and namespace rate limit quotas. In other words, the most specific
quota rule will be applied.
A rate limit can be created with an optional `block_interval`, such that when set
to a non-zero value, any client that hits a rate limit threshold will be blocked
from all subsequent requests for a duration of `block_interval` seconds.
Vault also allows the inspection of the state of rate limiting in a Vault node
through various [metrics](/docs/internals/telemetry#Resource-Quota-Metrics) exposed
and through enabling optional audit logging.
## Exempt Routes
The following routes are always exempt from rate limiting:
- `/v1/sys/generate-recovery-token/attempt`
- `/v1/sys/generate-recovery-token/update`
- `/v1/sys/generate-root/attempt`
- `/v1/sys/generate-root/update`
- `/v1/sys/health`
- `/v1/sys/seal-status`
- `/v1/sys/unseal`
## Learn
Refer to [Protecting Vault with Resource
Quotas](https://learn.hashicorp.com/vault/security/resource-quotas) for a
step-by-step tutorial.
## API
Rate limit quotas can be managed over the HTTP API. Please see
[Rate Limit Quotas API](/api/system/rate-limit-quotas) for more details.