Updates all List endpoints to automatically paginate
through results to preserve backwards compatibility.
Adding support for user controllable pagination could
be considered at a later time.
The max_page_size variable lets operators control the size of the
pagination pages. This value configures both the maximum permitted
page size and the default page size when none is explicitly provided.
Operators can tweak this option up or down to increase or reduce
the load on the database during pagination.
The ListRefreshToken type is used, in its marshalled form,
for pagination requests. A new refresh token is returned
which each invocation of a list method (unless
there was no input refresh token and there were no results).
The pagination package provides generic functions for
iterating over a collection of items such that each incoming
request is filled even after filtering is applied.
The refreshtoken package encapsulates domain logic surrouding
the refresh token. A refresh token is used both for
paginating through a collection and for requesting any
updates to that collection.
The resource type method is used to automatically
create refresh tokens from a resource when that
resource is the last item returned in a page.
This also renames the iam domain ResourceType method
to GetResourceType to align with the new method.
Creates a new foo_deleted table for each subtype of each
resource that needs to support pagination. The deleted
tables are used to track deletions of resources and return
them to users of the new pagination API. We track only the
ID and delete_time of the resource, so there's no way to
filter out resources that the user could not see before it
was deleted. This is intentional to keep the design simple
and is not considered a security issue.
This increases the default rate limits to:
- 1,500 reqs / 30 seconds for list actions in total
- 1,500 reqs / 30 seconds for list actions per IP address
- 150 reqs / 30 seconds for list actions per auth token
And for all other actions:
- 30,000 reqs / 30 seconds for list actions in total
- 30,000 reqs / 30 seconds for list actions per IP address
- 3,000 reqs / 30 seconds for list actions per auth token
This seems to be a reasonable default for a small to medium size cluster
based on some scale testing.
(cherry picked from commit 237c8b6084f42655edaba49055e511163fdf1c53)
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
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
* 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
Johan Brandhorst-Satzkorn
Jeff Mitchell
hc-github-team-es-release-engineering
Damian Debkowski
Lisbet Alvarez
Timothy Messier
Elim Tsiagbey
Jim