VAULT-35628 Add group_by and secondary_rate to RLQ API #30447
Conversation
|
CI Results: |
16bfd56 to
c49fe65
Compare
changelog/30447.txt
Outdated
| @@ -0,0 +1,3 @@ | |||
| ```release-note:improvement | |||
| core/quotas: Add new fields to the rate limit quota API to support different grouping modes on enterprise version. | |||
There was a problem hiding this comment.
| core/quotas: Add new fields to the rate limit quota API to support different grouping modes on enterprise version. | |
| core/quotas (enterprise): Add new fields to the rate limit quota API to support different grouping modes. |
There was a problem hiding this comment.
Actually: should this be added at this stage? It looks like this is not the full feature (which makes sense, it's good that we split them up), but we should only have one changelog that describes the full feature irrespective of how many PRs we have.
There was a problem hiding this comment.
It also might want to be a feature changeog compared to improvement, but we can figure that out later
There was a problem hiding this comment.
good point, I'll keep the changelog until the whole thing is in
|
Build Results: |
|
Will go ahead with the merge following this process. Running the diff command I see there's no difference between ent and CE PRs except the ent files: |
* Add group_by and secondary_rate to RLQ API * fix CE test * add more docs * fix tests and linter error * add changelog * address feedback * remove changelog
Description
This PR adds the
group_byandsecondary_ratefields to the RLQ API. These won't provide any additional functionality in CE, as we maintain support only to the current behavior there, but now as an explicit "IP" grouping mode. On enterprise we'll add 3 additional grouping modes to support different use cases:group_by: nonegroups all requests to which the RLQ applies together (i.e. collective rate limit);group_by: entity_then_ipgroups requests to which the RLQ applies by entity Id if available, otherwise by the client IP address (e.g. login or root token requests);group_by: entity_then_nonegroups requests to which the RLQ applies by entity Id if available, and all entity-less requests together (e.g. login or root token requests)To make things simpler most of the API and storage handling of the new fields will be present in both CE and ent codebases, it's only the evaluation of those fields that'll be moved to the ent codebase.
Jira: VAULT-35628
RFC: VLT-352: Identity-based and collective rate limit quotas
Ent PR: https://github.com/hashicorp/vault-enterprise/pull/7998
TODO only if you're a HashiCorp employee
backport/label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x, but older release branches will bebackport/ent/x.x.x+ent.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.