Skip to content

Releases: hashicorp/boundary

v0.6.2

28 Sep 18:54
Compare
Choose a tag to compare

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 within auth-methods/<id>:authenticate
    action. This field was deprecated in Boundary 0.2.0, please use
    attributes instead.
    (PR).

v0.6.1

15 Sep 22:11
1f7999e
Compare
Choose a tag to compare

0.6.1 (2021/09/14)

Bug Fixes

  • grants: Fix issue where credential-store, credential-library, and
    managed-group would not be accepted as specific type values in grant
    strings. Also, fix authorized actions not showing credential-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

09 Sep 11:08
7746916
Compare
Choose a tag to compare

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

19 Aug 17:54
5f88243
Compare
Choose a tag to compare

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 the wh_user_dimension table:
    auth_method_external_id, auth_account_external_id,
    auth_account_full_name, and auth_account_email.
    (PR)

Bug Fixes

  • events: Fix panic when using the hclog-text event's format.
    (PR)
  • oidc managed groups: Allow colons in selector paths
    (PR)

v0.5.0

05 Aug 18:48
477b541
Compare
Choose a tag to compare

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
      parallel application-credential-source flags to the existing
      application-credential-library flags, as well as boundary targets add/remove/set-credential-sources commands that parallel boundary 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.
    • 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.

New and Improved

  • OIDC Accounts: When performing a read on an oidc 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 a cloudevents-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 var BOUNDARY_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

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

30 Jun 22:51
Compare
Choose a tag to compare

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

09 Jun 20:18
Compare
Choose a tag to compare

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

24 May 17:39
Compare
Choose a tag to compare

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

19 May 16:06
Compare
Choose a tag to compare

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

06 May 17:26
Compare
Choose a tag to compare

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)