Limiting Root Protected Endpoints

This blog post is a follow up from a previous post Monitoring Root Protected API Endpoints on Vault where we learned why its important to monitor Vault endpoints and the many methods of doing so.

As with all software, new features are continually added to projects and the issue I was following for rate limiting endpoints has finally been closed.

With this blog post I want to provide a high level overview on how this rate limiting works as well as a review on why its important, make a call to action for Vault to improve upon how this feature is setup and lastly provide resources on how to get this setup and ready to use.

Overview of the Feature

Leveraging the token bucket algorithm Vault has implemented API rate limiting. The token bucket algorithm can be simply described as having a bucket that can only hold N number of tokens. Once the bucket has reached to the Nth number of tokens the bucket stops accepting new tokens.

Vaults limits are applied via unique client IP address requests per node until they reach the determined quota. This quota can be configured at the root level (empty path) where it is inherited by all namespaces and mounts or at the namespace level overriding the global quota.

In addition to setting up the default rate, a block-interval period in seconds can be set configuring the length in which blocked clients will be prevented from making additional requests.

While I hoped to cover everything in the topic surrounding rate limiting now and for the future, do checkout out the Vault website for an up-to-date overview on Resource Quotas.

Call to Action

While being aware of the technology you are using is important, many customers of Vault assume it is configured by default to provide a high level of security. That assumption, however, breaks when it comes to rate limiting.

My call to action for Vault is to implement a default global rate limit and block-interval that can be over-ridden as administrators see fit. This will help Vault become more secure by default while still allowing ‘advanced’ users the flexibility to disable/modify the default configuration.

Setup

For a more detailed tutorial on setting up resource-quotas please checkout this HashiCorp’s Learn page. In short, to enable rate limiting at the global level you simply run

vault write sys/quotas/rate-limit/global-rate rate=500

… for a path specific rate limit you add the additional path parameter like so

vault write sys/quotas/rate-limit/global-rate rate=500 path=/my-namespace

Conclusion

To summarize, being aware of most, if not all, configuration options for Vault is a must in any organization that intends to leverage Vault as their primary secret store due to the path Vault has gone down with default configuration.

Nebulaworks has helped many organizations rapidly adopt Vault in a wide range of computing platforms from architecture design, all the way down to monitoring. You can reach out to us to learn more about how we can help your team get started with Vault services.