From 3f4cd53d16889873242e120f0528ca382488e20b Mon Sep 17 00:00:00 2001 From: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> Date: Fri, 7 Jul 2023 14:42:11 -0400 Subject: [PATCH] docs: Update headings for new style rule (#3396) * docs: Update headings for new style rule * docs: Fix headings - Get started * docs: Fix headings - Install * docs: Fix headings - Concepts * docs: Fix typos * docs: Fix headings - Configuration * docs: Fix headings - Operations * docs: Fix headings - Troubleshoot * docs: Fix headings - Clients and Develop * docs: Fix headings - HCP and ENT * docs: Fix headings - Release notes * docs: Fix typos * docs: Fix capitalization in TOC --- website/content/docs/api-clients/api.mdx | 4 +- website/content/docs/api-clients/cli.mdx | 18 +-- website/content/docs/api-clients/desktop.mdx | 2 +- website/content/docs/api-clients/go-sdk.mdx | 4 +- .../docs/concepts/domain-model/accounts.mdx | 10 +- .../concepts/domain-model/auth-methods.mdx | 12 +- .../domain-model/credential-libraries.mdx | 2 +- .../domain-model/credential-stores.mdx | 20 +-- .../concepts/domain-model/credentials.mdx | 2 +- .../docs/concepts/domain-model/groups.mdx | 6 +- .../concepts/domain-model/host-catalogs.mdx | 10 +- .../docs/concepts/domain-model/host-sets.mdx | 10 +- .../docs/concepts/domain-model/hosts.mdx | 12 +- .../docs/concepts/domain-model/index.mdx | 12 +- .../concepts/domain-model/managed-groups.mdx | 12 +- .../docs/concepts/domain-model/roles.mdx | 6 +- .../docs/concepts/domain-model/scopes.mdx | 6 +- .../domain-model/session-connections.mdx | 7 +- .../domain-model/session-recordings.mdx | 4 +- .../docs/concepts/domain-model/sessions.mdx | 6 +- .../concepts/domain-model/storage-buckets.mdx | 6 +- .../docs/concepts/domain-model/targets.mdx | 2 +- .../docs/concepts/domain-model/users.mdx | 6 +- .../docs/concepts/filtering/events.mdx | 4 +- .../content/docs/concepts/filtering/index.mdx | 10 +- .../filtering/oidc-managed-groups.mdx | 4 +- .../concepts/filtering/resource-listing.mdx | 4 +- .../docs/concepts/filtering/worker-tags.mdx | 10 +- .../content/docs/concepts/host-discovery.mdx | 2 +- website/content/docs/concepts/iam.mdx | 14 +- .../concepts/security/connections-tls.mdx | 16 +-- .../concepts/security/data-encryption.mdx | 18 +-- .../permissions/assignable-permissions.mdx | 16 +-- .../concepts/security/permissions/index.mdx | 8 +- .../permissions/permission-grant-formats.mdx | 24 ++-- .../security/permissions/resource-table.mdx | 6 +- .../content/docs/configuration/controller.mdx | 9 +- .../docs/configuration/events/common.mdx | 6 +- .../docs/configuration/events/file.mdx | 6 +- .../docs/configuration/events/index.mdx | 8 +- .../docs/configuration/events/stderr.mdx | 6 +- website/content/docs/configuration/index.mdx | 11 +- .../content/docs/configuration/kms/aead.mdx | 2 +- .../docs/configuration/kms/alicloudkms.mdx | 6 +- .../content/docs/configuration/kms/awskms.mdx | 8 +- .../docs/configuration/kms/azurekeyvault.mdx | 6 +- .../docs/configuration/kms/gcpckms.mdx | 8 +- .../content/docs/configuration/kms/index.mdx | 4 +- .../content/docs/configuration/kms/ocikms.mdx | 8 +- .../docs/configuration/kms/transit.mdx | 8 +- .../docs/configuration/listener/index.mdx | 12 +- .../docs/configuration/listener/tcp.mdx | 28 ++-- .../docs/configuration/listener/unix.mdx | 22 +-- .../content/docs/configuration/plugins.mdx | 4 +- .../docs/configuration/worker/index.mdx | 15 ++- .../docs/configuration/worker/kms-worker.mdx | 3 +- .../docs/configuration/worker/pki-worker.mdx | 9 +- website/content/docs/developing/building.mdx | 2 +- website/content/docs/developing/ui.mdx | 2 +- .../automated-license-reporting.mdx | 2 +- .../dev-mode/connect-to-dev-target.mdx | 10 +- .../getting-started/dev-mode/dev-mode.mdx | 6 +- .../dev-mode/run-and-login.mdx | 4 +- .../content/docs/getting-started/index.mdx | 8 +- .../hcp/get-started/connect-to-target.mdx | 12 +- .../docs/hcp/get-started/deploy-and-login.mdx | 6 +- .../install-boundary/high-availability.mdx | 12 +- .../install-boundary/no-gen-resources.mdx | 22 +-- .../content/docs/install-boundary/systemd.mdx | 14 +- website/content/docs/operations/health.mdx | 6 +- website/content/docs/overview/use-cases.mdx | 2 +- .../docs/overview/vs/bastion-hosts.mdx | 4 +- .../docs/overview/vs/other-software.mdx | 4 +- website/content/docs/overview/vs/pam.mdx | 6 +- website/content/docs/overview/vs/sdp.mdx | 8 +- .../docs/overview/vs/secrets-management.mdx | 6 +- website/content/docs/overview/vs/vpn.mdx | 2 +- .../content/docs/overview/vs/zero-trust.mdx | 6 +- .../docs/overview/what-is-boundary.mdx | 4 +- website/content/docs/release-notes/index.mdx | 6 +- .../content/docs/release-notes/v0_10_0.mdx | 6 +- .../content/docs/release-notes/v0_11_0.mdx | 8 +- website/content/docs/release-notes/v0_1_0.mdx | 2 +- website/content/docs/release-notes/v0_2_0.mdx | 4 +- website/content/docs/release-notes/v0_3_0.mdx | 4 +- website/content/docs/release-notes/v0_4_0.mdx | 4 +- website/content/docs/release-notes/v0_5_0.mdx | 4 +- website/content/docs/release-notes/v0_6_0.mdx | 4 +- website/content/docs/release-notes/v0_7_0.mdx | 4 +- website/content/docs/release-notes/v0_8_0.mdx | 4 +- website/content/docs/release-notes/v0_9_0.mdx | 4 +- .../docs/troubleshoot/common-errors.mdx | 30 ++--- website/content/docs/troubleshoot/faq.mdx | 26 ++-- website/data/docs-nav-data.json | 126 +++++++++--------- 94 files changed, 452 insertions(+), 436 deletions(-) diff --git a/website/content/docs/api-clients/api.mdx b/website/content/docs/api-clients/api.mdx index 2e9862be2..7f0ef1146 100644 --- a/website/content/docs/api-clients/api.mdx +++ b/website/content/docs/api-clients/api.mdx @@ -17,7 +17,7 @@ Boundary's API is also described via OpenAPI v2; the version corresponding to an Boundary's current API version is 1; all API paths begin with `/v1/`. -## Status Codes +## Status codes - `2XX`: Boundary returns a code between `200` and `299` on success. Generally this is `200`, but implementations should be prepared to accept any `2XX` status code as indicating success. If a call returns a `2XX` code that is not `200`, it will follow well-understood semantics for those status codes. (Starting with Boundary 0.2.1, `delete` actions return `204` on success.) - `400`: Boundary returns `400` when a command cannot be completed due to invalid user input, except for a properly-formatted identifier that does not map to an existing resource, which will return a `404` as discussed below. @@ -27,7 +27,7 @@ Boundary's current API version is 1; all API paths begin with `/v1/`. - `405`: Boundary returns a `405` to indicate that the method (HTTP verb or custom action) is not implemented for the given resource. - `500`: Boundary returns `500` if an error occurred that is not (directly) tied to invalid user input. If a `500` is generated, information about the error will be logged to Boundary's server log but is not generally provided to the client. -## Path Layout +## Path layout Boundary follows a predictable path layout. There are two fundamental types of URL paths, each supporting a different set of operations. diff --git a/website/content/docs/api-clients/cli.mdx b/website/content/docs/api-clients/cli.mdx index 8043d0c68..b2e89cc02 100644 --- a/website/content/docs/api-clients/cli.mdx +++ b/website/content/docs/api-clients/cli.mdx @@ -11,7 +11,7 @@ Boundary's CLI has predictable behavior throughout its various commands. This page details the common patterns used in order to help users make better use of the CLI. -## CLI Command Structure +## CLI command structure There are a number of command and subcommand options available. To see all available command options, run `boundary -h` @@ -26,7 +26,7 @@ boundary [options] [args] - `options` - [Client](/boundary/docs/api-clients/cli#client-options) and [connection](/boundary/docs/api-clients/cli#connection-options) options to specify additional settings - `args` - API arguments specific to the operation -#### Examples: +### Examples The following shows use of the [`-addr`](/boundary/docs/api-clients/cli#addr) flag to specify which Boundary controller to send the request to. @@ -53,7 +53,7 @@ If you want to install it manually, for Bash, the following line in a `complete -C /path/to/boundary boundary` -## Keyring Token storage +## Keyring token storage Boundary uses various mechanisms, depending on platform, to allow for secure storage of authentication tokens for later use. Each platform has a @@ -100,7 +100,7 @@ Available keyring types: - `secret-service` - `none` -## Mapping to Collections and Sub-Types +## Map to collections and sub-types Generally speaking, Boundary's CLI commands map to the collections they operate on. For instance, when operating on roles, the command will be `boundary roles ...`. @@ -139,7 +139,7 @@ Similar to `read`, `update` operates on an existing target so will always take an `-id` parameter. Similar to `list`, `create` operates on a collection so will either take a `-scope-id` parameter or a parameter defining the parent resource. -## Parameter Handling +## Parameter handling All parameters specified on the CLI are specified as a Go-style flag with a single dash, e.g. `-id`. The arguments to those flags can be specified via an @@ -161,7 +161,7 @@ But the following results in an error: This applies to `-h` as well! -### Clearing/Defaulting Values +### Clear/default values On the CLI, you can use `null` as a value to indicate to Boundary that you want to unset a value, reverting to Boundary's default. In many cases this default @@ -178,7 +178,7 @@ call's JSON object but with the value set to the JSON `null`. This in turn informs the Controller that this value should be set to its default. Keep in mind that this is not a direct translation to database `NULL` semantics! -### Connection Options +### Connection options Every command that results in an API call contains a set of flags that control connection options, which control TLS and other settings for the connection. @@ -217,7 +217,7 @@ You can also run `boundary dev -h` to see the available connection options. environment variable. -### Client Options +### Client options Every command that results in an API call contains a set of flags that control client options. Some notable options: @@ -237,7 +237,7 @@ client options. Some notable options: the information necessary to access a KMS configured to be used for the recovery workflow within a Boundary controller. -### Output Options +### Output options Nearly every command supports having its success output be formatted as JSON via `-format json`. For commands that result in an API call, the JSON output will be diff --git a/website/content/docs/api-clients/desktop.mdx b/website/content/docs/api-clients/desktop.mdx index 9e6ca4fe6..e87acccbc 100644 --- a/website/content/docs/api-clients/desktop.mdx +++ b/website/content/docs/api-clients/desktop.mdx @@ -12,7 +12,7 @@ for browsing and connecting to targets on your local computer (macOS and Windows currently supported). Launch a session in Boundary Desktop and then make a connection using your favorite tooling! -## Getting Started +## Get started -> If you're running Boundary for the first time, [download the latest binary](/boundary/downloads) and run it in `dev` mode locally so you can have a server to run against: diff --git a/website/content/docs/api-clients/go-sdk.mdx b/website/content/docs/api-clients/go-sdk.mdx index 0253f5008..ad69a83b8 100644 --- a/website/content/docs/api-clients/go-sdk.mdx +++ b/website/content/docs/api-clients/go-sdk.mdx @@ -22,7 +22,7 @@ authenticating to Boundary: We'll cover how to authenticate to Boundary via both of these workflows. -### Auth Method +### Auth method This is the most common way for a client to authenticate to Boundary. To demonstrate this, we'll use the [authmethods](https://github.com/hashicorp/boundary/tree/main/api/authmethods) library to generate @@ -129,7 +129,7 @@ if err != nil { client.SetToken(fmt.Sprint(authenticationResult.Attributes["token"])) ``` -### Recovery KMS Workflow +### Recovery KMS workflow The recovery KMS workflow allows you to use a valid [KMS configuration](/boundary/docs/configuration/kms) to authenticate and authorize calls diff --git a/website/content/docs/concepts/domain-model/accounts.mdx b/website/content/docs/concepts/domain-model/accounts.mdx index 6a59b7ff9..5f9524199 100644 --- a/website/content/docs/concepts/domain-model/accounts.mdx +++ b/website/content/docs/concepts/domain-model/accounts.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Accounts +page_title: Domain model - accounts description: |- The anatomy of a Boundary account --- @@ -25,7 +25,7 @@ All account types have the following configurable attributes: - `description` - (optional) -### Password Account Attributes +### Password account attributes Password account types have the following additional attributes: @@ -36,7 +36,7 @@ Password account types have the following additional attributes: - `password` - (optional) Not setting the `password` disables the account. -### LDAP Account Attributes Beta +### LDAP account attributes Beta LDAP account types have the following additional attributes: @@ -63,7 +63,7 @@ LDAP account types have the following additional attributes: A list of the groups the authenticated user is a member of. It is empty until the user's first successful authentication. -## Referenced By +## Referenced by - [Auth Method][] - [Managed Group][] @@ -73,7 +73,7 @@ LDAP account types have the following additional attributes: [managed group]: /boundary/docs/concepts/domain-model/managed-groups [user]: /boundary/docs/concepts/domain-model/users -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/auth-methods.mdx b/website/content/docs/concepts/domain-model/auth-methods.mdx index cf0dc1f25..afdab1d58 100644 --- a/website/content/docs/concepts/domain-model/auth-methods.mdx +++ b/website/content/docs/concepts/domain-model/auth-methods.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Domain Model - Auth Methods +page_title: Domain model - auth methods description: |- The anatomy of a Boundary auth method --- -# Auth Methods +# Auth methods An auth method is a resource that provides a mechanism for [users][] to authenticate to Boundary. An auth method contains [accounts][] which link an @@ -23,7 +23,7 @@ All auth methods have the following configurable attributes: - `description` - (optional) -### Password Auth Method Attributes +### Password auth method attributes The password auth method has the following additional attributes: @@ -31,7 +31,7 @@ The password auth method has the following additional attributes: - `min_password_length` - (required) The default is 8. -### LDAP Auth Method Attributes Beta +### LDAP auth method attributes Beta The ldap auth method has the following additional attributes: @@ -123,7 +123,7 @@ The ldap auth method has the following additional attributes: attribute names are case insensitive. -## Referenced By +## Referenced by - [Account][] - [Global][] @@ -140,7 +140,7 @@ The ldap auth method has the following additional attributes: [scope]: /boundary/docs/concepts/domain-model/scopes [users]: /boundary/docs/concepts/domain-model/users -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/credential-libraries.mdx b/website/content/docs/concepts/domain-model/credential-libraries.mdx index af294edbd..fe1d701c5 100644 --- a/website/content/docs/concepts/domain-model/credential-libraries.mdx +++ b/website/content/docs/concepts/domain-model/credential-libraries.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Credential Libraries +page_title: Domain model - credential libraries description: |- The anatomy of a Boundary credential library --- diff --git a/website/content/docs/concepts/domain-model/credential-stores.mdx b/website/content/docs/concepts/domain-model/credential-stores.mdx index c1b2f74fa..46a36ad32 100644 --- a/website/content/docs/concepts/domain-model/credential-stores.mdx +++ b/website/content/docs/concepts/domain-model/credential-stores.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Domain Model - Credential Stores +page_title: Domain model - credential stores description: |- The anatomy of a Boundary credential store --- -# Credential Stores +# Credential stores A credential store is a resource that can retrieve, store, and potentially generate [credentials][] @@ -25,7 +25,7 @@ A credential store has the following configurable attributes: - `description` - (optional) -### Vault Credential Store Attributes +### Vault credential store attributes A Vault credential store has the following additional attributes: @@ -66,17 +66,17 @@ A Vault credential store has the following additional attributes: ~> **Note:** A PKI worker that matches the worker filter must exist before defining the Vault credential store, as it will perform the Vault calls needed to set up the credential store with Boundary. -### Static Credential Store Attributes +### Static credential store attributes A static credential store has no type-specific attributes. -## Referenced By +## Referenced by - [Credential Library][] - [Credential][] - [Project][] -## Service API Docs +## Service API docs The following services are relevant to this resource: @@ -88,7 +88,7 @@ The following services are relevant to this resource: [credentials]: /boundary/docs/concepts/domain-model/credentials [project]: /boundary/docs/concepts/domain-model/scopes#projects -## Vault Token Requirements +## Vault token requirements Each Vault credential store must be configured with a unique Vault token. The Vault tokens for all credential stores @@ -96,7 +96,7 @@ must be [periodic][], [renewable][], and an [orphan][]. All tokens must also have the capabilities of the [Vault Boundary Controller Policy][token_policy] described below. -### Vault Policies +### Vault policies The credential store's token must have the capabilities to issue credentials for each of it's [credential libraries][] plus the capabilities of the @@ -113,7 +113,7 @@ permissions necessary at any point in time. The policy unique to a credential store can then be updated as needed when credential libraries are added and removed from the credential store. -#### Vault Boundary Controller Policy +#### Vault Boundary controller policy The token Boundary receives must have the capabilities listed below. An explanation for the use of each capability is given. @@ -169,7 +169,7 @@ $ curl https://boundaryproject.io/data/vault/boundary-controller-policy.hcl -O - $ vault policy write boundary-controller boundary-controller-policy.hcl ``` -### Static Credential Store +### Static credential store A static credential store allows user-supplied credentials to be managed by Boundary. Credentials are encrypted and stored directly in Boundary. Currently, the static credential store can hold credentials of type `username_password`. diff --git a/website/content/docs/concepts/domain-model/credentials.mdx b/website/content/docs/concepts/domain-model/credentials.mdx index 7db4496d7..55bad8326 100644 --- a/website/content/docs/concepts/domain-model/credentials.mdx +++ b/website/content/docs/concepts/domain-model/credentials.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Credentials +page_title: Domain model - credentials description: |- The anatomy of a Boundary credential --- diff --git a/website/content/docs/concepts/domain-model/groups.mdx b/website/content/docs/concepts/domain-model/groups.mdx index d47432080..7c0045333 100644 --- a/website/content/docs/concepts/domain-model/groups.mdx +++ b/website/content/docs/concepts/domain-model/groups.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Groups +page_title: Domain model - groups description: |- The anatomy of a Boundary group --- @@ -27,7 +27,7 @@ A group has the following configurable attributes: - `description` - (optional) -## Referenced By +## Referenced by - [Global][] - [Organization][] @@ -46,7 +46,7 @@ A group has the following configurable attributes: [user]: /boundary/docs/concepts/domain-model/users [users]: /boundary/docs/concepts/domain-model/users -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/host-catalogs.mdx b/website/content/docs/concepts/domain-model/host-catalogs.mdx index ff2567e03..f10d50541 100644 --- a/website/content/docs/concepts/domain-model/host-catalogs.mdx +++ b/website/content/docs/concepts/domain-model/host-catalogs.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Domain Model - Host Catalogs +page_title: Domain model - host catalogs description: |- The anatomy of a Boundary host catalog --- -# Host Catalogs +# Host catalogs A host catalog is a resource that contains [hosts][] and [host sets][]. @@ -20,7 +20,7 @@ A host catalog has the following configurable attributes: - `description` - (optional) -### Plugin Host Catalog Information and Attributes +### Plugin host catalog information and attributes - `plugin_id` - (required) Must reference an installed plugin. @@ -33,7 +33,7 @@ A host catalog has the following configurable attributes: A collection of sensitive fields, like credentials, which the plugin uses to interface with the backing service. These fields are write-only. -## Referenced By +## Referenced by - [Host][] - [Host Set][] @@ -45,7 +45,7 @@ A host catalog has the following configurable attributes: [hosts]: /boundary/docs/concepts/domain-model/hosts [project]: /boundary/docs/concepts/domain-model/scopes#projects -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/host-sets.mdx b/website/content/docs/concepts/domain-model/host-sets.mdx index 6c06b7835..aa760f19f 100644 --- a/website/content/docs/concepts/domain-model/host-sets.mdx +++ b/website/content/docs/concepts/domain-model/host-sets.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Domain Model - Host Sets +page_title: Domain model - host sets description: |- The anatomy of a Boundary host set --- -# Host Sets +# Host sets A host set is a resource that represents a collection of [hosts][] @@ -30,7 +30,7 @@ A host set has the following configurable attributes: or `dns:` used to select the addresses of [hosts][] when establishing a [session][] with a [target][]. -### Plugin Host Set Attributes +### Plugin host set attributes - `attributes` - (optional) A collection of fields which the plugin uses to lookup which hosts should be @@ -42,7 +42,7 @@ A host set has the following configurable attributes: set using this host set's plugin. If not provided a system determined default is used. -## Referenced By +## Referenced by - [Host][] - [Host Catalog][] @@ -59,7 +59,7 @@ A host set has the following configurable attributes: [target]: /boundary/docs/concepts/domain-model/targets [targets]: /boundary/docs/concepts/domain-model/targets -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/hosts.mdx b/website/content/docs/concepts/domain-model/hosts.mdx index 79f06cd87..e4c493ba1 100644 --- a/website/content/docs/concepts/domain-model/hosts.mdx +++ b/website/content/docs/concepts/domain-model/hosts.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Hosts +page_title: Domain model - hosts description: |- The anatomy of a Boundary host --- @@ -14,9 +14,9 @@ A host belongs to a [host catalog][]. Hosts can only be associated with [host sets][] from the same host catalog as the host. -## Plugin Based Host Information +## Plugin-based host information -Plugin based hosts are read-only. They are synced by an installed plugin on +Plugin-based hosts are read-only. They are synced by an installed plugin on the boundary system using the configuration provided it from the [host catalog][] and [host set][] at an interval (configurable in the [host set][]). @@ -30,14 +30,14 @@ A host has the following configurable attributes: - `description` - (optional) -### Static Host Attributes +### Static host attributes Static host types have the following additional attribute: - `address` - (required) Must be at least 3 characters long and not greater than 255 characters. -## Referenced By +## Referenced by - [Host Catalog][] - [Host Set][] @@ -47,7 +47,7 @@ Static host types have the following additional attribute: [host set]: /boundary/docs/concepts/domain-model/host-sets [host sets]: /boundary/docs/concepts/domain-model/host-sets -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/index.mdx b/website/content/docs/concepts/domain-model/index.mdx index 4662f003b..81baa342c 100644 --- a/website/content/docs/concepts/domain-model/index.mdx +++ b/website/content/docs/concepts/domain-model/index.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model Index +page_title: Domain model index description: |- Reference documentation for Boundary's domain model. --- @@ -29,7 +29,7 @@ For example, they could have the following project scopes: - Product 2 - Product 3 -## Identity and Access Management +## Identity and access management As mentioned earlier, IAM is handled at the organization and global scope levels. Here, operators can create and manage principals. Principals are entities in Boundary that are either [Users](/boundary/docs/concepts/domain-model/users) or [Groups](/boundary/docs/concepts/domain-model/groups) that may be assigned capabilities. @@ -37,7 +37,7 @@ Users are associated with either the global or an organization’s scope. For be An [Auth Method](/boundary/docs/concepts/domain-model/auth-methods) is the mechanism in Boundary used for authentication. An organization may use numerous authentication methods. Boundary supports Open ID Connect (OIDC) auth methods to delegate authentication to an external identity provider (IDP) - such as Azure Active Directory, Okta, and other OIDC providers - as well as a Boundary-native password auth method. Within an auth method, [Accounts](/boundary/docs/concepts/domain-model/accounts) may be created and associated with users. Once associated with a user, the principal may authenticate in Boundary using the method specified by their auth method. An account for the password auth method consists of a login name and password. A user may be associated with accounts from different auth methods, where they can have both an Azure Active Directory account and an Okta account, for example. In such cases, the user could authenticate with either provider. -## Access Management +## Access management Boundary’s method of access management starts at the lowest level with Actions. Actions are capabilities that can be performed against Boundary resources. Boundary supports generic Actions such as, Create, Read, Update, Delete, and List. However, there are many more that are resource-type-specific actions that can be used in grants. @@ -49,7 +49,7 @@ The highest-level in Boundary utilizes the concepts of [Roles](/boundary/docs/co ![](/img/component-relationship.png) -## Target and Host Resources +## Target and host resources Boundary exposes endpoints to users as [Targets](/boundary/docs/concepts/domain-model/targets). A target is a resource representing a networked service, with an associated set of permissions, that allows a user to connect and interact with Boundary within a single session. A target may contain references to [Host](/boundary/docs/concepts/domain-model/hosts) sources or an address, and [Credential](/boundary/docs/concepts/domain-model/credentials) sources. Users who access a target create an authorized session to its address or one of its host sources with returned credentials from the target’s credential source. @@ -75,7 +75,7 @@ Host Catalogs for discovering and categorizing networked resources. We recommend using targets with host sources for setting up Boundary in environments where a significant number of resources exist. -### Summary of Resources +### Summary of resources - **[Account][]** : A resource @@ -166,7 +166,7 @@ significant number of resources exist. that represents an individual person or entity for the purposes of access control. -## Next Steps +## Next steps When getting started with Boundary, the first resource to look at should be [Scopes][]. diff --git a/website/content/docs/concepts/domain-model/managed-groups.mdx b/website/content/docs/concepts/domain-model/managed-groups.mdx index ee98461ef..81657f524 100644 --- a/website/content/docs/concepts/domain-model/managed-groups.mdx +++ b/website/content/docs/concepts/domain-model/managed-groups.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Domain Model - Managed Groups +page_title: Domain model - managed groups description: |- The anatomy of a Boundary managed group --- -# Managed Groups +# Managed groups A managed group is a resource that represents a collection of [accounts][]. The collection is formed by evaluating account information defined by the [auth @@ -23,7 +23,7 @@ All managed group types have the following configurable attributes: - `description` - (optional) -### OIDC Managed Group Information and Attributes +### OIDC managed group information and attributes Membership in OIDC managed groups is evaluated when the auth method is used for authentication, based on information contained within the OIDC ID token and the @@ -41,7 +41,7 @@ OIDC managed groups have the following additional attributes: [filtering concepts]: /boundary/docs/concepts/filtering [oidc managed groups filtering]: /boundary/docs/concepts/filtering/oidc-managed-groups -### LDAP Managed Group Information and Attributes Beta +### LDAP managed group information and attributes Beta Membership in LDAP managed groups is evaluated when the auth method is used for authentication, based on information contained within the LDAP server. Every @@ -51,7 +51,7 @@ LDAP managed groups have the following additional attributes: - `group-names` - (required) A list of group names. -## Referenced By +## Referenced by - [Accounts][] - [Auth Method][] @@ -60,7 +60,7 @@ LDAP managed groups have the following additional attributes: [auth method]: /boundary/docs/concepts/domain-model/auth-methods [roles]: /boundary/docs/concepts/domain-model/roles -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/roles.mdx b/website/content/docs/concepts/domain-model/roles.mdx index b15b9cef9..42164cffb 100644 --- a/website/content/docs/concepts/domain-model/roles.mdx +++ b/website/content/docs/concepts/domain-model/roles.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Roles +page_title: Domain model - roles description: |- The anatomy of a Boundary role --- @@ -24,7 +24,7 @@ A role has the following configurable attributes: - `description` - (optional) -## Referenced By +## Referenced by - [Group][] - [Managed Group][] @@ -41,7 +41,7 @@ A role has the following configurable attributes: [user]: /boundary/docs/concepts/domain-model/users [users]: /boundary/docs/concepts/domain-model/users -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/scopes.mdx b/website/content/docs/concepts/domain-model/scopes.mdx index 43a972895..18b8ad174 100644 --- a/website/content/docs/concepts/domain-model/scopes.mdx +++ b/website/content/docs/concepts/domain-model/scopes.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Scopes +page_title: Domain model - scopes description: |- The anatomy of a Boundary scope --- @@ -47,7 +47,7 @@ A scope has the following configurable attributes: - `description` - (optional) -## Referenced By +## Referenced by - [Auth Method][] - [Credential Store][] @@ -79,7 +79,7 @@ A scope has the following configurable attributes: [user]: /boundary/docs/concepts/domain-model/users [users]: /boundary/docs/concepts/domain-model/users -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/session-connections.mdx b/website/content/docs/concepts/domain-model/session-connections.mdx index 30acf89f2..cbf3b20a0 100644 --- a/website/content/docs/concepts/domain-model/session-connections.mdx +++ b/website/content/docs/concepts/domain-model/session-connections.mdx @@ -1,11 +1,12 @@ --- layout: docs -page_title: Domain Model - Session Connections +page_title: Domain model - session connections description: |- The anatomy of a Boundary session connection --- -# Session Connections +# Session connections + A session connection represents an authorized proxy between a [user][] and a [host][]. After the creation of a [session][], a user initiates a connection to a [target][] using the Boundary-provided proxy information and [credentials][] (if applicable). @@ -15,7 +16,7 @@ number of connections. Session connections terminate on user exit from the proxy, or on termination of the [session][]. -## Referenced By +## Referenced by - [Session][] diff --git a/website/content/docs/concepts/domain-model/session-recordings.mdx b/website/content/docs/concepts/domain-model/session-recordings.mdx index a54c5fb85..053e60e3e 100644 --- a/website/content/docs/concepts/domain-model/session-recordings.mdx +++ b/website/content/docs/concepts/domain-model/session-recordings.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Session Recordings +page_title: Domain model - session recordings description: |- The anatomy of a Boundary session recording --- @@ -48,7 +48,7 @@ scope. - [Storage Bucket][] -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/sessions.mdx b/website/content/docs/concepts/domain-model/sessions.mdx index 149e2c9b7..a328fc072 100644 --- a/website/content/docs/concepts/domain-model/sessions.mdx +++ b/website/content/docs/concepts/domain-model/sessions.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Sessions +page_title: Domain model - sessions description: |- The anatomy of a Boundary session --- @@ -60,7 +60,7 @@ terminated. Permissions are only evaluated at session establishment. Changes to a user's permissions do not effect existing sessions. -## Referenced By +## Referenced by - [Project][] - [Credential][] @@ -97,7 +97,7 @@ Changes to a user's permissions do not effect existing sessions. [projects]: /boundary/docs/concepts/domain-model/scopes#projects [permissions]: /boundary/docs/concepts/security/permissions -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/storage-buckets.mdx b/website/content/docs/concepts/domain-model/storage-buckets.mdx index 611d2ad24..0000b7889 100644 --- a/website/content/docs/concepts/domain-model/storage-buckets.mdx +++ b/website/content/docs/concepts/domain-model/storage-buckets.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Storage Bucket +page_title: Domain model - storage bucket description: |- The anatomy of a Boundary storage bucket --- @@ -58,11 +58,11 @@ AWS S3 buckets have the following secrets: - `access_key_id` - (Required) The access key ID for the IAM user to use with this storage bucket. - `secret_access_key` - (Required) The secret access key for the IAM user to use with this storage bucket. -# Referenced by +## Referenced by - [Session recordings](/boundary/docs/concepts/domain-model/session-recordings) -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/domain-model/targets.mdx b/website/content/docs/concepts/domain-model/targets.mdx index 000fc2cd8..734eaa9d7 100644 --- a/website/content/docs/concepts/domain-model/targets.mdx +++ b/website/content/docs/concepts/domain-model/targets.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Targets +page_title: Domain model - targets description: |- The anatomy of a Boundary target --- diff --git a/website/content/docs/concepts/domain-model/users.mdx b/website/content/docs/concepts/domain-model/users.mdx index c46f5a235..0750e105d 100644 --- a/website/content/docs/concepts/domain-model/users.mdx +++ b/website/content/docs/concepts/domain-model/users.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Domain Model - Users +page_title: Domain model - users description: |- The anatomy of a Boundary user --- @@ -33,7 +33,7 @@ A user has the following configurable attributes: - `description` - (optional) -## Referenced By +## Referenced by - [Account][] - [Global][] @@ -53,7 +53,7 @@ A user has the following configurable attributes: [roles]: /boundary/docs/concepts/domain-model/roles [scope]: /boundary/docs/concepts/domain-model/scopes -## Service API Docs +## Service API docs The following services are relevant to this resource: diff --git a/website/content/docs/concepts/filtering/events.mdx b/website/content/docs/concepts/filtering/events.mdx index 375baef14..f4b0060b0 100644 --- a/website/content/docs/concepts/filtering/events.mdx +++ b/website/content/docs/concepts/filtering/events.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Filtering - Events +page_title: Filtering - events description: |- How to filter events emitted by Boundary. --- -# Event Filtering +# Filter events This page describes how to filter events written to Boundary event sinks. diff --git a/website/content/docs/concepts/filtering/index.mdx b/website/content/docs/concepts/filtering/index.mdx index f7d7a5f0f..3d63b3285 100644 --- a/website/content/docs/concepts/filtering/index.mdx +++ b/website/content/docs/concepts/filtering/index.mdx @@ -5,7 +5,7 @@ description: |- An introduction to the filtering syntax used in Boundary. --- -# Filtering +# Filter expressions Filter expressions can be used by various parts of Boundary to provide useful functionality. This page describes the overall syntax; see the sub-pages for @@ -15,13 +15,13 @@ including examples. Each filter expression has matching operators composed with selectors and values. -## Creating Expressions +## Create expressions A single expression is a matching operator with a selector and value. They are written in plain text format, and Boolean logic and parenthesization are supported. In general whitespace is ignored, except within literal strings. -### Matching Operators +### Matching operators All matching operators use a selector or value to choose what data should be matched. Each endpoint that supports filtering accepts a potentially different @@ -71,7 +71,7 @@ When quoting strings, they may either be enclosed in double quotes or backticks. When enclosed in backticks they are treated as raw strings and escape sequences such as `\n` will not be expanded. -## Connecting Expressions +## Connect expressions There are several methods for connecting expressions, including @@ -107,7 +107,7 @@ the following two expressions would be equivalent. ( and (not )) or ``` -### Performance +## Performance Filters are executed on the controllers and therefore will consume some amount of CPU time on the controller. diff --git a/website/content/docs/concepts/filtering/oidc-managed-groups.mdx b/website/content/docs/concepts/filtering/oidc-managed-groups.mdx index 5892460ab..0a10319d5 100644 --- a/website/content/docs/concepts/filtering/oidc-managed-groups.mdx +++ b/website/content/docs/concepts/filtering/oidc-managed-groups.mdx @@ -1,13 +1,13 @@ --- layout: docs -page_title: Filtering - OIDC Managed Groups +page_title: Filtering - OIDC managed groups description: |- How to configure filters for managed groups within the OIDC auth method. --- [filter syntax]: /boundary/docs/concepts/filtering -# OIDC Managed Groups Filtering +# Filter OIDC managed groups This page describes how to use filters with OIDC managed groups. It assumes that the reader is familiar with the general [filter syntax][] as well as with diff --git a/website/content/docs/concepts/filtering/resource-listing.mdx b/website/content/docs/concepts/filtering/resource-listing.mdx index cb2be3f05..527fad787 100644 --- a/website/content/docs/concepts/filtering/resource-listing.mdx +++ b/website/content/docs/concepts/filtering/resource-listing.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Filtering - Resource Listing +page_title: Filtering - resource listing description: |- How to use filter list responses coming back from Boundary. --- -# List Filtering +# Filter resource listings This page describes how to use filters when listing resources. This can be used to reduce the returned set of resources when performing a list operation. diff --git a/website/content/docs/concepts/filtering/worker-tags.mdx b/website/content/docs/concepts/filtering/worker-tags.mdx index 70b3778fc..d9101b645 100644 --- a/website/content/docs/concepts/filtering/worker-tags.mdx +++ b/website/content/docs/concepts/filtering/worker-tags.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Filtering - Worker Tags +page_title: Filtering - worker tags description: |- How to use worker tags to control which workers can handle a given resource. --- -# Worker Tags +# Filter worker tags This page describes how to use worker tags and filters to control which workers are allowed to handle a given resource. This can be used to control traffic @@ -100,7 +100,7 @@ array with the tags intended for the particular key is required: ["prod", "webservers"] ``` -# Worker filtering +## Workers As filters operate on JSON Pointer selectors, the values that are input into the filter come from the JSON representation of the values in the configuration file @@ -135,7 +135,7 @@ Following are some examples of using these values in filters: ~> **Note:** Each tag can have multiple values, so the `in` operator must be used to match values. If you know that you have only one value, an equivalent would be `"/tags/key/0" == "value"`. -# Target worker filtering +## Target workers Once workers have tags, you can use these tags to control which workers are allowed to manage a given session by specifying optional worker filter attributes @@ -148,7 +148,7 @@ The `ingress_worker_filter`HCP/ENT attribute controls which workers a This is the worker a client connects to when initiating a connection to a target. -# Vault worker filtering HCP/ENT +## Vault workers HCP/ENT Tags are used to control which [PKI workers] can manage Vault requests by specifying a `worker_filter`attribute when configuring [credential stores]. diff --git a/website/content/docs/concepts/host-discovery.mdx b/website/content/docs/concepts/host-discovery.mdx index 83aa66f13..531d614a0 100644 --- a/website/content/docs/concepts/host-discovery.mdx +++ b/website/content/docs/concepts/host-discovery.mdx @@ -16,7 +16,7 @@ or dealing with dynamic services whose connection info frequently changes. changed infrastructure resources – and their connection info – to Boundary as hosts. -## Automating host discovery in Boundary +## Automated host discovery in Boundary Boundary supports target/host discovery in three primary workflows: diff --git a/website/content/docs/concepts/iam.mdx b/website/content/docs/concepts/iam.mdx index 4e5e2901f..015ccd34b 100644 --- a/website/content/docs/concepts/iam.mdx +++ b/website/content/docs/concepts/iam.mdx @@ -1,11 +1,12 @@ --- layout: docs -page_title: Identity and Access Management (IAM) +page_title: Identity and access management (IAM) description: |- - Identity and Access Management in Boundary + Identity and access management in Boundary --- # Identity and access management (IAM) + ## IAM components There are 6 key components to Boundary's identity and access management system: **Scopes**, **Auth Methods**, **Accounts**, **Users**, **Groups**, and **Roles**. @@ -41,18 +42,19 @@ method's identity provider to provide up-to-date information. can be contained by any scope, and the permissions can be applied to the same scope or any child scope. ## Access management -### Configuring users - username/password + +### Configure users - username/password There are 3 steps to adding new users to Boundary using the password auth method: 1. Choose the **scope** and the **auth method** that the user will use to authenticate to Boundary. If the desired auth method does not exist, you must create a new one. 2. After the auth method is selected, you can create an **account** under the auth method. 3. In the same scope, create a new **user**, and then attach the new account to the new user. The user is now able to authenticate to Boundary. -### Configuring users - OIDC/LDAP +### Configure users - OIDC/LDAP [OIDC](/boundary/tutorials/identity-management/oidc-auth) and LDAP accounts and users are auto-vivified (automatically generated) in Boundary in the same scope as the auth method. The accounts and users are only created once the user authenticates to Boundary for the first time. The same applies to OIDC/LDAP [managed groups](/boundary/tutorials/identity-management/oidc-idp-groups). -### Granting permissions +### Grant permissions When setting up access controls for a user, it is important to first consider which scope(s) the user needs access to. **Each scope requires its own set of roles**, giving users permission to perform actions through grants strings. It is recommended to add the user to a group, and then add the group to the role(s), instead of adding the user directly to the role(s). This way, you can manage multiple users at the same time, and it is easier to @@ -71,7 +73,7 @@ Projects. - `id=*;type=*;actions=*` -### Boundary Viewer +### Boundary viewer 1. **Each** of the 7 scopes requires a role (ex. “viewer”) 2. Each role needs to have the user/group added as a principal 3. Each role needs to have the grants of diff --git a/website/content/docs/concepts/security/connections-tls.mdx b/website/content/docs/concepts/security/connections-tls.mdx index 33d62984e..57e6c9824 100644 --- a/website/content/docs/concepts/security/connections-tls.mdx +++ b/website/content/docs/concepts/security/connections-tls.mdx @@ -19,7 +19,7 @@ security by default with simplicity of operation. Details are in the individual sections below. -## Client-to-Controller TLS +## Client-to-controller TLS Boundary's API access (that is, the Controller server defaulting to port 9200) uses standard PKI. TLS is configured by providing a valid certificate (and @@ -29,7 +29,7 @@ provides broad compatibility with a wide array of clients. It is possible to require client certificates; see the configuration for `listener` blocks to see the available TLS parameters. -## Client-to-Worker TLS +## Client-to-worker TLS Workers do not require any configuration for their client-facing listeners to support a high degree of security. Instead, the TLS configuration to use is @@ -94,7 +94,7 @@ certificate/private key would instead act as credentials for the session, similar to a username/password. -## Worker-to-Upstream TLS +## Worker-to-upstream TLS Workers connect to upstreams (Controllers, or other Workers) via TLS connections. In order to make these connections, Workers have to be @@ -108,7 +108,7 @@ cluster, while the PKI mechanism provides positive access control at registration time. Currently, HCP Boundary deployments only support PKI authentication for self-managed Workers. -### PKI-Based Worker Authentication +### PKI-based worker authentication In the PKI-based authentication mechanisms, Workers are registered to the cluster by informing the cluster of a Worker's public signing and encryption @@ -127,7 +127,7 @@ produces the initial key material. Note that the mechanisms described in this section omit detail for clarity. -#### Worker-Led PKI-Based Registration +#### Worker-led PKI-based registration Registration proceeds as follows: @@ -169,7 +169,7 @@ Registration proceeds as follows: bundle; and validates the nonce, storing the issued certificate and CA certificate. -#### PKI-Based Session Establishment +#### PKI-based session establishment Using the stored credentials, a PKI-based worker establishes a session as follows: @@ -202,7 +202,7 @@ follows: 5. The TLS connection is now established, and the upstream can handle the Worker protocol. -#### PKI-Based Credential Rotation +#### PKI-based credential rotation Periodically, a PKI-based Worker will trigger rotation of its credentials. The mechanism is as follows: @@ -239,7 +239,7 @@ mechanism is as follows: can be used to successfully derive a shared symmetric encryption key. The Worker saves the new credentials and uses them going forwardl -### KMS-Based Worker Authentication +### KMS-based worker authentication Workers can take advantage of the [KMS](/boundary/docs/concepts/security/data-encryption) key designated for `worker-auth` within Boundary's configuration file, which diff --git a/website/content/docs/concepts/security/data-encryption.mdx b/website/content/docs/concepts/security/data-encryption.mdx index 29cd9a5cd..b7ead769f 100644 --- a/website/content/docs/concepts/security/data-encryption.mdx +++ b/website/content/docs/concepts/security/data-encryption.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Data Encryption +page_title: Data encryption description: |- How Boundary secures data at rest --- -# Data Security in Boundary +# Data security in Boundary Boundary has multiple mechanisms to ensure secure end-to-end behavior of the system. A key part of this is [support for various Key Management @@ -13,14 +13,14 @@ Systems](/boundary/docs/configuration/kms) that protect the base encryption keys for various functions. This page describes the various KMS key purposes that Boundary supports and how they are used within the system. -## The `worker-auth-storage` KMS Key +## The `worker-auth-storage` KMS key The `worker-auth-storage` KMS key is used by a [PKI Worker](/boundary/docs/configuration/worker/pki-worker) for storage of authentication keys. It is optional for PKI workers; if not specified the authentication keys will not be encrypted on disk. This is not used by KMS workers. -## The `root` KMS Key and Per-Scope KEK/DEKs OSS Only +## The `root` KMS key and per-scope KEK/DEKs OSS only Following best practices of using different encryption keys for different purposes, Boundary has a number of encryption keys generated within each scope. @@ -58,7 +58,7 @@ The current scoped DEKs and their purposes are detailed below: - `sessions`: This is used as a base key against which to derive session-specific encryption keys. -### Key version lifecycle Management +### Key version lifecycle management You can control the lifecycles of the per-scope KEK and DEKs via the CLI or API using the key endpoints under the scopes section. To rotate all the keys @@ -110,14 +110,14 @@ The `bsr` KMS key is required for [session recording](/boundary/docs/configurati If you do not add a `bsr` key to your controller configuration, you will receive an error when you attempt to enable session recording. The key is used for encrypting data and checking the integrity of recordings. -## The `previous-root` KMS key OSS Only +## The `previous-root` KMS key OSS only The `previous-root` KMS key is used when migrating to a new `root` key. Adding the `previous-root` KMS key to your configuration informs the Controller to use it for decrypting the existing information in the database, allowing you to rotate and rewrap the KEKs to complete the migration to the new root key. -## The `worker-auth` KMS Key OSS Only +## The `worker-auth` KMS key OSS only The `worker-auth` KMS key is a key shared by the Controller and Worker in order to authenticate a Worker to the Controller. Specifics of this mechanism can be @@ -125,7 +125,7 @@ found on the [Connections/TLS page](/boundary/docs/concepts/security/connections a worker is used with [PKI authentication](/boundary/docs/configuration/worker/pki-worker) this is unnecessary. -## The `recovery` KMS Key OSS Only +## The `recovery` KMS key OSS only The `recovery` KMS key is used for rescue/recovery operations that can be used by a client to authenticate almost any operation within Boundary. Its mechanism @@ -161,7 +161,7 @@ with the options to skip creating default resources, Terraform can be used to create the specific resources needed instead, with the `recovery` KMS used to authenticate setting up the initial auth method(s). -## The `config` KMS Key OSS Only +## The `config` KMS key OSS only This key can be used to encrypt values within Boundary's configuration file. By sharing this block between Boundary and an operator, the operator can put diff --git a/website/content/docs/concepts/security/permissions/assignable-permissions.mdx b/website/content/docs/concepts/security/permissions/assignable-permissions.mdx index b1f65df4d..1683bae98 100644 --- a/website/content/docs/concepts/security/permissions/assignable-permissions.mdx +++ b/website/content/docs/concepts/security/permissions/assignable-permissions.mdx @@ -1,17 +1,17 @@ --- layout: docs -page_title: Assignable Permissions +page_title: Assignable permissions description: |- - Assignable Permissions + Assignable permissions --- -## Assignable Permissions +# Assignable permissions Resources identified by the ID/Type selectors have permissions granted to the user in the form of actions and visibility (via `output_fields`). Each of these is detailed in the subsections below. -### Actions +## Actions Actions convey the ability to perform some action against a resource or collection. Many of these are common CRUD actions (`create`, `read`, `update`, @@ -22,7 +22,7 @@ making a connection to that target, and `auth-method` resources have an part these are straightforward, however there are a couple of special cases to know. -#### Subactions +### Subactions Some subactions are supported. These actions have a format `top_level_action:subaction`, such as `read:self`. Being granted the top level @@ -30,7 +30,7 @@ action infers being granted all subactions. Thus, if a grant conveys `read`, it also matches the API actions `read` and `read:self`. However, if a grant conveys `read:self`, it will match the API action `read:self` but will not match `read`. -#### The `no-op` Action and Listing Visibility +### The `no-op` action and listing visibility There is an action that can be granted called `no-op`. As might be apparent, `no-op` is not used for any real action in Boundary; the purpose of this action @@ -45,7 +45,7 @@ Boundary (that is, granting access to `u_anon`). By granting the `no-op` action to users, they can see the resources in the output of a list command without needing other capability grants as well. -### Anonymous User Restrictions +## Anonymous user restrictions Starting in Boundary 0.9.0, there are severe limits placed on the actions allowed to be assigned to the anonymous user `u_anon`. This is meant to avoid @@ -65,7 +65,7 @@ anonymous user. In the future this may change, but trying to limit this introduces other restrictions on reasonable administrative workflows so an acceptable set of tradeoffs would need to be figured out. -### Output Fields +## Output fields Grant strings can contain an `output_fields` field. This allows fine-grained control over visibility of data returned to users. diff --git a/website/content/docs/concepts/security/permissions/index.mdx b/website/content/docs/concepts/security/permissions/index.mdx index efa5a187f..9d678c1a6 100644 --- a/website/content/docs/concepts/security/permissions/index.mdx +++ b/website/content/docs/concepts/security/permissions/index.mdx @@ -1,14 +1,12 @@ --- layout: docs -page_title: Permissions Index +page_title: Permissions index description: |- Boundary's permissions model --- # Permissions in Boundary -## Overview - Boundary's permissions model is a composable, RBAC, allow-only model that attempts to marry flexibility with usability. This page discusses the permission model's fundamental concepts, provides examples of the specific forms of allowed @@ -31,7 +29,7 @@ relatively simple and predictable. At a very high level, permissions within Boundary are declared via grant strings and mapped to users via roles. -### Grant Strings +## Grant strings A grant string has a form similar to: @@ -61,7 +59,7 @@ Additionally, there are two types of assigned permissions: Grant strings can be supplied via a human-friendly string syntax or via JSON. -### Roles +## Roles Roles map grant strings to _principals_, currently users and groups. Every role assigns grants within a specific scope: either the scope in which the role diff --git a/website/content/docs/concepts/security/permissions/permission-grant-formats.mdx b/website/content/docs/concepts/security/permissions/permission-grant-formats.mdx index 938301792..4adef8fb1 100644 --- a/website/content/docs/concepts/security/permissions/permission-grant-formats.mdx +++ b/website/content/docs/concepts/security/permissions/permission-grant-formats.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Permission Grant Formats +page_title: Permission grant formats description: |- - Permission Grant Formats + Permission grant formats --- -## Permission Grant Formats +# Permission grant formats Because of the aforementioned properties of the permissions model, grants are relatively simple. All grants take one of four forms. These examples use the @@ -17,7 +17,7 @@ array `output_fields` value. in all of them. It is also valid in each case to omit `actions` and specify _only_ `output_fields`. -### ID Only +## ID only This is the simplest form: for a given specific resource, allow these actions. Example: @@ -29,7 +29,7 @@ to specify `create` or `list` as actions in this format, as this format explicitly identifies a resource, whereas those actions operate exclusively on collections. -### Type Only +## Type only For a given type, allow these actions. Example: @@ -58,7 +58,7 @@ method. To specify actions against those, you must also specify to which specific containing resource you want the grants to apply. This can be done with the pinned format shown below. -### Pinned ID +## Pinned ID This form "pins" actions to a non-top-level type within a specific ID. It's easiest to explain with an example: @@ -70,18 +70,18 @@ the scope, but _only the host sets belonging to host catalog hcst_1234567890_. Pinning is essentially a way to use top-level resources to create mini permission boundaries for their subordinate resources. -### Wildcard ID +## Wildcards Various wildcard possibilities are allowed: -#### Wildcard ID +### Wildcard ID When just the ID is `*`, it matches all IDs of the given type. This can be used with both top-level resource types and not. Example: `id=*;type=host-set;actions=create,read,update,set-hosts` -#### Wildcard Type +### Wildcard type For non-top-level resources with pinned IDs, the `type` can be a wildcard: @@ -91,7 +91,7 @@ This would allow `create`, `read`, and `update` actions for all types of subordinate resources (in this case host sets and hosts) underneath the host catalog with ID `hcst_1234567890`. -#### Wildcard ID and Type +### Wildcard ID and type If ID and type are both a wildcard, the grant is essentially a catch-all that will match any resource of any type within the scope and allow the given @@ -99,7 +99,7 @@ actions. `id=*;type=*;actions=read,list` -#### Wildcard ID, Type, and Actions +### Wildcard ID, type, and actions Finally, ID, type, and actions can all be wildcards: @@ -107,7 +107,7 @@ Finally, ID, type, and actions can all be wildcards: Such a grant is essentially a full administrator grant for a scope. -### Templates +## Templates A few template possibilities exist, which will at grant evaluation time substitute the given value into the ID field of the grant string: diff --git a/website/content/docs/concepts/security/permissions/resource-table.mdx b/website/content/docs/concepts/security/permissions/resource-table.mdx index 43d1a8da2..1a2ab8494 100644 --- a/website/content/docs/concepts/security/permissions/resource-table.mdx +++ b/website/content/docs/concepts/security/permissions/resource-table.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Resource Table +page_title: Resource table description: |- - Resource Table + Resource table --- -## Resource Table +# Resource table The following table works as a quick cheat-sheet to help you manage your permissions. Note that it's not exhaustive; for brevity it does _not_ show diff --git a/website/content/docs/configuration/controller.mdx b/website/content/docs/configuration/controller.mdx index ccc9a6f52..34dab4943 100644 --- a/website/content/docs/configuration/controller.mdx +++ b/website/content/docs/configuration/controller.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Controller - Configuration +page_title: Controller - configuration description: |- The controller stanza configures controller-specifc parameters. --- -# `controller` Stanza +# `controller` stanza The `controller` stanza configures Boundary controller-specific parameters. @@ -107,11 +107,12 @@ description will be read. used when an `ops` listener is set and the Controller is present. Default is 0 seconds. ## Signals + The `SIGHUP` signal causes a controller to reload its configuration file to pick up any updates to the `database url` value. Any other updated values are ignored. The `SIGTERM` and `SIGINT` signals initiate a graceful shutdown on a controller. A graceful shutdown closes listeners and servers before shutting down the controller. -## KMS Configuration +## KMS configuration The controller requires two KMS stanzas for `root` and `worker-auth` purposes: @@ -164,7 +165,7 @@ kms "aead" { Boundary supports many kinds of KMS integrations. For a complete guide to all available KMS types, see our [KMS documentation](/boundary/docs/configuration/kms). -# Complete Configuration Example +## Complete configuration example ```hcl # Disable memory lock: https://www.man7.org/linux/man-pages/man2/mlock.2.html diff --git a/website/content/docs/configuration/events/common.mdx b/website/content/docs/configuration/events/common.mdx index 5a12a0bf0..5bfede66d 100644 --- a/website/content/docs/configuration/events/common.mdx +++ b/website/content/docs/configuration/events/common.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Controller/Worker - Events - Common Sink Parameters +page_title: Controller/worker - events - common sink parameters description: |- The common sink parameters for all sink types. --- -# Common Sink Parameters +# Common sink parameters These parameters are shared across all sink types: @@ -50,7 +50,7 @@ These parameters are shared across all sink types: - `secret` `(string: "", "encrypt", "hmac-sha256", "redact")` - Specifies the filter operation to apply to fields that are classified as secret. -## `audit_config` Examples +## `audit_config` examples This example is equivalent to the default settings if no `audit_config` stanza is provided. diff --git a/website/content/docs/configuration/events/file.mdx b/website/content/docs/configuration/events/file.mdx index b3f75cf12..e2fe8dac1 100644 --- a/website/content/docs/configuration/events/file.mdx +++ b/website/content/docs/configuration/events/file.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Controller/Worker - Events - File Sink - Configuration +page_title: Controller/worker - events - file sink - configuration description: |- The file sink configures Boundary to send events to a file. --- -# `file` Sink +# `file` sink The file sink configures Boundary to send events to a file. @@ -26,7 +26,7 @@ The `sink` stanza may be specified more than once to make Boundary send events to multiple sinks; however, each file sink must have a unique `path` + `file_name`. -## common parameters +## Common parameters These parameters are shared across all sink types: [common sink parameters](/boundary/docs/configuration/events/common) diff --git a/website/content/docs/configuration/events/index.mdx b/website/content/docs/configuration/events/index.mdx index d916d631f..c2480610e 100644 --- a/website/content/docs/configuration/events/index.mdx +++ b/website/content/docs/configuration/events/index.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Controller/Worker - Events +page_title: Controller/worker - events description: |- The events stanza configures events-specific parameters. --- -# `events` Stanza +# `events` stanza The `events` stanza configures Boundary events-specific parameters. @@ -34,7 +34,7 @@ events { } ``` -- `audit_enabled` - Specifies if audit events should be emitted. +- `audit_enabled` - Specifies if audit events should be emitted. - `observations_enabled` - Specifies if observation events should be emitted. @@ -45,7 +45,7 @@ events { events will be sent to a default [stderr](/boundary/docs/configuration/events/stderr) sink. Events may be sent to multiple sinks. -## Default Events Stanza +## Default events stanza If no event stanza is specified then the following default is used: diff --git a/website/content/docs/configuration/events/stderr.mdx b/website/content/docs/configuration/events/stderr.mdx index 11766ef11..75a5e0bb8 100644 --- a/website/content/docs/configuration/events/stderr.mdx +++ b/website/content/docs/configuration/events/stderr.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Controller - Events - stderr Sink - Configuration +page_title: Controller - events - stderr sink - configuration description: |- The stderr sink configures Boundary to send events to a stderr. --- -# `stderr` Sink +# `stderr` sink The stderr sink configures Boundary to send events to a stderr. @@ -19,7 +19,7 @@ sink "stderr" { } ``` -## common parameters +## Common parameters These parameters are shared across all sink types: [common sink parameters](/boundary/docs/configuration/events/common) diff --git a/website/content/docs/configuration/index.mdx b/website/content/docs/configuration/index.mdx index 2ef9b1426..13c8939ce 100644 --- a/website/content/docs/configuration/index.mdx +++ b/website/content/docs/configuration/index.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Overview/Top-Level Parameters +page_title: Overview/top-level parameters description: Boundary configuration reference. --- @@ -21,13 +21,13 @@ configuration block examples for Boundary controllers and workers. After the configuration is written, use the `-config` flag to specify a local path to the file. -## HCP Boundary-Only Parameters +## HCP Boundary-only parameters - `hcp_boundary_cluster_id` `(string)` - The ID of an HCP Boundary cluster. Setting this allows discovery of upstream addresses for self-managed workers to connect to the cluster. -## Shared OSS and HCP Boundary Parameters +## Shared self-managed and HCP Boundary parameters - [`worker`](/boundary/docs/configuration/worker): Worker specific configuration. If present, `boundary server` will start a Worker subprocess. @@ -80,7 +80,7 @@ path to the file. Specifies the log format to use; overridden by CLI and env var parameters. Supported log formats: `"standard"`, `"json"`. -## OSS-Only Parameters +## Self-managed Boundary-only parameters - [`controller`](/boundary/docs/configuration/controller): Controller specific configuration. If present, `boundary server` will start a Controller subprocess. @@ -88,6 +88,7 @@ path to the file. - [`plugins`](/boundary/docs/configuration/plugins): Configures options for plugins. ## Signals + The `SIGHUP` signal causes worker and controller processes to reload their configuration files to pick up updated values. ~> **Note:** You cannot reload all configuration values using the `SIGHUP` signal. Refer to the configuration pages for @@ -97,7 +98,7 @@ on which values can be reloaded on `SIGHUP`. The `SIGTERM` and `SIGINT` signals cause worker and controller processes to enter graceful shutdown. A graceful shutdown for a controller closes listeners and servers before shutting down the controller. A graceful shutdown for a worker waits for any sessions to drain before shutting down the worker. Workers in a graceful shutdown state do not receive any new work, including session proxying, from the control plane. -## Example Configurations +## Example configurations For complete example configurations see the sections for [controller](/boundary/docs/configuration/controller) and diff --git a/website/content/docs/configuration/kms/aead.mdx b/website/content/docs/configuration/kms/aead.mdx index 0b79d1b11..1de11bb9e 100644 --- a/website/content/docs/configuration/kms/aead.mdx +++ b/website/content/docs/configuration/kms/aead.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: AEAD - Configuration +page_title: AEAD - configuration description: |- The AEAD KMS configures AEAD-specific parameters. --- diff --git a/website/content/docs/configuration/kms/alicloudkms.mdx b/website/content/docs/configuration/kms/alicloudkms.mdx index bc8c13a6a..bcf9d1835 100644 --- a/website/content/docs/configuration/kms/alicloudkms.mdx +++ b/website/content/docs/configuration/kms/alicloudkms.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: AliCloud KMS - KMSs - Configuration +page_title: AliCloud KMS - KMSs - configuration description: >- The AliCloud KMS configures Boundary to use AliCloud KMS for key management. --- @@ -12,7 +12,7 @@ The AliCloud KMS is activated by one of the following: - The presence of a `kms "alicloudkms"` block in Boundary's configuration file. -## `alicloudkms` Example +## `alicloudkms` example This example shows configuring AliCloud KMS through the Boundary configuration file by providing all the required values: @@ -27,7 +27,7 @@ kms "alicloudkms" { } ``` -## `alicloudkms` Parameters +## `alicloudkms` parameters These parameters apply to the `kms` stanza in the Boundary configuration file: diff --git a/website/content/docs/configuration/kms/awskms.mdx b/website/content/docs/configuration/kms/awskms.mdx index e4e8d94c4..19310ad64 100644 --- a/website/content/docs/configuration/kms/awskms.mdx +++ b/website/content/docs/configuration/kms/awskms.mdx @@ -2,7 +2,7 @@ layout: docs page_title: AWS KMS - KMSs - Configuration description: |- - The AWS KMS configures Boundary to use AWS KMS for key management. + The AWS KMS configures Boundary to use AWS KMS for key management. mechanism. --- @@ -10,7 +10,7 @@ description: |- The AWS KMS configures Boundary to use AWS KMS for key management. -## `awskms` Example +## `awskms` example This example shows configuring AWS KMS through the Boundary configuration file by providing all the required values: @@ -26,7 +26,7 @@ kms "awskms" { } ``` -## `awskms` Parameters +## `awskms` parameters These parameters apply to the `kms` stanza in the Boundary configuration file: @@ -106,7 +106,7 @@ Boundary needs the following permissions on the KMS key: These can be granted via IAM permissions on the principal that Boundary uses, on the KMS key policy for the KMS key, or via KMS Grants on the key. -## Key Rotation +## Key rotation This KMS supports rotating the master keys defined in AWS KMS [doc](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). Both automatic diff --git a/website/content/docs/configuration/kms/azurekeyvault.mdx b/website/content/docs/configuration/kms/azurekeyvault.mdx index 81f7374a1..135770f12 100644 --- a/website/content/docs/configuration/kms/azurekeyvault.mdx +++ b/website/content/docs/configuration/kms/azurekeyvault.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Azure Key Vault - Seals - Configuration +page_title: Azure Key Vault - seals - configuration description: >- The Azure Key Vault seal configures Boundary to use Azure Key Vault for key management. --- @@ -12,7 +12,7 @@ The Azure Key Vault KMS is activated by one of the following: - The presence of a `seal "azurekeyvault"` block in Boundary's configuration file. -## `azurekeyvault` Example +## `azurekeyvault` example This example shows configuring Azure Key Vault KMS through the Boundary configuration file by providing all the required values: @@ -28,7 +28,7 @@ kms "azurekeyvault" { } ``` -## `azurekeyvault` Parameters +## `azurekeyvault` parameters These parameters apply to the `kms` stanza in the Vault configuration file: diff --git a/website/content/docs/configuration/kms/gcpckms.mdx b/website/content/docs/configuration/kms/gcpckms.mdx index d95f886c8..c5421b085 100644 --- a/website/content/docs/configuration/kms/gcpckms.mdx +++ b/website/content/docs/configuration/kms/gcpckms.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: GCP Cloud KMS - KMSs - Configuration +page_title: GCP Cloud KMS - KMSs - configuration description: >- The GCP Cloud KMS configures Boundary to use GCP Cloud KMS for key management. --- @@ -11,7 +11,7 @@ The GCP Cloud KMS configures Boundary to use GCP Cloud KMS for key management. The GCP Cloud KMS seal is activated by the presence of a `seal "gcpckms"` block in Boundary's configuration file. -## `gcpckms` Example +## `gcpckms` example This example shows configuring GCP Cloud KMS through the Boundary configuration file by providing all the required values: @@ -27,7 +27,7 @@ kms "gcpckms" { } ``` -## `gcpckms` Parameters +## `gcpckms` parameters These parameters apply to the `kms` stanza in the Boundary configuration file: @@ -53,7 +53,7 @@ These parameters apply to the `kms` stanza in the Boundary configuration file: encryption and decryption. May also be specified by the `GCPCKMS_WRAPPER_CRYPTO_KEY` environment variable. -## Authentication & Permissions +## Authentication & permissions Authentication-related values must be provided, either as environment variables or as configuration parameters. diff --git a/website/content/docs/configuration/kms/index.mdx b/website/content/docs/configuration/kms/index.mdx index 7c2b8cb9a..13238667f 100644 --- a/website/content/docs/configuration/kms/index.mdx +++ b/website/content/docs/configuration/kms/index.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: KMS - Configuration +page_title: KMS - configuration description: |- The KMS stanza configures KMS-specific parameters. --- -# `kms` Stanza +# `kms` stanza The `kms` stanza configures Boundary kms-specific parameters. diff --git a/website/content/docs/configuration/kms/ocikms.mdx b/website/content/docs/configuration/kms/ocikms.mdx index a01468782..a22bb8299 100644 --- a/website/content/docs/configuration/kms/ocikms.mdx +++ b/website/content/docs/configuration/kms/ocikms.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: OCI KMS - KMSs - Configuration +page_title: OCI KMS - KMSs - configuration description: |- The OCI KMS configures Boundary to use OCI KMS for key management. --- @@ -11,7 +11,7 @@ The OCI KMS configures Boundary to use OCI KMS for key management. The OCI KMS is activated by the presence of a `kms "ocikms"` block in Boundary's configuration file. -## `ocikms` Example +## `ocikms` example This example shows configuring the OCI KMS through the Boundary configuration file by providing all the required values: @@ -26,7 +26,7 @@ kms "ocikms" { } ``` -## `ocikms` Parameters +## `ocikms` parameters These parameters apply to the `kms` stanza in the Boundary configuration file: @@ -91,7 +91,7 @@ admit dynamic-group of tenancy tenantA to use keys in compa ``` -## `ocikms` Rotate OCI KMS Key +## `ocikms` rotate OCI KMS key For the [OCI KMS key rotation feature][oci-kms-rotation], OCI KMS will create a new version of key internally. This process is independent from Boundary, and boundary still uses the same `key_id` without any interruption. diff --git a/website/content/docs/configuration/kms/transit.mdx b/website/content/docs/configuration/kms/transit.mdx index d18aca5a0..5f39f96b4 100644 --- a/website/content/docs/configuration/kms/transit.mdx +++ b/website/content/docs/configuration/kms/transit.mdx @@ -1,17 +1,17 @@ --- layout: docs -page_title: Vault Transit - Seals - Configuration +page_title: Vault Transit - seals - configuration description: |- The Transit configures Boundary to use Vault's Transit Secret Engine for key management. --- -# `transit` Seal +# `transit` seal The Transit configures Boundary to use Vault's Transit Secret Engine for key management. The Transit KMS is activated by the presence of a `kms transit` block in Boundary's configuration file -## `transit` Example +## `transit` example This example shows configuring Transit KMS through the Boundary configuration file by providing all the required values: @@ -37,7 +37,7 @@ kms "transit" { } ``` -## `transit` Parameters +## `transit` parameters These parameters apply to the `kms` stanza in the Vault configuration file: diff --git a/website/content/docs/configuration/listener/index.mdx b/website/content/docs/configuration/listener/index.mdx index 3e39e5715..c7042eb26 100644 --- a/website/content/docs/configuration/listener/index.mdx +++ b/website/content/docs/configuration/listener/index.mdx @@ -1,19 +1,19 @@ --- layout: docs -page_title: Listeners - Configuration +page_title: Listeners - configuration description: |- The listener stanza configures the addresses and ports on which Boundary will respond to requests. --- -# `listener` Stanza +# `listener` stanza The `listener` stanza configures the addresses and ports on which Boundary will respond to requests. At this time, there are two listener types: [TCP](/boundary/docs/configuration/listener/tcp) and [Unix](/boundary/docs/configuration/listener/unix). -## `listener` Purpose +## `listener` purpose The `purpose` field is used to determine what part of Boundary's functionality is started and exposed for a given listener block. Each listener must have a `purpose` set. @@ -22,13 +22,13 @@ Currently, Boundary recognizes the following listener purposes: - `api`: Starts up and exposes Boundary's controller API. At least one `api` listener must be present if a Boundary - instance is set-up as a controller. + instance is set-up as a controller. By default, it runs on `:9200`. - `cluster`: Starts up and exposes Boundary's worker and controller communication layer. Only one `cluster` listener is allowed per Boundary instance. Must be present if a Boundary - instance is set-up as a controller. + instance is set-up as a controller. By default, it runs on `:9201`. - `proxy`: Starts up a Boundary Worker. By default, it runs @@ -39,5 +39,3 @@ endpoints (eg: /health). By default, it runs on `:9203`. This listener's exposed functionality depends on what Boundary components you're running on any given Boundary instance (eg: Health does not run unless your Boundary instance has a controller running) - - diff --git a/website/content/docs/configuration/listener/tcp.mdx b/website/content/docs/configuration/listener/tcp.mdx index d77352f6b..566a9de0f 100644 --- a/website/content/docs/configuration/listener/tcp.mdx +++ b/website/content/docs/configuration/listener/tcp.mdx @@ -1,12 +1,12 @@ --- layout: docs -page_title: TCP - Listeners - Configuration +page_title: TCP - listeners - configuration description: |- The TCP listener configures Boundary to listen on the specified TCP address and port. --- -# `tcp` Listener +# `tcp` listener The TCP listener configures Boundary to listen on a TCP address/port. @@ -37,7 +37,9 @@ There are two different config parameters that define headers: `custom_api_respo with `/v1/`. UI headers apply to all other paths. This allows for configuring headers specifically for serving content to a web browser, such as CSP headers. -## `tcp` Listener Parameters +## `tcp` listener parameters + +Refer to the following sections for `tcp` listener parameters. ### General @@ -61,7 +63,7 @@ for serving content to a web browser, such as CSP headers. reading the entire request, including the body. This is specified using a label suffix like `"30s"` or `"1h"`. -- `http_write_timeout` `string: "0")` - Specifies the maximum duration before +- `http_write_timeout` `(string: "0")` - Specifies the maximum duration before timing out writes of the response and is reset whenever a new request's header is read. The default value of `"0"` means infinity. This is specified using a label suffix like `"30s"` or `"1h"`. @@ -100,7 +102,7 @@ for serving content to a web browser, such as CSP headers. default, such as `"Content-Type"`, `"X-Requested-With"`, and `"Authorization"`. -### `custom_api_response_headers` Parameters +### `custom_api_response_headers` parameters - `default` `(key-value-map: {})` - A map of string header names to an array of string values. The default headers are set on all endpoints regardless of @@ -121,7 +123,7 @@ for serving content to a web browser, such as CSP headers. is set when the http response status code is `"200"`. This overrides headers defined at the `default` and `collective status code` level. -### `custom_ui_response_headers` Parameters +### `custom_ui_response_headers` parameters - `default` `(key-value-map: {})` - A map of string header names to an array of string values. The default headers are set on all endpoints regardless of @@ -145,7 +147,7 @@ for serving content to a web browser, such as CSP headers. ### TLS ~> `tls` parameters are valid for `api` and `ops` listeners. `cluster` -and `proxy` connections use their own ephemeral TLS stacks. For more +and `proxy` connections use their own ephemeral TLS stacks. For more information, see [the connections security concepts page](/boundary/docs/concepts/security/connections-tls). @@ -215,15 +217,17 @@ page](/boundary/docs/concepts/security/connections-tls). there is no X-Forwarded-For header or it is empty, the client address will be used as-is, rather than the client connection rejected. -### `telemetry` Parameters +### `telemetry` parameters - `unauthenticated_metrics_access` `(string: "false")` - If set to true, allows unauthenticated access to the `/v1/sys/metrics` endpoint. !--> -## `tcp` Listener Examples +## `tcp` listener examples -### Configuring TLS +Refer to the following sections for examples of `tcp` listeners. + +### Configure TLS This example shows enabling a TLS listener. @@ -235,7 +239,7 @@ listener "tcp" { } ``` -### Configuring custom http response headers +### Configure custom http response headers This example shows configuring custom http response headers. Operators can configure `"custom_api_response_headers"` and `"custom_ui_response_headers"` sub-stanzas in the listener stanza to @@ -321,7 +325,7 @@ listener "tcp" { } ``` -### Listening on Multiple Interfaces +### Listen on mulitple interfaces This example shows Boundary listening on a private interface, as well as localhost. diff --git a/website/content/docs/configuration/listener/unix.mdx b/website/content/docs/configuration/listener/unix.mdx index bde8cbb8f..c080d304d 100644 --- a/website/content/docs/configuration/listener/unix.mdx +++ b/website/content/docs/configuration/listener/unix.mdx @@ -1,13 +1,13 @@ --- layout: docs -page_title: Unix Domain Socket - Listeners - Configuration +page_title: Unix domain socket - listeners - configuration description: |- The Unix listener configures Boundary to listen on the specified Unix domain socket. --- -# `unix` Listener +# `unix` listener -The Unix listener configures Boundary to listen on a Unix domain socket. +The `unix` listener configures Boundary to listen on a Unix domain socket. ~> **Note:** This is only available for listeners for `api` and `cluster` purpose. Unix sockets cannot currently be used for `"proxy"` purpose on a Worker. @@ -23,7 +23,9 @@ The `listener` stanza may be specified more than once to make Boundary listen on multiple interfaces; however, only one listener marked for `cluster` purpose is allowed. -## `unix` Listener Parameters +## `unix` listener parameters + +Refer to the following sections for the supported `unix` listener parameters. ### General @@ -46,7 +48,7 @@ allowed. reading the entire request, including the body. This is specified using a label suffix like `"30s"` or `"1h"`. -- `http_write_timeout` `string: "0")` - Specifies the maximum duration before +- `http_write_timeout` `(string: "0")` - Specifies the maximum duration before timing out writes of the response and is reset whenever a new request's header is read. The default value of `"0"` means infinity. This is specified using a label suffix like `"30s"` or `"1h"`. @@ -158,15 +160,17 @@ page](/boundary/docs/concepts/security/connections-tls). there is no X-Forwarded-For header or it is empty, the client address will be used as-is, rather than the client connection rejected. -### `telemetry` Parameters +### `telemetry` parameters - `unauthenticated_metrics_access` `(string: "false")` - If set to true, allows unauthenticated access to the `/v1/sys/metrics` endpoint. !--> -## `unix` Listener Examples +## `unix` listener examples -### Configuring TLS +Refer to the following sections for examples of `unix` listeners. + +### Configure TLS This example shows enabling a TLS listener. @@ -179,7 +183,7 @@ listener "unix" { } ``` -### Listening on Multiple Interfaces +### Listen on multiple interfaces This example shows Boundary listening on a private interface, as well as localhost. diff --git a/website/content/docs/configuration/plugins.mdx b/website/content/docs/configuration/plugins.mdx index c73937506..1c4e5d148 100644 --- a/website/content/docs/configuration/plugins.mdx +++ b/website/content/docs/configuration/plugins.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Plugins - Configuration +page_title: Plugins - configuration description: |- The plugins stanza configures plugin-specific parameters. --- -# `plugin` Stanza +# `plugin` stanza The `plugin` stanza configures plugin-specific parameters. The plugin system was introduced in Boundary 0.7.0 and is currently internal; over time, the intent is diff --git a/website/content/docs/configuration/worker/index.mdx b/website/content/docs/configuration/worker/index.mdx index f3aef922f..55b4d1c17 100644 --- a/website/content/docs/configuration/worker/index.mdx +++ b/website/content/docs/configuration/worker/index.mdx @@ -1,11 +1,12 @@ --- layout: docs -page_title: Worker - Configuration +page_title: Worker - configuration description: |- The worker stanza configures worker-specific parameters. --- # Worker stanza + The `worker` stanza configures Boundary worker-specific parameters. All workers within Boundary use certificates and encryption keys to identify @@ -31,7 +32,7 @@ KMS-based authentication with pre-0.13 controllers, you _must_ set the `use_deprecated_kms_auth_method` value in the worker configuration. See the KMS page for more information. -## Common Worker Parameters +## Common worker parameters Regardless of registration mechanism, the following fields are supported. ```hcl @@ -86,6 +87,7 @@ worker { registration method and for workers directly connected to HCP Boundary. ## Signals + The `SIGHUP` signal causes a worker to reload its configuration file to pick up any updates for the `initial_upstreams` and `tags` values. Any other updated values are ignored. @@ -93,6 +95,7 @@ The `SIGTERM` and `SIGINT` signals initiate a graceful shutdown on a worker. The before shutting down. Workers in a graceful shutdown state do not receive any new work, including session proxying, from the control plane. ## Multi-hop worker capabilities HCP/ENT + Multi-hop capabilities, including multi-hop sessions and Vault private access, is when a session or Vault credential request goes through more than one worker. To enable this, two or more workers must be connected to each other in some @@ -118,25 +121,25 @@ traffic to a [target][]. Ingress worker filters determine which workers you connect with to initiate a session, and egress worker filters determine which workers are used to access targets. -## Multi-hop worker requirements +### Multi-hop worker requirements When you configure multi-hop sessions, there is an "ingress" worker, an "egress" worker, and any number of intermediary workers. Ingress, egress, and intermediary workers have the following requirements. -### Ingress worker requirements +#### Ingress worker requirements To proxy target connections, ingress workers require outbound access to the Boundary control plane and inbound access from clients. -### Intermediary worker requirements +#### Intermediary worker requirements Intermediary workers require outbound access to an upstream worker. The upstream worker may be an ingress worker or another intermediary worker. Intermediary workers also require inbound access from a downstream worker. The downstream worker may be an egress worker or another intermediary worker. -### Egress worker requirements +#### Egress worker requirements To proxy target connections, egress workers require outbound access to an upstream worker and outbound access to the destination host or service. diff --git a/website/content/docs/configuration/worker/kms-worker.mdx b/website/content/docs/configuration/worker/kms-worker.mdx index dd3a5b32c..21a2774b4 100644 --- a/website/content/docs/configuration/worker/kms-worker.mdx +++ b/website/content/docs/configuration/worker/kms-worker.mdx @@ -1,11 +1,10 @@ --- layout: docs -page_title: KMS Worker Configuration +page_title: KMS worker configuration description: |- KMS worker-specific parameters. --- - # KMS worker configuration This page describes configuration for workers that authenticate to upstreams diff --git a/website/content/docs/configuration/worker/pki-worker.mdx b/website/content/docs/configuration/worker/pki-worker.mdx index 9cb475650..e4912f799 100644 --- a/website/content/docs/configuration/worker/pki-worker.mdx +++ b/website/content/docs/configuration/worker/pki-worker.mdx @@ -1,12 +1,12 @@ --- layout: docs -page_title: PKI Worker Configuration +page_title: PKI worker configuration description: |- PKI worker-specific parameters. --- - # PKI worker configuration + PKI Workers authenticate to Boundary using an activation token. They require an accessible directory defined by `auth_storage_path` for credential storage and rotation. @@ -21,9 +21,11 @@ worker { ``` ## Authorization methods + There are two mechanisms that can be used to register a PKI worker to the cluster. ### Controller-led authorization flow + In this flow, the operator fetches an activation token from the controller's `workers:create:controller-led` action (on the CLI, this is via `boundary workers create controller-led`). That activation token is given to the worker @@ -52,6 +54,7 @@ authorize the worker, if the controller-generated activation token is provided and the worker restarted, it will make use of it. ### Worker-led authorization flow + In this flow, the worker prints out an authorization request token to two places: the startup information printed to stdout, and a file called `auth_request_token` in the base of the configured `auth_storage_path`. This @@ -60,6 +63,7 @@ on the CLI this would be via `boundary workers create worker-led -worker-generated-auth-token`. No values are needed in the configuration file. ## KMS configuration + PKI Workers' credentials can be encrypted by including an optional KMS stanza with the purpose `worker-auth-storage`. @@ -74,6 +78,7 @@ kms "aead" { ``` ## Session recording (HCP/ENT) + [Session recording](/boundary/docs/configuration/session-recording) requires at least one PKI worker with access to local and remote storage. PKI workers used for session recording require an accessible directory defined by `recording_storage_path` for storing in-progress session recordings. On session closure, a local session recording is moved to remote storage and diff --git a/website/content/docs/developing/building.mdx b/website/content/docs/developing/building.mdx index 24e8bdac1..9c323fce8 100644 --- a/website/content/docs/developing/building.mdx +++ b/website/content/docs/developing/building.mdx @@ -35,7 +35,7 @@ environment variable to set this. Example: `$ GOOS=linux GOARCH=amd64 make insta For more details, please consult the [Boundary project on GitHub](https://github.com/hashicorp/boundary#build-and-start-boundary-in-dev-mode). -## Troubleshooting +## Troubleshoot UI assets are built inside a Docker container. If this build step fails, try increasing memory and swap available to Docker. diff --git a/website/content/docs/developing/ui.mdx b/website/content/docs/developing/ui.mdx index 4fe220a98..2a92cbeab 100644 --- a/website/content/docs/developing/ui.mdx +++ b/website/content/docs/developing/ui.mdx @@ -9,7 +9,7 @@ description: Develop the Boundary user interface For detailed instructions and the most up-to-date information on developing the Boundary admin UI, please consult [the project README on GitHub](https://github.com/hashicorp/boundary-ui). -## Run a local fork of the UI locally in Dev Mode +## Run a local fork of the UI locally in dev mode If you're developing the Boundary UI locally you can point a dev mode server at a local checkout of the repo without building it into the binary. We call this diff --git a/website/content/docs/enterprise/automated-license-reporting.mdx b/website/content/docs/enterprise/automated-license-reporting.mdx index dad6de9bb..ebef96bdb 100644 --- a/website/content/docs/enterprise/automated-license-reporting.mdx +++ b/website/content/docs/enterprise/automated-license-reporting.mdx @@ -5,7 +5,7 @@ description: >- Learn what data HashiCorp collects to meter Enterprise license utilization. Enable or disable reporting. Review sample payloads and logs. --- -# Automated License utilization reporting +# Automated license utilization reporting Automated license utilization reporting sends license utilization data to HashiCorp without requiring you to manually collect and report them. It also lets you review your license usage with the monitoring solution you already use (for example Splunk, Datadog, or others) so you can optimize and manage your deployments. Use these reports to understand how much more you can deploy under your current contract, protect against overutilization, and budget for predicted consumption. diff --git a/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx b/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx index d818e1bdc..049cada26 100644 --- a/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx +++ b/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx @@ -49,7 +49,7 @@ The dev-mode default target allows you to make as many connections as you want within the authorized session. When you are finished making connections, simply `Ctrl-C/Command-C` the `boundary connect` process to shut down the session. -### Using Connect Helpers +## Use connect helpers Boundary includes connect helpers that automatically accept host SSH key prompts for you. These are written as `boundary connect `. @@ -82,7 +82,7 @@ specify a username other than your currently logged-in user. This ensures that regardless of your `-style` choice, the username is properly passed to the executed client, and you don't need to figure out the syntax yourself. -## Selecting Targets +## Select targets When using `boundary connect` you must identify the target used for connecting. Convention in this documentation is to use the target ID because it refers to a @@ -103,7 +103,7 @@ Here is an SSH example in dev mode: $ boundary connect ssh -target-name "Generated target" -target-scope-name "Generated project scope" ``` -## Built-In vs. Exec +## Built-in vs. exec Boundary comes with built-in wrappers for popular layer 7 connection protocols, such as: @@ -195,7 +195,7 @@ correct available binary (as WSL must use `.exe` when invoking Windows binaries) $ boundary connect ssh -style putty -exec putty.exe -target-id ttcp_1234567890 ``` -## Connect using Desktop Client +## Connect using the desktop client While using the desktop client, choose the target and connect to retrieve local proxy details. @@ -213,7 +213,7 @@ proxy details. /> -## Next Steps +## Next steps See our [basic administration workflows](/boundary/tutorials/oss-administration) diff --git a/website/content/docs/getting-started/dev-mode/dev-mode.mdx b/website/content/docs/getting-started/dev-mode/dev-mode.mdx index 4bcbe6186..809736337 100644 --- a/website/content/docs/getting-started/dev-mode/dev-mode.mdx +++ b/website/content/docs/getting-started/dev-mode/dev-mode.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: What is Dev Mode? -description: Getting started with Boundary OSS in Dev mode +page_title: What is dev mode? +description: Getting started with Boundary OSS in dev mode --- -# What is Dev Mode? +# What is dev mode? Dev mode is a method for getting started with Boundary quickly for testing and learning purposes. As the name implies, dev mode is not a production diff --git a/website/content/docs/getting-started/dev-mode/run-and-login.mdx b/website/content/docs/getting-started/dev-mode/run-and-login.mdx index b823ed87c..80f57c6a5 100644 --- a/website/content/docs/getting-started/dev-mode/run-and-login.mdx +++ b/website/content/docs/getting-started/dev-mode/run-and-login.mdx @@ -2,7 +2,7 @@ layout: docs page_title: Run and log in to Boundary description: |- - How to run Boundary services in dev mode and login for the first time. + How to run Boundary services in dev mode and log in for the first time. --- # Run and log in to Boundary @@ -114,7 +114,7 @@ the Boundary server does not use TLS in development mode. -## Next Steps +## Next steps See [connecting to your first target](/boundary/docs/oss/installing/connect-to-dev-target) for how to use Boundary to diff --git a/website/content/docs/getting-started/index.mdx b/website/content/docs/getting-started/index.mdx index ad302986c..9ca91aee3 100644 --- a/website/content/docs/getting-started/index.mdx +++ b/website/content/docs/getting-started/index.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: Getting Started -description: Getting started with Boundary +page_title: Get started +description: Get started with Boundary --- -# Getting Started +# Get started This section walks through how to get started with Boundary. You’ll learn how Boundary provides secure access to private endpoints. @@ -32,7 +32,7 @@ We recommend you use the Boundary model that best meets your intended use case. If you’re not sure what’s best for you, we recommend reviewing the [Getting started with HCP Boundary](/boundary/docs/getting-started/deploy-and-login) section. -# Key Concepts +## Key concepts Before getting started with Boundary, it's important to understand a few key concepts. Please consult our [Boundary concepts](/boundary/docs/concepts) page to diff --git a/website/content/docs/hcp/get-started/connect-to-target.mdx b/website/content/docs/hcp/get-started/connect-to-target.mdx index 35164aeb4..e0bcf3547 100644 --- a/website/content/docs/hcp/get-started/connect-to-target.mdx +++ b/website/content/docs/hcp/get-started/connect-to-target.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Connect to Target +page_title: Connect to target description: |- Connecting to your first target --- @@ -52,7 +52,7 @@ The dev-mode default target allows you to make as many connections as you want within the authorized session. When you are finished making connections, simply `Ctrl-C/Command-C` the `boundary connect` process to shut down the session. -### Using Connect Helpers +### Use connect helpers Boundary includes connect helpers that automatically accept host SSH key prompts for you. These are written as `boundary connect `. @@ -85,7 +85,7 @@ specify a username other than your currently logged-in user. This ensures that regardless of your `-style` choice, the username is properly passed to the executed client, and you don't need to figure out the syntax yourself. -## Selecting Targets +## Select targets When using `boundary connect` you must identify the target used for connecting. Convention in this documentation is to use the target ID because it refers to a @@ -106,7 +106,7 @@ Here is an SSH example in dev-mode: $ boundary connect ssh -target-name "Generated target" -target-scope-name "Generated project scope" ``` -## Built-In vs. Exec +## Built-in vs. exec Boundary comes with built-in wrappers for popular layer 7 connection protocols, such as: @@ -201,7 +201,7 @@ correct available binary (as WSL must use `.exe` when invoking Windows binaries) $ boundary connect ssh -style putty -exec putty.exe -target-id ttcp_eTcZMueUYv ``` -## Connect using Desktop Client +## Connect using the desktop client While using the desktop client, choose the target and connect to retrieve local proxy details. @@ -223,7 +223,7 @@ proxy details. Refer to the [Connect to your First Target](/boundary/tutorials/hcp-getting-started/hcp-getting-started-connect) tutorial for steps on how to create a host catalog, host set, and a target in Boundary. -## Next Steps +## Next steps Refer to our [basic administration workflows](/boundary/tutorials/hcp-administration) tutorial series diff --git a/website/content/docs/hcp/get-started/deploy-and-login.mdx b/website/content/docs/hcp/get-started/deploy-and-login.mdx index 5115ef54e..ae3f0b148 100644 --- a/website/content/docs/hcp/get-started/deploy-and-login.mdx +++ b/website/content/docs/hcp/get-started/deploy-and-login.mdx @@ -31,7 +31,7 @@ If you prefer to get started on your local machine, refer to [Run and Login in Dev Mode](/boundary/docs/oss/installing/run-and-login). For more information on Boundary OSS and self-managed installations, refer to [Boundary OSS](/boundary/docs/oss). -## Deploy an HCP Boundary Cluster +## Deploy an HCP Boundary cluster To deploy an HCP Boundary instance: @@ -56,7 +56,7 @@ To deploy an HCP Boundary instance: ![Deploy boundary](/img/hcp-deploy-form.png) -## Login to HCP Boundary +## Log in to HCP Boundary Once the deployment is complete, the HCP Boundary instance can be accessed directly from the HCP Boundary portal using the credentials created during @@ -225,7 +225,7 @@ To find your environment’s default `auth_method_id`: Boundary instance. -## Next Steps +## Next steps See [connecting to your first target](/boundary/docs/getting-started/connect-to-target) for how to use HCP Boundary to run your first SSH session. diff --git a/website/content/docs/install-boundary/high-availability.mdx b/website/content/docs/install-boundary/high-availability.mdx index 907333887..15def79d1 100644 --- a/website/content/docs/install-boundary/high-availability.mdx +++ b/website/content/docs/install-boundary/high-availability.mdx @@ -1,15 +1,15 @@ --- layout: docs -page_title: High Availability Installation +page_title: High availability installation description: |- How to install Boundary as a high availability service --- -# High Availability Installation +# High availability installation Installing Boundary as a high availability service requires certain infrastructure considerations. At the most basic level, running 3 controller and 3 worker instances gives a fundamental level of high availability for the control plane (controller), as well as bandwidth for a number of sessions on the data plane (worker). Both server types should be run in a fault-tolerant configuration, that is, in a self-healing environment such as an auto-scaling group. The documentation here does not cover self-healing infrastructure and assumes the operator has their preferred scheduling methods for these environments. -## Network Requirements +## Network requirements The following ports should be available: @@ -31,9 +31,7 @@ The workers must be able to establish a connection to the hosts with which they Boundary requires an external [Postgres](https://www.postgresql.org/) and [KMS](https://aws.amazon.com/kms/). In the example above, we're using AWS managed services for these components. For Postgres, we're using [RDS](https://aws.amazon.com/rds/) and for KMS we're using Amazon's [Key Management Service](https://aws.amazon.com/kms/). -## Architecture Breakdown - -### API and Console Load Balancer +### API and console load balancer Load balancing the controller allows operators to secure the ingress to the Boundary system. We recommend placing all Boundary servers in private networks and using load balancing techniques to expose services such as the API and administrative console to public networks. In the high availability architecture, we recommend load balancing using a layer 7 load balancer and further constraining ingress to that load balancer with layer 4 constraints such as [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) or [IP tables](https://wiki.archlinux.org/index.php/Iptables). @@ -42,7 +40,7 @@ For general configuration, we recommend the following: - HTTPS listener with valid TLS certificate for the domain it's serving or TLS passthrough - Health checks should use TCP port 9200 -### Controller Configuration +### Controller configuration When running Boundary controller as a service we recommend storing the file at `/etc/boundary-controller.hcl`. A `boundary` user and group should exist to manage this configuration file and to further restrict who can read and modify it. diff --git a/website/content/docs/install-boundary/no-gen-resources.mdx b/website/content/docs/install-boundary/no-gen-resources.mdx index 2ea108154..af91fb161 100644 --- a/website/content/docs/install-boundary/no-gen-resources.mdx +++ b/website/content/docs/install-boundary/no-gen-resources.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Running Boundary in Non-Dev Environments +page_title: Running Boundary in non-dev environments description: |- How to install boundary in non-dev environments. --- -# Installing Boundary Without Generated Resources +# Install Boundary without generated resources What are generated resources? When you run `boundary dev` or `boundary database init`, Boundary automatically generates a number of resources to make getting started easier. Default scopes, auth methods, user, account, and @@ -16,7 +16,7 @@ Boundary from scratch isn't straight forward. How do you create your first user deployment that has no authentication methods, users, accounts, etc.? This section describes how to get your freshly deployed Boundary installation off the ground for non-dev environments. -## Recovery KMS Workflow +## Recovery KMS workflow Initializing Boundary without generated resources starts with your Boundary configuration file. Specifically, the controller configuration specifies three KMS blocks: @@ -104,7 +104,7 @@ EOT -## Initialize the Database +## Initialize the database Before you can start Boundary, the database must be initialized. It's useful to look at the help output for the init command: @@ -131,13 +131,13 @@ you use the KMS recovery workflow described above to create at a minimum an auth role with sufficient grants. Otherwise, you need to continue to use the recovery workflow for management. It's important to realize that this is effectively a global super user type of workflow and comes with security concerns. -## Creating Your First Login Account +## Create your first login account This section covers how to configure your first auth method, user, account, and role to login to Boundary without the recovery KMS workflow. In this example, we're going to make an admin user for the global and project level scopes we create. This will allow our user to configure targets within those scopes and manage them. -### Create Org and Project Scopes +### Create org and project scopes In this example, we're going to create an org and project scope and skip creating an administrator and admin role for each scope. We're going to specify a role for managing these scopes by selected users in a later step. @@ -187,7 +187,7 @@ resource "boundary_scope" "project" { -### Create an Auth Method +### Create an auth method Create an auth method in the organization scope. @@ -220,7 +220,7 @@ resource "boundary_auth_method" "password" { -### Create a Login Account +### Create a login account Create a login account for the auth method. @@ -254,7 +254,7 @@ resource "boundary_account" "myuser" { -### Create a User +### Create a user Create a user and associate the user with the login account created in the previous step. This user will also be the principal in the role we create in the following step. @@ -292,7 +292,7 @@ resource "boundary_user" "myuser" { -### Create Roles to Manage Scopes +### Create roles to manage scopes The following describes the four baseline roles you'll need to create to manage resources within the org and project scopes created above. These roles are similar to the roles created for you if generation had not been skipped during `boundary database init` when executed with the `-skip-initial-login-role-creation` flag, Declaring roles explicitly @@ -478,7 +478,7 @@ resource "boundary_role" "project_admin" { -### Login as Your New User +### Log in as your new user ```shell-session boundary authenticate password \ diff --git a/website/content/docs/install-boundary/systemd.mdx b/website/content/docs/install-boundary/systemd.mdx index 17b2e80b1..2cd760c7e 100644 --- a/website/content/docs/install-boundary/systemd.mdx +++ b/website/content/docs/install-boundary/systemd.mdx @@ -1,15 +1,15 @@ --- layout: docs -page_title: Systemd Installation +page_title: systemd Installation description: |- - How to install Boundary under Systemd on Linux + How to install Boundary under systemd on Linux --- -# Installing Boundary under Systemd +# Install Boundary under systemd This section covers how to install Boundary under the [systemd](https://systemd.io/) init system on modern Linux distributions. In this section, we'll cover an example of breaking out the controller and worker servers onto separate instances, though you can opt to run both on a single server. -## Filesystem Configuration +## Filesystem configuration `TYPE` below can be either `worker` or `controller` if you want to run them independently, e.g. for high availability. If you want to run combined nodes, modify as desired. @@ -19,11 +19,11 @@ This section covers how to install Boundary under the [systemd](https://systemd. 3. `/etc/systemd/system/boundary-${TYPE}.service`: Systemd unit file for the Boundary service. -## User & Group Configuration +## User and group configuration We recommend running Boundary as a non-root user and using this user to manage the Boundary process running under systemd. The example init files here do exactly that. Our example install script below creates a user and group on Ubuntu or Debian-like systems. -## Systemd Unit file +## systemd unit file ``` [Unit] @@ -41,7 +41,7 @@ CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK WantedBy=multi-user.target ``` -## Systemd All-in-One Installation Script +## systemd all-in-one installation script Here's a simple install script that creates the `boundary` group and user, installs the systemd unit file, and enables it at startup: diff --git a/website/content/docs/operations/health.mdx b/website/content/docs/operations/health.mdx index 4442ffca3..88291c440 100644 --- a/website/content/docs/operations/health.mdx +++ b/website/content/docs/operations/health.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Boundary Health Endpoints +page_title: Boundary health endpoints description: |- Verify the Boundary controller server is up and able to receive requests --- -# Boundary Health Endpoints +# Boundary health endpoints Boundary provides health monitoring through the `/health` path using a listener with the `"ops"` purpose. By default, a listener with that purpose runs on port @@ -21,7 +21,7 @@ listener must be defined in Boundary's configuration file. Additionally, a file. Under these conditions, the `ops` server (which hosts the controller health api) will be exposed. -## Shutdown Grace Period +## Shutdown grace period Optionally, when the controller health endpoint is enabled, Boundary can be configured to change the controller health response to `503 Service Unavailable` diff --git a/website/content/docs/overview/use-cases.mdx b/website/content/docs/overview/use-cases.mdx index c85a6b925..252f54571 100644 --- a/website/content/docs/overview/use-cases.mdx +++ b/website/content/docs/overview/use-cases.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Use Cases +page_title: Use cases description: A list of Boundary use cases --- diff --git a/website/content/docs/overview/vs/bastion-hosts.mdx b/website/content/docs/overview/vs/bastion-hosts.mdx index 9d71dde83..bd314f684 100644 --- a/website/content/docs/overview/vs/bastion-hosts.mdx +++ b/website/content/docs/overview/vs/bastion-hosts.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: Boundary vs. Bastion Hosts +page_title: Boundary vs. bastion hosts description: Compares Boundary to bastion hosts --- -# Boundary vs. Bastion Hosts +# Boundary vs. bastion hosts If you want to set up your cloud environment securely, you may choose to run all of your important workloads behind a NAT Gateway, and provision a DMZ with a set of hardened bastion servers. diff --git a/website/content/docs/overview/vs/other-software.mdx b/website/content/docs/overview/vs/other-software.mdx index bcf85c65e..f47b69c6c 100644 --- a/website/content/docs/overview/vs/other-software.mdx +++ b/website/content/docs/overview/vs/other-software.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: Boundary vs. Other Software +page_title: Boundary vs. other software description: Compares Boundary to other security technologies --- -# Boundary vs. Other Software +# Boundary vs. other software Boundary is a software solution that provides secure remote access to infrastructure services. It can be difficult to understand how to compare the different remote access security solutions that are available on the market. diff --git a/website/content/docs/overview/vs/pam.mdx b/website/content/docs/overview/vs/pam.mdx index 9e76d3b0e..4d3479747 100644 --- a/website/content/docs/overview/vs/pam.mdx +++ b/website/content/docs/overview/vs/pam.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: Boundary vs. Privileged Access Management -description: Compares Boundary to using a Privileged Access Management (PAM) solution +page_title: Boundary vs. privileged access management +description: Compares Boundary to using a privileged access management (PAM) solution --- -# Boundary vs. Privileged Access Management +# Boundary vs. privileged access management Privileged access management (PAM) tools secure access to critical systems by managing and monitoring access to privileged accounts. PAM assists an organization in reducing their attack surface in an attempt to mitigate damage caused from internal or external incidents. diff --git a/website/content/docs/overview/vs/sdp.mdx b/website/content/docs/overview/vs/sdp.mdx index 70395d6b0..dc1689a73 100644 --- a/website/content/docs/overview/vs/sdp.mdx +++ b/website/content/docs/overview/vs/sdp.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Boundary vs. Software Defined Perimeter -description: Compares Boundary to using a Software Defined Perimeter solution +page_title: Boundary vs. software-defined perimeter +description: Compares Boundary to using a software-defined perimeter solution --- -# Boundary vs. Software Defined Perimeter +# Boundary vs. software-defined perimeter -Software Defined Perimeter (SDP) solutions secure access to applications and infrastructure based on user identity. +Software-defined perimeter (SDP) solutions secure access to applications and infrastructure based on user identity. Boundary is fundamentally an SDP solution that takes a zero trust approach to security design for system access; access to services is granted based on the scoped identity and intent of a user. Boundary is a scalable proxy that enables identity-based access with multiple layers of security controls including [dynamic credentials](/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection), [context-based access](/boundary/tutorials/access-management/oidc-idp-groups), [automated host discovery](/boundary/docs/concepts/host-discovery), and [access auditing](/hcp/docs/boundary/audit-logging) to name a few. \ No newline at end of file diff --git a/website/content/docs/overview/vs/secrets-management.mdx b/website/content/docs/overview/vs/secrets-management.mdx index 39fcb1f98..dbf8f2713 100644 --- a/website/content/docs/overview/vs/secrets-management.mdx +++ b/website/content/docs/overview/vs/secrets-management.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: Boundary vs. Secrets Management Tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) -description: Compares Boundary to using Secrets Management Tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) +page_title: Boundary vs. secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) +description: Compares Boundary to using secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) --- -# Boundary vs. Secrets Management Tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) +# Boundary vs. secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) Secrets management is the use of tools and methods to manage digital authentication credentials. This includes passwords, API keys, PKI, TOTP codes, etc. diff --git a/website/content/docs/overview/vs/vpn.mdx b/website/content/docs/overview/vs/vpn.mdx index 250ab1069..40ea8f06c 100644 --- a/website/content/docs/overview/vs/vpn.mdx +++ b/website/content/docs/overview/vs/vpn.mdx @@ -1,7 +1,7 @@ --- layout: docs page_title: Boundary vs. VPNs -description: Compares Boundary to using a Virtual Private Network (VPN) +description: Compares Boundary to using a virtual private network (VPN) --- # Boundary vs. VPNs diff --git a/website/content/docs/overview/vs/zero-trust.mdx b/website/content/docs/overview/vs/zero-trust.mdx index c78901100..7c8f2aa44 100644 --- a/website/content/docs/overview/vs/zero-trust.mdx +++ b/website/content/docs/overview/vs/zero-trust.mdx @@ -1,10 +1,10 @@ --- layout: docs -page_title: Boundary and Zero Trust -description: Describes how Boundary applies to a Zero Trust security approach +page_title: Boundary and zero trust +description: Describes how Boundary applies to a zero trust security approach --- -# Boundary and Zero Trust +# Boundary and zero trust Malware lands on the machine of an engineer working for an HVAC vendor. Credentials are harvested, and many of them belong to external clients. diff --git a/website/content/docs/overview/what-is-boundary.mdx b/website/content/docs/overview/what-is-boundary.mdx index 6aca2249d..5f7c3f8ce 100644 --- a/website/content/docs/overview/what-is-boundary.mdx +++ b/website/content/docs/overview/what-is-boundary.mdx @@ -16,7 +16,7 @@ With Boundary you can: - Record and manage privileged sessions - Standardize your team's access workflow with a consistent experience for any type of infrastructure across any provider -Get started [here](/boundary/tutorials). +Get started [here](/boundary/tutorials). ## How does Boundary work? @@ -52,7 +52,7 @@ If you're not sure which edition is right for you, we recommend [**HCP Boundary* Regardless of which server edition of Boundary you use, all editions require the same Desktop and CLI clients, which you can download [here](https://developer.hashicorp.com/boundary/downloads). -## Getting Started +## Get started Refer to the [Boundary tutorials](/boundary/tutorials) to learn how to set up, configure, and administer Boundary. diff --git a/website/content/docs/release-notes/index.mdx b/website/content/docs/release-notes/index.mdx index c94504ebb..6e05bfbfe 100644 --- a/website/content/docs/release-notes/index.mdx +++ b/website/content/docs/release-notes/index.mdx @@ -1,13 +1,13 @@ --- layout: docs -page_title: Release Notes +page_title: Release notes description: |- Boundary release notes --- -# Release Notes +# Release notes The side bar to the left has release notes for all major and minor releases of Boundary. -Downloads of Boundary can be found on the [Boundary Release Page](https://github.com/hashicorp/boundary/releases/) +Downloads of Boundary can be found on the [Boundary Release Page](https://github.com/hashicorp/boundary/releases/) and the documentation is available on the [Boundary Changelog Page](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). diff --git a/website/content/docs/release-notes/v0_10_0.mdx b/website/content/docs/release-notes/v0_10_0.mdx index 0aa59cddc..f89a43978 100644 --- a/website/content/docs/release-notes/v0_10_0.mdx +++ b/website/content/docs/release-notes/v0_10_0.mdx @@ -13,7 +13,7 @@ To learn about what Boundary consists of, we highly recommend you start at the [ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.10.0, please review Boundary's [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.10.0 Highlights +## Boundary v0.10.0 highlights **Credential Management of SSH Keys:** Boundary 0.10 includes enhancements to credential management, including added support for management of SSH private keys. @@ -27,10 +27,8 @@ project scope to resources such as group members and principals that reside in o **SSH Credential Injection via Password and Public Key Authentication:** HCP Boundary now supports SSH Credential Injection, an active method of injecting credentials into an established connection, so that credentials are never exposed to users. [Learn more here](/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection). +## What's changed - - -## What's Changed * `ssh` Target Type With Credential Injection (HCP Boundary only): Boundary has gained a new `ssh` target type. Using this type, username/password or SSH private key credentials can be sourced from `vault` credential libraries or diff --git a/website/content/docs/release-notes/v0_11_0.mdx b/website/content/docs/release-notes/v0_11_0.mdx index ba9670531..dab7e1e4f 100644 --- a/website/content/docs/release-notes/v0_11_0.mdx +++ b/website/content/docs/release-notes/v0_11_0.mdx @@ -14,7 +14,7 @@ consists of, we highly recommend you start at the [Getting Started Page](/bounda Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.11.0, please review Boundary's [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.11.0 Highlights +## Boundary v0.11.0 highlights **HCP Boundary General Availability:** Boundary is now available on the HashiCorp Cloud Platform! HCP Boundary provides an easy way to securely access critical systems with fine-grained authorizations based on trusted identities. Boundary on HashiCorp Cloud Platform provides a fully managed, single workflow to securely @@ -33,10 +33,6 @@ IP addresses and release versions of all registered workers through the 'Workers **Support for Generic Credentials:** Boundary now supports brokering of 'generic credentials'. This will enable users to broker any kind of key/value pair type credentials when they are connecting to a remote host. - - - -## What's Changed - +## What's changed **For more detailed information of all changes since 0.10.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md)** \ No newline at end of file diff --git a/website/content/docs/release-notes/v0_1_0.mdx b/website/content/docs/release-notes/v0_1_0.mdx index 107462e69..1f9e7ca35 100644 --- a/website/content/docs/release-notes/v0_1_0.mdx +++ b/website/content/docs/release-notes/v0_1_0.mdx @@ -9,7 +9,7 @@ description: |- v0.1.0 is the first release of Boundary. As a result there are no changes, improvements, or bugfixes from past versions. To learn about what Boundary consists of, we highly recommend you start at the [Getting Started Page](/boundary/docs/getting-started). -## Boundary v0.1.0 Highlights +## Boundary v0.1.0 highlights In this initial release, Boundary provides: diff --git a/website/content/docs/release-notes/v0_2_0.mdx b/website/content/docs/release-notes/v0_2_0.mdx index ac3d963ee..4823ff80a 100644 --- a/website/content/docs/release-notes/v0_2_0.mdx +++ b/website/content/docs/release-notes/v0_2_0.mdx @@ -11,7 +11,7 @@ The release notes below contain information about Boundary v0.2.0 as well as new Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.2.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.2.0 Highlights +## Boundary v0.2.0 highlights **Open ID Connect (OIDC) Authentication**: Boundary 0.2 adds support for OIDC authentication methods, which allow users to delegate authentication to an OIDC provider. This feature enables Boundary to integrate with popular identity providers like Microsoft Azure Active Directory, Okta, @@ -37,7 +37,7 @@ Improvements to list actions:\*\* There have been numerous improvements to listi **Database migrations (0.1.5):** Boundary provides an [easy upgrade path](/boundary/tutorials/oss-configuration/upgrade-version) with fail-safes in the event of migration issues. This includes support for database upgrades in a single transaction. -## What's Changed +## What's changed - **Authentication:** 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). diff --git a/website/content/docs/release-notes/v0_3_0.mdx b/website/content/docs/release-notes/v0_3_0.mdx index 20b6e087a..5d1c1cbd8 100644 --- a/website/content/docs/release-notes/v0_3_0.mdx +++ b/website/content/docs/release-notes/v0_3_0.mdx @@ -11,7 +11,7 @@ The release notes below contain information about Boundary v0.3.0, Boundary Desk Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.3.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.3.0 Highlights +## Boundary v0.3.0 highlights **Boundary Desktop for Windows:** [Boundary Desktop v1.1.0](https://releases.hashicorp.com/boundary-desktop/) gives users the ability to connect to remote targets and view active session details. Boundary Desktop is now available for both Windows and MacOS. @@ -19,6 +19,6 @@ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0 **OIDC configuration improvements:** Administrators can now configure Boundary authentication from OIDC identity providers in the Boundary admin console and Boundary's Terraform Provider. -## What's Changed +## What's changed For detailed information of all changes since 0.2.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/release-notes/v0_4_0.mdx b/website/content/docs/release-notes/v0_4_0.mdx index 589f2d547..e63a1e7a9 100644 --- a/website/content/docs/release-notes/v0_4_0.mdx +++ b/website/content/docs/release-notes/v0_4_0.mdx @@ -11,7 +11,7 @@ The release notes below contain information about new functionality available in Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.4.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.4.0 Highlights +## Boundary v0.4.0 highlights **Session Credential Brokering:** Boundary 0.4, adds a Vault integration for the brokering of [Vault](https://www.vaultproject.io/) secrets to Boundary clients (both command line and desktop clients) for use in Boundary sessions. Brokering of Vault secrets is the foundation of Boundary’s larger credential-management story for seamless single sign-on to infrastructure targets. This feature introduces new Boundary resources - [credential stores](/boundary/docs/concepts/domain-model/credential-stores), [credential libraries](/boundary/docs/concepts/domain-model/credential-libraries), and [credentials](/boundary/docs/concepts/domain-model/credentials) - @@ -21,6 +21,6 @@ to support binding credentials with user sessions, as well as surfacing those cr **Session Security Improvements:** Boundary workers will now close any existing proxy connections they're handling when they cannot make a status request to the worker. The timeout for this behavior is currenly 15 seconds. -## What's Changed +## What's changed For more detailed information of all changes since 0.3.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/release-notes/v0_5_0.mdx b/website/content/docs/release-notes/v0_5_0.mdx index 788c1e26c..349a9c12a 100644 --- a/website/content/docs/release-notes/v0_5_0.mdx +++ b/website/content/docs/release-notes/v0_5_0.mdx @@ -13,7 +13,7 @@ To learn about what Boundary consists of, we highly recommend you start at the [ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.5.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.5.0 Highlights +## Boundary v0.5.0 highlights **Event Logging:** 0.5.0 includes significant improvements to Boundary's event logging system with goal of giving operators greater visibility into system information in a well-defined, structured format. When enabled, event logs are the only type of logging Boundary performs, meaning standard system information and debug logs will no longer appear in stdout. @@ -24,6 +24,6 @@ For more about event logging usage, see our [documentation](/boundary/docs/confi **Credential CRUD operations for Administrative Console:** The 0.5.0 release enables administration to configure Vault credential libraries and Vault credential set resources through the administrative console. Vault credential resources allows users to create Boundary sessions with credentials brokered by a Vault deployment. -## What's Changed +## What's changed For more detailed information of all changes since 0.4.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/release-notes/v0_6_0.mdx b/website/content/docs/release-notes/v0_6_0.mdx index 57879ef5f..1a90b38d7 100644 --- a/website/content/docs/release-notes/v0_6_0.mdx +++ b/website/content/docs/release-notes/v0_6_0.mdx @@ -13,7 +13,7 @@ To learn about what Boundary consists of, we highly recommend you start at the [ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.6.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.6.0 Highlights +## Boundary v0.6.0 highlights **Permissions-based UI:** Boundary 0.6.0 dynamically tailors the administrator console to individual users’ permissions, ensuring users are presented only with actions and workflows that can succeed. @@ -21,6 +21,6 @@ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0 **Managed group configurations via Terraform:** Managed groups can now be configured via Terraform using v1.0.5 of [Boundary's Terraform Provider](https://registry.terraform.io/providers/hashicorp/boundary/latest) -## What's Changed +## What's changed For more detailed information of all changes since 0.5.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/release-notes/v0_7_0.mdx b/website/content/docs/release-notes/v0_7_0.mdx index a1c8c23ca..8df79dd7b 100644 --- a/website/content/docs/release-notes/v0_7_0.mdx +++ b/website/content/docs/release-notes/v0_7_0.mdx @@ -13,7 +13,7 @@ To learn about what Boundary consists of, we highly recommend you start at the [ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.7.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.7.0 Highlights +## Boundary v0.7.0 highlights **Dynamic Host Catalogs:** Boundary introduces a new resource type, dynamic host catalogs, which automate the discovery of host resources from a catalog provider. The 0.7 release includes initial support for Azure and AWS host catalogs with more catalog providers to follow in future releases. Catalogs are implemented via Boundary's (currently internal) new go-plugin system. @@ -23,6 +23,6 @@ Configuration of managed groups is now available in the Boundary admin console. **UI Support for Resource Filtering:** Users may now filter auth method and session resources in the admin console and Boundary Desktop. -## What's Changed +## What's changed For more detailed information of all changes since 0.6.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/release-notes/v0_8_0.mdx b/website/content/docs/release-notes/v0_8_0.mdx index 62cd147ef..82b45e715 100644 --- a/website/content/docs/release-notes/v0_8_0.mdx +++ b/website/content/docs/release-notes/v0_8_0.mdx @@ -13,7 +13,7 @@ To learn about what Boundary consists of, we highly recommend you start at the [ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.8.0, please review Boundary’s [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.8.0 Highlights +## Boundary v0.8.0 highlights **Metrics and Health Endpoint:** Boundary is adding [Prometheus metrics](/boundary/docs/oss/operations/metrics) to monitor the operations of workers and controllers, as well as a [health endpoint](/boundary/docs/oss/operations/health) for controllers. @@ -27,6 +27,6 @@ with support for sanitizing sensitive information from audit events. All of the and improving response times listing sessions and targets. We plan to continue these efforts as Boundary users grow their deployments! -## What's Changed +## What's changed For more detailed information of all changes since 0.7.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/release-notes/v0_9_0.mdx b/website/content/docs/release-notes/v0_9_0.mdx index 545f4e975..4c72af145 100644 --- a/website/content/docs/release-notes/v0_9_0.mdx +++ b/website/content/docs/release-notes/v0_9_0.mdx @@ -13,7 +13,7 @@ To learn about what Boundary consists of, we highly recommend you start at the [ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0.9.0, please review Boundary's [general upgrade guide](/boundary/tutorials/oss-configuration/upgrade-version). -## Boundary v0.9.0 Highlights +## Boundary v0.9.0 highlights **HCP Boundary Public Beta:** Boundary is coming to the HashiCorp Cloud Platform! HCP Boundary provides an easy way to securely access critical systems with fine-grained authorizations based on trusted identities. Boundary on HashiCorp Cloud Platform provides a fully managed, @@ -36,6 +36,6 @@ wish to use the Desktop Client for credential brokering, version 1.4.4 and up is **Admin UI Quickstart:** Users can now access a quickstart tool on the Admin UI which sets up a target along with a host, project, and organization. -## What's Changed +## What's changed For more detailed information of all changes since 0.8.0, please refer to the [Changelog](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md) diff --git a/website/content/docs/troubleshoot/common-errors.mdx b/website/content/docs/troubleshoot/common-errors.mdx index 975009962..90a489559 100644 --- a/website/content/docs/troubleshoot/common-errors.mdx +++ b/website/content/docs/troubleshoot/common-errors.mdx @@ -1,16 +1,17 @@ --- layout: docs -page_title: Common Error Messages +page_title: Common error messages description: |- Common error messages for Boundary --- -# Common Error Messages -When installing and running Boundary, there are some common messages you might see. Usually they indicate an issue in your network or in your IAM -configuration. Some of the more common errors and their solutions are listed below. If you think you have found a bug, please report the issue on +# Common error messages + +When installing and running Boundary, there are some common messages you might see. Usually they indicate an issue in your network or in your IAM +configuration. Some of the more common errors and their solutions are listed below. If you think you have found a bug, please report the issue on [github](https://github.com/hashicorp/boundary/issues/new/choose). -#### Cannot connect to target: error from controller when performing authorize-session action against given target +## Cannot connect to target: error from controller when performing authorize-session action against given target ``` $ boundary targets authorize-session @@ -23,12 +24,12 @@ Error information: context: Error from controller when performing authorize-session action against given target ``` -This error message indicates the user does not have permission to access the requested target. Ensure the right IAM policies are configured for the -user attempting to create a session. Users need to belong to a role in the target's scope with an authorize-session grant to access the target. -[Resource table](/boundary/docs/concepts/security/permissions/resource-table) page is a great reference for how to configure +This error message indicates the user does not have permission to access the requested target. Ensure the right IAM policies are configured for the +user attempting to create a session. Users need to belong to a role in the target's scope with an authorize-session grant to access the target. +[Resource table](/boundary/docs/concepts/security/permissions/resource-table) page is a great reference for how to configure the right permission grants for Boundary roles. -#### Error from controller when performing authorize-session action against given target +## Error from controller when performing authorize-session action against given target ``` $ boundary connect -target-id $TARGET_ID @@ -55,10 +56,10 @@ This error message indicates the worker is unable to proxy connections to the ta - The target is accessible by the Worker. The same error message is thrown if the target IP is either misconfigured or inaccessible by the worker **Worker tag and filter misconfiguration:** If your target is using a worker filter -- Ensure the worker filter selects the intended worker(s) to proxy connections to the target. +- Ensure the worker filter selects the intended worker(s) to proxy connections to the target. - Ensure your intended worker(s) have the intended tags to match your target's filter -#### Error from controller when performing authorize-session action against given target: unsupported credential *vault.baseCred +## Error from controller when performing authorize-session action against given target: unsupported credential *vault.baseCred ``` $ boundary connect ssh -target-id tssh_dmcFiVIakM @@ -71,9 +72,6 @@ Error information: Status: 500 context: Error from controller when performing authorize-session action against given target ``` -You may experience this error when attempting credential injection via Vault. Currently username_password and ssh_private_key credential -types are supported for credential injection, but only username_password can be set up using the Web UI. If you experience this error, +You may experience this error when attempting credential injection via Vault. Currently username_password and ssh_private_key credential +types are supported for credential injection, but only username_password can be set up using the Web UI. If you experience this error, attempt to create the Vault ssh_private_key credential library using the CLI instead of the UI. - - - diff --git a/website/content/docs/troubleshoot/faq.mdx b/website/content/docs/troubleshoot/faq.mdx index 33f053a4a..b9b8e1b4f 100644 --- a/website/content/docs/troubleshoot/faq.mdx +++ b/website/content/docs/troubleshoot/faq.mdx @@ -5,14 +5,19 @@ description: |- FAQ for Boundary --- -# Frequently Asked Questions -#### Q: What are the networking requirements for Boundary? Do my workers need to be exposed to the public internet? +# Frequently asked questions + +Refer to the following for answers to frequently asked questions about Boundary. + +## Q: What are the networking requirements for Boundary? Do my workers need to be exposed to the public internet? + Boundary workers require inbound access from clients. This does not necessarily require that workers be exposed to the public internet. If the client is coming from a private network (eg a corporate network), the worker needs to allow connectivity from the private network. If the client is coming from the public internet, the worker needs to allow connectivity from the public internet. For more information, check out the [worker networking requirements](/hcp/docs/boundary/self-managed-workers). -#### Q: Does Boundary require Vault? What is the integration story? +## Q: Does Boundary require Vault? What is the integration story? + While Vault isn't a *required* secrets backend for Boundary sessions, the potential for Boundary | Vault integration is a core part of Boundary's overall value proposition for identity-based access.There are three primary points of integration with Vault: 1. Vault can be used as a secrets backend for Boundary, offering single signon to end target systems via credential brokering. This was covered in Boundary's @@ -23,18 +28,21 @@ This scenario is walked through in this [tutorial](/vault/tutorials/auth-methods 3. OSS Boundary can use Vault as the external KMS that serves as Boundary's root of trust. More information on this use case can be found [here](/boundary/docs/configuration/kms/transit). -#### Q: What Identity Providers does Boundary Support? +## Q: What identity providers does Boundary support? + Boundary supports [OIDC authentication](/boundary/tutorials/access-management/oidc-auth), which allows support for many popular IdPs like Okta, Azure AD, Auth0, etc. For non-OIDC authentication protocols (such as LDAP), users can also log in with an OIDC bridge identity provider such as [Vault's OIDC bridge](/vault/docs/concepts/oidc-provider) capabilities released in 1.9, [Dex](https://dexidp.io), or various others. -#### Q: Does Boundary support Multi-factor Authentication (MFA)? +## Q: Does Boundary support multi-factor authentication (MFA)? + Boundary Open-ID Connect (OIDC)-based authentication supports MFA if the IdP being used enforces MFA. This allows users to authenticate with an identity provider supporting MFA, such as Azure AD, Okta, Auth0, etc. Boundary also supports syncing permission claims between an IDP-managed identity and Boundary. This can be very useful when you want to sync group memberships from an IDP to Boundary to assign role assignments dynamically. See Boundary's [managed groups capabilities](/boundary/tutorials/configuration/oidc-idp-groups). -#### Q: Does Boundary automate the discovery and configuration of new targets (e.g. servers)? What happens if a host IP address changes? +## Q: Does Boundary automate the discovery and configuration of new targets (e.g. servers)? What happens if a host IP address changes? + Yes, this is one of the core competencies of Boundary. Boundary can discover new targets in two primary ways 1. Boundary's [Terraform provider](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs) supports discovery of targets provisioned by Terraform 2. Boundary's [dynamic host catalog](/boundary/tutorials/access-management/aws-host-catalogs) @@ -46,7 +54,8 @@ For more information on dynamic host catalogs, please see: - [Dynamic Host Catalog on AWS](/boundary/tutorials/access-management/aws-host-catalogs) - [Dynamic Host Catalogs on Azure](/boundary/tutorials/access-management/azure-host-catalogs) -#### Q: Session management capabilities - Does Boundary support live session monitoring and termination? +## Q: Session management capabilities - Does Boundary support live session monitoring and termination? + **Session Logging/Monitoring:** Supported. Boundary creates a session log of all sessions created between identities and targets that have been onboarded to Boundary. You can learn how to monitor these sessions in this [tutorial](/boundary/tutorials/getting-started/getting-started-connect#manage-sessions). Boundary supports audit logs for [Boundary OSS](/boundary/tutorials/oss-configuration/event-logging) and [audit log streaming](/hcp/docs/boundary/audit-logging) @@ -55,7 +64,8 @@ for HCP Boundary. Audit logs for both distributions can be exported to SIEM or B **Session Termination:** Supported. Session termination for Boundary administrators is a supported capability, as demonstrated in this [tutorial](/boundary/tutorials/getting-started/getting-started-connect#manage-sessions). -#### Q: As an AWS user, can IAM roles be used to configure Boundary's dynamic host catalog? +## Q: As an AWS user, can IAM roles be used to configure Boundary's dynamic host catalog? + At this time, it is not possible to configure Boundary's dynamic host catalog using IAM roles. You can configure the dynamic host catalog using an IAM user, however. For more information, refer to the [Dynamic host catalogs on AWS](/boundary/tutorials/access-management/aws-host-catalogs) tutorial. diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index 111275402..0897765e8 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -7,22 +7,22 @@ "path": "overview/what-is-boundary" }, { - "title": "Use Cases", + "title": "Use cases", "path": "overview/use-cases" }, { - "title": "Boundary vs. Other Software", + "title": "Boundary vs. other software", "routes": [ { "title": "Overview", "path": "overview/vs/other-software" }, { - "title": "Zero Trust", + "title": "Zero trust", "path": "overview/vs/zero-trust" }, { - "title": "Bastion Hosts", + "title": "Bastion hosts", "path": "overview/vs/bastion-hosts" }, { @@ -30,15 +30,15 @@ "path": "overview/vs/vpn" }, { - "title": "Privileged Access Management", + "title": "Privileged access management", "path": "overview/vs/pam" }, { - "title": "Software Defined Perimeter", + "title": "Software-defined perimeter", "path": "overview/vs/sdp" }, { - "title": "Secrets Management Tools", + "title": "Secrets management tools", "path": "overview/vs/secrets-management" } ] @@ -53,15 +53,15 @@ "path": "getting-started" }, { - "title": "Self-Managed Boundary Quick Start", + "title": "Self-managed Boundary quick start", "href": "https://developer.hashicorp.com/boundary/tutorials/oss-getting-started/" }, { - "title": "HCP Boundary Quick Start", + "title": "HCP Boundary quick start", "href": "https://developer.hashicorp.com/boundary/tutorials/hcp-getting-started/" }, { - "title": "Dev Mode Quick Start", + "title": "Dev mode quick start", "routes": [ { "title": "Overview", @@ -87,15 +87,15 @@ "path": "install-boundary" }, { - "title": "Recommended Architecture", + "title": "Recommended architecture", "path": "install-boundary/recommended-architecture" }, { - "title": "System Requirements", + "title": "System requirements", "path": "install-boundary/system-requirements" }, { - "title": "Fault Tolerance Recommendations", + "title": "Fault tolerance recommendations", "path": "install-boundary/fault-tolerance" }, { @@ -103,24 +103,24 @@ "path": "install-boundary/install" }, { - "title": "Configure Controllers", + "title": "Configure controllers", "path": "install-boundary/configure-controllers" }, { - "title": "Configure Workers", + "title": "Configure workers", "path": "install-boundary/configure-workers" }, { - "title": "Non-Dev Environments", + "title": "Non-dev environments", "path": "install-boundary/no-gen-resources" }, { - "title": "Systemd Install", + "title": "Systemd install", "hidden": true, "path": "install-boundary/systemd" }, { - "title": "Configure High Availability", + "title": "Configure high availability", "path": "install-boundary/high-availability" } ] @@ -133,15 +133,15 @@ "path": "concepts" }, { - "title": "Identity and Access Management", + "title": "Identity and access management", "path": "concepts/iam" }, { - "title": "Host Discovery", + "title": "Host discovery", "path": "concepts/host-discovery" }, { - "title": "Credential Management", + "title": "Credential management", "path": "concepts/credential-management" }, { @@ -163,21 +163,21 @@ "path": "concepts/security/permissions" }, { - "title": "Assignable Permissions", + "title": "Assignable permissions", "path": "concepts/security/permissions/assignable-permissions" }, { - "title": "Permission Grant Formats", + "title": "Permission grant formats", "path": "concepts/security/permissions/permission-grant-formats" }, { - "title": "Resource Table", + "title": "Resource table", "path": "concepts/security/permissions/resource-table" } ] }, { - "title": "Data Encryption", + "title": "Data encryption", "path": "concepts/security/data-encryption" }, { @@ -187,7 +187,7 @@ ] }, { - "title": "Domain Model", + "title": "Domain model", "routes": [ { "title": "Overview", @@ -198,7 +198,7 @@ "path": "concepts/domain-model/accounts" }, { - "title": "Auth Methods", + "title": "Auth methods", "path": "concepts/domain-model/auth-methods" }, { @@ -206,11 +206,11 @@ "path": "concepts/domain-model/credentials" }, { - "title": "Credential Libraries", + "title": "Credential libraries", "path": "concepts/domain-model/credential-libraries" }, { - "title": "Credential Stores", + "title": "Credential stores", "path": "concepts/domain-model/credential-stores" }, { @@ -222,15 +222,15 @@ "path": "concepts/domain-model/hosts" }, { - "title": "Host Catalogs", + "title": "Host catalogs", "path": "concepts/domain-model/host-catalogs" }, { - "title": "Host Sets", + "title": "Host sets", "path": "concepts/domain-model/host-sets" }, { - "title": "Managed Groups", + "title": "Managed groups", "path": "concepts/domain-model/managed-groups" }, { @@ -242,15 +242,15 @@ "path": "concepts/domain-model/sessions" }, { - "title": "Session Connections", + "title": "Session connections", "path": "concepts/domain-model/session-connections" }, { - "title": "Session Recordings", + "title": "Session recordings", "path": "concepts/domain-model/session-recordings" }, { - "title": "Storage Buckets", + "title": "Storage buckets", "path": "concepts/domain-model/storage-buckets" }, { @@ -275,15 +275,15 @@ "path": "concepts/filtering" }, { - "title": "OIDC Managed Groups", + "title": "OIDC managed groups", "path": "concepts/filtering/oidc-managed-groups" }, { - "title": "Resource Listing", + "title": "Resource listing", "path": "concepts/filtering/resource-listing" }, { - "title": "Worker Tags", + "title": "Worker tags", "path": "concepts/filtering/worker-tags" }, { @@ -298,7 +298,7 @@ "title": "Configuration", "routes": [ { - "title": "Overview/Top-Level Parameters", + "title": "Overview/top-level parameters", "path": "configuration" }, { @@ -309,11 +309,11 @@ "path": "configuration/worker" }, { - "title": "PKI Workers", + "title": "PKI workers", "path": "configuration/worker/pki-worker" }, { - "title": "KMS Workers", + "title": "KMS workers", "path": "configuration/worker/kms-worker" } ] @@ -367,24 +367,24 @@ "path": "configuration/kms/ocikms" }, { - "title": "Vault Transit", + "title": "Vault transit", "path": "configuration/kms/transit" } ] }, { - "title": "Session Recordings", + "title": "Session recordings", "routes": [ { "title": "Overview", "path": "configuration/session-recording" }, { - "title": "Create Storage Buckets", + "title": "Create storage buckets", "path": "configuration/session-recording/create-storage-bucket" }, { - "title": "Enable Session Recording", + "title": "Enable session recording", "path": "configuration/session-recording/enable-session-recording" } ] @@ -397,15 +397,15 @@ "path": "configuration/events" }, { - "title": "Common Sink Parameters", + "title": "Common sink parameters", "path": "configuration/events/common" }, { - "title": "File Sink", + "title": "File sink", "path": "configuration/events/file" }, { - "title": "Stderr Sink", + "title": "Stderr sink", "path": "configuration/events/stderr" } ] @@ -432,11 +432,11 @@ "path": "operations/metrics" }, { - "title": "Health Endpoint", + "title": "Health endpoint", "path": "operations/health" }, { - "title": "Session Recordings", + "title": "Session recordings", "path": "operations/manage-recorded-sessions" } ] @@ -445,7 +445,7 @@ "title": "Troubleshoot", "routes": [ { - "title": "Common Error Messages", + "title": "Common error messages", "path": "troubleshoot/common-errors" }, { @@ -453,13 +453,13 @@ "path": "troubleshoot/faq" }, { - "title": "Recorded Sessions", + "title": "Recorded sessions", "path": "troubleshoot/troubleshoot-recorded-sessions" } ] }, { - "title": "Common Workflows", + "title": "Common workflows", "hidden": true, "routes": [ { @@ -467,33 +467,33 @@ "path": "common-workflows" }, { - "title": "Manage Roles", + "title": "Manage roles", "path": "common-workflows/manage-roles" }, { - "title": "Manage Scopes", + "title": "Manage scopes", "path": "common-workflows/manage-scopes" }, { - "title": "Manage Sessions", + "title": "Manage sessions", "path": "common-workflows/manage-sessions" }, { - "title": "Manage Targets", + "title": "Manage targets", "path": "common-workflows/manage-targets" }, { - "title": "Manage Users and Groups", + "title": "Manage users and groups", "path": "common-workflows/manage-users-groups" }, { - "title": "Workflow SSH Proxy", + "title": "Workflow SSH proxy", "path": "common-workflows/workflow-ssh-proxycommand" } ] }, { - "title": "API/Clients", + "title": "API/clients", "routes": [ { "title": "Overview", @@ -593,11 +593,11 @@ "path": "enterprise/licensing" }, { - "title": "Automated License Reporting", + "title": "Automated license reporting", "path": "enterprise/automated-license-reporting" }, { - "title": "Supported Versions Policy", + "title": "Supported versions policy", "path": "enterprise/supported-versions" } ] @@ -606,7 +606,7 @@ "divider": true }, { - "title": "Release Notes", + "title": "Release notes", "routes": [ { "title": "Overview",