generic type that takes in a user-defined request
body to send to Vault and thus can work for any type of Vault secrets engine.
When a credential library is used to fetch a credential, if the credential
contains a lease, Boundary will keep the credential refreshed, and revoke the
credential when the session that requested it is finished.boundary connect Credential Brokering Integration: Additionally, we have
started integration into the boundary connect helpers, starting in this
release with the Postgres helper; if the credential contains a
username/password and boundary connect postgres is the helper being used,
the command will automatically pass the credentials to the psql process.NOTE: When using credential brokering, remember that if the user can connect directly to the end resource, they can use the brokered username and password via that direct connection to skip Boundary. This isn't any different from normal Boundary behavior (if a user can directly connect, they can bypass Boundary) but it's worth repeating.
password account IDs: When the oidc auth method came out, accounts were
given the prefix acctoidc. Unfortunately, accounts in the password method
were using apw...oops. We're standardizing on acct and have updated the
password method to generate new IDs with acctpw prefixes.
Previously-generated prefixes will continue to work.boundary dev mode now extend to the accounts created
in the default password and oidc auth methods.cors_enabled is not specified for a listener is changing
to be equivalent to a cors_allowed_origins value of *; that is, accept all
origins. This allows Boundary, by default, to have the admin UI and desktop
client work without further specification of origins by the operator. This is
only affecting default behavior; if cors_enabled is explicitly set to
true, the behavior will be the same as before. This had been changed in
v0.2.1 due to a bug found in v0.2.0 that caused all origins to always be
allowed, but fixing that bug exposed that the default behavior was difficult
for users to configure to simply get up and running.cancel operation is run on a session already in a canceling or
terminated state, a 200 and the session information will be returned instead
of an error.200 and session information when canceling an
already-canceled or terminated session
(PR)cors_enabled is not specified
to be *. (PR)aud claim as a string or []string,
Boundary will properly parse the claims JSON.
(issue,
PR)terminated state because connections are not properly marked closed.
(Issue 1, Issue
2,
PR)json format output, the
command will no longer print out a notice that it's opening your web browser
(Issue,
PR)delete actions now result in a 204 status code and no body when
successful. This was not the case previously due to a technical limitation
which has now been solved.delete command within the CLI we now either show success or
treat the 404 error the same as any other 404 error, that is, it results
in a non-zero status code and an error message. This makes delete actions
behave the same as other commands, all of which pass through errors to the
CLI. Given -format json capability, it's relatively easy to perform a check
to see whether an error was 404 or something else from within scripts, in
conjunction with checking that the returned status code matches the API error
status code (1).item or items (depending on the action) now exactly matches the JSON sent
across the wire by the controller, as opposed to matching the Go SDK
representation which could result in some extra fields being shown or fields
having Go-specific types. This includes delete actions which previously
would show an object indicating existence, but now show no item on success
or the API's 404 error.list, read:self, and delete:self on auth-token resources. This
allows a user to list and manage their own authentication tokens. (As is the
case with other resources, list will still be limited to returning tokens on
which the user has authorization to perform actions, so granting this
capability does not automatically give user the ability to list other users'
authentication tokens.)permissions: Improving upon the work put into 0.2.0 to limit the fields that
are returned when listing as the anonymous user, grants now support a new
output_fields section. This takes in a comma-delimited (or in JSON format,
array) set of values that correspond to the JSON fields returned from an API
call (for listing, this will be applied to each resource under the items
field). If specified for a given ID or resource type (and scoped to specific
actions, if included), only the given values will be returned in the output.
If no output_fields are specified, the defaults are used. For authenticated
users this defaults to all fields; for u_anon this defaults to the fields
useful for navigating to and authenticating to the system. In either case,
this is overridable. See the permissions
documentation
for more information on why and when to use this. This currently only applies
to top-level fields in the response.
cli/api/sdk: Add support to request additional OIDC claims scope values from the OIDC provider when making an authentication request. (PR).
By default, Boundary only requests the "openid" claims scope value. Many providers, like Okta and Auth0 for example, will not return the standard claims of email and name when you request the default claims scope (openid).
Boundary uses the standard email and name claims to populate an OIDC
account's Email and FullName attributes. If you'd like these account
attributes populated, you'll need to reference your OIDC provider's documentation
to learn which claims scopes are required to have these claims returned during
the authentication process.
Boundary now provides a new OIDC auth method parameter claims_scopes which
allows you to add multiple additional claims scope values to an OIDC auth
method configuration.
For information on claims scope values see: Scope Claims in the OIDC specification
cli: Match JSON format output with the across-the-wire API JSON format (PR)
api: Return 204 instead of an empty object on successful delete operations
(PR)
actions: The new no-op action allows a grant to be given to a principals
without conveying any actionable result. Since resources do not appear in list
results if the principal has no actions granted on that resource, this can be
used to allow principals to see values in list results without also giving
read or other capabilities on the resources. The default scope permissions
have been updated to convey no-op,list instead of read,list.
(PR)
cli/api/sdk: User resources have new attributes for:
These new user attributes correspond to attributes from the user's primary auth method account. These attributes will be empty when the user has no account in the primary auth method for their scope, or there is no designated primary auth method for their scope.
cli: Support for reading and deleting the user's own token via the new
read:self and delete:self actions on auth tokens. If no token ID is
provided, the stored token's ID will be used (after prompting), or "self"
can be set as the value of the -id parameter to trigger this behavior
without prompting. (PR)
cli: New logout command deletes the current token in Boundary and forgets it
from the local system credential store, respecting -token-name
(PR)
config: The name field for workers and controllers now supports being set
from environment variables or a file on disk
(PR)
auth-methods/<id>:authenticate:login action is deprecated and will be
removed in a few releases. (Yes, this was meant to deprecate the
authenticate action; apologies for going back on this!) To better support
future auth methods, and especially the potential for plugins, rather than
defining custom actions on the URL path the authenticate action will consume
both a map of parameters but also a command parameter that specifies the
type of command. This allows workflows that require multiple steps, such as
OIDC, to not require custom subactions. Additionally, the credentials map in
the authenticate action has been renamed attributes to better match other
types of resources. credentials will still work for now but will be removed
in a few releases. Finally, in the Go SDK, the Authenticate function now
requires a command value to be passed in.auth-methods/<id>:authenticate call will return the given command value
and a map of attributes that depend on the given command. On the SDK side, the
output of the Authenticate function returns a map, from which a concrete
type can be easily umarshaled (see the updated authenticate password command
for an example).u_anon), only
information necessary for navigation to an auth method and authenticating to
the auth method is now output. Granting u_anon list access to other resource
types will not currently filter any information out.oidc subcommands available on CRUDL
operations for examples).
PRauthenticate password oidc subcommand for an example)
PRlist action is not longer
required to be granted to the calling user. Instead, the given scope acts as
the root point (so only results under that scope will be shown), and list
grant is evaluated per-scope.
PRdatabase migrate command works.
PRResponseMap()
and ResponseBody(), resources simply expose Response(). This higher-level
response object contains the map and body, and also exposes StatusCode() in
place of indivdidual resources.
PRjson output format, a resource item is now an object under the
top-level key item; a list of resource items is now an list of objects under
the top-level key items. This preserves the top level for putting in other
useful information later on (and the HTTP status code is included now).
PRjson output format, errors are now serialized as a JSON object with
an error key instead of outputting normal text
PRstderr. Previously
in the default table format, API errors would be written to stdout.
PR1 indicates an error generated from the actual controller API; an
error code of 2 is an error encountered due to the CLI command's logic; and
an error code of 3 indicates an error that was caused due to user input to
the command. (There is some nuance sometimes whether an error is really due to
user input or not, but we attempt to be consistent.)
PRSIGHUP. (This likely
worked before but wasn't fully tested.)
(PR)SIGHUP, worker
tags will be
re-parsed and new values used
(PR)tls_min_version listener configuration
value, tls_max_version is now supported. This should generally be left blank
but can be useful for situations where e.g. a load balancer has broken TLS 1.3
support, or does not support TLS 1.3 and flags it as a disallowed value.Release boundary v0.1.7
Release boundary v0.1.6
Release boundary v0.1.5
Release boundary v0.1.4
Release boundary v0.1.3
Release boundary v0.1.2
Release boundary v0.1.1
Release boundary v0.1.0
Find the latest binaries at https://releases.hashicorp.com/boundary/0.1.0/