Previously this would truncate to the nearest integer, which could
result in clients retrying before the quota has reset, and getting rate
limited again. This also includes an update from go-rate that will round
up when reporting the reset time for the RateLimit header.
Note that in the case of a 503, the Retry-After header was already being
set correctly.
See: https://github.com/hashicorp/go-rate/pull/8
If the api.Client receives a 429 or 503 along with a Retry-After header,
the client will automatically wait the amount of time specified, and
then re-try the request.
A sys event will be emitted when the controller is constructed, and if
the rate limits are changed via a SIGHUP. The event contains the details
of the rate limits for each combination of resource and action. This
event can be used by operators to confirm the limits are set as they
would expect based on the controller config.
This provides two prometheus metrics to monitor the rate limiter:
boundary_controller_api_ratelimiter_quota_storage_capacity:
This is a gague that shows the total number of quotas that can be stored
at a given moment by the rate limiter.
boundary_controller_api_ratelimiter_quota_storage_usage:
This is a gague that shows the number of quotas currently being stored
by the limiter. If this becomes equal to the capacity, requests that
would result in a new quota being created will get limited and receive a
429 status code.
This registers the ActionSets for each resource when the handler
packages are initialized. This then allows other packages to retrieve
the ActionSets for a given resource from the action package.
The initial consumer of this will be the ratelimit package so that it
can programmatically enumerate all of the valid combinations of a
resource and action.
This leaves a number of TODO to refactor the handler packages to also
retrieve the action sets from the registered actions instead of using a
package variable. This is left as a TODO since there is some
inconsistencies in how these package variables are used between the
handlers. For example a number of packages use a map of subtypes to
ActionSets which is then used withing the handler implementation. Others
use a map, but don't seem to use it at all. And others just use an
ActionSet.
This switches the implementation of an ActionSet from a slice to a map
to ensure the elements in an ActionSet are unique. This allows for other
packages to perform set operations such as a union or difference without
needing to account for duplicates.
* chore (managed groups): just a small rename to improve readability
* test (aut/ldap): add a test for user grants based on ldap grp
* tests (role grant): extend TestGrantsForUser(...) to cover ldap grps
* refact (iam.(Repository).GrantsForUser): more readable grantsQuery
Convert existing CTE to use sub-selects for readability
* test(e2e): Add test for LDAP
This adds the infrastructure and a test for an LDAP workflow
* test(e2e): Refactor test packages
This reduces the number of scenarios needed
* CR
* fixup! test(e2e): Add test for LDAP
* subtypes,handlers: add runtime trace regions
The subtype.Filterable and handlers.ProtoToStruct functions
are costly and worth measuring whenever runtime tracing
is in use. This has almost no cost when tracing is not in use,
so there's little harm in having them in place.
* testing: Add TRACING.md
TRACING.md contains information about how to perform
Go runtime tracing of the Boundary application.
Boundary OIDC method does not currently support passing in prompts during authentication. This change adds the capability of passing OIDC prompts. Prompts are optional OIDC parameters that determine the behaviour of the authentication server: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
## Changes
- New `auth_oidc_prompt` table which contains all the prompts for OIDC auth method
- New `auth_oidc_prompt_enm` table which contains possible enum values for a prompt
- Currently supported:
- `none`:
The Authorization Server MUST NOT display any authentication or consent user interface pages
- `login`: The Authorization Server SHOULD prompt the End-User for reauthentication
- `consent`: The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client
- `select_account`: The Authorization Server SHOULD prompt the End-User to select a user account
- `oidc_auth_method_with_value_obj` view has been updated to return `prompt` value
- Add `prompt` option for OIDC auth method CLI create and update
- Pass configured prompt during OIDC authentication
- Add `prompt` API validation for create and update
* Add generic read/update/delete commands
This adds three generic commands that use the resource prefix to
determine the subcommand to run and pass through args over to that
subcommand. Since this occurs very early on and to avoid loading
essentially every internal resource package, I moved subtype definitions
to globals.
This replaces #3967
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* De-duplicate Subtype code (#4031)
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
* If passing a private key without specifying it in URL syntax, give a
proper error message (previously we were only making sure it was a
scheme we knew how to handle, but we need to also be more informative
if it's not a URL at all)
* If the handshake from the proxy fails, don't hang, just exit
* Update some error messages to use capitalization in line with our
standard CLI error format
Timothy Messier
hashicorp-tsccr[bot]andhashicorp-tsccr[bot]
Lisbet Alvarez
Dan Heath
Damian Debkowski
Michael Li
Jim
hc-github-team-es-release-engineering
Johan Brandhorst-Satzkorn
Elim Tsiagbey
Sepehr