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 the 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.
• 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 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.
• 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

• scheduler: removes a Postgres check constraint, on the length of the controller name,
  causing an error when the scheduler attempts to run jobs
  (issue,
  PR).

v0.3.0

0.3.0 (2021/06/08)

Deprecations/Changes

• 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.

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 default password and oidc 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 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.
• If a 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.

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 a string 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
  to terminated 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 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.
• When using a 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).
• When outputting from the CLI in JSON format, the resource information under
  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.
• Permissions in new scope default roles have been updated to include support
  for 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.)

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 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:

  • Primary Account ID
  • Login Name
  • Full Name
  • Email

  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)

Bug Fixes

• cors: Fix allowing all origins by default
  (PR)
• cli: It is now an error to run boundary database migrate on an uninitalized db.
  Use boundary database init instead.
  (PR)
• cli: Correctly honor the -format flag when running boundary database init
  (PR)

v0.2.0

0.2.0 (2021/04/14)

Deprecations/Changes

• The 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.
• Related to the above change, the output of an API
  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).
• Anonymous scope/auth method listing: When listing auth methods and scopes
  without authentication (that is, as the anonymous user 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.

New and Improved

• cli/api/sdk: New OIDC auth method type added with support for create, read,
  update, delete, and list (see new cli oidc subcommands available on CRUDL
  operations for examples).
  PR
• cli: support to login using an OIDC auth method (see the new authenticate password oidc subcommand for an example)
  PR
• server: When performing recursive listing, list 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.
  PR
• database init: If the database is already initialized, return 0 as the exit
  code. This matches how the database migrate command works.
  PR

Bug Fixes

• server: Roles for auto generated scopes are now generated at database init.
  PR
• cli: Don't panic on certain commands when outputting in json format
  (Issue,
  PR)

v0.1.8

0.1.8 (2021/03/09)

Changes/Deprecations

• api: A few functions have changed places. Notably, instead of ResponseMap()
  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.
  PR
• cli: In json 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).
  PR
• cli: In json output format, errors are now serialized as a JSON object with
  an error key instead of outputting normal text
  PR
• cli: All errors, including API errors, are now written to stderr. Previously
  in the default table format, API errors would be written to stdout.
  PR
• cli: Error return codes have been standardized across CLI commands. An error
  code of 1 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.)
  PR

New and Improved

• list filtering: Listing now supports filtering results before being returned
  to the user. The filtering takes place server side and uses boolean
  expressions against the JSON representation of returned items. See the
  documentation
  for more details. (PR 1)
  (PR 2)
  (PR 3)
• server: Officially support reloading TLS parameters on SIGHUP. (This likely
  worked before but wasn't fully tested.)
  (PR)
• server: On SIGHUP, worker
  tags will be
  re-parsed and new values used
  (PR)
• server: In addition to the existing 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.

v0.1.7

Release boundary v0.1.7

v0.1.6

Release boundary v0.1.6

v0.1.5

Release boundary v0.1.5