Releases: hashicorp/boundary
v0.6.2
0.6.2 (2021/09/27)
Deprecations/Changes
- permissions: Fix bug in Host Sets service that authenticated requests
againist incorrect grant actions. This bug affects the SetHosts, AddHosts
and RemoveHosts paths that do not have wildcard (*
) action grants.
If affected, please update grant actions as follows: -
set-host-sets
->set-hosts
-
add-host-sets
->add-hosts
-
remove-host-sets
->remove-hosts
(PR).
- Removes support for the
auth-methods/<id>:authenticate:login
action that was
deprecated in Boundary 0.2.0, please use
auth-methods/<id>:authenticate
instead.
(PR). - Removes support for the
credential
field withinauth-methods/<id>:authenticate
action. This field was deprecated in Boundary 0.2.0, please use
attributes
instead.
(PR).
v0.6.1
0.6.1 (2021/09/14)
Bug Fixes
- grants: Fix issue where
credential-store
,credential-library
, and
managed-group
would not be accepted as specifictype
values in grant
strings. Also, fix authorized actions not showingcredential-store
values in
project scope output. (PR) - actions: Fix
sessions
collection actions not being visible when reading a
scope (PR) - credential stores: Fix credential stores not showing authorized collection
actions (PR)
v0.6.0
0.6.0 (2021/09/03)
New and Improved
- ui: Reflect user authorized actions in the UI: users now see only actionable
items for which they have permissions granted. - ui: Icons refreshed for a friendlier look and feel.
Bug Fixes
- controller: Fix issue with recursive listing across services when using the
unauthenticated user (u_anon
) with no token and the list was started in a
scope where the user does not have permission
(PR) - grants: Fix grant format
type=<type>;output_fields=<fields>
with no action
specified. In some code paths this format would trigger an error when
validating even though it is correctly handled within the ACL code.
(PR) - targets: Fix panic when using
boundary targets authorize-session
(issue,
PR).
v0.5.1
0.5.1 (2021/08/16)
New and Improved
- Data Warehouse: Add OIDC auth method and accounts to the database warehouse.
Four new columns have been added to thewh_user_dimension
table:
auth_method_external_id
,auth_account_external_id
,
auth_account_full_name
, andauth_account_email
.
(PR)
Bug Fixes
v0.5.0
0.5.0 (2021/08/02)
Deprecations/Changes
- With respect to Target resources, two naming changes are taking place. Note
that these are not affecting the resources themselves, only the fields on
Target resources that map them to targets: -
- Credential Libraries: In Target definitions, the field referring to
attached credential libraries is being renamed to the more abstract
credential sources. In the future Boundary will gain the ability to
internally store static credentials that are not generated or fetched
dynamically, and the sources terminology better reflects that the IDs
provided are a source of credentials, whether via dynamic generation or via
the credentials themselves. This will allow a paradigm similar to
principals
with roles, where the principal IDs can be a users, groups, and
managed groups, rather than having them split out, and should result in an
easier user experience once those features roll out compared to having
separate flags and fields. In this 0.5 release the Boundary CLI has gained
parallelapplication-credential-source
flags to the existing
application-credential-library
flags, as well asboundary targets add/remove/set-credential-sources
commands that parallelboundary targets add/remove/set-credential-libraries
commands. This parallelism extends to
the API actions and the grants system. In 0.6, the library versions of
these commands, flags, and actions will be removed.
- Credential Libraries: In Target definitions, the field referring to
-
- Host Sets: Similarly, in Target definitions, the field referring to
attached host sets is being renamed to the more abstract host sources. In
the future Boundary will allow attaching some host types directly, and
possibly other mechanisms for gathering hosts for targets, so the sources
terminology better reflects that the IDs provided are a source of hosts,
whether via sets or via the hosts themselves. Like with credential sources,
in this 0.5 release the Boundary CLI and API have gained parallel API
actions and fields, and the set versions of these will be removed in 0.6.
- Host Sets: Similarly, in Target definitions, the field referring to
New and Improved
-
OIDC Accounts: When performing a
read
on anoidc
type account, the
original token and userinfo claims are provided in the output. This can make
it significantly easier to write filters to create managed
groups.
(PR) -
Controllers will now mark connections as closed in the database if the worker
has not reported its status; this can be seen as the controller counterpart to
the worker-side session cleanup functionality released in 0.4.0. As with the
worker, the timeout for this behavior is 15s. -
Workers will shut down connections gracefully upon shutdown of the worker,
both closing the connection and sending a request to mark the connection as
closed in the database. -
Pressing CTRL-C (or sending a SIGINT) when Boundary is already shutting
down due to a CTRL-C or interrupt will now cause Boundary to immediately shut
down non-gracefully. This may leave various parts of the Boundary deployment
(namely sessions or connections) in an inconsistent state. -
Events: Boundary has moved from writing hclog entries to emitting events.
There are four types of Boundary events:error
,system
,observation
and
audit
. All events are emitted as
cloudevents and we
support both acloudevents-json
format and custom Boundary
cloudevents-text
format.Notes:
- There are still a few lingering hclog bits within Boundary. If you wish to
only output json from Boundary logging/events then you should specify both
"-log-format json"
and"-event-format cloudevents-json"
when starting
Boundary. - Filtering events: hclog log levels have been replaced by optional sets
of allow and deny event
filters which are
specified via configuration, or in the case of "boundary dev" there are new
new cmd flags. - Observation events are MVP and contain a minimal set of observations about a
request. Observations are aggregated for each request, so only one
observation event will be emitted per request. We anticipate that a rich set
of aggregate data about each request will be developed over time. - Audit events are a WIP and will only be emitted if they are both enabled
and the env varBOUNDARY_DEVELOPER_ENABLE_EVENTS
equals true. We
anticipate many changes for audit events before they are generally available
including what data is included and different options for
redacting/encrypting that data.
PRs:
hclog json,text formats,
log adapters,
unneeded log deps,
update eventlogger,
convert from hclog to events,
event filtering,
cloudevents node,
system events,
convert errors to events,
integrate events into servers,
event pkg name,
events using ctx,
add eventer,
and base event types - There are still a few lingering hclog bits within Boundary. If you wish to
Bug Fixes
- config: Fix error when populating all
kms
purposes in separate blocks (as
well as the error message)
(issue,
PR) - server: Fix panic on worker startup failure when the server was not also
configured as a controller
(PR)
New and Improved
- docker: Add support for muti-arch docker images (amd64/arm64) via Docker buildx
v0.4.0
0.4.0 (2021/06/29)
New and Improved
- Credential Stores: This release introduces Credential Stores, with the first
implementation targeting Vault. A credential store can be created that accepts
a Vault periodic token (which it will keep refreshed) and connection
information allowing it to make requests to Vault. - Credential Libraries: This release introduces Credential Libraries, with the
first implementation targeting Vault. Credential libraries describe how to
make a request to fetch a credential from the credential store. The first
credential library is thegeneric
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. - Credential Brokering: Credential libraries can be attached to targets; when a
session is authorized against that target, a credential will be fetched from
the library that is then relayed to the client. The client can then use this
information to make a connection, allowing them to gain the benefit of dynamic
credential generation from Vault, but without needing their own Vault
login/token (see NOTE below). boundary connect
Credential Brokering Integration: Additionally, we have
started integration into theboundary connect
helpers, starting in this
release with the Postgres helper; if the credential contains a
username/password andboundary connect postgres
is the helper being used,
the command will automatically pass the credentials to thepsql
process.- The worker will now close any existing proxy connections it is handling when
it cannot make a status request to the worker. The timeout for this behavior
is currently 15 seconds.
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.
Bug Fixes
v0.3.0
0.3.0 (2021/06/08)
Deprecations/Changes
password
account IDs: When theoidc
auth method came out, accounts were
given the prefixacctoidc
. Unfortunately, accounts in thepassword
method
were usingapw
...oops. We're standardizing onacct
and have updated the
password
method to generate new IDs withacctpw
prefixes.
Previously-generated prefixes will continue to work.
New and Improved
- oidc: The new Managed Groups feature allows groups of accounts to be created
based on an authenticating user's JWT or User Info data. This data uses the
same filtering syntax found elsewhere in Boundary to provide a rich way to
specify the criteria for group membership. Once defined, authenticated users
are added to or removed from these groups as appropriateds each time they
authenticate. These groups are treated like other role principals and can be
added to roles to provide grants to users. - dev: Predictable IDs in
boundary dev
mode now extend to the accounts created
in the defaultpassword
andoidc
auth methods. - mlock: Add a Docker entrypoint script and modify Dockerfiles to handle mlock
in a fashion similar to Vault
(PR)
v0.2.3
0.2.3 (2021/05/21)
Deprecations/Changes
- The behavior when
cors_enabled
is not specified for a listener is changing
to be equivalent to acors_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; ifcors_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. - If a
cancel
operation is run on a session already in a canceling or
terminated state, a200
and the session information will be returned instead
of an error.
New and Improved
- sessions: Return a
200
and session information when canceling an
already-canceled or terminated session
(PR)
Bug Fixes
- cors: Change the default allowed origins when
cors_enabled
is not specified
to be*
. (PR)
v0.2.2
0.2.2 (2021/05/17)
New and Improved
- Inline OIDC authentication flow: when the OIDC authentication flow succeeds,
the third-party provider browser window is automatically closed and the user
is returned to the admin UI.
Bug Fixes
- oidc: If provider returns an
aud
claim as astring
or[]string
,
Boundary will properly parse the claims JSON.
(issue,
PR) - sessions: Clean up connections that are dangling after a worker dies (is
restarted, powered off, etc.) This fixes some cases where a session never goes
toterminated
state because connections are not properly marked closed.
(Issue 1, Issue
2,
PR) - sessions: Add some missing API-level checks when session cancellation was
requested. It's much easier than interpreting the domain-level check failures.
(PR) - authenticate: When authenticating with OIDC and
json
format output, the
command will no longer print out a notice that it's opening your web browser
(Issue,
PR)
v0.2.1
0.2.1 (2021/05/05)
Deprecations/Changes
- API
delete
actions now result in a204
status code and no body when
successful. This was not the case previously due to a technical limitation
which has now been solved. - When using a
delete
command within the CLI we now either show success or
treat the404
error the same as any other404
error, that is, it results
in a non-zero status code and an error message. This makesdelete
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 was404
or something else from within scripts, in
conjunction with checking that the returned status code matches the API error
status code (1
). - When outputting from the CLI in JSON format, the resource information under
item
oritems
(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 includesdelete
actions which previously
would show an object indicating existence, but now show noitem
on success
or the API's404
error. - Permissions in new scope default roles have been updated to include support
forlist
,read:self
, anddelete:self
onauth-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.)
New and Improved
-
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 theitems
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 nooutput_fields
are specified, the defaults are used. For authenticated
users this defaults to all fields; foru_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'sEmail
andFullName
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 successfuldelete
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 conveyno-op,list
instead ofread,list
.
(PR) -
cli/api/sdk: User resources have new attributes for:
- Primary Account ID
- Login Name
- Full Name
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
anddelete: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)