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
2023-07-07 14:42:11 -04:00
1 parent 96d2531fbb
commit 3f4cd53d16
@@ -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.

@@ -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 <command> <subcommand> [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
@@ -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:
@@ -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
@@ -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 <sup>Beta</sup>
+### LDAP account attributes <sup>Beta</sup>

 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:

@@ -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 <sup>Beta</sup>
+### LDAP auth method attributes <sup>Beta</sup>

 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:

@@ -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
 ---
@@ -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`.

@@ -1,6 +1,6 @@
 ---
 layout: docs
-page_title: Domain Model - Credentials
+page_title: Domain model - credentials
 description: |-
  The anatomy of a Boundary credential
 ---
@@ -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:

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

@@ -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:<globbed name>` 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:

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

@@ -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][].
@@ -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 <sup>Beta</sup>
+### LDAP managed group information and attributes <sup>Beta</sup>

 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:

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

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

@@ -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][]

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

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

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

@@ -1,6 +1,6 @@
 ---
 layout: docs
-page_title: Domain Model - Targets
+page_title: Domain model - targets
 description: |-
  The anatomy of a Boundary target
 ---
@@ -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:

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

@@ -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.
 ( <Expression 1> and (not <Expression 2> )) or <Expression 3>
 ```

-### Performance
+## Performance

 Filters are executed on the controllers and therefore will consume some amount
 of CPU time on the controller.
@@ -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
@@ -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.
@@ -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`<sup>HCP/ENT</sup> attribute controls which workers a
 This is the worker a client connects to when initiating a connection to a target.


-# Vault worker filtering <sup>HCP/ENT</sup>
+## Vault workers <sup>HCP/ENT</sup>
 Tags are used to control which [PKI workers] can manage Vault requests by specifying
 a `worker_filter`attribute when configuring [credential stores].

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

@@ -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
@@ -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
@@ -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 <sup>OSS Only</sup>
+## The `root` KMS key and per-scope KEK/DEKs <sup>OSS only</sup>

 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 <sup>OSS Only</sup>
+## The `previous-root` KMS key <sup>OSS only</sup>

 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 <sup>OSS Only</sup>
+## The `worker-auth` KMS key <sup>OSS only</sup>

 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 <sup>OSS Only</sup>
+## The `recovery` KMS key <sup>OSS only</sup>

 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 <sup>OSS Only</sup>
+## The `config` KMS key <sup>OSS only</sup>

 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
@@ -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.
@@ -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
@@ -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:
@@ -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
@@ -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
@@ -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.
@@ -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)

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

@@ -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)

@@ -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
@@ -1,6 +1,6 @@
 ---
 layout: docs
-page_title: AEAD - Configuration
+page_title: AEAD - configuration
 description: |-
  The AEAD KMS configures AEAD-specific parameters.
 ---
@@ -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:

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

@@ -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 &amp; Permissions
+## Authentication &amp; permissions

 Authentication-related values must be provided, either as environment
 variables or as configuration parameters.
@@ -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.

@@ -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 <dynamic-group-name> 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.

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

@@ -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)
-
-
@@ -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.

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

@@ -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
@@ -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 <sup>HCP/ENT</sup>
+
 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.
@@ -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
@@ -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 <sup>(HCP/ENT)</sup>
+
 [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
@@ -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.
@@ -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
@@ -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.

@@ -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 <subcommand>`.
@@ -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.
  />
 </video>

-## Next Steps
+## Next steps

 See our [basic administration
 workflows](/boundary/tutorials/oss-administration)
@@ -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
@@ -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.
 </Tabs>


-## Next Steps
+## Next steps

 See [connecting to your first
 target](/boundary/docs/oss/installing/connect-to-dev-target) for how to use Boundary to
@@ -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
@@ -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 <subcommand>`.
@@ -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
@@ -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.
@@ -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.

@@ -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
 </Tabs>


-## 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" {
 </Tabs>


-### 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" {
 </Tabs>


-### Create a Login Account
+### Create a login account

 Create a login account for the auth method.

@@ -254,7 +254,7 @@ resource "boundary_account" "myuser" {
 </Tabs>


-### 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" {
 </Tabs>


-### 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" {
 </Tabs>


-### Login as Your New User
+### Log in as your new user

 ```shell-session
 boundary authenticate password \
@@ -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:
@@ -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`
@@ -1,6 +1,6 @@
 ---
 layout: docs
-page_title: Use Cases
+page_title: Use cases
 description: A list of Boundary use cases
 ---

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

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

@@ -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).
@@ -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
@@ -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)**
@@ -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:

@@ -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).
@@ -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)
@@ -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)
@@ -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)
@@ -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)
@@ -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)
@@ -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)
@@ -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)
@@ -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.
-
-
-
@@ -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.
@@ -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",