diff --git a/CHANGELOG.md b/CHANGELOG.md index 911a59053..3241fa99e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,8 +7,8 @@ Canonical reference for changes, improvements, and bugfixes for Boundary. ### New and Improved * cli: Added `boundary connect mysql` command for connecting to MySQL targets. - This new helper command allows users to authorize sessions against MySQL - targets and automatically invoke a MySQL client with the appropriate + This new helper command allows users to authorize sessions against MySQL + targets and automatically invoke a MySQL client with the appropriate connection parameters and credentials. * Adds support to parse User-Agent headers and emit them in telemetry events ([PR](https://github.com/hashicorp/boundary/pull/5645)). @@ -20,7 +20,7 @@ Canonical reference for changes, improvements, and bugfixes for Boundary. ### Deprecations/Changes * Modified parsing logic for various IP/host/address fields across Boundary. - Notably, for some fields, Boundary previously required bracket-enclosed + Notably, for some fields, Boundary previously required bracket-enclosed IPv6 addresses (eg: `[::1]`). With this change, if the provided address is just an IPv6 literal, enclosing the address in brackets is not valid. Additionally, an input address containing an IPv6 literal may be modified by @@ -998,7 +998,7 @@ open-source release of 0.12.3; the same fixes will be in 0.13.0 OSS. Encryption Keys (KEKs) and Data Encryption Keys (DEKs) using the new key rotation and key version destruction functionality. To learn more about this new feature, refer to the - [documentation](https://developer.hashicorp.com/boundary/docs/concepts/security/data-encryption). + [documentation](https://developer.hashicorp.com/boundary/docs/secure/encryption/data-encryption). Upgrade notice: If the Database purpose DEK for a scope is destroyed, you must use the API to cancel any sessions that predate the upgrade. @@ -1408,7 +1408,7 @@ open-source release of 0.12.3; the same fixes will be in 0.13.0 OSS. anonymous user; currently these are the same permissions as assigned in Boundary's default role permissions. If other use-cases arise this list can be expanded. See [the - documentation](https://www.boundaryproject.io/docs/concepts/security/permissions/assignable-permissions) + documentation](https://www.developer.hashicorp.com/boundary/docs/rbac/assignable-permissions) for more details. ## 0.8.1 (2022/05/13) @@ -1567,7 +1567,7 @@ isolate transactions and prevent resource contention that caused deadlocks. * Boundary now supports dynamic discovery of host resources using our (currently internal) new plugin system. See the - [documentation](https://www.boundaryproject.io/docs) for configuration + [documentation](https://www.developer.hashicorp.com/boundary/docs) for configuration instructions. Currently, only Azure and AWS are supported, but more providers will be following in future releases. * workers: The existing worker connection replay prevention logic has been @@ -1696,7 +1696,7 @@ isolate transactions and prevent resource contention that caused deadlocks. * OIDC Accounts: When performing a `read` on an `oidc` type account, the original token and userinfo claims are provided in the output. This can make it significantly easier to write filters to create [managed - groups](https://www.boundaryproject.io/docs/concepts/filtering/oidc-managed-groups). + groups](https://www.developer.hashicorp.com/boundary/docs/rbac/users/managed-groups). ([PR](https://github.com/hashicorp/boundary/pull/1419)) * Controllers will now mark connections as closed in the database if the worker has not reported its status; this can be seen as the controller counterpart to @@ -1724,7 +1724,7 @@ isolate transactions and prevent resource contention that caused deadlocks. Boundary. * Filtering events: hclog log levels have been replaced by optional sets of allow and deny event - [filters](https://www.boundaryproject.io/docs/concepts/filtering) which are + [filters](https://www.developer.hashicorp.com/boundary/docs/filtering) which are specified via configuration, or in the case of "boundary dev" there are new new cmd flags. * Observation events are MVP and contain a minimal set of observations about a @@ -1937,7 +1937,7 @@ Boundary) but it's worth repeating. users this defaults to all fields; for `u_anon` this defaults to the fields useful for navigating to and authenticating to the system. In either case, this is overridable. See the [permissions - documentation](https://www.boundaryproject.io/docs/concepts/security/permissions) + documentation](https://www.developer.hashicorp.com/boundary/docs/rbac) for more information on why and when to use this. This currently only applies to top-level fields in the response. * cli/api/sdk: Add support to request additional OIDC claims scope values from @@ -2123,7 +2123,7 @@ to call out in this changelog. The full set of open issues is on GitHub. * list filtering: Listing now supports filtering results before being returned to the user. The filtering takes place server side and uses boolean expressions against the JSON representation of returned items. See [the - documentation](https://www.boundaryproject.io/docs/concepts/filtering/resource-listing) + documentation](https://www.developer.hashicorp.com/boundary/docs/filtering) for more details. ([PR 1](https://github.com/hashicorp/boundary/pull/952)) ([PR 2](https://github.com/hashicorp/boundary/pull/957)) ([PR 3](https://github.com/hashicorp/boundary/pull/967)) @@ -2131,7 +2131,7 @@ to call out in this changelog. The full set of open issues is on GitHub. worked before but wasn't fully tested.) ([PR](https://github.com/hashicorp/boundary/pull/959)) * server: On `SIGHUP`, [worker - tags](https://www.boundaryproject.io/docs/configuration/worker#tags) will be + tags](https://www.developer.hashicorp.com/boundary/docs/workers/worker-tags) will be re-parsed and new values used ([PR](https://github.com/hashicorp/boundary/pull/959)) * server: In addition to the existing `tls_min_version` listener configuration @@ -2368,7 +2368,7 @@ them to access targets). favor of specifying `none` for the new `-keyring-type` parameter. * [`pass`](https://www.passwordstore.org/) is now the default keyring type on non-Windows/non-macOS platforms. See the [CLI docs - page](https://www.boundaryproject.io/docs/api-clients/cli) for more + page](https://www.developer.hashicorp.com/boundary/docs/commands) for more information. ### New and Improved diff --git a/README.md b/README.md index 3f25b10c2..097bcc6ff 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,9 @@ # Boundary -- What is Boundary: https://developer.hashicorp.com/boundary/docs/overview/what-is-boundary -- Website: https://www.boundaryproject.io/ +- What is Boundary: https://developer.hashicorp.com/boundary/docs/what-is-boundary +- Website: https://www.developer.hashicorp.com/boundary/ - Forums: [HashiCorp Discuss](https://discuss.hashicorp.com/c/boundary/) -- Documentation: [https://boundaryproject.io/docs](https://boundaryproject.io/docs) +- Documentation: [https://developer.hashicorp.com/boundary/docs](https://developer.hashicorp.com/boundary/docs) - Tutorials: [HashiCorp's Learn Platform](https://developer.hashicorp.com/boundary/tutorials) Boundary @@ -13,25 +13,26 @@ Boundary is an identity-aware proxy that provides a simple, secure way to access With Boundary you can: * Integrate with your IdP of choice using OpenID Connect, enabling users to securely sign-in to their Boundary environment -* Provide just-in-time network access to network resources, wherever they reside +* Provide just-in-time network access to network resources, wherever they reside * Manage session credentials via a native static credential store, or dynamically generate unique per-session credentials by integrating with HashiCorp Vault * Automate discovery of new endpoints * Manage privileged sessions using Boundary’s session controls * Standardize your team's access workflow with a consistent experience for any type of infrastructure across any provider -Boundary is designed to be straightforward to understand, highly scalable, and +Boundary is designed to be straightforward to understand, highly scalable, and resilient. It can run in clouds, on-prem, secure enclaves and more, and does not require an agent to be installed on every end host, making it suitable for access to managed/cloud services and container-based workflows in addition to traditional host systems and services. + -Watch the video - -For more information, refer to "[What is Boundary?](https://developer.hashicorp.com/boundary/docs/overview/what-is-boundary)" on the Boundary website. +For more information, refer to "[What is Boundary?](https://developer.hashicorp.com/boundary/docs/what-is-boundary)" on the Boundary website. ## Getting Started -Boundary consists of two server components: +Boundary consists of two server components: * **Controller**, which serves the API and coordinate session requests * **Workers**, which perform session handling @@ -40,7 +41,7 @@ A real-world Boundary installation will likely consist of one or more controllers paired with one or more workers. A single Boundary binary can act in either, or both, of these two modes. -Additionally, Boundary provides a Desktop client and CLI for end-users to request and establish +Additionally, Boundary provides a Desktop client and CLI for end-users to request and establish authorized sessions to resources across a network. Boundary Desktop GIF @@ -49,29 +50,29 @@ Boundary does _not_ require software to be installed on your hosts and services. ## Requirements -Boundary has two external dependencies: +Boundary has two external dependencies: - A SQL database - At least one KMS ### SQL database -The database contains Boundary's configuration and session information. The -controller nodes must be able to access the database. +The database contains Boundary's configuration and session information. The +controller nodes must be able to access the database. Values that are secrets (e.g credentials) are encrypted in the database. Currently, PostgreSQL is supported as a database and has been tested with Postgres 12 and above. Boundary uses only common extensions and both hosted and self-managed instances are supported. In most instances, all that you need is a database endpoint and the appropriate credentials. -### KMS +### KMS Boundary uses KMS keys for various purposes, such as protecting secrets, authenticating workers, recovering data, encrypting values in Boundary’s configuration, and more. Boundary uses key derivation extensively to avoid key sprawl of these high-value keys. -You can use [any cloud KMS or Vault's Transit Secrets Engine to satisfy the KMS requirement](https://developer.hashicorp.com/boundary/docs/configuration/kms). +You can use [any cloud KMS or Vault's Transit Secrets Engine to satisfy the KMS requirement](https://developer.hashicorp.com/boundary/docs/configuration/kms). ## Trying out Boundary Running Boundary in a more permanent context requires a few more steps, such as writing some simple configuration files to tell the nodes how to reach their database and KMS. The steps below, along with the extra information needed -for permanent installations, are detailed in our [Installation Guide](https://developer.hashicorp.com/boundary/docs/install-boundary/install). +for permanent installations, are detailed in our [Installation Guide](https://developer.hashicorp.com/boundary/docs/deploy/self-managed/install). > ⚠️ Do _not_ use the `main` branch except for dev or test cases. Boundary 0.10 introduced release branches which should be safe to track, however, migrations in `main` may be renumbered if needed. The Boundary team will not be able to provide assistance if running `main` over the long term results in migration breakages or other bugs. @@ -193,4 +194,3 @@ _please responsibly disclose_ by contacting us at Thank you for your interest in contributing! Please refer to [CONTRIBUTING.md](https://github.com/hashicorp/boundary/blob/main/CONTRIBUTING.md) for guidance. - diff --git a/website/README.md b/website/README.md index 1f1d56a6a..fbb33f2fa 100644 --- a/website/README.md +++ b/website/README.md @@ -1,6 +1,6 @@ # Boundary Documentation Website -This subdirectory contains the content for the [Boundary Website](https://boundaryproject.io/). +This subdirectory contains the content for the [Boundary Website](https://developer.hashicorp.com/boundary/). - -- `max_request_duration` `(string: "90s")` – Specifies the maximum - request duration allowed before Boundary cancels the request. This overrides - `default_max_request_duration` for this listener. - -- `cors_enabled` `(boolean: true)` - Specifies if CORS should be enabled, which - allows Boundary to support external browser-based clients (not including admin - UI), such as Boundary Desktop. If not specified, CORS will be enabled with an - allowed origin that grants access to Boundary Desktop, unless overridden with - `cors_disable_default_allowed_origin_values`. - -- `cors_disable_default_allowed_origin_values` `(boolean: false)` - Specifies - that Boundary should not append default allowed origin values to any specified - in `cors_allowed_origins`, such as Boundary Desktop's origin. This also - disables the behavior of enabling CORS if `cors_enabled` is not specified. - -- `cors_allowed_origins` `(array(string): ["serve://boundary"])` - An array of - allowed CORS origins. Origins must include protocol, host, and port (if port - is different than the default for the specified protocol). To allow all - origins, set to `['*']`. By default, Boundary Desktop's origin - `serve://boundary` is appended to any values included here, unless - `cors_disable_default_allowed_origin_values` is specified. - -- `cors_allowed_headers` `(array(string): [])` – An array specifying headers - that are permitted to be on cross-origin requests. Headers set via this - parameter will be appended to the list of headers that Boundary allows by - default, such as `"Content-Type"`, `"X-Requested-With"`, and - `"Authorization"`. - -### `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 - the status code value. For an example, refer to the - [Configuring custom http response headers](#configuring-custom-http-response-headers) - section. - -- `` `(key-value-map: {})` - A map of string header names - to an array of string values. These headers are set only when the response status - code falls under the collective status code. - For example, `"2xx" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` - is set when the http response status code is `"200"`, `"204"`, etc. This overrides - headers defined at the `default` level. - -- `` `(key-value-map: {})` - A map of string header names - to an array of string values. These headers are set only when the specific status - code is returned. For example, `"200" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` - 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 - -- `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 - the status code value. For an example, refer to the - [Configuring custom http response headers](#configuring-custom-http-response-headers) - section. - -- `` `(key-value-map: {})` - A map of string header names - to an array of string values. These headers are set only when the response status - code falls under the collective status code. - For example, `"2xx" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` - is set when the http response status code is `"200"`, `"204"`, etc. This overrides - headers defined at the `default` level. - -- `` `(key-value-map: {})` - A map of string header names - to an array of string values. These headers are set only when the specific status - code is returned. For example, `"200" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` - is set when the http response status code is `"200"`. This overrides headers defined at - the `default` and `collective status code` level. - -### TLS - -~> `tls` parameters are valid for `api` and `ops` listeners. `cluster` -and `proxy` connections use their own ephemeral TLS stacks. For more -information, see [the connections security concepts -page](/boundary/docs/concepts/security/connections-tls). - -- `tls_disable` `(string: "false")` – Specifies if TLS will be disabled. Boundary - assumes TLS by default, so you must explicitly disable TLS to opt-in to - insecure communication. - -- `tls_cert_file` `(string: )` – - Specifies the path to the certificate for TLS. To configure the listener to - use a CA certificate, concatenate the primary certificate and the CA - certificate together. The primary certificate should appear first in the - combined file. On `SIGHUP`, the path set here _at Boundary startup_ will be - used for reloading the certificate; modifying this value while Boundary is - running will have no effect for `SIGHUP`s. - -- `tls_key_file` `(string: )` – - Specifies the path to the private key for the certificate. If the key file is - encrypted, you will be prompted to enter the passphrase on server startup. The - passphrase must stay the same between key files when reloading your - configuration using `SIGHUP`. On `SIGHUP`, the path set here _at Boundary - startup_ will be used for reloading the certificate; modifying this value - while Boundary is running will have no effect for `SIGHUP`s. - -- `tls_min_version` `(string: "tls12")` – Specifies the minimum supported - version of TLS. Accepted values are "tls10", "tls11", "tls12" or "tls13". - - !> TLS 1.1 and lower are generally considered insecure. - -- `tls_max_version` `(string: "tls13")` – Specifies the maximum supported - version of TLS, useful if appliances (e.g. load balancers) are not yet capable - of higher levels. Accepted values are "tls10", "tls11", "tls12" or "tls13". - - !> TLS 1.1 and lower are generally considered insecure. - -- `tls_cipher_suites` `(string: "")` – Override the default list of supported - ciphersuites (which varies by TLS version) with the the specified - comma-delimited list. The list of all available ciphersuites is available in - the [Golang TLS documentation][golang-tls]. - -- `tls_prefer_server_cipher_suites` `(string: "false")` – Specifies to prefer the - server's ciphersuite over the client ciphersuites. - -- `tls_require_and_verify_client_cert` `(string: "false")` – Turns on client - authentication for this listener; the listener will require a presented - client cert that successfully validates against system CAs. - -- `tls_client_ca_file` `(string: "")` – PEM-encoded Certificate Authority file - used for checking the authenticity of client. - - - -## `tcp` listener examples - -Refer to the following sections for examples of `tcp` listeners. - -### Configure TLS - -This example shows enabling a TLS listener. - -```hcl -listener "tcp" { - purpose = "api" - tls_cert_file = "/etc/certs/Boundary.crt" - tls_key_file = "/etc/certs/Boundary.key" -} -``` - -### 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 -set custom http headers that are appropriate to their applications. Examples of such headers are -`"Strict-Transport-Security"` and `"Content-Security-Policy"` which are known HTTP headers, and could be -configured to harden the security of an application communicating with the Boundary endpoints. Note that -vulnerability scans often examine such security related HTTP headers. In addition, you can configure -application-specific custom headers. For example, `"X-Custom-Header"` has been configured in the example -below. - -```hcl -listener "tcp" { - custom_api_response_headers { - "default" = { - "Strict-Transport-Security" = ["max-age=31536000; includeSubDomains"], - "X-Custom-Header" = ["Custom Header Default Value"], - }, - "2xx" = { - "X-Custom-Header" = ["Custom Header Value 1", "Custom Header Value 2"], - }, - "301" = { - "Strict-Transport-Security" = ["max-age=31536000"], - }, - } - custom_ui_response_headers { - "default" = { - "Strict-Transport-Security" = ["max-age=31536000; includeSubDomains"], - "Content-Security-Policy" = ["default-src 'none'; script-src 'self' 'wasm-unsafe-eval'; frame-src 'self'; font-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self'; media-src 'self'; manifest-src 'self'; style-src-attr 'self'; frame-ancestors 'self'"], - "X-Custom-Header" = ["Custom Header Default Value"], - }, - "2xx" = { - "X-Custom-Header" = ["Custom Header Value 1", "Custom Header Value 2"], - }, - "301" = { - "Strict-Transport-Security" = ["max-age=31536000"], - "Content-Security-Policy" = ["default-src 'none'; script-src 'none'; connect-src 'none'"], - }, - } -} -``` - -Note that Boundary requires `script-src 'wasm-unsafe-eval'` for playback of session recordings. - -In situations where a header is defined under several status code subsections, -Boundary returns the header matching the most specific response code. For example, -with the config example below, a `307` response would return `307 Custom header value`, -while a `306` would return `3xx Custom header value`. - -```hcl -listener "tcp" { - custom_api_response_headers { - "default" = { - "X-Custom-Header" = ["default Custom header value"] - }, - "3xx" = { - "X-Custom-Header" = ["3xx Custom header value"] - }, - "307" = { - "X-Custom-Header" = ["307 Custom header value"] - } - } -} -``` - -There may also be situations where default or collective status headers have been defined, -but you do not want them returned for a specific status code. You can unset headers at any -level by defining the headers as an empty list. - -```hcl -listener "tcp" { - custom_api_response_headers { - "default" = { - "X-Custom-Header" = ["default Custom header value"] - }, - "3xx" = { - "X-Custom-Header" = ["3xx Custom header value"] - }, - "307" = { - // Do not return this header for 307 responses - "X-Custom-Header" = [] - } - } -} -``` - -### Listen on mulitple interfaces - -This example shows Boundary listening on a private interface, as well as localhost. - -```hcl -listener "tcp" { - purpose = "api" - address = "127.0.0.1:9200" -} - -listener "tcp" { - purpose = "cluster" - address = "10.0.0.5:9201" -} -``` - -[golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go -[api-addr]: /boundary/docs/configuration#api_addr -[cluster-addr]: /boundary/docs/configuration#cluster_addr diff --git a/website/content/docs/configuration/listener/unix.mdx b/website/content/docs/configuration/listener/unix.mdx deleted file mode 100644 index 4f6086259..000000000 --- a/website/content/docs/configuration/listener/unix.mdx +++ /dev/null @@ -1,204 +0,0 @@ ---- -layout: docs -page_title: Unix domain socket listener configuration -description: >- - Learn about using the Unix listener on a specified Unix domain socket, and view configurable parameters. View example Unix listener configurations. ---- - -# `unix` listener - -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. - -```hcl -listener "unix" { - purpose = "api" - address = "/var/run/boundary-api.sock" -} -``` - -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 - -Refer to the following sections for the supported `unix` listener parameters. - -### General - -- `purpose` `(string: "")` - Specifies the purpose. Can be `api`, `ops` or `cluster`. - -- `address` `(string: "")` – Specifies the address (filesystem path) to bind to - for listening. - -- `http_idle_timeout` `(string: "5m")` - Specifies the maximum amount of time to - wait for the next request when keep-alives are enabled. If `http_idle_timeout` - is zero, the value of `http_read_timeout` is used. If both are zero, the value - of `http_read_header_timeout` is used. This is specified using a label suffix - like `"30s"` or `"1h"`. - -- `http_read_header_timeout` `(string: "10s")` - Specifies the amount of time - allowed to read request headers. This is specified using a label suffix like - `"30s"` or `"1h"`. - -- `http_read_timeout` `(string: "30s")` - Specifies the maximum duration for - 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 - 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"`. - - - -- `max_request_duration` `(string: "90s")` – Specifies the maximum - request duration allowed before Boundary cancels the request. This overrides - `default_max_request_duration` for this listener. - -- `cors_enabled` `(boolean: true)` - Specifies if CORS should be enabled, which - allows Boundary to support external browser-based clients (not including admin - UI), such as Boundary Desktop. If not specified, CORS will be enabled with an - allowed origin that grants access to Boundary Desktop, unless overridden with - `cors_disable_default_allowed_origin_values`. - -- `cors_disable_default_allowed_origin_values` `(boolean: false)` - Specifies - that Boundary should not append default allowed origin values to any specified - in `cors_allowed_origins`, such as Boundary Desktop's origin. This also - disables the behavior of enabling CORS if `cors_enabled` is not specified. - -- `cors_allowed_origins` `(array(string): ["serve://boundary"])` - An array of - allowed CORS origins. Origins must include protocol, host, and port (if port - is different than the default for the specified protocol). To allow all - origins, set to `['*']`. By default, Boundary Desktop's origin - `serve://boundary` is appended to any values included here, unless - `cors_disable_default_allowed_origin_values` is specified. - -- `cors_allowed_headers` `(array(string): [])` – An array specifying headers - that are permitted to be on cross-origin requests. Headers set via this - parameter will be appended to the list of headers that Boundary allows by - default, such as `"Content-Type"`, `"X-Requested-With"`, and - `"Authorization"`. - -### TLS - -~> `tls` parameters are valid for `api` and `ops` listeners. `cluster` -and `proxy` connections use their own ephemeral TLS stacks. For more -information, see [the connections security concepts -page](/boundary/docs/concepts/security/connections-tls). - -- `tls_disable` `(string: "false")` – Specifies if TLS will be disabled. Boundary - assumes TLS by default, so you must explicitly disable TLS to opt-in to - insecure communication. - -- `tls_cert_file` `(string: )` – - Specifies the path to the certificate for TLS. To configure the listener to - use a CA certificate, concatenate the primary certificate and the CA - certificate together. The primary certificate should appear first in the - combined file. On `SIGHUP`, the path set here _at Boundary startup_ will be - used for reloading the certificate; modifying this value while Boundary is - running will have no effect for `SIGHUP`s. - -- `tls_key_file` `(string: )` – - Specifies the path to the private key for the certificate. If the key file is - encrypted, you will be prompted to enter the passphrase on server startup. The - passphrase must stay the same between key files when reloading your - configuration using `SIGHUP`. On `SIGHUP`, the path set here _at Boundary - startup_ will be used for reloading the certificate; modifying this value - while Boundary is running will have no effect for `SIGHUP`s. - -- `tls_min_version` `(string: "tls12")` – Specifies the minimum supported - version of TLS. Accepted values are "tls10", "tls11", "tls12" or "tls13". - - !> TLS 1.1 and lower are generally considered insecure. - -- `tls_max_version` `(string: "tls13")` – Specifies the maximum supported - version of TLS, useful if appliances (e.g. load balancers) are not yet capable - of higher levels. Accepted values are "tls10", "tls11", "tls12" or "tls13". - - !> TLS 1.1 and lower are generally considered insecure. - -- `tls_cipher_suites` `(string: "")` – Override the default list of supported - ciphersuites (which varies by TLS version) with the the specified - comma-delimited list. The list of all available ciphersuites is available in - the [Golang TLS documentation][golang-tls]. - -- `tls_prefer_server_cipher_suites` `(string: "false")` – Specifies to prefer the - server's ciphersuite over the client ciphersuites. - -- `tls_require_and_verify_client_cert` `(string: "false")` – Turns on client - authentication for this listener; the listener will require a presented - client cert that successfully validates against system CAs. - -- `tls_client_ca_file` `(string: "")` – PEM-encoded Certificate Authority file - used for checking the authenticity of client. - - - -## `unix` listener examples - -Refer to the following sections for examples of `unix` listeners. - -### Configure TLS - -This example shows enabling a TLS listener. - -```hcl -listener "unix" { - purpose = "api" - address = "/var/run/boundary-api.sock" - tls_cert_file = "/etc/certs/Boundary.crt" - tls_key_file = "/etc/certs/Boundary.key" -} -``` - -### Listen on multiple interfaces - -This example shows Boundary listening on a private interface, as well as localhost. - -```hcl -listener "tcp" { - purpose = "api" - address = "/var/run/boundary-api.sock" -} - -listener "tcp" { - purpose = "cluster" - address = "/var/run/boundary-cluster.sock" -} -``` - -[golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go -[api-addr]: /boundary/docs/configuration#api_addr -[cluster-addr]: /boundary/docs/configuration#cluster_addr diff --git a/website/content/docs/configuration/listeners/index.mdx b/website/content/docs/configuration/listeners/index.mdx new file mode 100644 index 000000000..e5ed3e6d6 --- /dev/null +++ b/website/content/docs/configuration/listeners/index.mdx @@ -0,0 +1,17 @@ +--- +layout: docs +page_title: Listeners - configuration reference +description: >- + The listener stanza configures the addresses and ports on which Boundary will respond to requests. +--- + +# `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/listeners/tcp-listeners) and [Unix](/boundary/docs/configuration/listeners/unix-listeners). + + +## `listener` purpose + +@include '/configuration-reference/listeners/listener-purpose.mdx' \ No newline at end of file diff --git a/website/content/docs/configuration/listeners/tcp-listeners.mdx b/website/content/docs/configuration/listeners/tcp-listeners.mdx new file mode 100644 index 000000000..3d8f395ee --- /dev/null +++ b/website/content/docs/configuration/listeners/tcp-listeners.mdx @@ -0,0 +1,55 @@ +--- +layout: docs +page_title: TCP listeners - configuration reference +description: >- + Learn about using the TCP listener on a TCP address and port, and view configurable parameters. Understand custom response headers. View example configurations. +--- + +# `tcp` listener + +@include '/configuration-reference/listeners/tcp-intro.mdx' + +## Listener's custom response headers + +@include '/configuration-reference/listeners/tcp-custom-response-headers.mdx' + +## `tcp` listener parameters + +Refer to the following sections for `tcp` listener parameters. + +### General + +@include '/configuration-reference/listeners/tcp-general-parameters.mdx' + +### `custom_api_response_headers` parameters + +@include '/configuration-reference/listeners/tcp-custom-api-response-headers.mdx' + +### `custom_ui_response_headers` parameters + +@include '/configuration-reference/listeners/tcp-custom-ui-response-headers.mdx' + +### TLS + +@include '/configuration-reference/listeners/tcp-tls.mdx' + + + +## `tcp` listener examples + +Refer to the following sections for examples of `tcp` listeners. + +### Configure TLS + +@include '/configuration-reference/listeners/tcp-configure-tls.mdx' + +### Configure custom http response headers + +@include '/configuration-reference/listeners/tcp-configure-custom-http-response-headers.mdx' + +### Listen on mulitple interfaces + +@include '/configuration-reference/listeners/tcp-listen-on-mulitple-interfaces.mdx' \ No newline at end of file diff --git a/website/content/docs/configuration/listeners/unix-listeners.mdx b/website/content/docs/configuration/listeners/unix-listeners.mdx new file mode 100644 index 000000000..4aede6297 --- /dev/null +++ b/website/content/docs/configuration/listeners/unix-listeners.mdx @@ -0,0 +1,45 @@ +--- +layout: docs +page_title: Unix domain socket - listeners - configuration reference +description: >- + Learn about using the Unix listener on a specified Unix domain socket, and view configurable parameters. View example Unix listener configurations. +--- + +# `unix` listener + +@include '/configuration-reference/listeners/unix-intro.mdx' + +## `unix` listener parameters + +Refer to the following sections for the supported `unix` listener parameters. + +### General + +@include '/configuration-reference/listeners/unix-general-parameters.mdx' + +### TLS + +@include '/configuration-reference/listeners/unix-tls-parameters.mdx' + + + +## `unix` listener examples + +Refer to the following sections for examples of `unix` listeners. + +### Configure TLS + +@include '/configuration-reference/listeners/unix-configure-tls.mdx' + +### Listen on multiple interfaces + +@include '/configuration-reference/listeners/unix-listen-on-multiple-interfaces.mdx' + +[golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go +[api-addr]: /boundary/docs/configuration#api_addr +[cluster-addr]: /boundary/docs/configuration#cluster_addr diff --git a/website/content/docs/configuration/plugins.mdx b/website/content/docs/configuration/plugins.mdx index 67d5a00db..c092513e1 100644 --- a/website/content/docs/configuration/plugins.mdx +++ b/website/content/docs/configuration/plugins.mdx @@ -7,10 +7,8 @@ description: >- # `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 -to provide a mechanism for third-party plugins to be able to be used. Available -plugins are currently bundled with Boundary and executed automatically. +The `plugin` stanza configures plugin-specific parameters. The plugin system is currently internal; over time, the intent is to provide a mechanism for third-party plugins to be able to be used. +Available plugins are currently bundled with Boundary and executed automatically. There is currently one configuration parameter available: diff --git a/website/content/docs/configuration/session-recording/index.mdx b/website/content/docs/configuration/session-recording/index.mdx deleted file mode 100644 index f0202502e..000000000 --- a/website/content/docs/configuration/session-recording/index.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -layout: docs -page_title: Session recording overview -description: >- - Learn about using session recording to audit user sessions for compliance and threat management. Understand considerations for local and remote storage. ---- - -# Overview - -This feature requires HCP Boundary Plus or Boundary Enterprise - -Boundary provides auditing capabilities using a feature called session recording. - -In Boundary, a session represents a set of connections between a user and a host from a target. The session begins when an authorized user requests access to a target, and it ends when that access is terminated. - -When you enable session recording on a target, a worker records any sessions that access that target. The worker stores the session recording on local disk during the recording phase, and then moves the recording to the external object store when the session is terminated. - -Session recordings are stored in the [BSR (Boundary Session Recording)](/boundary/docs/concepts/auditing/#bsr-directory-structure) format. Any credentials needed to access the external object store are passed from the controller to the recording worker when the session is established. -You can view the recordings later with a session player that runs in a web browser. - -## Storage considerations - -The BSR captures all the data transmitted between a user and a target during a single session. As a result, the size of a BSR is dependent on user activity. At a minimum, a BSR for a session with one connection requires 8KB of space for its file for BSR keys, checksums, and metadata. - -Determining how much storage you need to allocate on workers and the external storage provider for recordings depends on user activity, but the following two examples are provided to help with storage estimates: - -- For one minute of simple shell activity, a BSR can be around 20KB in size. The storage requirements for 1,000 such sessions would be 20MB. - -- Sending 50MB of data results in a BSR around 50.1MB in size. The storage requirements for 1,000 such sessions would be 50.1 GB. - -When you estimate worker storage requirements, consider the number of concurrent sessions that will be recorded on that worker. Boundary writes the BSR to the worker's local storage while the session is active, and then moves it to the remote storage bucket when the session is closed. - -When you estimate storage requirements for the external storage provider, consider your [storage policy](/boundary/docs/concepts/domain-model/storage-policy) and how long a BSR will be retained in the external storage bucket. - - - -Boundary supports recorded session files up to 5 GB in size. -If a recorded session file is over 5 GB, the session details show the recording state as `Failed` and you may not be able to play back the session. -Be careful when you use Secure File Copy (SCP) to transfer large files during a recorded session because it can result in large recorded session files. - - - -## Enable session recording - -To enable session recording, you must: - -1. [Configure workers for local storage](/boundary/docs/configuration/session-recording/configure-worker-storage) -1. Configure an external storage provider: - - [Amazon S3](/boundary/docs/configuration/session-recording/storage-providers/configure-s3) - - [MinIO](/boundary/docs/configuration/session-recording/storage-providers/configure-minio) - - [S3-compliant](/boundary/docs/configuration/session-recording/storage-providers/configure-s3-compliant) -1. [Create a storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket) -1. [Enable session recording on a target](/boundary/docs/configuration/session-recording/enable-session-recording) - -## Configure recording retention policies - -After enabling session recording, you can configure retention policies for recorded sessions: - -1. [Configure storage policies](/boundary/docs/configuration/session-recording/configure-storage-policy) -1. [Update storage policies](/boundary/docs/configuration/session-recording/update-storage-policy) \ No newline at end of file diff --git a/website/content/docs/configuration/target-aliases/index.mdx b/website/content/docs/configuration/target-aliases/index.mdx deleted file mode 100644 index 634156276..000000000 --- a/website/content/docs/configuration/target-aliases/index.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: docs -page_title: Overview -description: >- - Learn how to configure aliases and transparent sessions to enhance end-user workflows and simplify target access. ---- - -# Overview - -Target aliases simplify the connection workflow for end users by allowing them to reference targets using a globally unique DNS-like string. - -Without aliases, connecting to an end target requires you to reference the target ID, or a combination of target name and scope: - -```shell-session -$ boundary connect ssh -target-id ttcp_1234567890 -``` - -```shell-session -$ boundary connect ssh -target-name sql-database -target-scope-name -staging -``` - -With target aliases, a single globally referenced value is assigned to a target, simplifying connection workflows and enabling transparent sessions for Enterprise and HCP end users. - -```shell-session -$ boundary connect ssh sql-database-staging -``` - -## Configure target aliases - -To set up a target alias: - -1. [Create a target alias](/boundary/docs/configuration/target-aliases/create-target-alias) -1. [Connect to a target using an alias](/boundary/docs/configuration/target-aliases/connect-target-alias) - -After you set up a target alias, you can optionally [Configure transparent sessions for end users](/boundary/docs/configuration/target-aliases/transparent-sessions). HCP/ENT \ No newline at end of file diff --git a/website/content/docs/configuration/target-aliases/transparent-sessions.mdx b/website/content/docs/configuration/target-aliases/transparent-sessions.mdx deleted file mode 100644 index 708e7fc36..000000000 --- a/website/content/docs/configuration/target-aliases/transparent-sessions.mdx +++ /dev/null @@ -1,119 +0,0 @@ ---- -layout: docs -page_title: Configure transparent sessions -description: >- - Learn how to configure transparent sessions to enhance end-user workflows and simplify target access. ---- - -# Configure transparent sessions - -@include 'alerts/enterprise-only.mdx' - -## Requirements - -Before you configure transparent sessions, you must: - -- If you have previous versions of the Boundary Desktop or CLI client in your local environment, ensure that they are fully uninstalled before you install with the latest Boundary installer. -- Download the appropriate Boundary installer for your Windows or MacOS environment from the [Install Boundary](/boundary/install#installer) page or the [releases](https://releases.hashicorp.com/boundary-installer) page. -- Ensure that both IPv4 and IPv6 protocols are enabled for your environment. The [Client Agent](/boundary/docs/api-clients/client-agent) requires both protocols to start and perform DNS lookups. - -Once Boundary is installed, you should make sure you have the appropriate grants configured so that you can resolve aliases and establish transparent sessions. -For more information, refer to the [Grants](/boundary/docs/api-clients/client-agent#grants) section in the Client Agent documentation. - - - - A known issue regarding how grants were previously created in HCP Boundary may cause you to receive a 500 error when you attempt to list resolvable aliases. - Clusters created before April 26, 2025 may be missing the following grants: - - `ids={{.User.Id}};type=user;actions=list-resolvable-aliases` - - `ids=*;type=target;actions=list,read` - - If your cluster is missing these grants, HashiCorp recommends adding them. - - For more information, refer to the [known issue](/boundary/docs/release-notes/v0_19_0#hcp-grants). - - - -## Install the Boundary clients - -Complete the following steps to install the Boundary Client Agent, CLI, and Desktop client: - -1. Install Boundary using the installer. -Make sure to select the options **Boundary Client Agent**, **CLI**, and **Desktop**. -1. Open the CLI and type the following command to confirm that the version is 0.18.0: - ```shell-session - $ boundary version - ``` -1. In the CLI, run the status command to confirm that the Boundary Client Agent has started: - - ```shell-session - $ boundary client-agent status - ``` - -Refer to the [transparent sessions interoperability matrix](/boundary/docs/configuration/target-aliases/interoperability-matrix) for a list of the third-party products that have been tested for use with the Boundary installer and Client Agent. - -## Configure targets - -The following section details how to configure targets and use transparent sessions. - - - -If you use a cluster that was created earlier than release 0.16.0, you must add the grant `list-resolvable-aliases` so that the client agent can populate the local alias cache. - -As an example, you could add the grant: - -`type=user;actions=list-resolvable-aliases;ids=*`. - -For more information, refer to the [Grants](/boundary/docs/api-clients/client-agent#grants) section in the Client Agent documentation. - - - -Complete the following steps to configure targets and test transparent sessions: - -1. Authenticate to Boundary using the CLI or Desktop client. -1. [Create a new target with an alias](/boundary/docs/concepts/aliases#create-an-alias-during-target-creation) or [create an alias for an existing target](/boundary/docs/concepts/aliases#create-an-alias-for-an-existing-target). -Ensure that you have authorization to establish a session to the target. -1. Open the client of your choice and [connect to your target using the alias](/boundary/docs/concepts/aliases#connect-to-a-target-using-an-alias). - - Boundary routes your session using the Boundary Client Agent. - You can validate that Boundary routed the session by looking at the **Sessions** page in the Desktop client, by typing `boundary sessions list -recursive` in the CLI, or by looking at sessions managed by the Client Agent using `boundary client-agent sessions`. - - - - The Client Agent periodically requests an updated list of aliases from the controller, so the alias may not work immediately after you create it. - The alias should be updated in the Client Agent within 2 minutes. If you still see connection issues after 2 minutes, follow the troubleshooting steps in [the Client Agent troubleshooting guide](/boundary/docs/api-clients/client-agent#troubleshooting). - - - -When you have validated that transparent sessions work, you can create and establish transparent sessions to other services. - -To establish transparent sessions to other services: - -1. Make a list of the services you use. -1. Create workers as needed for network partitions. -1. Add the services to Boundary as targets. -1. [Create aliases for the targets](/boundary/docs/configuration/target-aliases/create-target-alias). -1. Connect to the target using your client of choice. - -## Connect using transparent sessions - -Without transparent sessions, you must use the [Boundary connect helpers](/boundary/docs/concepts/connection-workflows) to establish a session: - -```shell-session -$ boundary connect ssh -target-name sql-database -target-scope-name -staging -``` - -Alternatively, you can use the Boundary Desktop Client to start a session, and connect on a local port supplied by Boundary: - -```shell-session -$ ssh 127.0.0.1 -p 55374 -``` - -With transparent sessions, you use the target alias as the address to establish a session. If the [client agent is running](#install-the-boundary-clients) and you have authenticated using the CLI or Boundary Desktop Client, you can use the alias to start a session: - -```shell-session -$ ssh my.alias.name -``` - -Boundary starts the session as usual, and brokers or injects any credentials you have configured. diff --git a/website/content/docs/configuration/worker/index.mdx b/website/content/docs/configuration/worker/index.mdx deleted file mode 100644 index 6c124b6c4..000000000 --- a/website/content/docs/configuration/worker/index.mdx +++ /dev/null @@ -1,222 +0,0 @@ ---- -layout: docs -page_title: Worker configuration overview -description: >- - Learn about worker configuration for proxies, storage, and tags. Understand how multi-hop configurations let you chain workers together in private networks. ---- - -# Worker stanza - -The `worker` stanza configures Boundary worker-specific parameters. - -All workers within Boundary use certificates and encryption keys to identify -themselves and protect data in transit. However, there are three different -ways to register them so that registration of workers can fit into any workflow: controller-led, worker-led, and via external KMS. - -The sub-pages linked at the bottom of this page explain the differences in their configuration. - -You must register workers using the worker-led or controller-led methods in the system with an API call. These workers require storage on disk to store the current set of credentials. Workers using an external KMS auto-register after authenticating. This makes them an easy mechanism to use for automatic scaling. -This also means they do not need to store -credentials locally; the KMS re-authenticates them each time they connect. - - - -Before version 0.15 of Boundary, there were two different types of workers, PKI & KMS workers. -If you are using pre-0.15 workers with pre-0.15 upstream configurations, please switch the documentation version to `0.13.x` - `0.14.x`. This will ensure you have the correct information. - - - -## Common worker parameters -The following fields apply to all registration mechanisms. - -```hcl -worker { - public_addr = "5.1.23.198" - - # Local storage path required if session recording is enabled - recording_storage_path = "tmp/boundary/" - - # Minimum available disk space required in the local storage path if session recording is enabled - recording_storage_minimum_available_capacity = "500MB" - - # Mutually exclusive with hcp_boundary_cluster_id - initial_upstreams = [ - "10.0.0.1", - "10.0.0.2", - ] - - tags { - type = ["prod", "webservers"] - region = ["us-east-1"] - } - - # HCP Boundary only - # hcp_boundary_cluster_id = "....." -} -``` - -- `public_addr` - Specifies the public host or IP address (and optionally port) - where clients can reach the worker for proxying. By default, it uses the - address of the listener marked for `proxy` purpose. This is useful for cloud - environments that do not bind a publicly accessible IP directly to a NIC on - the host, such as an Amazon EIP. - - You should omit this parameter in multi-hop configurations if this self-managed worker connects to an upstream HCP-managed worker. - - This value can reference any of the following: - - a direct address string - - read an address from a file on disk (file://) - - read an address from an environment variable (env://) - -- `initial_upstreams` - A list of hosts/IP addresses and optionally ports for - reaching the Boundary cluster. The port will default to `:9201` if not - specified. This value can be a direct access string array with the addresses, - or it can refer to a file on disk (`file://`) from which the addresses will be - read, or an environment variable (`env://`) from which to read the addresses. When - using environment variable or file, their contents must formatted as a JSON array: - `["127.0.0.1", "192.168.0.1", "10.0.0.1"]` - - Self-managed workers connecting to HCP Boundary require the [`hcp_boundary_cluster_id`](/boundary/docs/configuration/worker/#hcp_boundary_cluster_id) parameter instead of `initial upstreams`, unless you are configuring an HCP-managed worker as an ingress worker. - If you configure a self-managed worker with both `initial_upstreams` and `hcp_boundary_cluster_id`, the worker configuration fails. - -- `hcp_boundary_cluster_id` - A string required to configure workers using worker-led or controller-led registration - to connect to your HCP Boundary cluster rather than specifying -`initial_upstreams`. This parameter is valid only for workers using the worker-led or controller-led - registration method and for workers directly connected to HCP Boundary. - -- `recording_storage_path` - A path to the local storage for recorded sessions. - Boundary stores session recordings in the local storage while they are in progress. - When the session is complete, Boundary moves the local session recording to remote storage and deletes the local copy. - -- `recording_storage_minimum_available_capacity` - A value measured in bytes that - defines the worker's local storage state. Boundary compares this value to the available local disk space found in the `recording_storage_path` and determines if a worker can perform session recording operations. - The supported suffixes are kb, kib, mb, mib, gb, gib, tb, tib, which are not case sensitive. Example: 2GB, 2gb, 2GiB, 2gib. - The possible storage states based on the `recording_storage_minimum_available_capacity` are: - - Available - The worker has storage above the threshold and can proxy sessions that have session recording enabled. - - Low storage - The worker has storage below the threshold. It allows existing sessions to continue without interruption but prevents proxying new sessions that have session recording enabled. The worker cannot record new sessions or play back existing recordings. - - Critically low storage - The worker falls below half the storage threshold. It forcefully closes existing sessions with session recording. The worker cannot record new sessions or play back existing recordings. - - Out of storage - The worker is out of local disk space. It cannot record new sessions or play back existing recordings. The worker enters an unrecoverable state, requiring an administrator to intervene and resolve the issue. - - Not configured - The worker lacks a configured local storage path. - - Unknown - The worker starts with this default local storage state. This state indicates that the worker's local storage state is not yet known. - -- `tags` - A map of key-value pairs where values are an array of strings. Most - commonly used for [filtering](/boundary/docs/concepts/filtering) targets a - worker can proxy via [worker - tags](/boundary/docs/concepts/filtering/worker-tags). On `SIGHUP`, the tags - set here will be re-parsed and new values used. It can also be a string - referring to a file on disk (`file://`) or an environment variable (`env://`). - -## Signals - -The `SIGHUP` signal causes a worker to reload its configuration file to pick up any updates for the `initial_upstreams` and `tags` values. -Boundary ignores other updated values. - -The `SIGTERM` and `SIGINT` signals initiate a graceful shutdown on a worker. The worker waits for any sessions to drain -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 - -This feature requires HCP Boundary or Boundary Enterprise - -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, you must connect two or more workers to each other in some -configuration. There are no limits on the number of workers allowed in a -multi-hop session configuration. - -It helps to think of “upstream” and “downstream” nodes in the context of -multi-hop. If you view controllers as the “top” node of a multi-hop chain, any -worker connected to a node is "downstream" of that node. The node that any -particular worker connects to (whether another worker or a controller) is the -"upstream" of that node. For example, in the diagram below, Worker 2’s upstream -is Worker 1, and its downstream is Worker 3. - -![multi-hop workers](/img/multi-hop-workers.png) - -You can deploy multi-hop workers in scenarios where inbound network traffic is -not allowed. A worker in a private network can send outbound communication to -its upstream worker, and create a reverse proxy to establish a session. - -You can configure [target worker filters][] with multi-hop workers to allow for -fine-grained control on which workers handle ingress and egress for session -traffic to a [target][]. Ingress worker filters specify the workers you use to initiate a session, and egress worker filters specify the workers you use to access targets. - -### 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 - -To proxy target connections, ingress workers require outbound access to the -Boundary control plane and inbound access from clients. - -#### 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 - -To proxy target connections, egress workers require outbound access to an -upstream worker and outbound access to the destination host or service. - -## Complete configuration example - -```hcl -listener "tcp" { - purpose = "proxy" - tls_disable = true - address = "127.0.0.1" -} - -worker { - # Path for worker storage, assuming worker-led or controller-led registration. Must be unique across workers - auth_storage_path="/boundary/demo-worker-1" - - # Local storage path required if session recording is enabled - recording_storage_path = "tmp/boundary/" - - # Minimum available disk space required in the local storage path if session recording is enabled - recording_storage_minimum_available_capacity = "500MB" - - # Workers typically need to reach upstreams on :9201 - initial_upstreams = [ - "10.0.0.1", - "10.0.0.2", - "10.0.0.3", - ] - - public_addr = "myhost.mycompany.com" - - tags { - type = ["prod", "webservers"] - region = ["us-east-1"] - } -} - -# The following KMS config is an example only -# Use a production KMS such as AWS KMS for production installs -kms "aead" { - purpose = "worker-auth-storage" - aead_type = "aes-gcm" - key = "X+IJMVT6OnsrIR6G/9OTcJSX+lM9FSPN" - key_id = "worker-auth-storage" -} - - -``` - -## Tutorials - -Refer to the [Self-Managed Worker Registration with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-workers) tutorial to learn how to register and manage Workers. - -Refer to the [Manage Multi-Hop Sessions with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-multi-hop) tutorial to learn how to configure a multi-hop session. - -[Worker Configuration Methods]: /boundary/docs/configuration/worker/worker-configuration -[target]: /boundary/docs/concepts/domain-model/targets -[target worker filters]: /boundary/docs/concepts/filtering/worker-tags#target-worker-filtering -[session recording]: /boundary/docs/configuration/session-recording diff --git a/website/content/docs/configuration/workers.mdx b/website/content/docs/configuration/workers.mdx new file mode 100644 index 000000000..60a55b5c8 --- /dev/null +++ b/website/content/docs/configuration/workers.mdx @@ -0,0 +1,16 @@ +--- +layout: docs +page_title: Worker stanza +description: >- + Learn about how to configure workers for proxies, storage, and tags. +--- + +# worker stanza + +The `worker` stanza configures Boundary worker-specific parameters. + +@include '/configuration-reference/workers/common-worker-parameters.mdx' + +## Complete configuration example + +@include '/configuration-reference/workers/complete-configuration-example.mdx' \ No newline at end of file diff --git a/website/content/docs/configuration/credential-management/configure-credential-brokering.mdx b/website/content/docs/credentials/configure-credential-brokering.mdx similarity index 84% rename from website/content/docs/configuration/credential-management/configure-credential-brokering.mdx rename to website/content/docs/credentials/configure-credential-brokering.mdx index b5c9f9f76..87fb0b18b 100644 --- a/website/content/docs/configuration/credential-management/configure-credential-brokering.mdx +++ b/website/content/docs/credentials/configure-credential-brokering.mdx @@ -16,8 +16,8 @@ When you use credential brokering, Boundary returns credentials to the user when - You must have configured either a static credential store or a Vault credential store: - - To configure a static credential store, refer to [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary). - - To configure a Vault credential store and credential library, refer to [Create Vault credential stores](/boundary/docs/configuration/credential-management/static-cred-vault). + - To configure a static credential store, refer to [Create static credential stores](/boundary/docs/credentials/static-cred-boundary). + - To configure a Vault credential store and credential library, refer to [Create Vault credential stores](/boundary/docs/credentials/static-cred-vault). - You must have a static credential saved in your static credential store or Vault credential store. The credential must correspond to the target you want to authenticate to. @@ -73,6 +73,6 @@ Complete the following steps to configure credential brokering for a target: Refer to the following topics for more information: -- [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary) -- [Create Vault credential stores](/boundary/docs/configuration/credential-management/static-cred-vault) -- [Target types](/boundary/docs/concepts/domain-model/targets#target-types) \ No newline at end of file +- [Create static credential stores](/boundary/docs/credentials/static-cred-boundary) +- [Create Vault credential stores](/boundary/docs/credentials/static-cred-vault) +- [Target types](/boundary/docs/domain-model/targets#target-types) \ No newline at end of file diff --git a/website/content/docs/configuration/credential-management/configure-credential-injection.mdx b/website/content/docs/credentials/configure-credential-injection.mdx similarity index 85% rename from website/content/docs/configuration/credential-management/configure-credential-injection.mdx rename to website/content/docs/credentials/configure-credential-injection.mdx index d7e2f6561..08cbd8552 100644 --- a/website/content/docs/configuration/credential-management/configure-credential-injection.mdx +++ b/website/content/docs/credentials/configure-credential-injection.mdx @@ -19,8 +19,8 @@ Credential injection provides end users with a passwordless experience when they - You must have configured either a static credential store or a Vault credential store: - - To configure a static credential store, refer to [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary). - - To configure a Vault credential store and credential library, refer to [Create Vault credential stores](/boundary/docs/configuration/credential-management/static-cred-vault). + - To configure a static credential store, refer to [Create static credential stores](/boundary/docs/credentials/static-cred-boundary). + - To configure a Vault credential store and credential library, refer to [Create Vault credential stores](/boundary/docs/credentials/static-cred-vault). - You must have a static credential saved in your static credential store or Vault credential store. The credential must correspond to the target to which you want to authenticate. @@ -79,7 +79,7 @@ Complete the following steps to configure targets with credential injection: Refer to the following topics for more information: -- [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary) -- [Create Vault credential stores](/boundary/docs/configuration/credential-management/static-cred-vault) -- [Target types](/boundary/docs/concepts/domain-model/targets#target-types) -- [Credentials](/boundary/docs/concepts/domain-model/credentials) \ No newline at end of file +- [Create static credential stores](/boundary/docs/credentials/static-cred-boundary) +- [Create Vault credential stores](/boundary/docs/credentials/static-cred-vault) +- [Target types](/boundary/docs/domain-model/targets#target-types) +- [Credentials](/boundary/docs/domain-model/credentials) diff --git a/website/content/docs/configuration/credential-management/index.mdx b/website/content/docs/credentials/index.mdx similarity index 86% rename from website/content/docs/configuration/credential-management/index.mdx rename to website/content/docs/credentials/index.mdx index d77b71492..27c2727a8 100644 --- a/website/content/docs/configuration/credential-management/index.mdx +++ b/website/content/docs/credentials/index.mdx @@ -5,13 +5,13 @@ description: >- Credential stores let you store and manage credentials in Boundary. Learn about configuring user workflows with credential management or credential injection. --- -# Overview +# Credentials in Boundary When users connect to a target machine, they typically need a set of credentials for authentication. Rather than requiring users to securely store and manage credentials for every target resource, Boundary centralizes credential management to enhance security. ## Credential stores -Boundary supports credential management using [credential stores](/boundary/docs/concepts/domain-model/credential-stores), which are resources that store credentials for various targets. +Boundary supports credential management using [credential stores](/boundary/docs/domain-model/credential-stores), which are resources that store credentials for various targets. There are two types of credential stores: @@ -34,13 +34,13 @@ The third workflow uses a featured called credential injection, where credential The type of target you connect to also determines which credential workflows you can configure. An SSH target must have at least one injected application credential to establish the SSH connection. A TCP target cannot have any injected application credentials. -For more information, refer to the [Target types](/boundary/docs/concepts/domain-model/targets#target-types) documentation. +For more information, refer to the [Target types](/boundary/docs/domain-model/targets#target-types) documentation. ## Next steps The following pages provide steps to configure static credentials using both a static credential store and a Vault credential store. You can also configure targets for either credential brokering or credential injection workflows. -- [Create a static credential store](/boundary/docs/configuration/credential-management/static-cred-boundary) -- [Create a Vault credential store](/boundary/docs/configuration/credential-management/static-cred-vault) -- [Configure targets with credential brokering](/boundary/docs/configuration/credential-management/configure-credential-brokering) -- [Configure targets with credential injection](/boundary/docs/configuration/credential-management/configure-credential-injection) \ No newline at end of file +- [Create a static credential store](/boundary/docs/credentials/static-cred-boundary) +- [Create a Vault credential store](/boundary/docs/credentials/static-cred-vault) +- [Configure targets with credential brokering](/boundary/docs/credentials/configure-credential-brokering) +- [Configure targets with credential injection](/boundary/docs/credentials/configure-credential-injection) \ No newline at end of file diff --git a/website/content/docs/configuration/credential-management/static-cred-boundary.mdx b/website/content/docs/credentials/static-cred-boundary.mdx similarity index 94% rename from website/content/docs/configuration/credential-management/static-cred-boundary.mdx rename to website/content/docs/credentials/static-cred-boundary.mdx index 26cf542ba..72da776df 100644 --- a/website/content/docs/configuration/credential-management/static-cred-boundary.mdx +++ b/website/content/docs/credentials/static-cred-boundary.mdx @@ -7,7 +7,7 @@ description: >- # Create a static credential store -You can manage credentials in Boundary using [credential stores](/boundary/docs/concepts/domain-model/credential-stores), which are resources that store credentials for various targets. +You can manage credentials in Boundary using [credential stores](/boundary/docs/domain-model/credential-stores), which are resources that store credentials for various targets. Static credential stores are built into Boundary and only store static credentials like username and password or keypairs. ## Requirements @@ -106,5 +106,5 @@ Once you have created a credential store, you can configure targets for credenti When you use credential brokering, Boundary centrally manages credentials and returns them to the user when they attempt to connect to a target. Credential injection requires HCP Boundary or Boundary Enterprise, and it provides end users with a passwordless experience when they connect to targets. -- [Configure a target for credential brokering](/boundary/docs/configuration/credential-management/configure-credential-brokering) -- [Configure a target for credential injection](/boundary/docs/configuration/credential-management/configure-credential-brokering) \ No newline at end of file +- [Configure a target for credential brokering](/boundary/docs/credentials/configure-credential-brokering) +- [Configure a target for credential injection](/boundary/docs/credentials/configure-credential-brokering) \ No newline at end of file diff --git a/website/content/docs/configuration/credential-management/static-cred-vault.mdx b/website/content/docs/credentials/static-cred-vault.mdx similarity index 91% rename from website/content/docs/configuration/credential-management/static-cred-vault.mdx rename to website/content/docs/credentials/static-cred-vault.mdx index 4035731a5..64bc5004e 100644 --- a/website/content/docs/configuration/credential-management/static-cred-vault.mdx +++ b/website/content/docs/credentials/static-cred-vault.mdx @@ -7,7 +7,7 @@ description: >- # Create a Vault credential store -You can manage credentials in Boundary using [credential stores](/boundary/docs/concepts/domain-model/credential-stores), which are resources that store credentials for various targets. +You can manage credentials in Boundary using [credential stores](/boundary/docs/domain-model/credential-stores), which are resources that store credentials for various targets. Vault credential stores point to a HashiCorp Vault instance, which provides capabilities like generating short-lived dynamic credentials. ## Requirements @@ -32,7 +32,7 @@ Complete the following steps to create a Vault credential store: 1. Provide a name for your credential store and select type **Vault**. 1. Complete the fields related to your Vault instance: - **Address** - The address of your Vault instance. - - **Worker Filter** (optional) - If your Vault instance does not have a publicly accessible address and instead is proxied through a Boundary worker, enter the worker filter. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to the examples in the [Worker tags](/boundary/docs/concepts/filtering/worker-tags) documentation. + - **Worker Filter** (optional) - If your Vault instance does not have a publicly accessible address and instead is proxied through a Boundary worker, enter the worker filter. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to the examples in the [Worker tags](/boundary/docs/workers/worker-tags) documentation. - **Token** - Token provided by Vault that provides access to the static credentials within your Vault instance. - **Namespace** (optional) - Vault namespace. Requires Vault Enterprise. - **TLS Server Name** (optional) - Name to use as the SNI host if you connect to Vault via TLS. @@ -95,11 +95,15 @@ Complete the following steps to create a Vault credential store: +## More information + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. + ## Next steps Once you have created a credential store, you can configure targets for credential brokering or credential injection. When you use credential brokering, Boundary centrally manages credentials and returns them to the user when they attempt to connect to a target. Credential injection requires HCP Boundary or Boundary Enterprise, and it provides end users with a passwordless experience when they connect to targets. -- [Configure a target for credential brokering](/boundary/docs/configuration/credential-management/configure-credential-brokering) -- [Configure a target for credential injection](/boundary/docs/configuration/credential-management/configure-credential-brokering) \ No newline at end of file +- [Configure a target for credential brokering](/boundary/docs/credentials/configure-credential-brokering) +- [Configure a target for credential injection](/boundary/docs/credentials/configure-credential-brokering) \ No newline at end of file diff --git a/website/content/docs/install-boundary/configure-controllers.mdx b/website/content/docs/deploy/self-managed/configure-controllers.mdx similarity index 93% rename from website/content/docs/install-boundary/configure-controllers.mdx rename to website/content/docs/deploy/self-managed/configure-controllers.mdx index ff3dc438f..0f131842f 100644 --- a/website/content/docs/install-boundary/configure-controllers.mdx +++ b/website/content/docs/deploy/self-managed/configure-controllers.mdx @@ -50,7 +50,7 @@ If you do not add a BSR key to your controller configuration, you receive an err There are other optional KMS keys that you can configure for different encryption scenarios. These scenarios include Boundary worker PKI auth encryption and Boundary worker or controller configuration encryption. -Refer to [Data security in Boundary](/boundary/docs/concepts/security/data-encryption) for more information. +Refer to [Data encryption in Boundary](/boundary/docs/secure/encryption/data-encryption) for more information. There are two types of Boundary workers, distinguished by the method by which they authenticate with the Boundary controllers. @@ -68,7 +68,7 @@ After you create the keys in Vault or the key management system of your choice, Boundary manages its state and configuration in a Relational Database Management System (RDBMS), PostgreSQL. You should create, set up, and make the PostgreSQL database accessible to the Boundary controller nodes before you configure the nodes. -Refer to the [Database recommendations](/boundary/docs/install-boundary/system-requirements#database-recommendations) documentation for examples of cloud managed PostgreSQL databases. +Refer to the [Database recommendations](/boundary/docs/architecture/system-requirements#database-recommendations) documentation for examples of cloud managed PostgreSQL databases. ## Create the controller configuration @@ -285,7 +285,7 @@ If present, `boundary server` starts a controller subprocess. The example events configuration above is exhaustive and writes all events to both `stderr` and a file. This configuration may or may not work for your organization's logging solution. -- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/concepts/security/data-encryption). +- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/secure/encryption/data-encryption). Refer to the links below for configuration information for the different cloud KMS blocks: @@ -338,11 +338,13 @@ Run the following commands to start the service: Upon logging in to Boundary for the first time, HashiCorp recommends creating an admin user for the global and project level scopes to manage Boundary. Creating an admin user allows you to configure targets within those scopes and manage them. -HashiCorp recommends that you use the [KMS recovery workflow](/boundary/docs/install-boundary/initialize#log-in-with-recovery-kms) to log in to Boundary for the first time. -Refer to [Creating your first login account](/boundary/docs/install-boundary/initialize#create-your-first-login-account) to learn about setting up your first auth method, user, account, and role to log in to Boundary going forward without the recovery KMS workflow. +HashiCorp recommends that you use the [KMS recovery workflow](/boundary/docs/deploy/self-managed/initialize#log-in-with-recovery-kms) to log in to Boundary for the first time. +Refer to [Creating your first login account](/boundary/docs/deploy/self-managed/initialize#create-your-first-login-account) to learn about setting up your first auth method, user, account, and role to log in to Boundary going forward without the recovery KMS workflow. -After configuring the controller, you should: +## Next steps -- [Configure Boundary workers](/boundary/docs/install-boundary/configure-workers) -- [Initialize Boundary](/boundary/docs/install-boundary/initialize) -- [Install the Boundary Clients](/boundary/docs/install-boundary/install-clients) \ No newline at end of file +After you configure the controller, you should: + +1. [Deploy workers](/boundary/docs/deploy/self-managed/deploy-workers) +1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize) +1. [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients) \ No newline at end of file diff --git a/website/content/docs/deploy/self-managed/deploy-workers.mdx b/website/content/docs/deploy/self-managed/deploy-workers.mdx new file mode 100644 index 000000000..6a60e4cbf --- /dev/null +++ b/website/content/docs/deploy/self-managed/deploy-workers.mdx @@ -0,0 +1,278 @@ +--- +layout: docs +page_title: Deploy workers +description: >- + Configure Boundary workers for a self-managed deployment, including environment files and KMS keys. Set up ingress, intermediary, and egress roles for multi-hop. +--- + +# Deploy workers + +Before you deploy workers, you should have completed the following steps: + +- Installed Boundary on at least three [controller nodes](/boundary/docs/deploy/self-managed/configure-controllers). +- Prepared or have three existing network boundaries: + - Public/DMZ network + - Intermediary network + - Private network +- Prepared three virtual machines for Boundary workers, one in each network boundary with the Boundary binary installed on it. + +In the following configuration files, there are common configuration components as well as some unique components depending on the role the Boundary worker performs. +There are three files, one for each worker in a unique network boundary. +Additionally, Boundary Enterprise supports a [multi-hop configuration](/boundary/docs/workers/multi-hop) in which the Boundary workers can serve one of three purposes: an ingress worker, an ingress/egress worker, or an egress worker. + +## Prepare the environment files + +HashiCorp recommends using either the `env://` or `file://` notation within the configuration files, to securely provide secret configuration components to the Boundary worker binaries. +The following configuration example uses `env://` to secure AWS KMS configuration items. + +When you install the Boundary binary using a package manager, it includes a unit file which configures an environment file at `/etc/boundar.d/boundary.env`. +You can use this file to set the sensitive values that are used to configure the Boundary workers. +The following file is an example of how this environment file could be configured: + + + +```shell-session +AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE +AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY +``` + + + +In the example above, the proper IAM roles and permissions for the given `AWS_ACCESS_KEY` and `AWS_SECRET_ACCESS_KEY` must be in place so that Boundary can use them to access the different KMS keys. + +## Prepare the worker KMS keys + +The worker-auth storage KMS key is used by a Worker for the encrypted storage of authentication keys. +This is recommended Workers using controller-led or worker-led methods. If it is not specified, the authentication keys are not encrypted on disk. +Optionally, if you deploy KMS authentication-driven Boundary workers, an additional KMS key must be generated to authenticate the Boundary worker with the controller. + +HashiCorp strongly recommends using the Key Management System (KMS) of the cloud provider where you deploy your Boundary workers. +Keep in mind that Boundary workers must have the correct level of permissions for interacting with the cloud provider's KMS. +Refer to your cloud provider's documentation, for more information. + +## Create the worker configurations + +After you create the requisite key or keys in the cloud provider of your choice, you can begin configuring the workers. + +The following configuration examples all employ the worker-led authorization flow. +For more information on configuring KMS authentication for Boundary workers, refer to the [KMS authentication configuration documenation](/boundary/docs/workers/registration#kms-configuration). + +If you use Boundary Enterprise, you can configure multiple workers to act in three different roles: ingress, intermediary, and egress. +For Community Edition, workers only serve one role, acting as both the point of ingress and egress. +Select your Boundary edition, and complete the following steps to configure workers. + + + + +For Boundary Enterprise, you can configure ingress, intermediary, and egress workers to take advantage of [multi-hop worker capabilities](/boundary/docs/workers#multi-hop-sessions). + +Note that "ingress," "intermediary," and "egress" are general ways to describe how the respective worker interacts with resources. +A worker can serve more than one of those roles at a time. +Refer to [Multi-hop sessions](/boundary/docs/workers/multi-hop) for more information. + +Complete the steps below to configure workers for Boundary Enterprise. + +### Ingress worker configuration + +@include '/workers/ingress-worker-config.mdx' + +### Intermediate worker configuration + +@include '/workers/intermediate-worker-config.mdx' + +### Egress worker configuration + +@include '/workers/egress-worker-config.mdx' + + + + +For the Community Edition of Boundary, you must configure a worker server that communicates with the controller and is responsible for storage-related tasks. + +Boundary Community Edition only supports egress workers. To configure workers for multi-hop sessions, check the Boundary Enterprise configuration. + +Complete the following steps to configure the worker. + +### Worker configuration + +@include '/workers/single-worker-config.mdx' + + + + + +## Start the Boundary service + +When the configuration files are in place on each Boundary controller, you can proceed to enable and start the binary on each of the Boundary worker nodes using `systemd`. +Run the following commands to start the service: + +1. `sudo systemctl enable boundary` +1. `sudo systemctl start boundary` + +## Adopt the workers (optional) + +If you use the workers as outlined above, you must adopt the Boundary workers. +Complete the following steps to adopt the workers: + + + + + +Complete the following steps to adopt the worker using the UI: + +1. Log in to Boundary as the admin user. + +1. Select **Workers** in the navigation pane. + +1. Click **New**. + +1. (Optional) You can use the workers page to construct the contents of the `worker.hcl` file, if you did not [create the configuration file](/boundary/docs/deploy/self-managed/deploy-workers#create-the-worker-configurations) as part of the installation process above. +Provide the following details, and Boundary constructs the worker configuration file for you: + - Boundary Cluster ID + - Worker Public Address + - Config file path + - Worker Tags + +1. Scroll to the bottom of the **New Worker** page, and paste the **Worker Auth Registration Request** key. +Boundary provides you with the **Worker Auth Registration Request** key in the CLI output when you start the worker. +You can also locate this value in the `auth_request_token` file. + +1. Click **Register Worker**. + +1. Click **Done**. + + The new worker appears on the **Workers** page. + +1. Repeat the registration process for any other workers, such as the intermediate and egress workers. + + + + + +Complete the following steps to adopt the worker using the CLI: + +1. Use the following command to ensure that the `BOUNDARY_ADDR` is set as an environment variable: + + ```hcl + $ export BOUNDARY_ADDR="https://c3a7a20a-f663-40f3-a8e3-1b2f69b3625.boundary.hashicorp.cloud" + ``` + +1. Log into the CLI as the admin user, providing the Auth Method ID, admin login name, and admin password when prompted. + + ```hcl + $ boundary authenticate password \ + -auth-method-id=ampw_KfLAjMS2CG \ + -login-name=admin + ``` + + Example: + + + + ```hcl + $ boundary authenticate password \ + -auth-method-id=ampw_KfLAjMS2CG \ + -login-name=admin + Please enter the password (it will be hidden): + + Authentication information: + Account ID: acctpw_r6crEm0FgM + Auth Method ID: ampw_KfLAjMS2CG + Expiration Time: Mon, 27 Jun 2022 22:03:28 MDT + User ID: u_ysJd0LXX9T + + The token was successfully stored in the chosen keyring and is not displayed here. + ``` + + + +1. Next, use the following command to export the **Worker Auth Request Token** value as an environment variable: + + ```shell-session + $ export WORKER_TOKEN= + ``` + + Boundary provides you with the **Worker Auth Registration Request** key in the CLI output when you start the worker. + You can also locate this value in the `auth_request_token` file. + + The token is used to issue a create worker request that authorizes the worker to Boundary and makes it available. + Currently worker creation is only supported for workers with an authorization token (worker-led and controller-led). + +1. Create a new worker using the worker-led registration method with the following command: + + ```shell-session + $ boundary workers create worker-led -worker-generated-auth-token=$WORKER_TOKEN + + Worker information: + Active Connection Count: 0 + Created Time: Fri, 03 Jan 2025 13:52:04 MST + ID: w_zLGjAbYx1h + Local Storage State: unknown + Type: pki + Updated Time: Fri, 03 Jan 2025 13:52:04 MST + Version: 1 + + Scope: + ID: global + Name: global + Type: global + + Authorized Actions: + no-op + read + update + delete + add-worker-tags + set-worker-tags + remove-worker-tags + ``` + + Confirm the worker registration and view its details by executing the following command and supplying the new worker's id: + + ```shell-session + $ boundary workers read -id w_zLGjAbYx1h + + Worker information: + Active Connection Count: 0 + Address: 127.0.0.1:9202 + Created Time: Fri, 03 Jan 2025 13:52:04 MST + ID: w_zLGjAbYx1h + Last Status Time: 2025-01-03 20:58:41.346537 +0000 UTC + Local Storage State: not configured + Release Version: Boundary v0.18.1+ent + Type: pki + Updated Time: Fri, 03 Jan 2025 13:58:41 MST + Version: 1 + + Scope: + ID: global + Name: global + Type: global + + Tags: + Configuration: + type: ["worker1" "upstream"] + Canonical: + type: ["upstream" "worker1"] + + Authorized Actions: + add-worker-tags + set-worker-tags + remove-worker-tags + no-op + read + update + delete + ``` + +1. Repeat the registration process for any other workers, such as the intermediate and egress workers. + + + + +## Next steps + +After you configure workers, you should: + +1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize) +1. [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients) \ No newline at end of file diff --git a/website/content/docs/deploy/self-managed/index.mdx b/website/content/docs/deploy/self-managed/index.mdx new file mode 100644 index 000000000..ee5e486a0 --- /dev/null +++ b/website/content/docs/deploy/self-managed/index.mdx @@ -0,0 +1,51 @@ +--- +layout: docs +page_title: Deploy Boundary in a self-managed environment +description: >- + Discover resources for deploying a self-managed version of Boundary Enterprise or Boundary Community Edition. +--- + +# Deploy Boundary in a self-managed environment + +To deploy a self-managed Boundary environment you should: + +1. Install the Boundary binary +1. Deploy and configure Boundary controllers and workers +1. Install end-user clients + +This guide outlines the required steps to manually install and configure a +single self-managed HashiCorp Boundary cluster as defined in the Recommended +architecture topic. +It assumes you install Boundary on virtual machines (VMs) or bare-metal servers +running a Debian or Red Hat-based Linux distribution. + +To deploy HCP Boundary instead, refer to the [Deploy and log in](/boundary/docs/hcp/get-started/deploy-and-login) in the HCP Boundary Get started documentation. + +This document includes general guidance as well as specific recommendations for +popular cloud infrastructure platforms. These recommendations have also been +encoded into official Terraform reference architectures for +[AWS](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/aws), +[Azure](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/azure), +and +[GCP](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/gcp). + +## More information + +Before you begin, you may want to review the following information about Boundary's architecture and system requirements: + +- [System requirements](/boundary/docs/architecture/system-requirements) +- [Recommended architecture](/boundary/docs/architecture/recommended-architecture) +- [Fault tolerance](/boundary/docs/architecture/fault-tolerance) +- [High availability](/boundary/docs/architecture/high-availability) + +## Next steps + +Refer to the following topics to deploy your self-managed environment: + +1. [Install Boundary](/boundary/docs/deploy/self-managed/install) +1. [Configure controllers](/boundary/docs/deploy/self-managed/configure-controllers) +1. [Deploy workers](/boundary/docs/deploy/self-managed/deploy-workers) +1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize) +1. [Install Boundary clients](/boundary/docs/deploy/self-managed/install-clients) + +To configure Boundary resources using Terraform, refer to [Terraform patterns](/boundary/docs/deploy/terraform-patterns). \ No newline at end of file diff --git a/website/content/docs/install-boundary/initialize.mdx b/website/content/docs/deploy/self-managed/initialize.mdx similarity index 97% rename from website/content/docs/install-boundary/initialize.mdx rename to website/content/docs/deploy/self-managed/initialize.mdx index d12831687..b2e5910e6 100644 --- a/website/content/docs/install-boundary/initialize.mdx +++ b/website/content/docs/deploy/self-managed/initialize.mdx @@ -10,11 +10,11 @@ description: >- This document describes how to access Boundary for the first time and create the necessary resources to log in as a user. -You can also initialize and manage Boundary using Terraform. Refer to the [Terraform patterns](/boundary/docs/install-boundary/terraform-patterns) page to learn more. +You can also initialize and manage Boundary using Terraform. Refer to the [Terraform patterns](/boundary/docs/deploy/terraform-patterns) page to learn more. ## Requirements -Before you initialize Boundary, you should have [initialized a database](/boundary/docs/install-boundary/configure-controllers#initialize-the-database). +Before you initialize Boundary, you should have [initialized a database](/boundary/docs/deploy/self-managed/configure-controllers#initialize-the-database). ## Log in with recovery KMS @@ -463,8 +463,6 @@ boundary authenticate password \ -auth-method-id ``` -After initializing Boundary, you should: +## Next steps -Next, you should: - -- [Install the Boundary Clients](/boundary/docs/install-boundary/install-clients) \ No newline at end of file +After you initialize Boundary, you should [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients). \ No newline at end of file diff --git a/website/content/docs/install-boundary/install-clients.mdx b/website/content/docs/deploy/self-managed/install-clients.mdx similarity index 73% rename from website/content/docs/install-boundary/install-clients.mdx rename to website/content/docs/deploy/self-managed/install-clients.mdx index 0dc4385a6..d5a99627a 100644 --- a/website/content/docs/install-boundary/install-clients.mdx +++ b/website/content/docs/deploy/self-managed/install-clients.mdx @@ -11,7 +11,7 @@ Boundary end users access infrastructure targets using the Boundary Desktop Clie This guide outlines the required steps to manually install and configure a Boundary client depending on which distribution of Boundary end users access. -To learn about installing the Boundary binary when you deploy Boundary controllers or workers, refer to the [Deploy Boundary](/boundary/docs/install-boundary/deploy) page. +To learn about installing the Boundary binary when you deploy Boundary controllers or workers, refer to the [Install Boundary](/boundary/docs/deploy/self-managed/install) page. Select your Boundary distribution, and complete the steps to install the correct clients: @@ -27,7 +27,7 @@ The Boundary installer bundles together the following components: - Boundary Desktop Client app - Boundary Client Agent HCP/ENT -Download the appropriate Boundary installer for your Windows, MacOS, or Linux environment from the [Install Boundary](/boundary/install#installer) page or the [releases](https://releases.hashicorp.com/boundary-installer) page. You can also download the components individually, but compatibility is not guaranteed. Refer to the [Supported versions policy](/boundary/docs/enterprise/supported-versions#control-plane-and-client-cli-compatibility) to learn more. +Download the appropriate Boundary installer for your Windows, MacOS, or Linux environment from the [Install Boundary](/boundary/install#installer) downloads page or the [releases](https://releases.hashicorp.com/boundary-installer) page. You can also download the components individually, but compatibility is not guaranteed. Refer to the [Supported versions policy](/boundary/docs/enterprise/supported-versions#control-plane-and-client-cli-compatibility) to learn more. @@ -45,11 +45,11 @@ We recommend the following components for end users: - Boundary binary (CLI) - Boundary Desktop Client app -Download these components for your Windows, MacOS, or Linux environment from the [Install Boundary](/boundary/install) page or the [HashiCorp releases](https://releases.hashicorp.com/) page. +Download these components for your Windows, MacOS, or Linux environment from the [Install Boundary](/boundary/install) downloads page or the [HashiCorp releases](https://releases.hashicorp.com/) page. -Client compatibility is not guaranteed. You should always ensure that your client is compatible with the version of the Boundary control plane you are connecting to. Refer to the [Supported versions policy](/boundary/docs/enterprise/supported-versions#control-plane-and-client-cli-compatibility) to learn more. +Client compatibility is not guaranteed. You should always ensure that your client is compatible with the version of the Boundary control plane you connect to. Refer to the [Supported versions policy](/boundary/docs/enterprise/supported-versions#control-plane-and-client-cli-compatibility) to learn more. diff --git a/website/content/docs/install-boundary/deploy.mdx b/website/content/docs/deploy/self-managed/install.mdx similarity index 74% rename from website/content/docs/install-boundary/deploy.mdx rename to website/content/docs/deploy/self-managed/install.mdx index 25dedec7a..b2c756e63 100644 --- a/website/content/docs/install-boundary/deploy.mdx +++ b/website/content/docs/deploy/self-managed/install.mdx @@ -1,32 +1,11 @@ --- layout: docs -page_title: Deploy Boundary +page_title: Install Boundary description: >- Deploy a self-managed version of Boundary Enterprise or Community Edition on Ubuntu/Debian, CentOS/RHEL, or Amazon Linux by installing the binary file. --- -# Deploy Boundary - -To deploy a self-managed Boundary environment you should: - -1. Deploy and configure Boundary controllers and workers -2. Install end-user clients - -This guide outlines the required steps to manually install and configure a -single HashiCorp Boundary cluster as defined in the [Recommended -architecture](/boundary/docs/install-boundary/recommended-architecture) topic. -It assumes you install Boundary on virtual machines (VMs) or bare-metal servers -running a Debian or Red Hat-based Linux distribution. - -To learn about installing end-user clients, refer to the [Install Boundary clients](/boundary/docs/install-boundary/install-clients) page. - -This document includes general guidance as well as specific recommendations for -popular cloud infrastructure platforms. These recommendations have also been -encoded into official Terraform reference architectures for -[AWS](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/aws), -[Azure](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/azure), -and -[GCP](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/gcp). +# Install Boundary Pre-built Boundary packages are available from the [HashiCorp Linux Repository](https://www.hashicorp.com/blog/announcing-the-hashicorp-linux-repository). @@ -203,11 +182,13 @@ binary: -You should install the binary on the controller and worker instances you configure to run in your Boundary environments. +You should install the binary on the controller and worker instances you configure to run in your Boundary environments. -Next, you should: +## Next steps -- [Configure Boundary controllers](/boundary/docs/install-boundary/configure-controllers) -- [Configure Boundary workers](/boundary/docs/install-boundary/configure-workers) -- [Initialize Boundary](/boundary/docs/install-boundary/initialize) -- [Install the Boundary Clients](/boundary/docs/install-boundary/install-clients) \ No newline at end of file +After you install the binary, you should: + +1. [Configure controllers](/boundary/docs/deploy/self-managed/configure-controllers) +1. [Deploy workers](/boundary/docs/deploy/self-managed/deploy-workers) +1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize) +1. [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients) \ No newline at end of file diff --git a/website/content/docs/install-boundary/systemd.mdx b/website/content/docs/deploy/self-managed/systemd.mdx similarity index 97% rename from website/content/docs/install-boundary/systemd.mdx rename to website/content/docs/deploy/self-managed/systemd.mdx index 2cd760c7e..4b2c00a3c 100644 --- a/website/content/docs/install-boundary/systemd.mdx +++ b/website/content/docs/deploy/self-managed/systemd.mdx @@ -13,7 +13,7 @@ This section covers how to install Boundary under the [systemd](https://systemd. `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. -1. `/etc/boundary-${TYPE}.hcl`: Configuration file for the boundary service. +1. `/etc/boundary.d/boundary-${TYPE}.hcl`: Configuration file for the boundary service. 2. `/usr/local/bin/boundary`: The Boundary binary, which can be built from the [source](https://github.com/hashicorp/boundary) or downloaded from our [release page](/boundary/downloads). diff --git a/website/content/docs/install-boundary/terraform-patterns/index.mdx b/website/content/docs/deploy/terraform-patterns/index.mdx similarity index 65% rename from website/content/docs/install-boundary/terraform-patterns/index.mdx rename to website/content/docs/deploy/terraform-patterns/index.mdx index 700331926..aeabf0520 100644 --- a/website/content/docs/install-boundary/terraform-patterns/index.mdx +++ b/website/content/docs/deploy/terraform-patterns/index.mdx @@ -15,8 +15,8 @@ This following topics outline MVP (Minimum Viable Product) patterns to deploy an This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. ## Terraform provider configuration @@ -55,10 +55,10 @@ The following pages provide examples and patterns for configuring Boundary resou If you are configuring Boundary resources for the first time, you may want to start by creating a scope. You create scopes to partition resources and then assign ownership of those resources to users and groups. -- [Scopes](/boundary/docs/install-boundary/terraform-patterns/terraform-scopes) -- [Users and auth methods](/boundary/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods) -- [Groups and role-based-access-control (RBAC)](/boundary/docs/install-boundary/terraform-patterns/terraform-groups-and-rbac) -- [Hosts and host management](/boundary/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management) -- [Credentials and credential stores](/boundary/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores) -- [Session recording](/boundary/docs/install-boundary/terraform-patterns/terraform-session-recording) -- [Targets](/boundary/docs/install-boundary/terraform-patterns/terraform-targets) \ No newline at end of file +- [Scopes](/boundary/docs/deploy/terraform-patterns/terraform-scopes) +- [Users and auth methods](/boundary/docs/deploy/terraform-patterns/terraform-users-and-auth-methods) +- [Groups and role-based-access-control (RBAC)](/boundary/docs/deploy/terraform-patterns/terraform-groups-and-rbac) +- [Hosts and host management](/boundary/docs/deploy/terraform-patterns/terraform-hosts-and-host-management) +- [Credentials and credential stores](/boundary/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores) +- [Session recording](/boundary/docs/deploy/terraform-patterns/terraform-session-recording) +- [Targets](/boundary/docs/deploy/terraform-patterns/terraform-targets) \ No newline at end of file diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores.mdx b/website/content/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores.mdx similarity index 86% rename from website/content/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores.mdx index 40e8030e2..df580a5e0 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Terraform patterns for Boundary credentials and credential stores +page_title: Terraform patterns for credentials and credential stores description: >- Use Terraform patterns to create and manage Boundary credentials and credential stores. Learn how to create static or Vault credential stores, add credentials. --- -# Terraform patterns for Boundary credentials and credential stores +# Terraform patterns for credentials and credential stores Boundary supports multiple types of static credentials and Vault dynamic credentials. A credential store stores credentials for hosts. Static credential stores can hold username/passwords, JSON tokens, SSH key pairs, and SSH certificates. @@ -13,10 +13,10 @@ Boundary supports multiple types of static credentials and Vault dynamic credent This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). -- Configured [hosts](/boundary/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management) for any credential store you plan to create. +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). +- Configured [hosts](/boundary/docs/deploy/terraform-patterns/terraform-hosts-and-host-management) for any credential store you plan to create. ## Static credential store configuration @@ -177,9 +177,9 @@ resource "boundary_credential_library_vault_ssh_certificate" "example" { For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Credential stores](/boundary/docs/concepts/domain-model/credential-stores) -- [Credentials](/boundary/docs/concepts/domain-model/credentials) -- [Credential libraries](/boundary/docs/concepts/domain-model/credential-libraries) +- [Credential stores](/boundary/docs/domain-model/credential-stores) +- [Credentials](/boundary/docs/domain-model/credentials) +- [Credential libraries](/boundary/docs/domain-model/credential-libraries) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: @@ -196,4 +196,4 @@ For more information about managing the following resources using Terraform, ref ## Next steps -Once you have configured credentials and credential stores, you may want to enable [session recording](/boundary/docs/install-boundary/terraform-patterns/terraform-session-recording) for auditing purposes or configure [targets](/boundary/docs/install-boundary/terraform-patterns/terraform-targets) for your users to connect to. \ No newline at end of file +Once you have configured credentials and credential stores, you may want to enable [session recording](/boundary/docs/deploy/terraform-patterns/terraform-session-recording) for auditing purposes or configure [targets](/boundary/docs/deploy/terraform-patterns/terraform-targets) for your users to connect to. \ No newline at end of file diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-groups-and-rbac.mdx b/website/content/docs/deploy/terraform-patterns/terraform-groups-and-rbac.mdx similarity index 78% rename from website/content/docs/install-boundary/terraform-patterns/terraform-groups-and-rbac.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-groups-and-rbac.mdx index 7c9a7ada0..b20e58ad8 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-groups-and-rbac.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-groups-and-rbac.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Terraform patterns for Boundary groups and RBAC +page_title: Terraform patterns for groups and RBAC description: >- Use Terraform patterns to create and manage Boundary groups and role-based access control (RBAC). Learn how to add users to managed groups and assign roles. --- -# Terraform patterns for Boundary groups and RBAC +# Terraform patterns for groups and RBAC The following pattern demonstrates how to aggregate users into groups. @@ -17,10 +17,10 @@ In Boundary, you can assign users directly to a role, but a better pattern is to This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). -- Created Boundary [users and auth methods](/boundary/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods) to assign to the group you plan to create. +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). +- Created Boundary [users and auth methods](/boundary/docs/deploy/terraform-patterns/terraform-users-and-auth-methods) to assign to the group you plan to create. ## Group configuration @@ -78,10 +78,10 @@ resource "boundary_role" "readonly" { For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Roles](/boundary/docs/concepts/domain-model/roles) -- [Groups](/boundary/docs/concepts/domain-model/groups) -- [Managed groups](/boundary/docs/concepts/domain-model/managed-groups) -- [Grants](/boundary/docs/concepts/security/permissions#grant-strings) +- [Roles](/boundary/docs/domain-model/roles) +- [Groups](/boundary/docs/domain-model/groups) +- [Managed groups](/boundary/docs/domain-model/managed-groups) +- [Grants](/boundary/docs/rbac#grant-strings) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: @@ -96,5 +96,5 @@ For more information about managing the following resources using Terraform, ref ## Next steps -You may want to create [hosts and host sets](/boundary/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management) so that you can configure targets for your users to connect to. +You may want to create [hosts and host sets](/boundary/docs/deploy/terraform-patterns/terraform-hosts-and-host-management) so that you can configure targets for your users to connect to. Targets require an address or host, and credentials to connect to that host. \ No newline at end of file diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management.mdx b/website/content/docs/deploy/terraform-patterns/terraform-hosts-and-host-management.mdx similarity index 84% rename from website/content/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-hosts-and-host-management.mdx index bf41a985e..301267443 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-hosts-and-host-management.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Terraform patterns for Boundary hosts and host management +page_title: Terraform patterns for hosts and host management description: >- Use Terraform patterns to create and manage Boundary hosts and host catalogs. Learn how to add static or plugin-based hosts to static or dynamic host catalogs. --- -# Terraform patterns for Boundary hosts and host management +# Terraform patterns for hosts and host management Before you can access a system, you must create a target. Targets require an address or host, and credentials to connect to that host. @@ -16,9 +16,9 @@ Instead, HashiCorp recommends adding hosts to a host set, and then attaching the This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). ## Static host catalog configuration @@ -134,10 +134,10 @@ resource "boundary_host_set_plugin" "web" { For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Targets](/boundary/docs/concepts/domain-model/targets) -- [Hosts](/boundary/docs/concepts/domain-model/hosts) -- [Host sets](/boundary/docs/concepts/domain-model/host-sets) -- [Host catalogs](/boundary/docs/concepts/domain-model/host-catalogs) +- [Targets](/boundary/docs/domain-model/targets) +- [Hosts](/boundary/docs/domain-model/hosts) +- [Host sets](/boundary/docs/domain-model/host-sets) +- [Host catalogs](/boundary/docs/domain-model/host-catalogs) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: @@ -147,6 +147,8 @@ For more information about managing the following resources using Terraform, ref - [Plugin-based host catalogs](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs/resources/host_catalog_plugin/) - [Plugin-based host sets](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs/resources/host_set_plugin/) +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. + ## Next steps -Once you have configured hosts, you may want to configure [credentials and credential stores](/boundary/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores) for your hosts and users. \ No newline at end of file +Once you have configured hosts, you may want to configure [credentials and credential stores](/boundary/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores) for your hosts and users. \ No newline at end of file diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-scopes.mdx b/website/content/docs/deploy/terraform-patterns/terraform-scopes.mdx similarity index 69% rename from website/content/docs/install-boundary/terraform-patterns/terraform-scopes.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-scopes.mdx index e13f83178..6e692cdf9 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-scopes.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-scopes.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Terraform patterns for Boundary scopes +page_title: Terraform patterns for scopes description: >- Use Terraform patterns to create and manage Boundary scopes. Learn how to configure global, org-level, and project-level scopes using the Boundary provider. --- -# Terraform patterns for Boundary scopes +# Terraform patterns for scopes You can use the following patterns to create org-level and project-level scopes. @@ -13,9 +13,9 @@ You can use the following patterns to create org-level and project-level scopes. This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). ## Scopes configuration @@ -45,9 +45,9 @@ resource "boundary_scope" "project" { For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Scopes](/boundary/docs/concepts/domain-model/scopes) -- [Org-level scopes](/boundary/docs/concepts/domain-model/scopes#organizations) -- [Project-level scopes](/boundary/docs/concepts/domain-model/scopes#projects) +- [Scopes](/boundary/docs/domain-model/scopes) +- [Org-level scopes](/boundary/docs/domain-model/scopes#organizations) +- [Project-level scopes](/boundary/docs/domain-model/scopes#projects) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: @@ -56,4 +56,4 @@ For more information about managing the following resources using Terraform, ref ## Next steps You use scopes to partition resources and assign them to users. -Once you have created scopes, you may want to create [users and auth methods](/boundary/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods). \ No newline at end of file +Once you have created scopes, you may want to create [users and auth methods](/boundary/docs/deploy/terraform-patterns/terraform-users-and-auth-methods). \ No newline at end of file diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-session-recording.mdx b/website/content/docs/deploy/terraform-patterns/terraform-session-recording.mdx similarity index 77% rename from website/content/docs/install-boundary/terraform-patterns/terraform-session-recording.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-session-recording.mdx index a4cb08891..ca0307725 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-session-recording.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-session-recording.mdx @@ -1,24 +1,24 @@ --- layout: docs -page_title: Terraform patterns for Boundary session recording +page_title: Terraform patterns for session recording description: >- Use Terraform patterns to enable session recording for auditing user sessions in Boundary. Learn how to configure storage policies and storage buckets. --- -# Terraform patterns for Boundary session recording +# Terraform patterns for session recording This feature requires HCP Boundary or Boundary Enterprise -Session recording requires that you create a storage policy for your current scope and then allocate an AWS S3 bucket to store the recordings. This example does not demonstrate creating the S3 bucket or the associated IAM policies. Refer to the [create storage buckets](/boundary/docs/configuration/session-recording/create-storage-bucket) documentation to learn how to configure AWS. +Session recording requires that you create a storage policy for your current scope and then allocate an AWS S3 bucket to store the recordings. This example does not demonstrate creating the S3 bucket or the associated IAM policies. Refer to the [create storage buckets](/boundary/docs/session-recording/configuration/create-storage-bucket) documentation to learn how to configure AWS. ## Requirements This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). -- Created a [scope](/boundary/docs/install-boundary/terraform-patterns/terraform-scopes) for any storage policy you plan to create. +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). +- Created a [scope](/boundary/docs/deploy/terraform-patterns/terraform-scopes) for any storage policy you plan to create. - A licensed version of HCP Boundary or Boundary Enterprise. ## Storage policy configuration @@ -75,8 +75,8 @@ You have configured the prerequisites for session recording. The last task is to For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Session recordings](/boundary/docs/concepts/domain-model/session-recordings) -- [Storage buckets](/boundary/docs/concepts/domain-model/storage-buckets) +- [Session recordings](/boundary/docs/domain-model/session-recordings) +- [Storage buckets](/boundary/docs/domain-model/storage-buckets) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: @@ -85,4 +85,4 @@ For more information about managing the following resources using Terraform, ref ## Next steps -Once you have configured the prerequisites for session recording, you can enable recording on a Boundary [target](/boundary/docs/install-boundary/terraform-patterns/terraform-targets). \ No newline at end of file +Once you have configured the prerequisites for session recording, you can enable recording on a Boundary [target](/boundary/docs/deploy/terraform-patterns/terraform-targets). \ No newline at end of file diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-targets.mdx b/website/content/docs/deploy/terraform-patterns/terraform-targets.mdx similarity index 79% rename from website/content/docs/install-boundary/terraform-patterns/terraform-targets.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-targets.mdx index a3472896c..84d7de5cd 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-targets.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-targets.mdx @@ -1,24 +1,24 @@ --- layout: docs -page_title: Terraform patterns for Boundary targets +page_title: Terraform patterns for targets description: >- Use Terraform patterns to create and manage Boundary targets. Learn how to configure SSH and TCP targets, inject passwords, and enable session recording. --- -# Terraform patterns for Boundary targets +# Terraform patterns for targets Once you have defined a host, a host catalog, and a credential store, you -can create [targets](/boundary/docs/concepts/domain-model/targets). +can create [targets](/boundary/docs/domain-model/targets). ## Requirements This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). -- Defined a host, [host catalog](/boundary/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management), and [credential store](/boundary/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores). -- (Optional) Configured a storage policy and storage bucket for any targets you want to enable for [session recording](/boundary/docs/install-boundary/terraform-patterns/terraform-session-recording). +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). +- Defined a host, [host catalog](/boundary/docs/deploy/terraform-patterns/terraform-hosts-and-host-management), and [credential store](/boundary/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores). +- (Optional) Configured a storage policy and storage bucket for any targets you want to enable for [session recording](/boundary/docs/deploy/terraform-patterns/terraform-session-recording). ## Target configuration @@ -118,7 +118,7 @@ resource "boundary_target" "rdp_foo" { For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Targets](/boundary/docs/concepts/domain-model/targets) +- [Targets](/boundary/docs/domain-model/targets) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: diff --git a/website/content/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods.mdx b/website/content/docs/deploy/terraform-patterns/terraform-users-and-auth-methods.mdx similarity index 79% rename from website/content/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods.mdx rename to website/content/docs/deploy/terraform-patterns/terraform-users-and-auth-methods.mdx index c72cae70e..a589a7053 100644 --- a/website/content/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods.mdx +++ b/website/content/docs/deploy/terraform-patterns/terraform-users-and-auth-methods.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Terraform patterns for Boundary users and auth methods +page_title: Terraform patterns for users and auth methods description: >- Use Terraform patterns to create and manage Boundary users and auth methods. Learn how to configure password and LDAP auth methods, add accounts, create users. --- -# Terraform patterns for Boundary users and auth methods +# Terraform patterns for users and auth methods Boundary supports password, OIDC, and LDAP auth methods. @@ -13,10 +13,10 @@ Boundary supports password, OIDC, and LDAP auth methods. This document assumes the reader has: -- An understanding of [Terraform](/terraform/docs) fundamentals -- An existing Boundary installation. Refer to [Initialize Boundary](/boundary/docs/install-boundary/initialize) to learn about deploying Boundary. -- Configured the [Terraform Boundary provider](/boundary/docs/install-boundary/terraform-patterns/#terraform-provider-configuration). -- Created a [scope](/boundary/docs/install-boundary/terraform-patterns/terraform-scopes) to add the users and auth methods to. +- An understanding of [Terraform](/terraform/docs) fundamentals. +- An existing Boundary installation. Refer to [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) to learn about deploying Boundary. +- Configured the [Terraform Boundary provider](/boundary/docs/deploy/terraform-patterns/#terraform-provider-configuration). +- Created a [scope](/boundary/docs/deploy/terraform-patterns/terraform-scopes) to add the users and auth methods to. ## Auth method configuration @@ -92,9 +92,9 @@ resource "boundary_user" "susmitha" { ## More information For more information about the Boundary resources mentioned in this topic, refer to the domain model documentation: -- [Auth methods](/boundary/docs/concepts/domain-model/auth-methods) -- [Users](/boundary/docs/concepts/domain-model/users) -- [Accounts](/boundary/docs/concepts/domain-model/accounts) +- [Auth methods](/boundary/docs/domain-model/auth-methods) +- [Users](/boundary/docs/domain-model/users) +- [Accounts](/boundary/docs/domain-model/accounts) For more information about managing the following resources using Terraform, refer to the Boundary provider documentation: - [LDAP accounts](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs/resources/account_ldap/) @@ -103,4 +103,4 @@ For more information about managing the following resources using Terraform, ref ## Next steps -Once you have created users and auth methods, you may want to create [groups for your users or configure RBAC](/boundary/docs/install-boundary/terraform-patterns/terraform-groups-and-rbac) to define the actions a user is allowed to take. \ No newline at end of file +Once you have created users and auth methods, you may want to create [groups for your users or configure RBAC](/boundary/docs/deploy/terraform-patterns/terraform-groups-and-rbac) to define the actions a user is allowed to take. \ No newline at end of file diff --git a/website/content/docs/concepts/domain-model/accounts.mdx b/website/content/docs/domain-model/accounts.mdx similarity index 81% rename from website/content/docs/concepts/domain-model/accounts.mdx rename to website/content/docs/domain-model/accounts.mdx index d527d5bde..c0d5dd244 100644 --- a/website/content/docs/concepts/domain-model/accounts.mdx +++ b/website/content/docs/domain-model/accounts.mdx @@ -21,7 +21,7 @@ in the same scope as the account's [auth method][]. All account types have the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the account's [auth method][]. + If set, the `name` must be unique within the account's auth method. - `description` - (optional) @@ -30,7 +30,7 @@ All account types have the following configurable attributes: Password account types have the following additional attributes: - `login_name` - (required) - Must be unique within the account's [auth method][]. + Must be unique within the account's auth method. Can only contain lower case letters. - `password` - (optional) @@ -41,7 +41,7 @@ Password account types have the following additional attributes: LDAP account types have the following additional attributes: - `login_name` - (required) - Must be unique within the account's [auth method][]. + Must be unique within the account's auth method. Can only contain lower case letters. - `full_name` - (output only) @@ -65,16 +65,16 @@ LDAP account types have the following additional attributes: ## Referenced by -- [Auth Method][] -- [Managed Group][] +- [Auth method][] +- [Managed group][] - [User][] -[auth method]: /boundary/docs/concepts/domain-model/auth-methods -[managed group]: /boundary/docs/concepts/domain-model/managed-groups -[user]: /boundary/docs/concepts/domain-model/users +[auth method]: /boundary/docs/domain-model/auth-methods +[managed group]: /boundary/docs/domain-model/managed-groups +[user]: /boundary/docs/domain-model/users ## Service API docs The following services are relevant to this resource: -- [Account Service](/boundary/api-docs/account-service) +- [Account service](/boundary/api-docs/account-service) diff --git a/website/content/docs/domain-model/aliases.mdx b/website/content/docs/domain-model/aliases.mdx new file mode 100644 index 000000000..1b86f52f4 --- /dev/null +++ b/website/content/docs/domain-model/aliases.mdx @@ -0,0 +1,36 @@ +--- +layout: docs +page_title: Alias resource +description: >- + Learn about using the alias resource to transparently connect to targets without having to provide the target ID or target name and scope ID. +--- + +# Aliases + +An alias is a globally unique, DNS-like string that is associated with a destination resource. +Examples of valid aliases are `webserver` and `webserver.boundary`. +You can establish a session to a target by referencing its alias, instead of having to provide a target ID or target name and scope ID. +For example, if you have an alias `boundary.dev`, you can use it to connect to a target with the following command: `boundary connect ssh boundary.dev`. + +## Attributes + +Aliases have the following attributes: + +- `-description=` - Specifies the optional description you want to use to describe the alias for identification purposes. +- `-destination-id=` - Specifies the ID of the target that the alias points to. +- `-name=` - Specifies the optional name you want to use to describe the alias for identification purposes. +- `-scope-id=` - Scope in which to create the alias. The default is `global`. + You can also specify the scope using the BOUNDARY_SCOPE_ID environment variable. + At this time, aliases are only supported for the global scope. +- `-value=` - Specifies the string that you want to use as the alias to represent the target. + The `value` must comply with DNS naming rules. + +### Target subtypes + +The target subtype has the following additional attributes: + +- `-authorize-session-host-id=` - Indicates the host ID to use when you use the alias to authorize a session. + +## More information + +- [Aliases](/boundary/docs/concepts/aliases) diff --git a/website/content/docs/concepts/domain-model/auth-methods.mdx b/website/content/docs/domain-model/auth-methods.mdx similarity index 92% rename from website/content/docs/concepts/domain-model/auth-methods.mdx rename to website/content/docs/domain-model/auth-methods.mdx index 02f88eb1b..1b1e9d7c3 100644 --- a/website/content/docs/concepts/domain-model/auth-methods.mdx +++ b/website/content/docs/domain-model/auth-methods.mdx @@ -11,7 +11,7 @@ An auth method is a resource that provides a mechanism for [users][] to authenticate to Boundary. An auth method contains [accounts][] which link an individual user to a set of credentials and [managed groups][] which groups [accounts][] that satisfy criteria and can be used as principals in [roles][]. -Auth methods can be defined at either a [Global][] or [Organization][] +Auth methods can be defined at either a [global][] or [organization][] [scope][]. ## Attributes @@ -205,22 +205,22 @@ The ldap auth method has the following additional attributes: - [Account][] - [Global][] -- [Managed Group][] +- [Managed group][] - [Organization][] -[account]: /boundary/docs/concepts/domain-model/accounts -[accounts]: /boundary/docs/concepts/domain-model/accounts -[global]: /boundary/docs/concepts/domain-model/scopes#global -[managed group]: /boundary/docs/concepts/domain-model/managed-groups -[managed groups]: /boundary/docs/concepts/domain-model/managed-groups -[organization]: /boundary/docs/concepts/domain-model/scopes#organizations -[roles]: /boundary/docs/concepts/domain-model/roles -[scope]: /boundary/docs/concepts/domain-model/scopes -[users]: /boundary/docs/concepts/domain-model/users +[account]: /boundary/docs/domain-model/accounts +[accounts]: /boundary/docs/domain-model/accounts +[global]: /boundary/docs/domain-model/scopes#global +[managed group]: /boundary/docs/domain-model/managed-groups +[managed groups]: /boundary/docs/domain-model/managed-groups +[organization]: /boundary/docs/domain-model/scopes#organizations +[roles]: /boundary/docs/domain-model/roles +[scope]: /boundary/docs/domain-model/scopes +[users]: /boundary/docs/domain-model/users ## Service API docs The following services are relevant to this resource: -- [Auth Method Service](/boundary/api-docs/auth-method-service) -- [Auth Token Service](/boundary/api-docs/auth-token-service) +- [Auth method service](/boundary/api-docs/auth-method-service) +- [Auth token service](/boundary/api-docs/auth-token-service) diff --git a/website/content/docs/concepts/domain-model/credential-libraries.mdx b/website/content/docs/domain-model/credential-libraries.mdx similarity index 86% rename from website/content/docs/concepts/domain-model/credential-libraries.mdx rename to website/content/docs/domain-model/credential-libraries.mdx index afbeefd0a..b6216d8c1 100644 --- a/website/content/docs/concepts/domain-model/credential-libraries.mdx +++ b/website/content/docs/domain-model/credential-libraries.mdx @@ -13,7 +13,7 @@ A credential library is a resource that provides [credentials][] of the same typ A credential library has the following configurable attributes: -- `name` - (optional) If you set this attribute, the `name` must be unique within the credential library's parent [credential store][]. +- `name` - (optional) If you set this attribute, the `name` must be unique within the credential library's parent credential store. - `description` - (optional) A user-defined description of the credential library for identification purposes. @@ -38,7 +38,7 @@ Only valid if `http_method` is set to `POST`. This feature requires HCP Boundary or Boundary Enterprise -As of Boundary 0.12.0, you can configure SSH credential injection using [Vault's SSH secrets engine](/vault/docs/secrets/ssh) to create the SSH certificate credentials. +You can configure SSH credential injection using [Vault's SSH secrets engine](/vault/docs/secrets/ssh) to create the SSH certificate credentials. SSH certificate-based authentication extends key-based authentication using digital signatures. Your users' authenticity is determined by a certificate signed by a trusted certificate authority (CA). You can configure Vault's SSH secrets engine to act as the CA. @@ -83,12 +83,12 @@ For more information, refer to the [list of extensions](https://github.com/opens Note that the `permit-pty` value should be set for an interactive shell to function properly. - `additional_valid_principals` - (optional) Valid Principals that the certificate should be signed for in addition to the provided username. -For more information, refer to OpenSSH's ["valid principals" definition](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L176-L181) as well as Vault's documentation for the [SSH Secrets Engine](https://developer.hashicorp.com/vault/api-docs/secret/ssh#valid_principals). +For more information, refer to OpenSSH's ["valid principals" definition](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L176-L181) as well as Vault's documentation for the [SSH secrets engine](https://developer.hashicorp.com/vault/api-docs/secret/ssh#valid_principals). Note that all SSH certificates issued by a Vault SSH certificate credential library use the `SSH_CERT_TYPE_USER` certificate type mentioned in the OpenSSH definition link. ### Vault credential library parameter templating -Sometimes it can be useful to provide information about a Boundary user or account when making a call to Vault. For example, this can allow picking the correct role when asking for database credentials (if roles are separated per-user), or providing a value to encode in an X.509 certificate generated by Vault. As of Boundary 0.11.1, you can template user and account information into either the path in Vault, the `POST` request body, or both. +Sometimes it can be useful to provide information about a Boundary user or account when making a call to Vault. For example, this can allow picking the correct role when asking for database credentials (if roles are separated per-user), or providing a value to encode in an X.509 certificate generated by Vault. You can template user and account information into either the path in Vault, the `POST` request body, or both. The following Vault template parameters are supported in Boundary. Note that account values are tied to the account associated with the token used to make the call: @@ -127,20 +127,20 @@ Refer to the [SSH certificate injection with HCP Boundary](/boundary/tutorials/c ## Referenced by - [Credential][] -- [Credential Store][] +- [Credential store][] - [Target][] -[credential store]: /boundary/docs/concepts/domain-model/credential-stores -[credential stores]: /boundary/docs/concepts/domain-model/credential-stores -[credential]: /boundary/docs/concepts/domain-model/credentials -[credentials]: /boundary/docs/concepts/domain-model/credentials -[project]: /boundary/docs/concepts/domain-model/scopes#projects -[projects]: /boundary/docs/concepts/domain-model/scopes#projects -[target]: /boundary/docs/concepts/domain-model/targets -[targets]: /boundary/docs/concepts/domain-model/targets +[credential store]: /boundary/docs/domain-model/credential-stores +[credential stores]: /boundary/docs/domain-model/credential-stores +[credential]: /boundary/docs/domain-model/credentials +[credentials]: /boundary/docs/domain-model/credentials +[project]: /boundary/docs/domain-model/scopes#projects +[projects]: /boundary/docs/domain-model/scopes#projects +[target]: /boundary/docs/domain-model/targets +[targets]: /boundary/docs/domain-model/targets ## Service API docs The following services are relevant to this resource: -- [Credential Library Service](/boundary/api-docs/credential-library-service) +- [Credential library service](/boundary/api-docs/credential-library-service) diff --git a/website/content/docs/concepts/domain-model/credential-stores.mdx b/website/content/docs/domain-model/credential-stores.mdx similarity index 85% rename from website/content/docs/concepts/domain-model/credential-stores.mdx rename to website/content/docs/domain-model/credential-stores.mdx index 08b2df045..8be26cea2 100644 --- a/website/content/docs/concepts/domain-model/credential-stores.mdx +++ b/website/content/docs/domain-model/credential-stores.mdx @@ -66,7 +66,7 @@ A Vault credential store has the following additional attributes: A Vault [namespace][]. Requires Vault Enterprise. - `worker_filter` HCP/ENT - (optional) - A [filter] used to control which [workers] can handle Vault requests. + A [filter] used to control which workers can handle Vault requests. This allows the use of private Vault instances with Boundary. Workers deployed in the same network as a private Vault instance can access and relay Vault requests to Boundary controllers. @@ -79,7 +79,7 @@ A static credential store has no type-specific attributes. ## Referenced by -- [Credential Library][] +- [Credential library][] - [Credential][] - [Project][] @@ -87,13 +87,13 @@ A static credential store has no type-specific attributes. The following services are relevant to this resource: -- [Credential Store Service](/boundary/api-docs/credential-store-service) +- [Credential store service](/boundary/api-docs/credential-store-service) -[credential library]: /boundary/docs/concepts/domain-model/credential-libraries -[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries -[credential]: /boundary/docs/concepts/domain-model/credentials -[credentials]: /boundary/docs/concepts/domain-model/credentials -[project]: /boundary/docs/concepts/domain-model/scopes#projects +[credential library]: /boundary/docs/domain-model/credential-libraries +[credential libraries]: /boundary/docs/domain-model/credential-libraries +[credential]: /boundary/docs/domain-model/credentials +[credentials]: /boundary/docs/domain-model/credentials +[project]: /boundary/docs/domain-model/scopes#projects ## Vault token requirements @@ -101,18 +101,18 @@ Each Vault credential store must be configured with a unique Vault token. The Vault tokens for all credential stores 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 Boundary controller policy][token_policy] described below. ### Vault policies The credential store's token must have the capabilities to issue credentials for each of its credential libraries plus the capabilities of the -[Vault Boundary Controller Policy][token_policy] described below. +[Vault Boundary controller policy][token_policy] described below. We recommend creating a unique Vault policy for each Vault credential store that grants the minimum set of permissions needed by the credential store's -libraries. We also recommend the [Vault Boundary Controller -Policy][token_policy] be kept distinct from any other Vault policies. This +libraries. We also recommend the [Vault Boundary controller +policy][token_policy] be kept distinct from any other Vault policies. This allows each credential store to have a token that is configured with two polices: one shared by all credential stores and one unique to that credential store. This also allows a credential store to be created with the minimum @@ -180,12 +180,11 @@ $ vault policy write boundary-controller boundary-controller-policy.hcl 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 types `username_password`, `ssh_private_key`, and `json`. -[token_requirements]: /boundary/docs/concepts/domain-model/credential-stores#vault-token-requirements -[token_policy]: /boundary/docs/concepts/domain-model/credential-stores#vault-boundary-controller-policy +[token_requirements]: /boundary/docs/domain-model/credential-stores#vault-token-requirements +[token_policy]: /boundary/docs/domain-model/credential-stores#vault-boundary-controller-policy [vault]: https://www.vaultproject.io/ [namespace]: /vault/docs/enterprise/namespaces [renewable]: /vault/api-docs/auth/token#renewable-1 [periodic]: /vault/api-docs/auth/token#token_period [orphan]: /vault/api-docs/auth/token#orphan -[workers]: /boundary/docs/configuration/worker/worker-configuration -[filter]: /boundary/docs/concepts/filtering/worker-tags +[filter]: /boundary/docs/workers/worker-tags diff --git a/website/content/docs/concepts/domain-model/credentials.mdx b/website/content/docs/domain-model/credentials.mdx similarity index 74% rename from website/content/docs/concepts/domain-model/credentials.mdx rename to website/content/docs/domain-model/credentials.mdx index 99fefbbcb..cc6cb978a 100644 --- a/website/content/docs/concepts/domain-model/credentials.mdx +++ b/website/content/docs/domain-model/credentials.mdx @@ -9,8 +9,6 @@ description: >- A credential is a data structure containing one or more secrets that binds an identity to a set of permissions or capabilities on a [host][] for a [session][]. -## Credential types - Optionally, credentials can be typed to indicate compliance with a specific format. The following credential types are supported in Boundary: @@ -19,7 +17,7 @@ The following credential types are supported in Boundary: - [SSH certificate](#ssh-certificate) - [JSON](#json) -### Username password +## Username password `username_password` credentials contain the following fields: @@ -27,7 +25,7 @@ The following credential types are supported in Boundary: - `password` - The password field associated with the credential. -### SSH private key +## SSH private key `ssh_private_key` credentials contain the following fields: @@ -35,7 +33,7 @@ The following credential types are supported in Boundary: - `private_key` - The private key field associated with the credential. -### SSH certificate +## SSH certificate `ssh_certificate` credentials contain the following fields: @@ -43,9 +41,9 @@ The following credential types are supported in Boundary: - `ssh_certificate` - The SSH certificate associated with the credential. -### JSON +## JSON -As of Boundary 0.11.0, you can provide credentials using a JSON blob. +You can provide credentials using a JSON blob. JSON credentials are only brokered to users that connect to machines. There is no required structure for the JSON blob, other than it must be a key value map. Refer to the example below: @@ -71,15 +69,15 @@ Refer to the example below: ## Referenced by -- [Credential Store][] -- [Credential Library][] +- [Credential store][] +- [Credential library][] - [Session][] - [Target][] -[credential library]: /boundary/docs/concepts/domain-model/credential-libraries -[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries -[credential store]: /boundary/docs/concepts/domain-model/credential-stores -[credential stores]: /boundary/docs/concepts/domain-model/credential-stores -[host]: /boundary/docs/concepts/domain-model/hosts -[session]: /boundary/docs/concepts/domain-model/sessions -[target]: /boundary/docs/concepts/domain-model/targets +[credential library]: /boundary/docs/domain-model/credential-libraries +[credential libraries]: /boundary/docs/domain-model/credential-libraries +[credential store]: /boundary/docs/domain-model/credential-stores +[credential stores]: /boundary/docs/domain-model/credential-stores +[host]: /boundary/docs/domain-model/hosts +[session]: /boundary/docs/domain-model/sessions +[target]: /boundary/docs/domain-model/targets diff --git a/website/content/docs/concepts/domain-model/groups.mdx b/website/content/docs/domain-model/groups.mdx similarity index 61% rename from website/content/docs/concepts/domain-model/groups.mdx rename to website/content/docs/domain-model/groups.mdx index 5da4dfb2b..8627ba720 100644 --- a/website/content/docs/concepts/domain-model/groups.mdx +++ b/website/content/docs/domain-model/groups.mdx @@ -16,14 +16,14 @@ which allows it to be assigned to [roles][]. Any role assigned to a group is indirectly assigned to the users in the group. This assignment is a transitive property. A user in a group receives all [permissions][] of the roles assigned to the group. -Groups can be defined at the [Global][], [Organization][], or [Project][] [scope][]. +Groups can be defined at the [global][], [organization][], or [project][] [scope][]. ## Attributes A group has the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the group's immediate parent [scope][]. + If set, the `name` must be unique within the group's immediate parent scope. - `description` - (optional) @@ -34,23 +34,23 @@ A group has the following configurable attributes: - [Role][] - [User][] -[global]: /boundary/docs/concepts/domain-model/scopes#global -[group]: /boundary/docs/concepts/domain-model/groups -[groups]: /boundary/docs/concepts/domain-model/groups -[organization]: /boundary/docs/concepts/domain-model/scopes#organizations -[permissions]: /boundary/docs/concepts/security/permissions -[project]: /boundary/docs/concepts/domain-model/scopes#projects -[role]: /boundary/docs/concepts/domain-model/roles -[roles]: /boundary/docs/concepts/domain-model/roles -[scope]: /boundary/docs/concepts/domain-model/scopes -[user]: /boundary/docs/concepts/domain-model/users -[users]: /boundary/docs/concepts/domain-model/users +[global]: /boundary/docs/domain-model/scopes#global +[group]: /boundary/docs/domain-model/groups +[groups]: /boundary/docs/domain-model/groups +[organization]: /boundary/docs/domain-model/scopes#organizations +[permissions]: /boundary/docs/rbac +[project]: /boundary/docs/domain-model/scopes#projects +[role]: /boundary/docs/domain-model/roles +[roles]: /boundary/docs/domain-model/roles +[scope]: /boundary/docs/domain-model/scopes +[user]: /boundary/docs/domain-model/users +[users]: /boundary/docs/domain-model/users ## Service API docs The following services are relevant to this resource: -- [Group Service](/boundary/api-docs/group-service) +- [Group service](/boundary/api-docs/group-service) ## Tutorial diff --git a/website/content/docs/concepts/domain-model/host-catalogs.mdx b/website/content/docs/domain-model/host-catalogs.mdx similarity index 70% rename from website/content/docs/concepts/domain-model/host-catalogs.mdx rename to website/content/docs/domain-model/host-catalogs.mdx index 883af093c..d18e81008 100644 --- a/website/content/docs/concepts/domain-model/host-catalogs.mdx +++ b/website/content/docs/domain-model/host-catalogs.mdx @@ -16,7 +16,7 @@ A host catalog can only be defined within a [project][]. A host catalog has the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the host catalog's [project][]. + If set, the `name` must be unique within the host catalog's project. - `description` - (optional) @@ -36,17 +36,17 @@ A host catalog has the following configurable attributes: ## Referenced by - [Host][] -- [Host Set][] +- [Host set][] - [Project][] -[host set]: /boundary/docs/concepts/domain-model/host-sets -[host sets]: /boundary/docs/concepts/domain-model/host-sets -[host]: /boundary/docs/concepts/domain-model/hosts -[hosts]: /boundary/docs/concepts/domain-model/hosts -[project]: /boundary/docs/concepts/domain-model/scopes#projects +[host set]: /boundary/docs/domain-model/host-sets +[host sets]: /boundary/docs/domain-model/host-sets +[host]: /boundary/docs/domain-model/hosts +[hosts]: /boundary/docs/domain-model/hosts +[project]: /boundary/docs/domain-model/scopes#projects ## Service API docs The following services are relevant to this resource: -- [Host Catalog Service](/boundary/api-docs/host-catalog-service) +- [Host catalog service](/boundary/api-docs/host-catalog-service) diff --git a/website/content/docs/concepts/domain-model/host-sets.mdx b/website/content/docs/domain-model/host-sets.mdx similarity index 60% rename from website/content/docs/concepts/domain-model/host-sets.mdx rename to website/content/docs/domain-model/host-sets.mdx index e8d01513b..e5a5a2c7c 100644 --- a/website/content/docs/concepts/domain-model/host-sets.mdx +++ b/website/content/docs/domain-model/host-sets.mdx @@ -21,14 +21,14 @@ which belong to the same [project][] as the target. A host set has the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the host set's parent [host catalog][]. + If set, the `name` must be unique within the host set's parent host catalog. - `description` - (optional) - `preferred_endpoints` - (optional) A list of selector strings in the format of either `cidr:` - or `dns:` used to select the addresses of [hosts][] when - establishing a [session][] with a [target][]. + or `dns:` used to select the addresses of hosts when + establishing a [session][] with a target. ### Plugin host set attributes @@ -38,28 +38,28 @@ A host set has the following configurable attributes: syntax which is usable by the backing service. - `sync_interval_seconds` - (optional) - The number of seconds between the time boundary syncs the [hosts][] in this + The number of seconds between the time boundary syncs the hosts in this set using this host set's plugin. Defaults to `600` seconds, or 10 minutes. ## Referenced by - [Host][] -- [Host Catalog][] +- [Host catalog][] - [Target][] -[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs -[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs -[host]: /boundary/docs/concepts/domain-model/hosts -[hosts]: /boundary/docs/concepts/domain-model/hosts -[project]: /boundary/docs/concepts/domain-model/scopes#projects -[projects]: /boundary/docs/concepts/domain-model/scopes#projects -[session]: /boundary/docs/concepts/domain-model/sessions -[sessions]: /boundary/docs/concepts/domain-model/sessions -[target]: /boundary/docs/concepts/domain-model/targets -[targets]: /boundary/docs/concepts/domain-model/targets +[host catalog]: /boundary/docs/domain-model/host-catalogs +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[host]: /boundary/docs/domain-model/hosts +[hosts]: /boundary/docs/domain-model/hosts +[project]: /boundary/docs/domain-model/scopes#projects +[projects]: /boundary/docs/domain-model/scopes#projects +[session]: /boundary/docs/domain-model/sessions +[sessions]: /boundary/docs/domain-model/sessions +[target]: /boundary/docs/domain-model/targets +[targets]: /boundary/docs/domain-model/targets ## Service API docs The following services are relevant to this resource: -- [Host Set Service](/boundary/api-docs/host-set-service) +- [Host set service](/boundary/api-docs/host-set-service) diff --git a/website/content/docs/concepts/domain-model/hosts.mdx b/website/content/docs/domain-model/hosts.mdx similarity index 67% rename from website/content/docs/concepts/domain-model/hosts.mdx rename to website/content/docs/domain-model/hosts.mdx index d2f53a910..33d7cd992 100644 --- a/website/content/docs/concepts/domain-model/hosts.mdx +++ b/website/content/docs/domain-model/hosts.mdx @@ -18,15 +18,15 @@ from the same host catalog as the host. 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][]). +host catalog and host set at an interval (configurable in the +host set). ## Attributes A host has the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the host's parent [host catalog][]. + If set, the `name` must be unique within the host's parent host catalog. - `description` - (optional) @@ -39,16 +39,16 @@ Static host types have the following additional attribute: ## Referenced by -- [Host Catalog][] -- [Host Set][] +- [Host catalog][] +- [Host set][] -[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs -[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs -[host set]: /boundary/docs/concepts/domain-model/host-sets -[host sets]: /boundary/docs/concepts/domain-model/host-sets +[host catalog]: /boundary/docs/domain-model/host-catalogs +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[host set]: /boundary/docs/domain-model/host-sets +[host sets]: /boundary/docs/domain-model/host-sets ## Service API docs The following services are relevant to this resource: -- [Host Service](/boundary/api-docs/host-service) +- [Host service](/boundary/api-docs/host-service) diff --git a/website/content/docs/domain-model/index.mdx b/website/content/docs/domain-model/index.mdx new file mode 100644 index 000000000..662faa122 --- /dev/null +++ b/website/content/docs/domain-model/index.mdx @@ -0,0 +1,224 @@ +--- +layout: docs +page_title: Domain model overview +description: >- + Learn about using the domain model to organize identity and access management and target resources for secure access. Understand how resources work together. +--- + +# Boundary domain model overview + +HashiCorp Boundary has an extensible domain model that allows administrators to organize IAM (Identity and Access Management) and target resources in a way that best compliments how their organization manages its computing infrastructure. This concept page is a high-level look at scopes, how they work, and their role in the domain model. We will also explore how Boundary approaches IAM and granting access to Targets. For more information about Boundary’s resource types, see the subpages of the Domain Model section. + +## Scopes + +When conducting threat modeling exercises, it is common practice to mitigate identified risks by reducing their potential blast radius and attack surface. Boundary uses the concept of scopes to help security operators achieve this type of mitigation. A [scope](/boundary/docs/domain-model/scopes) can be considered as a container for resources and permissions. Each scope has a permissions boundary that is isolated from other scopes on the same level, creating a defined blast radius. +The diagram below illustrates the relationship between the different levels of scopes. + + +![](/img/boundary-domain-model-overview.jpg) + +The highest-level scope is the [global scope](/boundary/docs/domain-model/scopes#global). Boundary administrators operate on this level to configure and manage Boundary for the entire business. Boundary administrators can also manage child scopes, auth methods, users, groups, roles, and grants. + +The intermediate scope level is [organizations](/boundary/docs/domain-model/scopes#organizations), also referred to as orgs, which are a child scope of global. Though the implementation may be flexible for organization scopes, we recommend scoping by business units in this case. Scoping by business unit provides a clear separation of concerns for each business unit. Creating organizations for the development, operations, and support teams would be an example. + +The lowest scope level is the [project](/boundary/docs/domain-model/scopes#projects). An organization’s scope may have as many projects as required based on its business workflows. To expand on the example used earlier, the development team’s organization can also have project scopes for their different products. + +For example, they could have the following project scopes: + +- Product 1 +- Product 2 +- Product 3 + +## 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/domain-model/users) or [groups](/boundary/docs/domain-model/groups) that may be assigned capabilities. + +Users are associated with either the global or an organization’s scope. For better access control management, users may be positioned into groups to ease access control demands. Groups can also contain users from different organizations or global scopes without creating multiple users for a single entity, making permissioning less complicated to implement. + +An [auth method](/boundary/docs/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/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 + +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. + +The next level of access management is a [grant](/boundary/docs/rbac#grant-strings). A grant in Boundary contains an action(s) and the resource(s) that the action(s) are permitted to be performed against. This can be thought of like a rule. + +For example, a grant can specify the List Action against a specific resource. Grants can specify resource types or resource IDs and may also be implemented as a rule. + +The highest-level in Boundary utilizes the concepts of [roles](/boundary/docs/domain-model/roles). Roles are a collection of zero or more grants. Roles are assigned to principals (users and groups) and govern what actions they are authorized to perform. Roles belong to a single scope and their lifecycle is dependent on the existence of that scope. Should the scope be deleted, the role would be deleted too. The diagram below illustrates the relationship between the different IAM components within Boundary. + +![](/img/component-relationship.png) + +## Target and host resources + +Boundary exposes endpoints to users as [targets](/boundary/docs/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/domain-model/hosts) sources or an address, and [credential](/boundary/docs/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. + +A target exposes two distinct and mutually exclusive configuration paths for its +representation of a networked service: + +- Target with an address +- Target with host sources + +A target with an address represents a target that is set up with a single IP +address or DNS name directly on the target resource. This mechanism provides +benefits for new Boundary users and users who do not need the flexibility +provided by hosts, host sets, and host catalogs. It is well suited for cases +where there are stand-alone hosts that should not be grouped together and +treated as equal from an access control point of view. Because of its +simplicity, using targets with an address is not recommended when there are a +either a large number of hosts and/or dynamic hosts. + +A target with host sources represents a target that has one or more [host +sets][] associated with it. It trades off the simplicity of directly setting an +address on a target with the flexibility and scalability of Hosts, Host Sets and +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 + +- **[Account][]** : + A resource + that represents a unique set of credentials + issued from a configured [authentication method][] + which can be used to establish the identity of a [user][]. + +- **[Alias][]** : + A resource + that represents a globally unique, DNS-like string that is + associated with a destination resource, such as a [target][]. + +- **[Authentication method][]** : + A resource + that provides a mechanism + for [users][] to authenticate to Boundary. + +- **[Credential][]** : + A data structure containing one or more secrets + that binds an identity to a set of permissions or capabilities + on a [host][] for a [session][]. + +- **[Credential library][]** : + A resource + that provides [credentials][] + of the same type and same access level + from a single [credential store][]. + +- **[Credential store][]** : + A resource + that can retrieve, store, and potentially generate [credentials][] + of differing types and differing access levels. + It may also contain [credential libraries][]. + +- **[Group][]** : + A resource + that represents a collection of [users][] + which can be treated equally + for the purposes of access control. + +- **[Host][]** : + A resource + that represents a computing element with a network address + reachable from Boundary. + +- **[Host catalog][]** : + A resource + that contains [hosts][] and [host sets][]. + +- **[Host set][]** : + A resource + that represents a collection of [hosts][] + which are considered equivalent + for the purposes of access control. + +- **[Managed group][]** : + A resource that groups [accounts][] based on criteria + established by a third-party service backing the [authentication method][]. It + can be used as a principal in [roles][]. + +- **[Role][]** : + A resource + that contains a collection of [permissions][] + which are granted to any principal assigned to the role. + +- **[Session][]** : + A set of related connections between a [user][] and a [host][]. + A session may include a set of [credentials][] + which define the permissions granted to the [user][] on the [host][] for the duration + of the session. + +- **[Session recordings][]** : + A session recording represents a directory structure of files in an external object store that together are the recording of a single [session][] between a [user][] and a [target][]. + +- **[Scope][]** : + A [permission][] boundary modeled as a container. + +- **[Storage bucket][]** : + A storage bucket is used to store [session recordings][]. + The storage bucket represents a bucket in an external object store. + +- **[Storage policy][]** : + A storage policy defines the rules for storing + [session recordings][] in a [storage bucket][]. + The storage policy may specify the retention period for the recordings. + +- **[Target][]** : + A resource + that represents a networked service + with an associated set of permissions + a [user][] can connect to + and interact with + through Boundary + by way of a [session][]. + +- **[User][]** : + A resource + that represents an individual person or entity + for the purposes of access control. + +## Next steps + +When getting started with Boundary, +the first resource to look at should be [scopes][]. +Every other resources is either contained within a scope, +or contained within another resource +that is itself contained within a scope. +Refer to the [scopes] section to help you understand the structure of resources within Boundary. + +[iam]: https://en.wikipedia.org/wiki/Identity_management +[account]: /boundary/docs/domain-model/accounts +[accounts]: /boundary/docs/domain-model/accounts +[alias]: /boundary/docs/concepts/domain-model/aliases +[authentication method]: /boundary/docs/domain-model/auth-methods +[authentication methods]: /boundary/docs/domain-model/auth-methods +[credential library]: /boundary/docs/domain-model/credential-libraries +[credential libraries]: /boundary/docs/domain-model/credential-libraries +[credential store]: /boundary/docs/domain-model/credential-stores +[credential stores]: /boundary/docs/domain-model/credential-stores +[credential]: /boundary/docs/domain-model/credentials +[credentials]: /boundary/docs/domain-model/credentials +[group]: /boundary/docs/domain-model/groups +[groups]: /boundary/docs/domain-model/groups +[host catalog]: /boundary/docs/domain-model/host-catalogs +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[host set]: /boundary/docs/domain-model/host-sets +[host sets]: /boundary/docs/domain-model/host-sets +[host]: /boundary/docs/domain-model/hosts +[hosts]: /boundary/docs/domain-model/hosts +[managed group]: /boundary/docs/domain-model/managed-groups +[role]: /boundary/docs/domain-model/roles +[roles]: /boundary/docs/domain-model/roles +[scope]: /boundary/docs/domain-model/scopes +[scopes]: /boundary/docs/domain-model/scopes +[project]: /boundary/docs/domain-model/scopes#projects +[session]: /boundary/docs/domain-model/sessions +[session recordings]: /boundary/docs/domain-model/session-recordings +[sessions]: /boundary/docs/domain-model/sessions +[storage bucket]: /boundary/docs/domain-model/storage-buckets +[storage policy]: /boundary/docs/concepts/domain-model/storage-policy +[target]: /boundary/docs/domain-model/targets +[targets]: /boundary/docs/domain-model/targets +[user]: /boundary/docs/domain-model/users +[users]: /boundary/docs/domain-model/users +[permission]: /boundary/docs/rbac +[permissions]: /boundary/docs/rbac diff --git a/website/content/docs/concepts/domain-model/managed-groups.mdx b/website/content/docs/domain-model/managed-groups.mdx similarity index 83% rename from website/content/docs/concepts/domain-model/managed-groups.mdx rename to website/content/docs/domain-model/managed-groups.mdx index e845a129b..81eb0a8dd 100644 --- a/website/content/docs/concepts/domain-model/managed-groups.mdx +++ b/website/content/docs/domain-model/managed-groups.mdx @@ -19,7 +19,7 @@ a principal within [roles][] to assign grants. All managed group types have the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the account's [auth method][]. + If set, the `name` must be unique within the account's auth method. - `description` - (optional) @@ -36,8 +36,8 @@ OIDC managed groups have the following additional attributes: A boolean expression defining a filter run against the provided information. For general syntax information refer to the [filtering concepts][] page; for more specific information on the data available for this purpose refer to the [managed groups filtering][] page. -[filtering concepts]: /boundary/docs/concepts/filtering -[managed groups filtering]: /boundary/docs/concepts/filtering/managed-groups +[filtering concepts]: /boundary/docs/filtering +[managed groups filtering]: /boundary/docs/rbac/users/managed-groups ### LDAP managed group information and attributes @@ -52,17 +52,17 @@ LDAP managed groups have the following additional attributes: ## Referenced by - [Accounts][] -- [Auth Method][] +- [Auth method][] -[accounts]: /boundary/docs/concepts/domain-model/accounts -[auth method]: /boundary/docs/concepts/domain-model/auth-methods -[roles]: /boundary/docs/concepts/domain-model/roles +[accounts]: /boundary/docs/domain-model/accounts +[auth method]: /boundary/docs/domain-model/auth-methods +[roles]: /boundary/docs/domain-model/roles ## Service API docs The following services are relevant to this resource: -- [Managed Group Service](/boundary/api-docs/managed-group-service) +- [Managed group service](/boundary/api-docs/managed-group-service) ## Tutorial diff --git a/website/content/docs/concepts/domain-model/roles.mdx b/website/content/docs/domain-model/roles.mdx similarity index 63% rename from website/content/docs/concepts/domain-model/roles.mdx rename to website/content/docs/domain-model/roles.mdx index 5da68d81b..fe6d1ed64 100644 --- a/website/content/docs/concepts/domain-model/roles.mdx +++ b/website/content/docs/domain-model/roles.mdx @@ -27,25 +27,25 @@ A role has the following configurable attributes: ## Referenced by - [Group][] -- [Managed Group][] +- [Managed group][] - [Project][] - [User][] -[group]: /boundary/docs/concepts/domain-model/groups -[groups]: /boundary/docs/concepts/domain-model/groups -[managed group]: /boundary/docs/concepts/domain-model/managed-groups -[managed groups]: /boundary/docs/concepts/domain-model/managed-groups -[permissions]: /boundary/docs/concepts/security/permissions -[project]: /boundary/docs/concepts/domain-model/scopes#projects -[scope]: /boundary/docs/concepts/domain-model/scopes -[user]: /boundary/docs/concepts/domain-model/users -[users]: /boundary/docs/concepts/domain-model/users +[group]: /boundary/docs/domain-model/groups +[groups]: /boundary/docs/domain-model/groups +[managed group]: /boundary/docs/domain-model/managed-groups +[managed groups]: /boundary/docs/domain-model/managed-groups +[permissions]: /boundary/docs/rbac +[project]: /boundary/docs/domain-model/scopes#projects +[scope]: /boundary/docs/domain-model/scopes +[user]: /boundary/docs/domain-model/users +[users]: /boundary/docs/domain-model/users ## Service API docs The following services are relevant to this resource: -- [Role Service](/boundary/api-docs/role-service) +- [Role service](/boundary/api-docs/role-service) ## Tutorial diff --git a/website/content/docs/concepts/domain-model/scopes.mdx b/website/content/docs/domain-model/scopes.mdx similarity index 78% rename from website/content/docs/concepts/domain-model/scopes.mdx rename to website/content/docs/domain-model/scopes.mdx index 92549f506..4903beb01 100644 --- a/website/content/docs/concepts/domain-model/scopes.mdx +++ b/website/content/docs/domain-model/scopes.mdx @@ -113,34 +113,34 @@ Changing the storage policy assigned to a scope can impact the resultant set of - [Target][] - [User][] -[auth method]: /boundary/docs/concepts/domain-model/auth-methods -[auth methods]: /boundary/docs/concepts/domain-model/auth-methods -[credential store]: /boundary/docs/concepts/domain-model/credential-stores -[credential stores]: /boundary/docs/concepts/domain-model/credential-stores -[global]: /boundary/docs/concepts/domain-model/scopes#global -[group]: /boundary/docs/concepts/domain-model/groups -[groups]: /boundary/docs/concepts/domain-model/groups -[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs -[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs -[organization]: /boundary/docs/concepts/domain-model/scopes#organizations -[organizations]: /boundary/docs/concepts/domain-model/scopes#organizations -[permission]: /boundary/docs/concepts/security/permissions -[permissions]: /boundary/docs/concepts/security/permissions -[project]: /boundary/docs/concepts/domain-model/scopes#projects -[projects]: /boundary/docs/concepts/domain-model/scopes#projects -[role]: /boundary/docs/concepts/domain-model/roles -[roles]: /boundary/docs/concepts/domain-model/roles -[storage policies]: /boundary/docs/concepts/domain-model/storage-policy -[target]: /boundary/docs/concepts/domain-model/targets -[targets]: /boundary/docs/concepts/domain-model/targets -[user]: /boundary/docs/concepts/domain-model/users -[users]: /boundary/docs/concepts/domain-model/users +[auth method]: /boundary/docs/domain-model/auth-methods +[auth methods]: /boundary/docs/domain-model/auth-methods +[credential store]: /boundary/docs/domain-model/credential-stores +[credential stores]: /boundary/docs/domain-model/credential-stores +[global]: /boundary/docs/domain-model/scopes#global +[group]: /boundary/docs/domain-model/groups +[groups]: /boundary/docs/domain-model/groups +[host catalog]: /boundary/docs/domain-model/host-catalogs +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[organization]: /boundary/docs/domain-model/scopes#organizations +[organizations]: /boundary/docs/domain-model/scopes#organizations +[permission]: /boundary/docs/rbac +[permissions]: /boundary/docs/rbac +[project]: /boundary/docs/domain-model/scopes#projects +[projects]: /boundary/docs/domain-model/scopes#projects +[role]: /boundary/docs/domain-model/roles +[roles]: /boundary/docs/domain-model/roles +[storage policies]: /boundary/docs/domain-model/storage-policy +[target]: /boundary/docs/domain-model/targets +[targets]: /boundary/docs/domain-model/targets +[user]: /boundary/docs/domain-model/users +[users]: /boundary/docs/domain-model/users ## Service API docs The following services are relevant to this resource: -- [Scope Service](/boundary/api-docs/scope-service) +- [Scope service](/boundary/api-docs/scope-service) ## Tutorial diff --git a/website/content/docs/concepts/domain-model/session-connections.mdx b/website/content/docs/domain-model/session-connections.mdx similarity index 59% rename from website/content/docs/concepts/domain-model/session-connections.mdx rename to website/content/docs/domain-model/session-connections.mdx index a5f9c555e..e0ff7b208 100644 --- a/website/content/docs/concepts/domain-model/session-connections.mdx +++ b/website/content/docs/domain-model/session-connections.mdx @@ -11,17 +11,17 @@ A session connection represents an authorized proxy between a [user][] and a [ho [session][], a user initiates a connection to a [target][] using the Boundary-provided proxy information and [credentials][] (if applicable). -Users can create multiple connections to a [target][], so long as the [session][] has not expired or reached its maximum +Users can create multiple connections to a target, so long as the session has not expired or reached its maximum number of connections. -Session connections terminate on user exit from the proxy, or on termination of the [session][]. +Session connections terminate on user exit from the proxy, or on termination of the session. ## Referenced by - [Session][] -[credentials]: /boundary/docs/concepts/domain-model/credentials -[host]: /boundary/docs/concepts/domain-model/hosts -[session]: /boundary/docs/concepts/domain-model/sessions -[target]: /boundary/docs/concepts/domain-model/targets -[user]: /boundary/docs/concepts/domain-model/users +[credentials]: /boundary/docs/domain-model/credentials +[host]: /boundary/docs/domain-model/hosts +[session]: /boundary/docs/domain-model/sessions +[target]: /boundary/docs/domain-model/targets +[user]: /boundary/docs/domain-model/users diff --git a/website/content/docs/concepts/domain-model/session-recordings.mdx b/website/content/docs/domain-model/session-recordings.mdx similarity index 81% rename from website/content/docs/concepts/domain-model/session-recordings.mdx rename to website/content/docs/domain-model/session-recordings.mdx index 33f74a050..45c7b9b14 100644 --- a/website/content/docs/concepts/domain-model/session-recordings.mdx +++ b/website/content/docs/domain-model/session-recordings.mdx @@ -17,31 +17,31 @@ The lifecycle of a session recording does not affect the lifecycle of any files stored in the external object store. A session recording belongs to one and only one [storage bucket][]. -It is deleted when you delete the [storage bucket][] it belongs to. +It is deleted when you delete the storage bucket it belongs to. A session recording is associated with the -[target][] that the recorded session was against. +target that the recorded session was against. However, the lifecycle of a session recording is not tied to -the lifecycle of the [target][] it is associated with. -If the [target][] associated wtih a session recording is deleted, -the association to the [target][] is deleted, not the session recording itself. +the lifecycle of the target it is associated with. +If the target associated wtih a session recording is deleted, +the association to the target is deleted, not the session recording itself. Deleting a session recording does not delete or modify any of the files in the external object store that the session recording represents. The session recording captures all interactions that take place during -the session, including metadata about the [user][], [target][] and any +the session, including metadata about the user, target and any [hosts][], [host sets][], [host catalogs][], or [credentials][] used. A session recording represents [connections][] as separate entities within the recording. Each recorded connection may also contain a recorded channel. This represents a single channel -in which the [user][] interacted with the [target][] in protocols that +in which the user interacted with the target in protocols that multiplex user interactions over single connections. For example, the SSH protocol multiplexes user interactions in a single connection, so a user's interactions over SSH are recorded in a channel. -A session recording belongs to the scope of the [storage bucket][] +A session recording belongs to the scope of the storage bucket it is stored in. The scope can be either the global scope or an [organization][] scope. @@ -96,7 +96,7 @@ Therefore, Boundary sets the deletion value to the retention value. | Retain for days (Overridable) | 30 (True) | 20 (True) | 30 | | Delete after days (Overridable) | 50 (True) | 20 (True) | 30 | -For more information, refer to the [storage policy attributes](/boundary/docs/concepts/domain-model/storage-policy#attributes) documentation. +For more information, refer to the [storage policy attributes](/boundary/docs/domain-model/storage-policy#attributes) documentation. ## Service API docs @@ -104,14 +104,14 @@ The following services are relevant to this resource: - [Session recording service](/boundary/api-docs/session-recording-service) -[connections]: /boundary/docs/concepts/domain-model/session-connections -[credentials]: /boundary/docs/concepts/domain-model/credentials -[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs -[host sets]: /boundary/docs/concepts/domain-model/host-sets -[hosts]: /boundary/docs/concepts/domain-model/hosts -[target]: /boundary/docs/concepts/domain-model/targets -[user]: /boundary/docs/concepts/domain-model/users -[organization]: /boundary/docs/concepts/domain-model/scopes#organizations -[session]: /boundary/docs/concepts/domain-model/sessions -[storage bucket]: /boundary/docs/concepts/domain-model/storage-buckets -[storage policies]: /boundary/docs/concepts/domain-model/storage-policy \ No newline at end of file +[connections]: /boundary/docs/domain-model/session-connections +[credentials]: /boundary/docs/domain-model/credentials +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[host sets]: /boundary/docs/domain-model/host-sets +[hosts]: /boundary/docs/domain-model/hosts +[target]: /boundary/docs/domain-model/targets +[user]: /boundary/docs/domain-model/users +[organization]: /boundary/docs/domain-model/scopes#organizations +[session]: /boundary/docs/domain-model/sessions +[storage bucket]: /boundary/docs/domain-model/storage-buckets +[storage policies]: /boundary/docs/domain-model/storage-policy \ No newline at end of file diff --git a/website/content/docs/domain-model/sessions.mdx b/website/content/docs/domain-model/sessions.mdx new file mode 100644 index 000000000..e6d8e65a5 --- /dev/null +++ b/website/content/docs/domain-model/sessions.mdx @@ -0,0 +1,108 @@ +--- +layout: docs +page_title: Session resource +description: >- + Learn how the session resource is a set of connections between users and hosts that may include credentials. Understand how sessions are created and terminated. +--- + +# Sessions + +A session is +a set of related [connections][] +between a [user][] and a [host][]. +A session may include a set of [credentials][] +which define the permissions granted to the [user][] on the [host][] for the duration +of the session. + +A user initiates a session +by requesting access to a [target][]. +If a user has the proper [permissions][], +a session is created +and the [expiration time][] and [connection limit][] +are set based on the [target's attributes][]. +If the target is associated with [credential libraries][], +credentials are retrieved and returned from each +credential library. +A snapshot of the data +relevant to authorizing the session +is also captured and stored in the Boundary data warehouse +when the session is created. + +Sessions are created in the [project][] of the corresponding target. +Deleting a project will terminate all of the active sessions in the project +but will not effect any session data in the data warehouse. +Historical data in the data warehouse is never deleted. + +## Termination + +A session is forcefully terminated when one of the following occurs: + +- The session reaches the time limit and expires. + +- An authorized user manually cancels the session. + +- Any resource associated with the session is deleted + or removed from the target. + This includes: the host, the [host set][], the [host catalog][], + a credential, a credential library, a [credential store][], + the target itself, the project, the [organization][], + the user, the user's [account][], or the account's [authentication method][]. + +In addition to the above, +a session terminates non-forcefully +when the user closes all connections +and no additional connections are allowed +because of a connection limit. + +Any credentials associated with the session are revoked when the session is +terminated. + +Permissions are only evaluated at session establishment. +Changes to a user's permissions do not effect existing sessions. + +## Referenced by + +- [Project][] +- [Credential][] +- [Host set][] +- [Target][] + +[expiration time]: /boundary/docs/domain-model/targets#session_max_seconds +[connection limit]: /boundary/docs/domain-model/targets#session_connection_limit +[target's attributes]: /boundary/docs/domain-model/targets#tcp-target-attributes +[account]: /boundary/docs/domain-model/accounts +[accounts]: /boundary/docs/domain-model/accounts +[authentication method]: /boundary/docs/domain-model/auth-methods +[authentication methods]: /boundary/docs/domain-model/auth-methods +[connections]: /boundary/docs/domain-model/session-connections +[credential library]: /boundary/docs/domain-model/credential-libraries +[credential libraries]: /boundary/docs/domain-model/credential-libraries +[credential store]: /boundary/docs/domain-model/credential-stores +[credential stores]: /boundary/docs/domain-model/credential-stores +[credential]: /boundary/docs/domain-model/credentials +[credentials]: /boundary/docs/domain-model/credentials +[host catalog]: /boundary/docs/domain-model/host-catalogs +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[host set]: /boundary/docs/domain-model/host-sets +[host sets]: /boundary/docs/domain-model/host-sets +[host]: /boundary/docs/domain-model/hosts +[hosts]: /boundary/docs/domain-model/hosts +[target]: /boundary/docs/domain-model/targets +[targets]: /boundary/docs/domain-model/targets +[user]: /boundary/docs/domain-model/users +[users]: /boundary/docs/domain-model/users +[organization]: /boundary/docs/domain-model/scopes#organizations +[organizations]: /boundary/docs/domain-model/scopes#organizations +[project]: /boundary/docs/domain-model/scopes#projects +[projects]: /boundary/docs/domain-model/scopes#projects +[permissions]: /boundary/docs/rbac + +## Service API docs + +The following services are relevant to this resource: + +- [Session service](/boundary/api-docs/session-service) + +## Tutorial + +Refer to the [Manage Sessions with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-sessions) tutorial to learn how to start, view, and cancel a session. diff --git a/website/content/docs/concepts/domain-model/storage-buckets.mdx b/website/content/docs/domain-model/storage-buckets.mdx similarity index 92% rename from website/content/docs/concepts/domain-model/storage-buckets.mdx rename to website/content/docs/domain-model/storage-buckets.mdx index 7b3240cd6..abce7574c 100644 --- a/website/content/docs/concepts/domain-model/storage-buckets.mdx +++ b/website/content/docs/domain-model/storage-buckets.mdx @@ -79,8 +79,8 @@ Secret access keys are required if the AWS S3 bucket is configured to use static ## Referenced by -- [Session recordings](/boundary/docs/concepts/domain-model/session-recordings) -- [Create a storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket) +- [Session recordings](/boundary/docs/domain-model/session-recordings) +- [Create a storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket) ## Service API docs @@ -88,7 +88,7 @@ The following services are relevant to this resource: - [Session recording service](/boundary/api-docs/session-recording-service) -[session recordings]: /boundary/docs/concepts/domain-model/session-recordings -[credentials]: /boundary/docs/concepts/domain-model/credentials -[targets]: /boundary/docs/concepts/domain-model/targets -[scope]: /boundary/docs/concepts/domain-model/scopes \ No newline at end of file +[session recordings]: /boundary/docs/domain-model/session-recordings +[credentials]: /boundary/docs/domain-model/credentials +[targets]: /boundary/docs/domain-model/targets +[scope]: /boundary/docs/domain-model/scopes \ No newline at end of file diff --git a/website/content/docs/concepts/domain-model/storage-policy.mdx b/website/content/docs/domain-model/storage-policy.mdx similarity index 85% rename from website/content/docs/concepts/domain-model/storage-policy.mdx rename to website/content/docs/domain-model/storage-policy.mdx index e0d15fc06..710d594bc 100644 --- a/website/content/docs/concepts/domain-model/storage-policy.mdx +++ b/website/content/docs/domain-model/storage-policy.mdx @@ -46,16 +46,16 @@ However, such a change only affects future recordings created within that scope ## Referenced by -- [scopes](/boundary/docs/concepts/domain-model/scopes) -- [session recordings](/boundary/docs/concepts/domain-model/session-recordings) +- [Scopes](/boundary/docs/domain-model/scopes) +- [Session recordings](/boundary/docs/domain-model/session-recordings) ## Service API docs The following services are relevant to this resource: -- [Scope Service](/boundary/api-docs/scope-service) -- [Policy Service](/boundary/api-docs/policy-service) +- [Scope service](/boundary/api-docs/scope-service) +- [Policy service](/boundary/api-docs/policy-service) -[attach]: /boundary/docs/configuration/session-recording/configure-storage-policy#attach-storage-policies-to-a-scope -[session recordings]: /boundary/docs/concepts/domain-model/session-recordings -[scope]: /boundary/docs/concepts/domain-model/scopes +[attach]: /boundary/docs/session-recording/compliance/configure-storage-policy#attach-storage-policies-to-a-scope +[session recordings]: /boundary/docs/domain-model/session-recordings +[scope]: /boundary/docs/domain-model/scopes diff --git a/website/content/docs/concepts/domain-model/targets.mdx b/website/content/docs/domain-model/targets.mdx similarity index 76% rename from website/content/docs/concepts/domain-model/targets.mdx rename to website/content/docs/domain-model/targets.mdx index 7e233be95..0b30bd27b 100644 --- a/website/content/docs/concepts/domain-model/targets.mdx +++ b/website/content/docs/domain-model/targets.mdx @@ -35,7 +35,7 @@ or host in any host set referenced by the target. A target has the following configurable attributes: - `name` - (required) - The `name` must be unique within the target's [project][]. + The `name` must be unique within the target's project. - `description` - (optional) An optional description of the target for identificaiton purposes. @@ -51,7 +51,7 @@ A target has the following configurable attributes: A boolean expression to [filter][] which egress workers can handle sessions for this target. Egress worker filters determine which workers are used to access targets. - You can configure an egress filter to enable [multi-hop](/boundary/docs/configuration/worker#multi-hop-worker-capabilities) connections. + You can configure an egress filter to enable [multi-hop](/boundary/docs/workers/multi-hop) connections. If you do not configure an egress filter, then Boundary uses a single worker to connect to the controller. - `ingress_worker_filter` - (optional) HCP/ENT @@ -113,7 +113,7 @@ TCP targets have the following additional attribute: SSH targets use injected application credentials to authenticate an SSH session between the client and end host. Injected credentials allow users to securely connect to remost hosts using SSH, while never being in the possession of a valid credential for that target host. -The injected credentials can be a username/password or username/private key credential from Vault [credential libraries][] or they can be static [credentials][] or an SSH certificate from Vault SSH credential libraries. +The injected credentials can be a username/password or username/private key credential from Vault credential libraries or they can be static [credentials][] or an SSH certificate from Vault SSH credential libraries. SSH targets require you to configure injected credentials to create a session. If you attempt to create a session against an SSH target without configuring injected credentials, it results in an error. @@ -135,40 +135,40 @@ SSH targets have the following additional attributes: ## Referenced by -- [Credential Library][] -- [Host Set][] +- [Credential library][] +- [Host set][] - [Project][] - [Session][] -- [Session Recordings][] -- [Worker Filtering][] +- [Session recordings][] +- [Worker filtering][] -[credentials]: /boundary/docs/concepts/domain-model/credentials -[credential library]: /boundary/docs/concepts/domain-model/credential-libraries -[credential libraries]: /boundary/docs/concepts/domain-model/credential-libraries -[credential store]: /boundary/docs/concepts/domain-model/credential-stores -[credential stores]: /boundary/docs/concepts/domain-model/credential-stores -[host catalog]: /boundary/docs/concepts/domain-model/host-catalogs -[host catalogs]: /boundary/docs/concepts/domain-model/host-catalogs -[host set]: /boundary/docs/concepts/domain-model/host-sets -[host sets]: /boundary/docs/concepts/domain-model/host-sets -[host]: /boundary/docs/concepts/domain-model/hosts -[hosts]: /boundary/docs/concepts/domain-model/hosts -[permission]: /boundary/docs/concepts/security/permissions -[permissions]: /boundary/docs/concepts/security/permissions -[project]: /boundary/docs/concepts/domain-model/scopes#projects -[projects]: /boundary/docs/concepts/domain-model/scopes#projects -[role]: /boundary/docs/concepts/domain-model/roles -[roles]: /boundary/docs/concepts/domain-model/roles -[session]: /boundary/docs/concepts/domain-model/sessions -[sessions]: /boundary/docs/concepts/domain-model/sessions -[session recordings]: /boundary/docs/concepts/domain-model/session-recordings -[filter]: /boundary/docs/concepts/filtering/worker-tags -[worker filtering]: /boundary/docs/concepts/filtering/worker-tags -[user]: /boundary/docs/concepts/domain-model/users -[users]: /boundary/docs/concepts/domain-model/users +[credentials]: /boundary/docs/domain-model/credentials +[credential library]: /boundary/docs/domain-model/credential-libraries +[credential libraries]: /boundary/docs/domain-model/credential-libraries +[credential store]: /boundary/docs/domain-model/credential-stores +[credential stores]: /boundary/docs/domain-model/credential-stores +[host catalog]: /boundary/docs/domain-model/host-catalogs +[host catalogs]: /boundary/docs/domain-model/host-catalogs +[host set]: /boundary/docs/domain-model/host-sets +[host sets]: /boundary/docs/domain-model/host-sets +[host]: /boundary/docs/domain-model/hosts +[hosts]: /boundary/docs/domain-model/hosts +[permission]: /boundary/docs/rbac +[permissions]: /boundary/docs/rbac +[project]: /boundary/docs/domain-model/scopes#projects +[projects]: /boundary/docs/domain-model/scopes#projects +[role]: /boundary/docs/domain-model/roles +[roles]: /boundary/docs/domain-model/roles +[session]: /boundary/docs/domain-model/sessions +[sessions]: /boundary/docs/domain-model/sessions +[session recordings]: /boundary/docs/domain-model/session-recordings +[filter]: /boundary/docs/workers/worker-tags +[worker filtering]: /boundary/docs/workers/worker-tags +[user]: /boundary/docs/domain-model/users +[users]: /boundary/docs/domain-model/users ## Service API docs The following services are relevant to this resource: -- [Target Service](/boundary/api-docs/target-service) +- [Target service](/boundary/api-docs/target-service) diff --git a/website/content/docs/concepts/domain-model/users.mdx b/website/content/docs/domain-model/users.mdx similarity index 61% rename from website/content/docs/concepts/domain-model/users.mdx rename to website/content/docs/domain-model/users.mdx index 8a7753f9f..73d17fb54 100644 --- a/website/content/docs/concepts/domain-model/users.mdx +++ b/website/content/docs/domain-model/users.mdx @@ -20,7 +20,7 @@ A user receives all the [permissions][] of the roles assigned directly to the user and all the permissions of roles assigned to [groups][] the user is in. -Users can be defined at either a [Global][] or [Organization][] [scope][]. +Users can be defined at either a [global][] or [organization][] [scope][]. A user can only be associated with accounts from an [auth method][] configured in the same scope. @@ -29,7 +29,7 @@ configured in the same scope. A user has the following configurable attributes: - `name` - (optional) - If set, the `name` must be unique within the user's immediate parent [scope][]. + If set, the `name` must be unique within the user's immediate parent scope. - `description` - (optional) @@ -41,20 +41,20 @@ A user has the following configurable attributes: - [Organization][] - [Role][] -[account]: /boundary/docs/concepts/domain-model/accounts -[accounts]: /boundary/docs/concepts/domain-model/accounts -[auth method]: /boundary/docs/concepts/domain-model/auth-methods -[global]: /boundary/docs/concepts/domain-model/scopes#global -[group]: /boundary/docs/concepts/domain-model/groups -[groups]: /boundary/docs/concepts/domain-model/groups -[organization]: /boundary/docs/concepts/domain-model/scopes#organizations -[permissions]: /boundary/docs/concepts/security/permissions -[role]: /boundary/docs/concepts/domain-model/roles -[roles]: /boundary/docs/concepts/domain-model/roles -[scope]: /boundary/docs/concepts/domain-model/scopes +[account]: /boundary/docs/domain-model/accounts +[accounts]: /boundary/docs/domain-model/accounts +[auth method]: /boundary/docs/domain-model/auth-methods +[global]: /boundary/docs/domain-model/scopes#global +[group]: /boundary/docs/domain-model/groups +[groups]: /boundary/docs/domain-model/groups +[organization]: /boundary/docs/domain-model/scopes#organizations +[permissions]: /boundary/docs/rbac +[role]: /boundary/docs/domain-model/roles +[roles]: /boundary/docs/domain-model/roles +[scope]: /boundary/docs/domain-model/scopes ## Service API docs The following services are relevant to this resource: -- [User Service](/boundary/api-docs/user-service) +- [User service](/boundary/api-docs/user-service) diff --git a/website/content/docs/enterprise/index.mdx b/website/content/docs/enterprise/index.mdx index 0be356187..84ac9578c 100644 --- a/website/content/docs/enterprise/index.mdx +++ b/website/content/docs/enterprise/index.mdx @@ -9,7 +9,7 @@ description: >- Boundary Enterprise has features that are not available in the Community Edition of the product, as well as support. The Enterprise version is self-managed in your environment, making it the perfect choice for agencies that are not able to use SaaS products for compliance or regulatory reasons. -The [Install Boundary](/boundary/docs/install-boundary) section can help you build a self-managed production environment using Boundary Enterprise. +The [Deploy Boundary](/boundary/docs/deploy/self-managed) section can help you build a self-managed production environment using Boundary Enterprise. You must obtain a [license](/boundary/docs/enterprise/licensing) to use Boundary Enterprise. diff --git a/website/content/docs/enterprise/licensing.mdx b/website/content/docs/enterprise/licensing.mdx index 191187e75..d1ec78491 100644 --- a/website/content/docs/enterprise/licensing.mdx +++ b/website/content/docs/enterprise/licensing.mdx @@ -9,7 +9,7 @@ description: >- The Boundary Enterprise binaries require a license key to enforce entitlements and time restrictions according to your contractual agreement. Once purchased, your HashiCorp account team send you a valid Boundary license for environment activation. -If you don't yet have an acccount team, but are interested in Boundary Enterprise, you can request access [here](https://www.hashicorp.com/contact-sales). +If you don't yet have an acccount team, but are interested in Boundary Enterprise, you can [contact sales](https://www.hashicorp.com/contact-sales). Once you have received your valid Boundary license, there are two options for enabling Boundary Enterprise: diff --git a/website/content/docs/troubleshoot/common-errors.mdx b/website/content/docs/errors/index.mdx similarity index 85% rename from website/content/docs/troubleshoot/common-errors.mdx rename to website/content/docs/errors/index.mdx index e92467b7e..196f70d36 100644 --- a/website/content/docs/troubleshoot/common-errors.mdx +++ b/website/content/docs/errors/index.mdx @@ -11,6 +11,12 @@ When installing and running Boundary, there are some common messages you might s 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). +To troubleshoot specific issues with the Client Agent or transparent sessions, refer to the following topics: + +- [Troubleshoot issues with the Client Agent](/boundary/docs/client-agent/troubleshoot) +- [Client Agent software conflicts](/boundary/docs/client-agent/conflicting-software) +- [Transparent sessions interoperability matrix](/boundary/docs/interoperability-matrix) + ## Cannot connect to target: error from controller when performing authorize-session action against given target ``` @@ -26,7 +32,7 @@ Error information: 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 [Resource tables](/boundary/docs/rbac/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 @@ -101,3 +107,13 @@ Error: error creating storage bucket: {"kind":"Internal","message":"storage_buck You may experience this error when deploying Boundary controllers in Docker when enabling IMDSv2. The fix is to extend the `http-put-response-hop-limit` option key to a value of 2 or greater. For more information, refer to [Boundary Client in Docker Additional Configuration When Using IMDSv2](https://support.hashicorp.com/hc/en-us/articles/36515134051859-Boundary-Client-in-Docker-Additional-Configuration-When-Using-IMDSv2).``` + +## More information + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. + +To troubleshoot specific issues with the Client Agent or transparent sessions, refer to the following topics: + +- [Troubleshoot issues with the Client Agent](/boundary/docs/client-agent/troubleshoot) +- [Client Agent software conflicts](/boundary/docs/client-agent/conflicting-software) +- [Transparent sessions interoperability matrix](/boundary/docs/interoperability-matrix) diff --git a/website/content/docs/filtering/index.mdx b/website/content/docs/filtering/index.mdx new file mode 100644 index 000000000..aea7ab1e9 --- /dev/null +++ b/website/content/docs/filtering/index.mdx @@ -0,0 +1,200 @@ +--- +layout: docs +page_title: Filtering +description: >- + Learn how to create filter expressions and use filters to match and find data or to reduce the set of resources returned when you list resources. +--- + +# Filtering and listing resources + +Filter expressions can be used by various parts of Boundary to provide useful functionality. +Each filter expression has matching operators composed with selectors and values. +This page describes the overall syntax and provides information on the specific values available for filtering for various features, including examples. + +For more information about creating filters for events, workers, targets, and credential stores, refer to the following topics: + +- [Filter events](/boundary/docs/monitor/events/filter-events) +- [Route traffic through a worker](/boundary/docs/workers/worker-tags) +- [Configure a worker filter](/boundary/docs/workers/filters) +- [Filter managed groups](/boundary/docs/rbac/users/managed-groups) + +## 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 + +All matching operators use a selector or value to choose what data should be +matched. Each endpoint that supports filtering accepts a potentially different +list of selectors and is detailed in the API documentation for those endpoints. + +```text +// Equality & Inequality checks + == "" + != "" + +// Emptiness checks + is empty + is not empty + +// Contains checks or Substring Matching +"" in +"" not in + contains "" + not contains "" + +// Regular Expression Matching + matches "" + not matches "" +``` + +### Selectors + +Selectors are used by matching operators to create an expression. Inputs to +filter expressions are JSON (or JSON-derived); selectors therefore use [JSON +Pointer](https://tools.ietf.org/html/rfc6901) to select values from the input. +Each selector must be enclosed in quotes and contain a valid JSON Pointer path, +including leading slash (`/`). + +```text +// Selects the value `zipzap` from the input `{ "foo": { "bar": "zipzap" } }` +"/foo/bar" +``` + +### Values + +Values are used by matching operators to create an expression. Values can be any +valid selector, a number, or a string. It is best practice to quote values. + +Numbers can be base 10 integers or floating point numbers. + +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. + +## Connect expressions + +There are several methods for connecting expressions, including + +- Logical `or` +- Logical `and` +- Logical `not` +- Grouping with parenthesis +- Matching expressions + +```text +// Logical Or - evaluates to true if either sub-expression does + or + +// Logical And - evaluates to true if both sub-expressions do + and + +// Logical Not - evaluates to true if the sub-expression does not +not + +// Grouping - Overrides normal precedence rules +( ) + +// Inspects data to check for a match + +``` + +Standard operator precedence can be expected for the various forms. For example, +the following two expressions would be equivalent. + +```text + and not or + +( and (not )) or +``` + +## Performance + +Filters are executed on the controllers and therefore will consume some amount +of CPU time on the controller. + +## Listing resources + +This section describes how to use filters when listing resources. This can be used +to reduce the returned set of resources when performing a list operation. + + + +This feature is intended to provide a userful service to clients; it does not +affect the database queries generated for the operation and as such is not +designed to provide greater efficiency. + + + +When you run a list action, you can specify a filter. It uses the standard filter syntax used +elsewhere in Boundary. Unless otherwise specified for a given list endpoint, the +list of items being returned is looped through and the filter is run on the JSON +representation of that item. A good way to see what that data looks like is by +looking at representative JSON output on the command line; for example, the +following is the output of `boundary targets list -scope-id p_1234567890 -format json` on a dev instance (piped through `jq` for readability): + +```json +[ + { + "id": "ttcp_1234567890", + "scope_id": "p_1234567890", + "scope": { + "id": "p_1234567890", + "type": "project", + "name": "Generated project scope", + "description": "Provides an initial project scope in Boundary", + "parent_scope_id": "o_1234567890" + }, + "name": "Generated target", + "description": "Provides an initial target in Boundary", + "created_time": "2021-02-24T22:19:50.640476Z", + "updated_time": "2021-02-24T22:19:50.640476Z", + "version": 1, + "type": "tcp", + "session_max_seconds": 28800, + "session_connection_limit": -1, + "attributes": { + "default_port": 22 + }, + "authorized_actions": [ + "read", + "update", + "delete", + "add-host-sources", + "set-host-sources", + "remove-host-sources", + "authorize-session" + ] + } +] +``` + +As the filter tests each entry being returned, it places the data under test +within the filter at `/item`. + +On the CLI a filter can be given via `-filter`. + +Double quotes are part of the filter syntax; when using the CLI, it is likely +easier to surround the filter with single quotes than to deal with escaping +double quotes. + +When using the HTTP API, it is a `filter` query parameter. + +Ensure that the query parameter is properly escaped! Most HTTP libraries will +do this for you. If you're having trouble, try using the `-output-curl-string` +flag with the Boundary CLI: + +``` +$ boundary targets list -scope-id p_1234567890 -format json -filter '"authorize-session" in "/item/authorized_actions"' -output-curl-string +curl -H "Authorization: Bearer $(boundary config get-token -keyring-type pass -token-name default)" -H "Content-Type: application/json" 'http://127.0.0.1:9200/v1/targets?filter=%22authorize-session%22+in+%22%2Fitem%2Fauthorized_actions%22&scope_id=p_1234567890' +``` + +Following are some examples. + +- Resources in which the user is allowed to run an "update" action: + `"update" in "/item/authorized_actions"` + +- Resources matching a name pattern, but only those within an organization + scope: `"/item/name" matches "groupa-*" and "/item/scope/type" == "org"` diff --git a/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx b/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx index ff14b8004..beede4c07 100644 --- a/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx +++ b/website/content/docs/getting-started/dev-mode/connect-to-dev-target.mdx @@ -30,7 +30,7 @@ boundary connect -target-id ttcp_0987654321 For the purpose of this guide, both of these targets accomplish the same goal, however they have different purposes. Refer to the -[domain](/boundary/docs/concepts/domain-model/index) documentation for more information. +[domain model](/boundary/docs/domain-model/) documentation for more information. For the rest of this guide, assume the default is used. @@ -82,7 +82,7 @@ These are written as `boundary connect ` and are supported for the f - RDP - SSH -Refer to the [Connect helpers](/boundary/docs/concepts/connection-workflows/connect-helpers) documentation for more information. +Refer to the [Connect helpers](/boundary/docs/targets/connections/connect-helpers) documentation for more information. ## Built-in vs. exec @@ -93,7 +93,7 @@ tool, allowing you to wrap Boundary TCP sessions in your preferred client. You can use this flag to create an authenticated proxy to almost anything. -Refer to the [Exec flag](/boundary/docs/concepts/connection-workflows/exec-flag) documentation for more information. +Refer to the [Exec flag](/boundary/docs/targets/connections/exec-flag) documentation for more information. ## SSH ProxyCommand @@ -101,7 +101,7 @@ SSH `ProxyCommand` lets you proxy an SSH connection to a target according to a c It can help simplify common developer and operator workflows. You can configure the file to connect to the target ID or the target domain. -Refer to the [SSH ProxyCommand](/boundary/docs/concepts/connection-workflows/workflow-ssh-proxycommand) documentation for more information. +Refer to the [SSH ProxyCommand](/boundary/docs/targets/connections/workflow-ssh-proxycommand) documentation for more information. ## Desktop client @@ -124,5 +124,5 @@ proxy details. ## Next steps See our [basic administration -workflows](/boundary/tutorials/oss-administration) +workflow](/boundary/tutorials/community-administration) tutorials for in depth discussion on managing scopes, targets, identities, and sessions. diff --git a/website/content/docs/getting-started/dev-mode/dev-mode.mdx b/website/content/docs/getting-started/dev-mode/index.mdx similarity index 71% rename from website/content/docs/getting-started/dev-mode/dev-mode.mdx rename to website/content/docs/getting-started/dev-mode/index.mdx index a42c98132..667d82852 100644 --- a/website/content/docs/getting-started/dev-mode/dev-mode.mdx +++ b/website/content/docs/getting-started/dev-mode/index.mdx @@ -10,9 +10,13 @@ description: >- 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 installation method, and provides a way to get Boundary running with a Postgres -database easily. Do not use dev mode in a production environment, see the -[Production Installation](/boundary/docs/oss/installing/high-availability) section for -production-ready deployment methods. +database easily. + +Do not use dev mode in a production environment, refer to the following sections for production-ready deployment methods: + +- [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed) +- [Deploy HCP Boundary](/boundary/docs/hcp/get-started/deploy-and-login) +- [Terraform patterns for Boundary](/boundary/docs/deploy/terraform-patterns) Dev mode brings up a fully-functioning instance of Boundary, including: @@ -25,22 +29,22 @@ across dev mode restarts. Along with these external components, dev mode also creates several resources within Boundary to make it easier and faster to connect to your first target: -1. An org [scope](/boundary/docs/concepts/domain-model/scopes) and a project scope with a +1. An org [scope](/boundary/docs/domain-model/scopes) and a project scope with a default ID of `o_1234567890` and `p_1234567890` respectively. -1. A password [auth method](/boundary/docs/concepts/domain-model/auth-methods) with a +1. A password [auth method](/boundary/docs/domain-model/auth-methods) with a default auth method ID of `ampw_1234567890`. -1. An OIDC [auth method](/boundary/docs/concepts/domain-model/auth-methods) with a +1. An OIDC [auth method](/boundary/docs/domain-model/auth-methods) with a default auth method ID of `amoidc_1234567890`. 1. An admin user with login name `admin` and password `password`. 1. An unprivileged user with login name `user` and password `password`. -1. A static [host catalog](/boundary/docs/concepts/domain-model/host-catalogs) with a +1. A static [host catalog](/boundary/docs/domain-model/host-catalogs) with a default ID of `hcst_1234567890`. -1. A static [host](/boundary/docs/concepts/domain-model/hosts) and [host - set](/boundary/docs/concepts/domain-model/host-sets) with default ID's of +1. A static [host](/boundary/docs/domain-model/hosts) and [host + set](/boundary/docs/domain-model/host-sets) with default ID's of `hst_1234567890` and `hsst_1234567890` respectively. -1. A TCP [target](/boundary/docs/concepts/domain-model/targets) with a default ID of +1. A TCP [target](/boundary/docs/domain-model/targets) with a default ID of `ttcp_1234567890`, directly set-up with an address and port. -1. A TCP [target](/boundary/docs/concepts/domain-model/targets) with a default ID of +1. A TCP [target](/boundary/docs/domain-model/targets) with a default ID of `ttcp_0987654321` using the previously mentioned static host set. The default ID suffixes can be overwritten or randomly generated, and there are diff --git a/website/content/docs/getting-started/dev-mode/run-and-login.mdx b/website/content/docs/getting-started/dev-mode/run-and-login.mdx index 93c212ea3..c4568b9be 100644 --- a/website/content/docs/getting-started/dev-mode/run-and-login.mdx +++ b/website/content/docs/getting-started/dev-mode/run-and-login.mdx @@ -68,12 +68,10 @@ name and password: -

- -To authenticate using the Boundary desktop client, launch Boundary desktop client -and connect to boundary to using [http://127.0.0.1:9200](http://127.0.0.1:9200) -and enter the login name and password: +To authenticate using the Boundary desktop client, launch the Boundary desktop client +and connect to Boundary using [http://127.0.0.1:9200](http://127.0.0.1:9200), +then enter the login name and password: -

 @@ -117,5 +114,5 @@ the Boundary server does not use TLS in development mode. ## Next steps See [connecting to your first -target](/boundary/docs/oss/installing/connect-to-dev-target) for how to use Boundary to +target](/boundary/docs/getting-started/dev-mode/connect-to-dev-target) for how to use Boundary to run your first SSH session. diff --git a/website/content/docs/getting-started/index.mdx b/website/content/docs/getting-started/index.mdx index 1c2b59437..75aa719cc 100644 --- a/website/content/docs/getting-started/index.mdx +++ b/website/content/docs/getting-started/index.mdx @@ -23,9 +23,9 @@ There are three options to get started with Boundary: - **Boundary Enterprise** is a customer-hosted offering of Boundary with Enterprise support. It has full feature-parity with HCP Boundary. The Enterprise version is self-managed in your environment, making it the perfect choice for agencies that are not able to use SaaS products for compliance or regulatory reasons. -The [Install Boundary](/boundary/docs/install-boundary) section can help you build a self-managed production environment using Boundary Enterprise. +The [Deploy Boundary](/boundary/docs/deploy/self-managed) section can help you build a self-managed production environment using Boundary Enterprise. - **Boundary Community Edition** is a free distribution of Boundary that users can run - in their own environments. The [Dev Mode quick start](/boundary/docs/oss/installing/dev-mode) section discusses running Boundary + in their own environments. The [Dev Mode quick start](/boundary/docs/getting-started/dev-mode) section discusses running Boundary in Dev mode on your local machine, allowing you to get started with the Community Edition distribution quickly. We recommend you use the Boundary model that best meets your intended use case. @@ -34,6 +34,12 @@ started with HCP Boundary](/boundary/docs/getting-started/deploy-and-login) sect ## 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 -familiarize yourself with Boundary's architecture and terminology. +Before getting started with Boundary, it's important to understand a few key concepts. +Please consult any of the following Boundary concepts pages to familiarize yourself with Boundary's architecture and terminology: + +- [Auditing](/boundary/docs/concepts/auditing) +- [Identity and access management](/boundary/docs/concepts/iam) +- [Credential management](/boundary/docs/concepts/credential-management) +- [Workers](/boundary/docs/concepts/workers) +- [Aliases](/boundary/docs/concepts/aliases) +- [Transparent sessions](/boundary/docs/concepts/transparent-sessions) diff --git a/website/content/docs/api-clients/go-sdk.mdx b/website/content/docs/go-sdk/index.mdx similarity index 94% rename from website/content/docs/api-clients/go-sdk.mdx rename to website/content/docs/go-sdk/index.mdx index b1d6232ee..a9bc733de 100644 --- a/website/content/docs/api-clients/go-sdk.mdx +++ b/website/content/docs/go-sdk/index.mdx @@ -11,8 +11,8 @@ Boundary has a Go SDK that sports full coverage of Boundary's API. This SDK is m -The Boundary API is configured with [rate limiting](/boundary/docs/api-clients/api#rate-limiting), by default. -If the Boundary SDK client is unable to process a request due to a rate limit being met, it sends the API a `429` or `523` [status code](/boundary/docs/api-clients/api#status-codes) and limits the request. +The Boundary API is configured with [rate limiting](/boundary/docs/api/rate-limiting), by default. +If the Boundary SDK client is unable to process a request due to a rate limit being met, it sends the API a `429` or `523` [status code](/boundary/docs/api#status-codes) and limits the request. By default the client will wait for the amount of time specified in the `Retry-After` header and then try again for a maximum of 2 retries. @@ -21,7 +21,7 @@ Below, an example walks through using the SDK to authenticate against an auth me ## Authenticating to Boundary with the Go SDK -Authenticating to Boundary starts with an [Auth Method](/boundary/docs/concepts/domain-model/auth-methods). An auth method provides +Authenticating to Boundary starts with an [auth method](/boundary/docs/domain-model/auth-methods). An auth method provides the basic identity delegation needed for Boundary to generate a token for a client. There are two primary methods for authenticating to Boundary: @@ -36,7 +36,7 @@ This is the most common way for a client to authenticate to Boundary. To demonst use the [authmethods](https://github.com/hashicorp/boundary/tree/main/api/authmethods) library to generate a valid token for a client in Go. -For this example, we're going to use the [password auth method](/boundary/docs/concepts/domain-model/auth-methods#password-auth-method-attributes). This example +For this example, we're going to use the [password auth method](/boundary/docs/domain-model/auth-methods#password-auth-method-attributes). This example assumes there's already a valid user and an associated account in Boundary against which the client can authenticate. To simplify this example, we're assuming you're running a Boundary instance in dev mode, where the default auth diff --git a/website/content/docs/hcp/get-started/connect-to-target.mdx b/website/content/docs/hcp/get-started/connect-to-target.mdx index 8f4fc2fa0..7e63cc02e 100644 --- a/website/content/docs/hcp/get-started/connect-to-target.mdx +++ b/website/content/docs/hcp/get-started/connect-to-target.mdx @@ -8,7 +8,7 @@ description: >- # Connect to your first target The [Quick setup -wizard](/boundary/docs/getting-started/deploy-and-login#login-to-hcp-boundary) +wizard](/boundary/docs/hcp/get-started/deploy-and-login#log-in-to-hcp-boundary) is the fastest way to onboard a target to HCP Boundary. ![Setup Wizard](/img/setup-wizard-address-target.png) @@ -83,7 +83,7 @@ Boundary includes connect helpers for the following connection types: - RDP - SSH -Refer to the [Connect helpers](/boundary/docs/concepts/connection-workflows/connect-helpers) documentation for more information. +Refer to the [Connect helpers](/boundary/docs/targets/connections/connect-helpers) documentation for more information. ## Exec flag @@ -94,7 +94,7 @@ tool, allowing you to wrap Boundary TCP sessions in your preferred client. You can use this flag to create an authenticated proxy to almost anything. -Refer to the [Exec flag](/boundary/docs/concepts/connection-workflows/exec-flag) documentation for more information. +Refer to the [Exec flag](/boundary/docs/targets/connections/exec-flag) documentation for more information. ## SSH ProxyCommand @@ -102,7 +102,7 @@ SSH `ProxyCommand` lets you proxy an SSH connection to a target according to a c It can help simplify common developer and operator workflows. You can configure the file to connect to the target ID or the target domain. -Refer to the [SSH ProxyCommand](/boundary/docs/concepts/connection-workflows/workflow-ssh-proxycommand) documentation for more information. +Refer to the [SSH ProxyCommand](/boundary/docs/targets/connections/workflow-ssh-proxycommand) documentation for more information. ## Desktop client diff --git a/website/content/docs/hcp/get-started/deploy-and-login.mdx b/website/content/docs/hcp/get-started/deploy-and-login.mdx index c22dbebf3..5b6d654fb 100644 --- a/website/content/docs/hcp/get-started/deploy-and-login.mdx +++ b/website/content/docs/hcp/get-started/deploy-and-login.mdx @@ -27,9 +27,8 @@ To get started with HCP Boundary, users need: - Optionally, an [installation of Boundary Desktop](/boundary/tutorials/hcp-getting-started/hcp-getting-started-desktop-app) -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 -Community Edition and self-managed installations, refer to [Boundary Community Edition](/boundary/docs/oss). +If you prefer to test Boundary on your local machine, refer to [Run and log in to Boundary](/boundary/docs/oss/installing/run-and-login). For more information on Boundary +Community Edition and self-managed installations, refer to [Which edition of Boundary is right for me?](/boundary/docs/what-is-boundary#which-edition-of-boundary-is-right-for-me) or [Deploy Boundary in a self-managed environment](/boundary/docs/deploy/self-managed). ## Deploy an HCP Boundary cluster @@ -227,5 +226,4 @@ To find your environment’s default `auth_method_id`: ## 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. +Refer to [Connect to your first target](/boundary/docs/getting-started/connect-to-target) to use HCP Boundary to run your first SSH session. diff --git a/website/content/docs/concepts/host-discovery/aws.mdx b/website/content/docs/hosts/aws.mdx similarity index 90% rename from website/content/docs/concepts/host-discovery/aws.mdx rename to website/content/docs/hosts/aws.mdx index a452eb888..03b38f575 100644 --- a/website/content/docs/concepts/host-discovery/aws.mdx +++ b/website/content/docs/hosts/aws.mdx @@ -27,7 +27,7 @@ HashiCorp recommends using dynamic credentials when possible. Select a credentia Boundary needs the following IAM privileges, at the very least, to be attached to a configured IAM user. -Configure `DescribeInstances` to `*`. `DescribeInstances` cannot be scoped to a resource ARN. +Configure `DescribeInstances` to `*`. `DescribeInstances` cannot be scoped to a resource ARN. Example policy: @@ -74,13 +74,13 @@ To allow static credential rotation, add the `iam:GetUser`, `iam:CreateAccessKey -This feature requires a self-managed Boundary [worker](/boundary/docs/install-boundary/configure-workers). +This feature requires a self-managed Boundary [worker](/boundary/docs/deploy/self-managed/deploy-workers). To set up a dynamic host catalog using an AWS role, a self-managed worker must assume the role. You must assign the role to the self-managed worker AWS instance, and then supply a worker filter that matches the AWS worker when you set up the dynamic host catalog. Perform the following steps to set up a host catalog using [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html): -1. Deploy a self-managed worker in your AWS account. The worker must be in the same VPC as the hosts you want to access using the dynamic host catalog. Consider [adding worker tags](/boundary/docs/concepts/filtering/worker-tags) to make it easier to route traffic through it using a worker filter later on. +1. Deploy a self-managed worker in your AWS account. The worker must be in the same VPC as the hosts you want to access using the dynamic host catalog. Consider [adding worker tags](/boundary/docs/workers/worker-tags) to make it easier to route traffic through it using a worker filter later on. 1. Create an IAM role with the `AmazonEC2ReadOnlyAccess` policy attached, or define a custom policy with the `ec2:DescribeInstances` action allowed for all resources. This policy should contain the following, at least: @@ -185,7 +185,7 @@ The required fields for creating a dynamic host catalog depend on whether you co - `access_key_id`: The access key ID for the IAM user to use with this host catalog. - `secret_access_key`: The secret access key for the IAM user to use with this host catalog. - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -218,9 +218,9 @@ The required fields for creating a dynamic host catalog depend on whether you co - `role_external_id`: The external ID that you configured for the `AssumeRole` provider. - `role_session_name`: The session name that you configured for the `AssumeRole` provider. - `role_tags`: The key-value pair tags that you configured for the `AssumeRole` provider. - - `worker-filter` A boolean expression to filter which workers can handle dynamic host catalog commands for this host catalog. This should match a valid filter expression for the self-managed worker deployed in AWS. Refer to worker [Filter examples](/boundary/docs/concepts/filtering/worker-tags#filter-workers-using-tags) to learn more. + - `worker-filter` A boolean expression to filter which workers can handle dynamic host catalog commands for this host catalog. This should match a valid filter expression for the self-managed worker deployed in AWS. Refer to worker [Filter examples](/boundary/docs/workers/worker-tags#filter-workers-using-tags) to learn more. - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -264,7 +264,7 @@ Replace the values in the configuration with the following required AWS secrets - `access_key_id`: The access key ID for the IAM user to use with this host catalog. - `secret_access_key`: The secret access key for the IAM user to use with this host catalog. -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -294,7 +294,7 @@ The `scope_id` and `plugin_name` fields are required when you create a dynamic h Replace the values in the configuration with the following required AWS secrets and any attributes you want to associate with the host catalog: - - `worker_filter`: A boolean expression to filter which workers can handle dynamic host catalog commands for this host catalog. This should match a valid filter expression for the self-managed worker deployed in AWS. Refer to worker [Filter examples](/boundary/docs/concepts/filtering/worker-tags#filter-workers-using-tags) to learn more. + - `worker_filter`: A boolean expression to filter which workers can handle dynamic host catalog commands for this host catalog. This should match a valid filter expression for the self-managed worker deployed in AWS. Refer to worker [Filter examples](/boundary/docs/workers/worker-tags#filter-workers-using-tags) to learn more. - `disable_credential_rotation`: When set to `true`, Boundary does not rotate the credentials with AWS automatically. You must disable credential rotation to use dynamic credentials. - `region`: The region to configure the host catalog for. All host sets in this catalog are configured for this region. @@ -303,7 +303,7 @@ Replace the values in the configuration with the following required AWS secrets - `role_session_name`: The session name that you configured for the `AssumeRole` provider. - `role_tags`: The key-value pair tags that you configured for the `AssumeRole` provider. -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -313,7 +313,7 @@ Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/h ## Create a host set to connect with AWS -[Host sets](/boundary/docs/concepts/domain-model/host-sets) specify which AWS filters should be used to identify the discovered hosts that should be added as members. +[Host sets](/boundary/docs/domain-model/host-sets) specify which AWS filters should be used to identify the discovered hosts that should be added as members. Complete the following steps to create a host set: @@ -356,7 +356,7 @@ Complete the following steps to create a host set: When multiple filters fields are provided, they must all match for a host to match. In the example above, an instance must have either tags `foo` or `bar`, and must have the tag `baz`. - For more fields that you can use when creating host sets, refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-sets). + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -383,8 +383,12 @@ When the values in a single `filters` field are separated by a comma, either can When multiple filters fields are provided, they must all match for a host to match. In the example above, an instance must have either tags `foo` or `bar`, and must have the tag `baz`. -For more fields that you can use when creating host sets, refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-sets). +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. + +## More information + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. diff --git a/website/content/docs/concepts/host-discovery/azure.mdx b/website/content/docs/hosts/azure.mdx similarity index 90% rename from website/content/docs/concepts/host-discovery/azure.mdx rename to website/content/docs/hosts/azure.mdx index a185b0a27..0f44c4d0a 100644 --- a/website/content/docs/concepts/host-discovery/azure.mdx +++ b/website/content/docs/hosts/azure.mdx @@ -67,7 +67,7 @@ Complete the following steps to create a dynamic host catalog for Azure: - `client_id`: (Required) The client (application) ID of the Azure service principal that Boundary should use to authenticate and discover hosts. - `secret_value`: (Required) The ARM client secret value that Azure generates for authentication. - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -107,13 +107,13 @@ Azure host catalogs do not currently support credential rotation. - `client_id`: (Required) The client (application) ID of the Azure service principal that Boundary should use to authenticate and discover hosts. - `secret_value`: (Required) The ARM client secret value that Azure generates for authentication. -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. ## Create a host set to connect with Azure -[Host sets](/boundary/docs/concepts/domain-model/host-sets) specify which Azure +[Host sets](/boundary/docs/domain-model/host-sets) specify which Azure Resource Manager (ARM) filters should be used to identify the discovered hosts that should be added as members. Complete the following steps to create a host set: @@ -157,7 +157,7 @@ Complete the following steps to create a host set: - `tagName eq 'application'` - `tagName eq 'application' and tagValue eq 'app2'` - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -190,7 +190,11 @@ The `filter` field represents the ARM filter used to select resources that shoul - `tagName eq 'application'` - `tagName eq 'application' and tagValue eq 'app2'` -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. + +## More information + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. \ No newline at end of file diff --git a/website/content/docs/concepts/host-discovery/gcp.mdx b/website/content/docs/hosts/gcp.mdx similarity index 92% rename from website/content/docs/concepts/host-discovery/gcp.mdx rename to website/content/docs/hosts/gcp.mdx index 8a94aeb61..557f15b17 100644 --- a/website/content/docs/concepts/host-discovery/gcp.mdx +++ b/website/content/docs/hosts/gcp.mdx @@ -185,7 +185,7 @@ The required fields for creating a dynamic host catalog depend on the type of au If you downloaded the private key from GCP, it may contain extra `/n` characters that cause an error. You can use `jq` to remove the extra `/n` characters. - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -227,7 +227,7 @@ The required fields for creating a dynamic host catalog depend on the type of au If you downloaded the private key from GCP, it may contain extra `/n` characters that cause an error. You can use `jq` to remove the extra `/n` characters. - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -254,7 +254,7 @@ The required fields for creating a dynamic host catalog depend on the type of au All host sets in this catalog are configured for this zone. - `project_id`: (Required) The project ID associated with the service account. - Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -309,7 +309,7 @@ Apply the following Terraform policy: If you downloaded the private key from GCP, it may contain extra `/n` characters that cause an error. You can use `jq` to remove the extra `/n` characters. -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -359,7 +359,7 @@ It is required when you authenticate using service account impersonation. If you downloaded the private key from GCP, it may contain extra `/n` characters that cause an error. You can use `jq` to remove the extra `/n` characters. -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -392,7 +392,7 @@ The fields following `attributes_json` are specific to GCP and are required by B - `project_id`: (Required) The project ID of any instances that you want to add to the host catalog. - `disable_credential_rotation`: (Optional) When set to `true`, Boundary does not rotate the credentials with GCP automatically. -Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-catalogs) for additional fields that you can use when you create host catalogs. +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -402,7 +402,7 @@ Refer to [the domain model documentation](/boundary/docs/concepts/domain-model/h ## Create a host set to connect with GCP -[Host sets](/boundary/docs/concepts/domain-model/host-sets) specify which GCP filters Boundary should use to identify which discovered hosts that should be added as members. +[Host sets](/boundary/docs/domain-model/host-sets) specify which GCP filters Boundary should use to identify which discovered hosts that should be added as members. Complete the following steps to create a host set: @@ -452,7 +452,7 @@ Complete the following steps to create a host set: - `-attr filters=labels.env:dev` - `-attr filters="labels.env:prod AND labels.app:web"` - For more fields that you can use when creating host sets, refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-sets). + Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. @@ -488,7 +488,11 @@ We recommend using labels as filters because they are more flexible and can filt - `-attr filters=labels.env:dev` - `-attr filters="labels.env:prod AND labels.app:web"` -For more fields that you can use when creating host sets, refer to [the domain model documentation](/boundary/docs/concepts/domain-model/host-sets). +Refer to the [host catalogs](/boundary/docs/domain-model/host-catalogs) domain model documentation for additional fields that you can use when you create host catalogs. + +## More information + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. \ No newline at end of file diff --git a/website/content/docs/concepts/host-discovery/index.mdx b/website/content/docs/hosts/index.mdx similarity index 86% rename from website/content/docs/concepts/host-discovery/index.mdx rename to website/content/docs/hosts/index.mdx index a1a57dbf1..15f1a8a58 100644 --- a/website/content/docs/concepts/host-discovery/index.mdx +++ b/website/content/docs/hosts/index.mdx @@ -24,13 +24,13 @@ as hosts. Boundary supports target/host discovery in three primary workflows: -**[Manual configuration](/boundary/tutorials/oss-administration/oss-manage-targets)**: +**[Manual configuration](/boundary/tutorials/community-administration/community-manage-targets)**: Boundary administrators can manually configure static hosts and targets via the administrator UI and CLI. Manual configuration of targets with static hosts requires knowledge of the IP address or endpoint used to connect to a host. -**[Host discovery via configuration as code with Terraform](/boundary/tutorials/oss-getting-started/oss-getting-started-config)**: +**[Host discovery via configuration as code with Terraform](/boundary/tutorials/get-started-community/community-get-started-config)**: Boundary is fully programmatically instrumented and the discovery and configuration of new infrastructure targets can be automated with [Boundary’s Terraform provider](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs). @@ -50,7 +50,7 @@ Dynamic host catalogs are an agentless workflow for Boundary to securely query infrastructure providers at runtime to discover and configure new services. Boundary administrators can define rules for which external resources should be ingested into the catalog by -[creating a host sets](/boundary/docs/concepts/domain-model/host-sets) +[creating a host set](/boundary/docs/domain-model/host-sets) with an attributes filter. These filters specify which discovered hosts should be members of the host set. @@ -60,6 +60,6 @@ We will continue to grow this ecosystem to support additional providers. ## Next steps To get started with dynamic host catalogs, refer to the following topics: -- [AWS dynamic host catalogs](/boundary/docs/concepts/host-discovery/aws) -- [Azure dynamic host catalogs](/boundary/docs/concepts/host-discovery/azure) -- [GCP dynamic host catalogs](/boundary/docs/concepts/host-discovery/gcp) +- [AWS dynamic host catalogs](/boundary/docs/hosts/aws) +- [Azure dynamic host catalogs](/boundary/docs/hosts/azure) +- [GCP dynamic host catalogs](/boundary/docs/hosts/gcp) diff --git a/website/content/docs/install-boundary/configure-workers.mdx b/website/content/docs/install-boundary/configure-workers.mdx deleted file mode 100644 index 65c600dd7..000000000 --- a/website/content/docs/install-boundary/configure-workers.mdx +++ /dev/null @@ -1,612 +0,0 @@ ---- -layout: docs -page_title: Configure workers -description: >- - Configure Boundary workers for a self-managed deployment, including environment files and KMS keys. Set up ingress, intermediary, and egress roles for multi-hop. ---- - -# Configure workers - -Before you configure workers, you should have completed the following steps: - -- Installed Boundary on at least three [controller nodes](/boundary/docs/install-boundary/configure-controllers). -- Prepared or have three existing network boundaries: - - Public/DMZ network - - Intermediary network - - Private network -- Prepared three virtual machines for Boundary workers, one in each network boundary with the Boundary binary installed on it. - -In the following configuration files, there are common configuration components as well as some unique components depending on the role the Boundary worker performs. -There are three files, one for each worker in a unique network boundary. -Additionally, Boundary Enterprise supports a [multi-hop configuration](/boundary/docs/configuration/worker#multi-hop-worker-capabilities) in which the Boundary workers can serve one of three purposes: an ingress worker, an ingress/egress worker, or an egress worker. - -## Prepare the environment files - -HashiCorp recommends using either the `env://` or `file://` notation within the configuration files, to securely provide secret configuration components to the Boundary worker binaries. -The following configuration example uses `env://` to secure AWS KMS configuration items. - -When you install the Boundary binary using a package manager, it includes a unit file which configures an environment file at `/etc/boundar.d/boundary.env`. -You can use this file to set the sensitive values that are used to configure the Boundary workers. -The following file is an example of how this environment file could be configured: - - - -```shell-session -AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE -AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -``` - - - - - -In the example above, the proper IAM roles and permissions for the given `AWS_ACCESS_KEY` and `AWS_SECRET_ACCESS_KEY` must be in place so that Boundary can use them to access the different KMS keys. - - - -## Prepare the worker KMS keys - -The worker-auth storage KMS key is used by a Worker for the encrypted storage of authentication keys. -This is recommended Workers using controller-led or worker-led methods. If it is not specified, the authentication keys are not encrypted on disk. -Optionally, if you deploy KMS authentication-driven Boundary workers, an additional KMS key must be generated to authenticate the Boundary worker with the controller. - -HashiCorp strongly recommends using the Key Management System (KMS) of the cloud provider where you deploy your Boundary workers. -Keep in mind that Boundary workers must have the correct level of permissions for interacting with the cloud provider's KMS. -Refer to your cloud provider's documentation, for more information. - -## Create the worker configurations - -After you create the requisite key or keys in the cloud provider of your choice, you can begin configuring the workers. - -The following configuration examples all employ the worker-led authorization flow. -For more information on configuring KMS authentication for Boundary workers, refer to the [KMS authentication configuration documenation](/boundary/docs/configuration/worker/worker-configuration). - -If you use Boundary Enterprise, you can configure multiple workers to act in three different roles: ingress, intermediary, and egress. -For Community Edition, workers only serve one role, acting as both the point of ingress and egress. -Select your Boundary edition, and complete the following steps to configure workers. - - - - -For Boundary Enterprise, you can configure ingress, intermediary, and egress workers to take advantage of [multi-hop worker capabilities](/boundary/docs/configuration/worker#multi-hop-worker-capabilities). - -Note that "ingress," "intermediary," and "egress" are general ways to describe how the respective worker interacts with resources. -A worker can serve more than one of those roles at a time. -Refer to [Multi-hop sessions](/boundary/docs/concepts/workers#multi-hop-sessions) for more information. - -Complete the steps below to configure workers for Boundary Enterprise. - -### Ingress worker configuration - -Create the `ingress-worker.hcl` file with the relevant configuration information: - - - -```hcl -# disable memory from being swapped to disk -disable_mlock = true - -# listener denoting this is a worker proxy -listener "tcp" { - address = "0.0.0.0:9202" - purpose = "proxy" -} - -# worker block for configuring the specifics of the -# worker service -worker { - public_addr = "" - initial_upstreams = [":9201"] - auth_storage_path = "/var/lib/boundary" - tags { - type = ["worker1", "upstream"] - } -} - -# Events (logging) configuration. This -# configures logging for ALL events to both -# stderr and a file at /var/log/boundary/.log -events { - audit_enabled = true - sysevents_enabled = true - observations_enable = true - sink "stderr" { - name = "all-events" - description = "All events sent to stderr" - event_types = ["*"] - format = "cloudevents-json" - } - sink { - name = "file-sink" - description = "All events sent to a file" - event_types = ["*"] - format = "cloudevents-json" - file { - path = "/var/log/boundary" - file_name = "ingress-worker.log" - } - audit_config { - audit_filter_overrides { - sensitive = "redact" - secret = "redact" - } - } - } -} - -# kms block for encrypting the authentication PKI material -kms "awskms" { - purpose = "worker-auth-storage" - region = "us-east-1" - kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey3" - endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" -} -``` - - - -### Intermediate worker configuration - -Create the `intermediate-worker.hcl` file with the relevant configuration information: - - - -```hcl -# disable memory from being swapped to disk -disable_mlock = true - -# listener denoting this is a worker proxy -listener "tcp" { - address = "0.0.0.0:9202" - purpose = "proxy" -} - -# worker block for configuring the specifics of the -# worker service -worker { - public_addr = "" - initial_upstreams = [":9202"] - auth_storage_path = "/var/lib/boundary" - tags { - type = ["worker2", "intermediate"] - } -} - -# Events (logging) configuration. This -# configures logging for ALL events to both -# stderr and a file at /var/log/boundary/.log -events { - audit_enabled = true - sysevents_enabled = true - observations_enable = true - sink "stderr" { - name = "all-events" - description = "All events sent to stderr" - event_types = ["*"] - format = "cloudevents-json" - } - sink { - name = "file-sink" - description = "All events sent to a file" - event_types = ["*"] - format = "cloudevents-json" - file { - path = "/var/log/boundary" - file_name = "intermediate-worker.log" - } - audit_config { - audit_filter_overrides { - sensitive = "redact" - secret = "redact" - } - } - } -} - -# kms block for encrypting the authentication PKI material -kms "awskms" { - purpose = "worker-auth-storage" - region = "us-east-1" - kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey4" - endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" -} -``` - - - -### Egress worker configuration - -Create the `egress-worker.hcl` file with the relevant configuration information: - - - -```hcl -# disable memory from being swapped to disk -disable_mlock = true - -# listener denoting this is a worker proxy -listener "tcp" { - address = "0.0.0.0:9202" - purpose = "proxy" -} - -# worker block for configuring the specifics of the -# worker service -worker { - public_addr = "" - initial_upstreams = [":9202"] - auth_storage_path = "/var/lib/boundary" - tags { - type = ["worker3", "egress"] - } -} - -# Events (logging) configuration. This -# configures logging for ALL events to both -# stderr and a file at /var/log/boundary/.log -events { - audit_enabled = true - sysevents_enabled = true - observations_enable = true - sink "stderr" { - name = "all-events" - description = "All events sent to stderr" - event_types = ["*"] - format = "cloudevents-json" - } - sink { - name = "file-sink" - description = "All events sent to a file" - event_types = ["*"] - format = "cloudevents-json" - file { - path = "/var/log/boundary" - file_name = "egress-worker.log" - } - audit_config { - audit_filter_overrides { - sensitive = "redact" - secret = "redact" - } - } - } -} - -# kms block for encrypting the authentication PKI material -kms "awskms" { - purpose = "worker-auth-storage" - region = "us-east-1" - kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey5" - endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" -} -``` - - - -Refer to the list below for explanations of the parameters used in the example above: - -- `disable mlock (bool: false)` - Disables the server from executing the `mlock` syscall, which prevents memory from being swapped to the disk. -This is fine for local development and testing. -However, it is not recommended for production unless the systems running Boundary use only encrypted swap or do not use swap at all. -Boundary only supports memory locking on UNIX-like systems that support `mlock()` syscall like Linux and FreeBSD. - - On Linux, to give the Boundary executable the ability to use `mlock` syscall without running the process as root, run the following command: - - `sudo setcap cap_ipc_lock=+ep $(readlink -f $(which boundary))` - - If you use a Linux distribution with a modern version of systemd, you can add the following directive to the **"[Service]"** configuration section: - - `LimitMEMLOCK=infinity` - -- `listener` - Configures the listeners on which Boundary serves traffic (API cluster and proxy). -- `worker` - Configures the worker. -If present, `boundary server` starts a worker subprocess. -- `events` - Configures event-specific parameters. - - The example events configuration above is exhaustive and writes all events to both `stderr` and a file. - This configuration may or may not work for your organization's logging solution. - -- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/concepts/security/data-encryption). - - Refer to the links below for configuration information for the different cloud KMS blocks: - - - [AWS](/boundary/docs/configuration/kms/awskms) - - [Azure](/boundary/docs/configuration/kms/azurekeyvault) - - [GCP](/boundary/docs/configuration/kms/gcpckms) - - [OCI](/boundary/docs/configuration/kms/ocikms) - - [AliCloud](/boundary/docs/configuration/kms/alicloudkms) - - [Vault Transit](/boundary/docs/configuration/kms/transit) - -Refer to the documentation for additional [top-level configuration options](/boundary/docs/configuration) and additional [controller-specific options](/boundary/docs/configuration/controller). - - - - -For the Community Edition of Boundary, you must configure a worker server that communicates with the controller and is responsible for storage-related tasks. - -Boundary Community Edition only supports egress workers. To configure workers for multi-hop sessions, check the Boundary Enterprise configuration. - -Complete the following steps to configure the worker. - -### Worker configuration - -Create the `egress-worker.hcl` file with the relevant configuration information: - - - -```hcl -# disable memory from being swapped to disk -disable_mlock = true - -# listener denoting this is a worker proxy -listener "tcp" { - address = "0.0.0.0:9202" - purpose = "proxy" -} - -# worker block for configuring the specifics of the -# worker service -worker { - public_addr = "" - initial_upstreams = [":9201"] - auth_storage_path = "/var/lib/boundary" - tags { - type = ["worker", "egress"] - } -} - -# Events (logging) configuration. This -# configures logging for ALL events to both -# stderr and a file at /var/log/boundary/.log -events { - audit_enabled = true - sysevents_enabled = true - observations_enable = true - sink "stderr" { - name = "all-events" - description = "All events sent to stderr" - event_types = ["*"] - format = "cloudevents-json" - } - sink { - name = "file-sink" - description = "All events sent to a file" - event_types = ["*"] - format = "cloudevents-json" - file { - path = "/var/log/boundary" - file_name = "egress-worker.log" - } - audit_config { - audit_filter_overrides { - sensitive = "redact" - secret = "redact" - } - } - } -} - -# kms block for encrypting the authentication PKI material -kms "awskms" { - purpose = "worker-auth-storage" - region = "us-east-1" - kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey5" - endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" -} -``` - - - -Refer to the list below for explanations of the parameters used in the example above: - -- `disable mlock (bool: false)` - Disables the server from executing the `mlock` syscall, which prevents memory from being swapped to the disk. -This is fine for local development and testing. -However, it is not recommended for production unless the systems running Boundary use only encrypted swap or do not use swap at all. -Boundary only supports memory locking on UNIX-like systems that support `mlock()` syscall like Linux and FreeBSD. - - On Linux, to give the Boundary executable the ability to use `mlock` syscall without running the process as root, run the following command: - - `sudo setcap cap_ipc_lock=+ep $(readlink -f $(which boundary))` - - If you use a Linux distribution with a modern version of systemd, you can add the following directive to the **"[Service]"** configuration section: - - `LimitMEMLOCK=infinity` - -- `listener` - Configures the listeners on which Boundary serves traffic (API cluster and proxy). -- `worker` - Configures the worker. -If present, `boundary server` starts a worker subprocess. -- `events` - Configures event-specific parameters. - - The example events configuration above is exhaustive and writes all events to both `stderr` and a file. - This configuration may or may not work for your organization's logging solution. - -- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/concepts/security/data-encryption). - - Refer to the links below for configuration information for the different cloud KMS blocks: - - - [AWS](/boundary/docs/configuration/kms/awskms) - - [Azure](/boundary/docs/configuration/kms/azurekeyvault) - - [GCP](/boundary/docs/configuration/kms/gcpckms) - - [OCI](/boundary/docs/configuration/kms/ocikms) - - [AliCloud](/boundary/docs/configuration/kms/alicloudkms) - - [Vault Transit](/boundary/docs/configuration/kms/transit) - -Refer to the documentation for additional [top-level configuration options](/boundary/docs/configuration) and additional [controller-specific options](/boundary/docs/configuration/controller). - - - - - -## Start the Boundary service - -When the configuration files are in place on each Boundary controller, you can proceed to enable and start the binary on each of the Boundary worker nodes using `systemd`. -Run the following commands to start the service: - -1. `sudo systemctl enable boundary` -1. `sudo systemctl start boundary` - -## Adopt the Workers (optional) - -If you use the Workers as outlined above, you must adopt the Boundary Workers. -Complete the following steps to adopt the workers: - - - - - -Complete the following steps to adopt the worker using the UI: - -1. Log in to Boundary as the admin user. - -1. Select **Workers** in the navigation pane. - -1. Click **New**. - -1. (Optional) You can use the workers page to construct the contents of the `worker.hcl` file, if you did not [create the configuration file](/boundary/docs/install-boundary/configure-workers#create-the-worker-configurations) as part of the installation process above. -Provide the following details, and Boundary constructs the worker configuration file for you: - - Boundary Cluster ID - - Worker Public Address - - Config file path - - Worker Tags - -1. Scroll to the bottom of the **New Worker** page, and paste the **Worker Auth Registration Request** key. -Boundary provides you with the **Worker Auth Registration Request** key in the CLI output when you start the worker. -You can also locate this value in the `auth_request_token` file. - -1. Click **Register Worker**. - -1. Click **Done**. - - The new worker appears on the **Workers** page. - -1. Repeat the registration process for any other workers, such as the intermediate and egress workers. - - - - - -Complete the following steps to adopt the worker using the CLI: - -1. Use the following command to ensure that the `BOUNDARY_ADDR` is set as an environment variable: - - ```hcl - $ export BOUNDARY_ADDR="https://c3a7a20a-f663-40f3-a8e3-1b2f69b3625.boundary.hashicorp.cloud" - ``` - -1. Log into the CLI as the admin user, providing the Auth Method ID, admin login name, and admin password when prompted. - - ```hcl - $ boundary authenticate password \ - -auth-method-id=ampw_KfLAjMS2CG \ - -login-name=admin - ``` - - Example: - - - - ```hcl - $ boundary authenticate password \ - -auth-method-id=ampw_KfLAjMS2CG \ - -login-name=admin - Please enter the password (it will be hidden): - - Authentication information: - Account ID: acctpw_r6crEm0FgM - Auth Method ID: ampw_KfLAjMS2CG - Expiration Time: Mon, 27 Jun 2022 22:03:28 MDT - User ID: u_ysJd0LXX9T - - The token was successfully stored in the chosen keyring and is not displayed here. - ``` - - - -1. Next, use the following command to export the **Worker Auth Request Token** value as an environment variable: - - ```shell-session - $ export WORKER_TOKEN= - ``` - - Boundary provides you with the **Worker Auth Registration Request** key in the CLI output when you start the worker. - You can also locate this value in the `auth_request_token` file. - - The token is used to issue a create worker request that authorizes the worker to Boundary and makes it available. - Currently worker creation is only supported for workers with an authorization token (worker-led and controller-led). - -1. Create a new worker using the worker-led registration method with the following command: - - ```shell-session - $ boundary workers create worker-led -worker-generated-auth-token=$WORKER_TOKEN - - Worker information: - Active Connection Count: 0 - Created Time: Fri, 03 Jan 2025 13:52:04 MST - ID: w_zLGjAbYx1h - Local Storage State: unknown - Type: pki - Updated Time: Fri, 03 Jan 2025 13:52:04 MST - Version: 1 - - Scope: - ID: global - Name: global - Type: global - - Authorized Actions: - no-op - read - update - delete - add-worker-tags - set-worker-tags - remove-worker-tags - ``` - - Confirm the worker registration and view its details by executing the following command and supplying the new worker's id: - - ```shell-session - $ boundary workers read -id w_zLGjAbYx1h - - Worker information: - Active Connection Count: 0 - Address: 127.0.0.1:9202 - Created Time: Fri, 03 Jan 2025 13:52:04 MST - ID: w_zLGjAbYx1h - Last Status Time: 2025-01-03 20:58:41.346537 +0000 UTC - Local Storage State: not configured - Release Version: Boundary v0.18.1+ent - Type: pki - Updated Time: Fri, 03 Jan 2025 13:58:41 MST - Version: 1 - - Scope: - ID: global - Name: global - Type: global - - Tags: - Configuration: - type: ["worker1" "upstream"] - Canonical: - type: ["upstream" "worker1"] - - Authorized Actions: - add-worker-tags - set-worker-tags - remove-worker-tags - no-op - read - update - delete - ``` - -1. Repeat the registration process for any other workers, such as the intermediate and egress workers. - - - - -After configuring workers, you should: - -- [Initialize Boundary](/boundary/docs/install-boundary/initialize) -- [Install the Boundary Clients](/boundary/docs/install-boundary/install-clients) \ No newline at end of file diff --git a/website/content/docs/install-boundary/index.mdx b/website/content/docs/install-boundary/index.mdx deleted file mode 100644 index e6ce23347..000000000 --- a/website/content/docs/install-boundary/index.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: docs -page_title: Overview -description: >- - Discover resources for deploying a self-managed version of Boundary Enterprise or Boundary Community Edition. ---- - -# Overview - -This section details deploying Boundary in a self-managed environment. -You can use the topics in this section to install the Community Edition or the Enterprise version of Boundary. -The section also includes reference architecture, system requirement recommendations, and best practices. - -To deploy HCP Boundary instead, refer to the [HCP Boundary Get Started section](/boundary/docs/hcp/get-started/deploy-and-login). - -This section outlines the following topics for deploying your self-managed environment: - -- Architectural considerations - - [System requirements](/boundary/docs/install-boundary/architecture/system-requirements) - - [Recommended architecture](/boundary/docs/install-boundary/architecture/recommended-architecture) - - [Fault tolerance](/boundary/docs/install-boundary/architecture/fault-tolerance) - - [High availability](/boundary/docs/install-boundary/architecture/high-availability) -- [Deploy Boundary](/boundary/docs/install-boundary/deploy) -- [Configure controllers](/boundary/docs/install-boundary/configure-controllers) -- [Configure workers](/boundary/docs/install-boundary/configure-workers) -- [Initialize Boundary](/boundary/docs/install-boundary/initialize) -- [Install Boundary clients](/boundary/docs/install-boundary/install-clients) -- [Terraform patterns](/boundary/docs/install-boundary/terraform-patterns) \ No newline at end of file diff --git a/website/content/docs/integrations/index.mdx b/website/content/docs/integrations/index.mdx deleted file mode 100644 index 55a23b521..000000000 --- a/website/content/docs/integrations/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -layout: docs -page_title: Integrations -description: >- - Discover integrations that extend Boundary's features and capabilities. ---- - -# Overview - -This section details integrations that extend Boundary's features and capabilities. - -Use the navigation on the left to learn more about a topic. diff --git a/website/content/docs/configuration/target-aliases/interoperability-matrix.mdx b/website/content/docs/interoperability-matrix/index.mdx similarity index 92% rename from website/content/docs/configuration/target-aliases/interoperability-matrix.mdx rename to website/content/docs/interoperability-matrix/index.mdx index 55ff2dec1..3e4bea9cb 100644 --- a/website/content/docs/configuration/target-aliases/interoperability-matrix.mdx +++ b/website/content/docs/interoperability-matrix/index.mdx @@ -57,7 +57,7 @@ Any patches or updates will be reflected in the minor number. Windows: 10 Pro, 11 Pro - Refer to Conflicting software + Refer to Conflicting software @@ -81,7 +81,7 @@ Any patches or updates will be reflected in the minor number. Windows: 10 Pro, 11 Pro - Refer to Conflicting software + Refer to Conflicting software @@ -173,5 +173,5 @@ Any patches or updates will be reflected in the minor number. For more information, refer to the following topics: - [Transparent sessions](/boundary/docs/concepts/transparent-sessions) -- [Configure transparent sessions](/boundary/docs/configuration/target-aliases/transparent-sessions) -- [Boundary Client Agent](/boundary/docs/api-clients/client-agent) \ No newline at end of file +- [Configure transparent sessions](/boundary/docs/targets/configuration/configure-transparent-sessions) +- [Boundary Client Agent](/boundary/docs/client-agent) \ No newline at end of file diff --git a/website/content/docs/monitor/events/common.mdx b/website/content/docs/monitor/events/common.mdx new file mode 100644 index 000000000..4971f5c3e --- /dev/null +++ b/website/content/docs/monitor/events/common.mdx @@ -0,0 +1,22 @@ +--- +layout: docs +page_title: Controller/worker - events - common sink parameters +description: |- + The common sink parameters for all sink types. +--- + +# Common sink parameters + +@include '/configuration-reference/events/common-sink-intro.mdx' + +## `audit_config` parameters + +@include '/configuration-reference/events/common-audit_config-parameters.mdx' + +### `audit_filter_overrides` parameters + +@include '/configuration-reference/events/common-audit_filter_overrides-parameters.mdx' + +## `audit_config` examples + +@include '/configuration-reference/events/common-audit_config-examples.mdx' diff --git a/website/content/docs/monitor/events/events.mdx b/website/content/docs/monitor/events/events.mdx new file mode 100644 index 000000000..296405d9b --- /dev/null +++ b/website/content/docs/monitor/events/events.mdx @@ -0,0 +1,14 @@ +--- +layout: docs +page_title: Controller/worker - events +description: |- + The events stanza configures events-specific parameters. +--- + +# `events` stanza + +@include '/configuration-reference/events/events-stanza-intro.mdx' + +## Default events stanza + +@include '/configuration-reference/events/default-events-stanza.mdx' diff --git a/website/content/docs/monitor/events/file.mdx b/website/content/docs/monitor/events/file.mdx new file mode 100644 index 000000000..b7dd98f3b --- /dev/null +++ b/website/content/docs/monitor/events/file.mdx @@ -0,0 +1,18 @@ +--- +layout: docs +page_title: Controller/worker - events - file sink - configuration +description: |- + The file sink configures Boundary to send events to a file. +--- + +# `file` sink + +@include '/configuration-reference/events/file-sink-intro.mdx' + +## Common parameters + +These parameters are shared across all sink types: [common sink parameters](/boundary/docs/monitor/events/common) + +## `file` parameters + +@include '/configuration-reference/events/file-parameters.mdx' \ No newline at end of file diff --git a/website/content/docs/concepts/filtering/events.mdx b/website/content/docs/monitor/events/filter-events.mdx similarity index 90% rename from website/content/docs/concepts/filtering/events.mdx rename to website/content/docs/monitor/events/filter-events.mdx index 7f7b1e8b9..4ce5bdd31 100644 --- a/website/content/docs/concepts/filtering/events.mdx +++ b/website/content/docs/monitor/events/filter-events.mdx @@ -8,8 +8,9 @@ description: >- # Filter events This page describes how to filter events written to Boundary event sinks. +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. -Starting in Boundary 0.5.0, a variety of event types (error, observation, +A variety of event types (error, observation, system, etc) are emitted from Boundary. Boundary events can be emitted in several formats including [cloudevents](https://github.com/cloudevents/spec) and [hclog](https://github.com/hashicorp/go-hclog), and can be encoded as text and @@ -17,9 +18,9 @@ json. Boundary allows you to configure any number of sinks where these events will be written. When configuring an event sink, you can specify [common sink -parameters](/boundary/docs/configuration/events/common) which include both +parameters](/boundary/docs/monitor/events/common) which include both `allow_filters` and `deny_filters` which use the standard [filter -syntax](/boundary/docs/concepts/filtering) used elsewhere in Boundary. +syntax](/boundary/docs/filtering) used elsewhere in Boundary. Example events encoded as cloudevents-text. The first event is a system event and the second event is an observation event. diff --git a/website/content/docs/monitor/events/stderr.mdx b/website/content/docs/monitor/events/stderr.mdx new file mode 100644 index 000000000..2aaa53be7 --- /dev/null +++ b/website/content/docs/monitor/events/stderr.mdx @@ -0,0 +1,18 @@ +--- +layout: docs +page_title: Controller - events - stderr sink - configuration +description: |- + The stderr sink configures Boundary to send events to a stderr. +--- + +# `stderr` sink + +@include '/configuration-reference/events/stderr-intro.mdx' + +## Common parameters + +These parameters are shared across all sink types: [common sink parameters](/boundary/docs/monitor/events/common) + +## `stderr` parameters + +@include '/configuration-reference/events/stderr-parameters.mdx' diff --git a/website/content/docs/operations/health.mdx b/website/content/docs/monitor/health.mdx similarity index 99% rename from website/content/docs/operations/health.mdx rename to website/content/docs/monitor/health.mdx index 39dd46b5e..125befed0 100644 --- a/website/content/docs/operations/health.mdx +++ b/website/content/docs/monitor/health.mdx @@ -95,7 +95,7 @@ The response contains the following fields: ## Example configuration -Health checks are available for a controller defined with a `purpose = "ops"` listener stanza. For details on what fields are allowed in this stanza, refer to the documentation about [TCP Listener](/boundary/docs/configuration/listener/tcp). +Health checks are available for a controller defined with a `purpose = "ops"` listener stanza. For details on what fields are allowed in this stanza, refer to the documentation about [TCP Listener](/boundary/docs/monitor/listeners/tcp). An example listener stanza: diff --git a/website/content/docs/monitor/index.mdx b/website/content/docs/monitor/index.mdx new file mode 100644 index 000000000..93bc681e1 --- /dev/null +++ b/website/content/docs/monitor/index.mdx @@ -0,0 +1,56 @@ +--- +layout: docs +page_title: Monitor Boundary +description: >- + Discover resources to help you learn more about maintaining and operating Boundary, including information about metrics and health. +--- + +# Monitor Boundary + +Visibility into various components of Boundary plays an important role in +ensuring the health of its controllers and workers. + +You can export metrics for controllers +and workers and then configure them to be collected by Prometheus. Metrics +provide insight into the current state of a Boundary deployment by enabling the +diagnosis of deployed controllers and workers. Enabling metrics assists in the +detection and mitigation of anomalies in a deployment. +These docs describe the available metrics and the naming and labeling standards +used. + +Additionally, the health of controllers can be monitored using the +`/health` endpoint. The health endpoint is enabled by defining a listener in +Boundary's configuration file, and a health response may be configured to add a +shutdown grace period process. + +You can also configure Boundary to monitor events. +You can choose to monitor audit, observation, system, and telemetry events. +Boundary supports both file and stderr sinks for events and you can send events to multiple sinks. + +Listeners let you configure the addresses and ports on which Boundary responds to requests. +You can configure TCP and Unix listeners. +Boundary also supports custom response headers for any requests made on controllers. +You can define headers based on the status code that is returned. + +## Tutorials + +To learn how to configure event filtering and sinks, complete the [Event filtering and sink configuration](/boundary/tutorials/self-managed-deployment/event-logging) tutorial. + +To learn how to configure metrics collection, complete the [Visualize metrics with Prometheus](/boundary/tutorials/self-managed-deployment/prometheus-metrics) tutorial. + +## More information + +Refer to the following topics for the parameters you use to configure the addresses and ports on which Boundary responds to requests: + +- [Listeners](/boundary/docs/monitor/listeners) + - [TCP listeners](/boundary/docs/monitor/listeners/tcp) + - [Unix listeners](/boundary/docs/monitor/listeners/unix) + +Refer to the following topics for more information on the various ways to monitor Boundary: + +- [Monitor metrics](/boundary/docs/monitor/metrics) +- [Monitor health](/boundary/docs/monitor/health) +- [Monitor events](/boundary/docs/monitor/events) + - [Common sink parameters](/boundary/docs/monitor/events/common) + - [File sink](/boundary/docs/monitor/events/file) + - [Stderr sink](/boundary//docs/monitor/events/stderr) diff --git a/website/content/docs/monitor/listeners/index.mdx b/website/content/docs/monitor/listeners/index.mdx new file mode 100644 index 000000000..a784ef2d1 --- /dev/null +++ b/website/content/docs/monitor/listeners/index.mdx @@ -0,0 +1,17 @@ +--- +layout: docs +page_title: Listener configuration +description: >- + Learn about TCP and Unix listener configuration settings. Understand where to change the default addresses and ports on which Boundary responds to requests. +--- + +# `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/monitor/listeners/tcp) and [Unix](/boundary/docs/monitor/listeners/unix). + + +## `listener` purpose + +@include '/configuration-reference/listeners/listener-purpose.mdx' \ No newline at end of file diff --git a/website/content/docs/monitor/listeners/tcp.mdx b/website/content/docs/monitor/listeners/tcp.mdx new file mode 100644 index 000000000..55685ffb2 --- /dev/null +++ b/website/content/docs/monitor/listeners/tcp.mdx @@ -0,0 +1,55 @@ +--- +layout: docs +page_title: TCP listener configuration +description: >- + Learn about using the TCP listener on a TCP address and port, and view configurable parameters. Understand custom response headers. View example configurations. +--- + +# `tcp` listener + +@include '/configuration-reference/listeners/tcp-intro.mdx' + +## Listener's custom response headers + +@include '/configuration-reference/listeners/tcp-custom-response-headers.mdx' + +## `tcp` listener parameters + +Refer to the following sections for `tcp` listener parameters. + +### General + +@include '/configuration-reference/listeners/tcp-general-parameters.mdx' + +### `custom_api_response_headers` parameters + +@include '/configuration-reference/listeners/tcp-custom-api-response-headers.mdx' + +### `custom_ui_response_headers` parameters + +@include '/configuration-reference/listeners/tcp-custom-ui-response-headers.mdx' + +### TLS + +@include '/configuration-reference/listeners/tcp-tls.mdx' + + + +## `tcp` listener examples + +Refer to the following sections for examples of `tcp` listeners. + +### Configure TLS + +@include '/configuration-reference/listeners/tcp-configure-tls.mdx' + +### Configure custom http response headers + +@include '/configuration-reference/listeners/tcp-configure-custom-http-response-headers.mdx' + +### Listen on mulitple interfaces + +@include '/configuration-reference/listeners/tcp-listen-on-mulitple-interfaces.mdx' \ No newline at end of file diff --git a/website/content/docs/monitor/listeners/unix.mdx b/website/content/docs/monitor/listeners/unix.mdx new file mode 100644 index 000000000..129a85ab3 --- /dev/null +++ b/website/content/docs/monitor/listeners/unix.mdx @@ -0,0 +1,45 @@ +--- +layout: docs +page_title: Unix domain socket listener configuration +description: >- + Learn about using the Unix listener on a specified Unix domain socket, and view configurable parameters. View example Unix listener configurations. +--- + +# `unix` listener + +@include '/configuration-reference/listeners/unix-intro.mdx' + +## `unix` listener parameters + +Refer to the following sections for the supported `unix` listener parameters. + +### General + +@include '/configuration-reference/listeners/unix-general-parameters.mdx' + +### TLS + +@include '/configuration-reference/listeners/unix-tls-parameters.mdx' + + + +## `unix` listener examples + +Refer to the following sections for examples of `unix` listeners. + +### Configure TLS + +@include '/configuration-reference/listeners/unix-configure-tls.mdx' + +### Listen on multiple interfaces + +@include '/configuration-reference/listeners/unix-listen-on-multiple-interfaces.mdx' + +[golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go +[api-addr]: /boundary/docs/configuration#api_addr +[cluster-addr]: /boundary/docs/configuration#cluster_addr diff --git a/website/content/docs/operations/metrics.mdx b/website/content/docs/monitor/metrics.mdx similarity index 99% rename from website/content/docs/operations/metrics.mdx rename to website/content/docs/monitor/metrics.mdx index 9a253337a..8e663337e 100644 --- a/website/content/docs/operations/metrics.mdx +++ b/website/content/docs/monitor/metrics.mdx @@ -85,7 +85,7 @@ measurements collected. Defining a listener stanza in the config file is sufficient for enabling metrics reporting in Boundary. For details on what fields are allowed in this stanza, refer to the documentation about [TCP -Listener](/boundary/docs/configuration/listener/tcp). +listener](/boundary/docs/monitor/listeners/tcp). An example listener stanza: diff --git a/website/content/docs/operations/index.mdx b/website/content/docs/operations/index.mdx deleted file mode 100644 index 18e44f711..000000000 --- a/website/content/docs/operations/index.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: docs -page_title: Maintaining and operating Boundary -description: >- - Discover resources to help you learn more about maintaining and operating Boundary, including information about metrics and health. ---- - -# Maintaining and operating Boundary - -Visibility into various components of Boundary plays an important role in -ensuring the health of its controllers and workers. While additional monitoring -components are planned for subsequent Boundary releases, metrics for controllers -and workers can now be exported and then collected by Prometheus. Metrics -provide insight into the current state of a Boundary deployment by enabling the -diagnosis of deployed controllers and workers. Enabling metrics assists in the -detection and mitigation of anomalies in a deployment. - -These docs describe the available metrics and the naming and labeling standards -used. Additionally, the health of controllers can be monitored using the -`/health` endpoint. The health endpoint is enabled by defining a listener in -Boundary's configuration file, and a health response may be configured to add a -shutdown grace period process. - -* Refer to the [Metrics](/boundary/docs/oss/operations/metrics) documentation to learn - more about Boundary metrics. -* Refer to the [Health Endpoint](/boundary/docs/oss/operations/health) documentation to - learn more about Boundary health endpoints. diff --git a/website/content/docs/operations/session-recordings/index.mdx b/website/content/docs/operations/session-recordings/index.mdx deleted file mode 100644 index 15b8bd1c1..000000000 --- a/website/content/docs/operations/session-recordings/index.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: docs -page_title: Recorded sessions format and security -description: >- - Learn about asciicast, the recording format used for recorded sessions. Understand security concerns and discover resources for working with recorded sessions. ---- - -# Recorded sessions operations - -This feature requires HCP Boundary or Boundary Enterprise - -Boundary provides [auditing](/boundary/docs/concepts/auditing) capabilities via [session recording](/boundary/docs/configuration/session-recording). -In Boundary, a session represents a set of connections between a user and a host from a target. -The session begins when an authorized user requests access to a target, and it ends when that access is terminated. -When you enable session recording on a target, any user session that connects to the target is automatically recorded. -An administrator can later view the recordings to investigate security issues, review system activity, or perform regular assessments of security policies and procedures. - -Recorded sessions are stored in an external storage bucket that you create. -Storing session recordings in a system external to Boundary means those recordings can be accessed, modified, deleted, and even restored independently of Boundary. -You can view any sessions that Boundary recorded in your storage provider or via the CLI. - -## asciicast - -When you view recorded sessions using the CLI or Admin UI, Boundary can convert the recording into other formats for playback. -Currently Boundary supports converting the recording of an individual SSH channel into an [asciicast](https://github.com/asciinema/asciinema/blob/develop/doc/asciicast-v2.md) format to play back an interactive SSH session. - -### Limitations - -The asciicast format is well suited for the playback of interactive shell activity. -However, some aspects of the recording cannot be translated into asciicast. -For example, if an SSH session uses the `RemoteCommand` option, or is used to `exec` a command, the command is not displayed in the asciicast. -The output of the command may be displayed, though. - -If you use SSH for something other than an interactive shell, such as for file transfer, X11 forwarding, or port forwarding, Boundary does not attempt to create an asciicast. -In all cases, the SSH session is still recorded in the [BSR file](/boundary/docs/concepts/auditing/#bsr-directory-structure) and you can view the BSR file in the external storage bucket. - -### Security - -When a worker converts an SSH recording into the BSR file, it iterates through each of the requests in the recording and displays some of them to the user. -If you use an environment request to set the shell variable, the request is included in the asciicast header. -You should be aware of the following security concerns that could result from this behavior: - -- asciicast only includes the last value that you send in the header, any previous values are overwritten. -An attacker may be able to use a malicious shell value at the beginning of a session, and then switch to `shell=/bin/bash` at the end of the session to conceal the malicious activity. - -- asciicast does not display other variables such as `path` in the header, but they can cause drastic changes to code execution during the SSH session. -An attacker could change the `path` variable to point to a malicious program or change the beahvior of a normal program so that it performs a malicious action. - -- asciicast silently ignores any requests that do not have an explicit handler, even though they may cause signficant changes to code execution during the SSH session. -An attacker could execute malicious code using a request without an explicit handler. - -## Next steps - -For more information about working with recorded sessions, refer to the following topics: - -- [Find and view recorded sessions](/boundary/docs/operations/session-recordings/manage-recorded-sessions) -- [Validate the integrity of session recordings](/boundary/docs/operations/session-recordings/validate-session-recordings) -- [How Boundary validates data integrity in the external data store](/boundary/docs/operations/session-recordings/validate-data-store) \ No newline at end of file diff --git a/website/content/docs/overview/vs/bastion-hosts.mdx b/website/content/docs/overview/bastion-hosts.mdx similarity index 85% rename from website/content/docs/overview/vs/bastion-hosts.mdx rename to website/content/docs/overview/bastion-hosts.mdx index 4fbdd193a..a64a0be60 100644 --- a/website/content/docs/overview/vs/bastion-hosts.mdx +++ b/website/content/docs/overview/bastion-hosts.mdx @@ -22,11 +22,11 @@ Boundary's worker nodes, the resources that proxy connections to private endpoin You can use SSH to inject the credentials of any target resources that you want to connect to using Boundary, so that the credentials are never exposed to the user while establishing a connection. Alternatively, Boundary can return brokered credentials back to users (if permitted), which could take the form of API tokens, usernames and passwords, public keys, etc. -_Can Boundary replace a Bastion/Jumphost access model?_ +**Can Boundary replace a bastion/jumphost access model?** -**Yes**, in many cases you can use Boundary as a replacement for an existing bastion host-based access model to infrastructure. +Yes, in many cases you can use Boundary as a replacement for an existing bastion host-based access model to infrastructure. The advantages to Boundary's access model are outlined above. -_Can Boundary extend a Bastion/Jumphost access model?_ +**Can Boundary extend a bastion/jumphost access model?** -**Yes**, some users may see value in Boundary providing access to an existing bastion host deployment. \ No newline at end of file +Yes, some users may see value in Boundary providing access to an existing bastion host deployment. \ No newline at end of file diff --git a/website/content/docs/troubleshoot/faq.mdx b/website/content/docs/overview/faq.mdx similarity index 85% rename from website/content/docs/troubleshoot/faq.mdx rename to website/content/docs/overview/faq.mdx index 760350ec5..754d8a808 100644 --- a/website/content/docs/troubleshoot/faq.mdx +++ b/website/content/docs/overview/faq.mdx @@ -22,7 +22,7 @@ While Vault isn't a *required* secrets backend for Boundary sessions, the potent 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 [0.4 announcement](https://www.hashicorp.com/blog/announcing-hashicorp-boundary-0-4) and there are ample -[tutorials](/boundary/tutorials/access-management/oss-vault-cred-brokering-quickstart) of this scenario. +[tutorials](/boundary/tutorials/credential-management/community-vault-cred-brokering-quickstart) of this scenario. 2. Boundary can use Vault as an OIDC provider to enable sign-in with Vault's supported auth methods (even non-OIDC auth methods like Active Directory kerberos/LDAP). This scenario is walked through in this [tutorial](/vault/tutorials/auth-methods/oidc-identity-provider). 3. Boundary Community Edition can use Vault as the external KMS that serves as Boundary's root of trust. More information on this use case can be found @@ -39,33 +39,35 @@ such as [Vault's OIDC bridge](/vault/docs/concepts/oidc-provider) capabilities r 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). +from an IDP to Boundary to assign role assignments dynamically. See Boundary's [managed groups capabilities](/boundary/tutorials/identity-management/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? 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) +2. Boundary's [dynamic host catalog](/boundary/docs/hosts#dynamic-host-catalogs) agentlessly queries infrastructure providers to automate the onboarding and configuration of hosts All of these methods will automate the discovery and configuration of targets when their ip addresses change. Of course, static hosts can still be manually added via Boundary admin UI and CLI. -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) +For more information on dynamic host catalogs, refer to: + +- [AWS dynamic host catalogs](/boundary/docs/hosts/aws) +- [Azure dynamic host catalogs](/boundary/docs/hosts/azure) +- [GCP dynamic host catalogs](/boundary/docs/hosts/gcp) ## 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. You can learn how to monitor these sessions in the [Manage sessions tutorial](/boundary/tutorials/community-administration/community-manage-sessions). Boundary supports audit logs for [Boundary Community Edition](/boundary/tutorials/oss-configuration/event-logging) and [audit log streaming](/hcp/docs/boundary/audit-logging) for HCP Boundary. Audit logs for both distributions can be exported to SIEM or BI tools. **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). +[Manage sessions tutorial](/boundary/tutorials/community-administration/community-manage-sessions). ## 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. +For more information, refer to the [Dynamic host catalogs on AWS](/boundary/tutorials/host-management/aws-host-catalogs) tutorial. diff --git a/website/content/docs/overview/vs/pam.mdx b/website/content/docs/overview/pam.mdx similarity index 78% rename from website/content/docs/overview/vs/pam.mdx rename to website/content/docs/overview/pam.mdx index fbb05ed3e..3bbd37ca2 100644 --- a/website/content/docs/overview/vs/pam.mdx +++ b/website/content/docs/overview/pam.mdx @@ -19,13 +19,13 @@ Where Boundary differs from traditional PAM solutions is in its automation-frien Boundary is instrumented programmatically via REST, CLI, and [Terraform](https://registry.terraform.io/providers/hashicorp/boundary/latest/docs). It provides automation-friendly workflows for managing users and credentials, as well as the discovery and configuration of new services: -- **Automated credential management**: Boundary and Vault can create workflows with automated credential management in which user sessions are secured with [single-use dynamic credentials that are injected into sessions](/boundary/tutorials/access-management/hcp-private-vault-cred-injection) such that secrets are never returned to users. +- **Automated credential management**: Boundary and Vault can create workflows with automated credential management in which user sessions are secured with [single-use dynamic credentials that are injected into sessions](/boundary/tutorials/credential-management/hcp-private-vault-cred-injection) such that secrets are never returned to users. - **Context-based access**: When users' business context changes, you want to ensure their permissions reflect the new business context. As an example, on-call engineers might require different permissions than when they end their on-call shifts. [Boundary's managed groups](/boundary/tutorials/access-management/oidc-idp-groups) enable user permission workflows to be assigned dynamically based on identity provider MFA checks, group memberships, and other IDP-level context. -- **[Host discovery](/boundary/docs/concepts/host-discovery)**: Boundary's [dynamic host catalogs](/boundary/tutorials/access-management/aws-host-catalogs) are advanced workflows for automating the process of onboarding new or changed infrastructure resources and their connection information, and applying pre-configured security policies. +- **[Host discovery](/boundary/docs/hosts)**: Boundary's [dynamic host catalogs](/boundary/tutorials/host-management/aws-host-catalogs) are advanced workflows for automating the process of onboarding new or changed infrastructure resources and their connection information, and applying pre-configured security policies. -_Can Boundary replace a PAM solution?_ +**Can Boundary replace a PAM solution?** -**Yes**, Boundary provides many of the security controls traditionally delivered by PAM tools. +Yes, Boundary provides many of the security controls traditionally delivered by PAM tools. Boundary can also be used with an existing PAM tool, particularly the ones that emphasize agent-based security where Boundary's proxy-based security can be a natural complement. \ No newline at end of file diff --git a/website/content/docs/overview/vs/sdp.mdx b/website/content/docs/overview/sdp.mdx similarity index 90% rename from website/content/docs/overview/vs/sdp.mdx rename to website/content/docs/overview/sdp.mdx index 6b8d27a2a..a9f0c2bde 100644 --- a/website/content/docs/overview/vs/sdp.mdx +++ b/website/content/docs/overview/sdp.mdx @@ -9,4 +9,4 @@ description: >- Software-defined perimeter (SDP) solutions secure access to applications and infrastructure based on user identity. Boundary is fundamentally an SDP solution that takes a zero trust approach to security design for system access; access to services is granted based on the scoped identity and intent of a user. -Boundary is a scalable proxy that enables identity-based access with multiple layers of security controls including [dynamic credentials](/boundary/tutorials/hcp-administration/hcp-ssh-cred-injection), [context-based access](/boundary/tutorials/access-management/oidc-idp-groups), [automated host discovery](/boundary/docs/concepts/host-discovery), and [access auditing](/hcp/docs/boundary/audit-logging) to name a few. \ No newline at end of file +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/hosts), and [access auditing](/hcp/docs/boundary/audit-logging) to name a few. \ No newline at end of file diff --git a/website/content/docs/overview/vs/secrets-management.mdx b/website/content/docs/overview/secrets-management.mdx similarity index 83% rename from website/content/docs/overview/vs/secrets-management.mdx rename to website/content/docs/overview/secrets-management.mdx index e9d0010ec..d5b5f4461 100644 --- a/website/content/docs/overview/vs/secrets-management.mdx +++ b/website/content/docs/overview/secrets-management.mdx @@ -11,14 +11,14 @@ Secrets management is the use of tools and methods to manage digital authenticat This includes passwords, API keys, PKI, TOTP codes, etc. Popular tools in this space includes HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, Cloud KMS, and CyberArk Conjur. -Boundary itself is **not** a secrets manager for your infrastructure. +Boundary itself is not a secrets manager for your infrastructure. A core step in Boundary's access workflow is integrating with your existing secrets management providers, such as HashiCorp Vault, to retrieve dynamic credentials, and return them to end users when they attempt to establish connections. For customers who may not yet have a credential management solution, or are looking to easily onboard, Boundary can function as a rudimentary static credential store. Boundary provides a comprehensive access workflow that integrates with secrets management providers, enforces secure and granular network and credential access based on identity, audits all access, and automates the discovery and configuration of new target endpoints. -_Does Boundary replace a secrets management solution?_ +**Does Boundary replace a secrets management solution?** -Boundary is **not** intended to replace an existing secrets management solution. +Boundary is not intended to replace an existing secrets management solution. Boundary is designed to work with your secrets management solution to comprehensively secure infrastructure access. For many users, Boundary's native static credential management capabilities may be sufficient. -For those that require more advanced credential workflows, such as dynamic credentials, [HashiCorp Vault](https://www.vaultproject.io/) is a natural complement to Boundary. \ No newline at end of file +For those that require more advanced credential workflows, such as dynamic credentials, [HashiCorp Vault](https://developer.hashicorp.com/vault/) is a natural complement to Boundary. \ No newline at end of file diff --git a/website/content/docs/overview/use-cases.mdx b/website/content/docs/overview/use-cases.mdx index 377779724..f14c0d4de 100644 --- a/website/content/docs/overview/use-cases.mdx +++ b/website/content/docs/overview/use-cases.mdx @@ -7,8 +7,7 @@ description: >- # Use cases -Before understanding use cases, it's useful to know [what Boundary is](/boundary/docs/overview/what-is-boundary). This page lists some concrete use cases for Boundary, but the possible use cases are much broader than what we cover. - +Before understanding use cases, it's useful to know [what Boundary is](/boundary/docs/what-is-boundary). This page lists some concrete use cases for Boundary, but the possible use cases are much broader than what we cover. ## Zero trust access @@ -30,4 +29,21 @@ Boundary provides session monitoring capabilities that give security administrat Further, administrators can enable session recording on targets. When you enable session recording on a target, a worker records any sessions that access that target from the time the user requests access to when that access is terminated. -Administrators can view the recordings later using a session player that runs in a browser. \ No newline at end of file +Administrators can view the recordings later using a session player that runs in a browser. + +## Boundary vs. other software + +It can be difficult to understand how to compare the different remote access security solutions that are available on the market. +Is one a replacement for another? +Are they complementary? +Refer to the following topics for a more detailed comparison of Boundary to specific technologies: + +- [Zero trust](/boundary/docs/overview/zero-trust) +- [Bastion hosts](/boundary/docs/overview/bastion-hosts) +- [VPNs](/boundary/docs/overview/vpn) +- [Privileged access management](/boundary/docs/overview/pam) +- [Software-defined-perimeter](/boundary/docs/overview/sdp) +- [Secrets management tools](/boundary/docs/overview/secrets-management) + +The comparisons are philosophical in nature, and are not intended to be oppositional. +Our goal is to provide readers with a better understanding of how access management solutions overlap with Boundary, and where Boundary does things differently. \ No newline at end of file diff --git a/website/content/docs/overview/vs/vpn.mdx b/website/content/docs/overview/vpn.mdx similarity index 97% rename from website/content/docs/overview/vs/vpn.mdx rename to website/content/docs/overview/vpn.mdx index 4d5fd60a2..9d6bbb6ff 100644 --- a/website/content/docs/overview/vs/vpn.mdx +++ b/website/content/docs/overview/vpn.mdx @@ -21,10 +21,10 @@ Boundary uses a non-repudiable user identity that is established by your integra A traditional VPN provides users with **network access**. Boundary provides users with **delegated access to services within the network**. -_Can Boundary replace a VPN?_ +**Can Boundary replace a VPN?** For many organizations, Boundary's granular network access will be a security improvement from traditional data center VPN solutions that lack granular controls. -_Can Boundary work with a VPN?_ +**Can Boundary work with a VPN?** Boundary can work with existing corporate VPNs to provide heightened security when accessing privileged networks such as data centers and cloud VPCs. \ No newline at end of file diff --git a/website/content/docs/overview/vs/other-software.mdx b/website/content/docs/overview/vs/other-software.mdx deleted file mode 100644 index 9bf6130c0..000000000 --- a/website/content/docs/overview/vs/other-software.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: docs -page_title: Boundary vs. other software -description: >- - Learn how HashiCorp Boundary compares to other security technologies. ---- - -# 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. -Is one a replacement for another? -Are they complementary? -In this section, we compare Boundary to other available security solutions. - -We also recommend referring to [What is Boundary](/boundary/docs/overview/what-is-boundary) and [Why Boundary](/boundary/docs/overview/what-is-boundary#why-boundary) for a better understanding of Boundary and the problems that it solves. - -Use the navigation to the left to read the comparison of Boundary to specific technologies. - -~> The following comparisons are philosophical in nature, and are not intended to be oppositional. -Our goal is to provide readers with a better understanding of how Access Management solutions overlap with Boundary, and where Boundary does things differently. \ No newline at end of file diff --git a/website/content/docs/overview/vs/zero-trust.mdx b/website/content/docs/overview/zero-trust.mdx similarity index 100% rename from website/content/docs/overview/vs/zero-trust.mdx rename to website/content/docs/overview/zero-trust.mdx diff --git a/website/content/docs/configuration/identity-access-management/assignable-permissions.mdx b/website/content/docs/rbac/assignable-permissions.mdx similarity index 90% rename from website/content/docs/configuration/identity-access-management/assignable-permissions.mdx rename to website/content/docs/rbac/assignable-permissions.mdx index ad38c1013..7e00c1d18 100644 --- a/website/content/docs/configuration/identity-access-management/assignable-permissions.mdx +++ b/website/content/docs/rbac/assignable-permissions.mdx @@ -96,9 +96,9 @@ They include `id`, `scope_id`, `scope`, `name`, and `description`. ## More information -1. Refer to [Permission grant formats](/boundary/docs/configuration/identity-access-management/permission-grant-formats) for more information about grant strings and example formats. -1. Refer to the [Resource table](/boundary/docs/configuration/identity-access-management/resource-table) for a cheat sheet to help you manage your permissions. +1. Refer to [Permission grant formats](/boundary/docs/rbac/permission-grant-formats) for more information about grant strings and example formats. +1. Refer to the [Resource tables](/boundary/docs/rbac/resource-table) for a cheat sheet to help you manage your permissions. ## Next steps -Refer to [Manage roles and permissions](/boundary/docs/common-workflows/manage-roles) for instructions to configure roles and grant scopes for principals. +Refer to [Manage access with roles](/boundary/docs/rbac/manage-roles) for instructions to configure roles and grant scopes for principals. diff --git a/website/content/docs/configuration/identity-access-management/index.mdx b/website/content/docs/rbac/index.mdx similarity index 80% rename from website/content/docs/configuration/identity-access-management/index.mdx rename to website/content/docs/rbac/index.mdx index 8eedea3e5..bd62e4fe7 100644 --- a/website/content/docs/configuration/identity-access-management/index.mdx +++ b/website/content/docs/rbac/index.mdx @@ -7,11 +7,11 @@ description: >- # Permissions in Boundary -Boundary's permissions model is a composable, RBAC, allow-only model that +Boundary's permissions model is a composable, role-based access control (RBAC), allow-only model that attempts to marry flexibility with usability. The following pages discuss the permission model's fundamental concepts, provide examples of the specific forms of allowed grants, and contain a table that acts as a cheat sheet to help you craft roles. -Boundary's [domain model](/boundary/docs/concepts/domain-model) is based on resource +Boundary's [domain model](/boundary/docs/domain-model) is based on resource types. You can implement resource types directly, such as with targets, or they can be abstract types that you implement using concrete types within the system. As an example of the latter, a host catalog is an abstract type and a static host @@ -79,7 +79,7 @@ that originate from all matching roles. ## Next steps -1. Refer to [Assignable permissions](/boundary/docs/configuration/identity-access-management/assignable-permissions) for more information about the permissions you can assign to Boundary principals. -1. Refer to [Permission grant formats](/boundary/docs/configuration/identity-access-management/permission-grant-formats) for more information about grant strings and example formats. -1. Refer to [Manage roles and permissions](/boundary/docs/common-workflows/manage-roles) for instructions to configure roles and grant scopes for principals. -1. Refer to the [Resource table](/boundary/docs/configuration/identity-access-management/resource-table) for a cheat sheet to help you manage your permissions. \ No newline at end of file +1. Refer to [Assignable permissions](/boundary/docs/rbac/assignable-permissions) for more information about the permissions you can assign to Boundary principals. +1. Refer to [Permission grant formats](/boundary/docs/rbac/permission-grant-formats) for more information about grant strings and example formats. +1. Refer to [Manage access with roles](/boundary/docs/rbac/manage-roles) for instructions to configure roles and grant scopes for principals. +1. Refer to the [Resource tables](/boundary/docs/rbac/resource-table) for a cheat sheet to help you manage your permissions. \ No newline at end of file diff --git a/website/content/docs/common-workflows/manage-roles.mdx b/website/content/docs/rbac/manage-roles.mdx similarity index 91% rename from website/content/docs/common-workflows/manage-roles.mdx rename to website/content/docs/rbac/manage-roles.mdx index f45f162be..05d35ee18 100644 --- a/website/content/docs/common-workflows/manage-roles.mdx +++ b/website/content/docs/rbac/manage-roles.mdx @@ -1,17 +1,17 @@ --- layout: docs -page_title: Manage roles and permissions +page_title: Manage access with roles description: >- Use roles to manage permissions assigned to users and groups. Create roles and assign principals and grants to them. Add grant scopes and configure inheritance. --- -# Manage roles and permissions +# Manage access with roles -[Roles](/boundary/docs/concepts/domain-model/roles) in Boundary manage the permissions assigned to principals: +[Roles](/boundary/docs/domain-model/roles) in Boundary manage the permissions assigned to principals: -- [Users](/boundary/docs/concepts/domain-model/users) -- [Groups](/boundary/docs/concepts/domain-model/groups) -- [Managed Groups](/boundary/docs/concepts/domain-model/managed-groups) +- [Users](/boundary/docs/domain-model/users) +- [Groups](/boundary/docs/domain-model/groups) +- [Managed groups](/boundary/docs/domain-model/managed-groups) You can define a role in the global, org, or project scopes. @@ -25,7 +25,7 @@ All resource IDs in this guide are examples. Boundary generates unique IDs for e ## Create a role -Roles can live in the global, org, or project scopes. In this example, we create a role in the generated org scope in [Boundary's `dev` mode](/boundary/docs/getting-started/dev-mode/dev-mode). +Roles can live in the global, org, or project scopes. In this example, we create a role in the generated org scope in [Boundary's `dev` mode](/boundary/docs/getting-started/dev-mode). @@ -219,7 +219,7 @@ resource "boundary_role" "listonly" { ## Assign grants to a role -Grants describe the actions that the principals are allowed to perform. For more information on how to format grants, refer to [Permission grant formats](/boundary/docs/configuration/identity-access-management/permission-grant-formats). +Grants describe the actions that the principals are allowed to perform. For more information on how to format grants, refer to [Permission grant formats](/boundary/docs/rbac/permission-grant-formats). In this example, we give a role read and list permissions for all resources. The grant we apply for the role is: @@ -414,6 +414,6 @@ resource "boundary_role" "listonly" { ## More information -1. Refer to [Assignable permissions](/boundary/docs/configuration/identity-access-management/assignable-permissions) for more information about the permissions you can assign to Boundary principals. -1. Refer to [Permission grant formats](/boundary/docs/configuration/identity-access-management/permission-grant-formats) for more information about grant strings and example formats. -1. Refer to the [Resource table](/boundary/docs/configuration/identity-access-management/resource-table) for a cheat sheet to help you manage your permissions. +1. Refer to [Assignable permissions](/boundary/docs/rbac/assignable-permissions) for more information about the permissions you can assign to Boundary principals. +1. Refer to [Permission grant formats](/boundary/docs/rbac/permission-grant-formats) for more information about grant strings and example formats. +1. Refer to the [Resource tables](/boundary/docs/rbac/resource-table) for a cheat sheet to help you manage your permissions. diff --git a/website/content/docs/configuration/identity-access-management/permission-grant-formats.mdx b/website/content/docs/rbac/permission-grant-formats.mdx similarity index 88% rename from website/content/docs/configuration/identity-access-management/permission-grant-formats.mdx rename to website/content/docs/rbac/permission-grant-formats.mdx index e99cef0e8..57f733907 100644 --- a/website/content/docs/configuration/identity-access-management/permission-grant-formats.mdx +++ b/website/content/docs/rbac/permission-grant-formats.mdx @@ -10,7 +10,7 @@ description: >- Each grant string is a mapping that describes a resource or set of resources and the permissions that should be granted on them. -Refer to [Assignable permissons](/boundary/docs/configuration/identity-access-management/assignable-permissions) for more information about the permissions you can include in grants. +Refer to [Assignable permissons](/boundary/docs/rbac/assignable-permissions) for more information about the permissions you can include in grants. A grant string has a form similar to: @@ -150,9 +150,9 @@ The following templates substitute a given value into the ID field of the grant ## More information -1. Refer to [Assignable permissions](/boundary/docs/configuration/identity-access-management/assignable-permissions) for more information about the permissions you can assign to Boundary principals. -1. Refer to the [Resource table](/boundary/docs/configuration/identity-access-management/resource-table) for a cheat sheet to help you manage your permissions. +1. Refer to [Assignable permissions](/boundary/docs/rbac/assignable-permissions) for more information about the permissions you can assign to Boundary principals. +1. Refer to the [Resource tables](/boundary/docs/rbac/resource-table) for a cheat sheet to help you manage your permissions. ## Next steps -Refer to [Manage roles and permissions](/boundary/docs/common-workflows/manage-roles) for instructions to configure roles and grant scopes for principals. +Refer to [Manage access with roles](/boundary/docs/rbac/manage-roles) for instructions to configure roles and grant scopes for principals. diff --git a/website/content/docs/configuration/identity-access-management/resource-table.mdx b/website/content/docs/rbac/resource-table.mdx similarity index 100% rename from website/content/docs/configuration/identity-access-management/resource-table.mdx rename to website/content/docs/rbac/resource-table.mdx diff --git a/website/content/docs/common-workflows/manage-users-groups.mdx b/website/content/docs/rbac/users/manage-users-groups.mdx similarity index 94% rename from website/content/docs/common-workflows/manage-users-groups.mdx rename to website/content/docs/rbac/users/manage-users-groups.mdx index ed34be00c..af0ee2be3 100644 --- a/website/content/docs/common-workflows/manage-users-groups.mdx +++ b/website/content/docs/rbac/users/manage-users-groups.mdx @@ -1,14 +1,14 @@ --- layout: docs -page_title: Manage Users and Groups +page_title: Manage users and groups description: How to manage Boundary users and groups --- -# Managing Principals (Users and Groups) +# Managing principals Users and Groups in Boundary are collectively known as principals. Assigning -[grants](/boundary/docs/concepts/security/permissions) on -[Roles](/boundary/docs/concepts/domain-model/roles) is performed through principal IDs; +[grants](/boundary/docs/rbac#grant-strings) on +[roles](/boundary/docs/domain-model/roles) is performed through principal IDs; that is, the unique IDs of either users, groups, or both. This page will walk you through managing users within Boundary. (Groups will be @@ -18,8 +18,8 @@ added at a later time.) Users in Boundary represent an _internal_ notion of a particular entity (human, machine, etc.). Users can be correlated with one or more -[Account](/boundary/docs/concepts/domain-model/accounts) resources via [Auth -Methods](/boundary/docs/concepts/domain-model/auth-methods). Accounts represent +[account](/boundary/docs/domain-model/accounts) resources via [auth +methods](/boundary/docs/domain-model/auth-methods). Accounts represent _external_ notions of a particular entity. Among other use-cases, this mechanism allows for an easy way to switch users to new IdPs within the organization deploying Boundary. @@ -40,7 +40,7 @@ walk you through manually making these resources and linking them. A future Boundary update will allow turning off auto-vivification on a per-auth-method basis. -## Create an Auth Method +## Create an auth method Create a password-type auth method in the generated default org: @@ -104,7 +104,7 @@ resource "boundary_auth_method" "password" { -## Create Account +## Create an account Create an account for the org-scoped auth method. Note that by default, user names must be all lowercase alphanumeric of at least 3 characters and the @@ -173,7 +173,7 @@ resource "boundary_account" "my_user" { -## Create a User +## Create a user Next, create a user at the org scope. @@ -274,7 +274,7 @@ resource "boundary_user" "myuser" { -## Login +## Log in Now you can test logging in. @@ -317,4 +317,3 @@ provider "boundary" { - diff --git a/website/content/docs/concepts/filtering/managed-groups.mdx b/website/content/docs/rbac/users/managed-groups.mdx similarity index 93% rename from website/content/docs/concepts/filtering/managed-groups.mdx rename to website/content/docs/rbac/users/managed-groups.mdx index 3298e1bf4..357246be8 100644 --- a/website/content/docs/concepts/filtering/managed-groups.mdx +++ b/website/content/docs/rbac/users/managed-groups.mdx @@ -5,12 +5,11 @@ description: >- Learn how to configure filters for managed groups. View search filter attributes and examples of filters for OIDC and LDAP managed groups. --- -[filter syntax]: /boundary/docs/concepts/filtering - # Filter managed groups -This page describes how to use filters with OIDC or LDAP managed groups. It assumes that you are familiar with the general [filter syntax][] as well as [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) or [LDAP](https://ldap.com/ldap-specifications/). +This page describes how to use filters with OIDC or LDAP managed groups. It assumes that you are familiar with the Boundary's general filter syntax as well as [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) or [LDAP](https://ldap.com/ldap-specifications/). +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. ## OIDC filters diff --git a/website/content/docs/release-notes/index.mdx b/website/content/docs/release-notes/index.mdx deleted file mode 100644 index 412127489..000000000 --- a/website/content/docs/release-notes/index.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -layout: docs -page_title: Release notes -description: >- - Discover more information about the important updates in each version of Boundary in the 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/) -and the documentation is available on the [Boundary Changelog Page](https://github.com/hashicorp/boundary/blob/main/CHANGELOG.md). diff --git a/website/content/docs/release-notes/v0_12_0.mdx b/website/content/docs/release-notes/v0_12_0.mdx index de65b24d8..6dcb9e3af 100644 --- a/website/content/docs/release-notes/v0_12_0.mdx +++ b/website/content/docs/release-notes/v0_12_0.mdx @@ -46,21 +46,21 @@ Vault is the only supported CA in Boundary version 0.12.0. SSH certificates let you specify how long they are valid for, who can gain access to a target, how users can log in, and what commands can be used on the target machine. SSH certificates are short-lived and self-destructive unlinke SSH key pairs. -For more information, refer to the [Vault SSH certificate credential library attributes](/boundary/docs/concepts/domain-model/credential-libraries#vault-ssh-certificate-credential-library-attributeshcp-only) documentation. +For more information, refer to the [Vault SSH certificate credential library attributes](/boundary/docs/domain-model/credential-libraries#vault-ssh-certificate-credential-library-attributeshcp-only) documentation. **Addresses on targets**: HashiCorp Boundary offers an extensible domain model that allows administrators to organize target resources in a way that best compliments how their organization manages its computing infrastructure. But that flexibility could become a hindrance when setting up a quick proof-of-concept and defining a target to create a session. Version 0.12.0 introduces a quick way to set up a target. -Previously, you would need to define [hosts](/boundary/docs/concepts/domain-model/hosts) within a [host set](/boundary/docs/concepts/domain-model/host-sets), and then assign that to a [target](/boundary/docs/concepts/domain-model/targets). +Previously, you would need to define [hosts](/boundary/docs/domain-model/hosts) within a [host set](/boundary/docs/domain-model/host-sets), and then assign that to a [target](/boundary/docs/domain-model/targets). The hosts contain the hostname or IP address of the computing resources, and the target definition contains various connection parameters for those hosts. Starting with version 0.12.0 the hostname or IP address can be specified directly within the target definition, without having to create hosts, host sets, or a host catalog. This functionality allows you to get started with Boundary quickly while still maintaining the same flexibility for more complex and production-like scenarios. -For more information, refer to the [Target and Host Resources](/boundary/docs/concepts/domain-model#target-and-host-resources) documentation. +For more information, refer to the [Target and Host Resources](/boundary/docs/domain-model#target-and-host-resources) documentation. -**Authentication improvements**: In previous versions, authenticating through the CLI required you to provide an [**Auth Method ID**](/boundary/docs/concepts/domain-model/auth-methods). +**Authentication improvements**: In previous versions, authenticating through the CLI required you to provide an [**Auth Method ID**](/boundary/docs/domain-model/auth-methods). This value could be difficult to find if you did not previously save it. Starting in version 0.12.0 the Boundary CLI no longer requires an **Auth Method ID**, and will use the default **Auth Method ID** if none is provided. The built-in password auth method is now marked as **Primary** when an HCP Boundary cluster is deployed. @@ -69,7 +69,7 @@ The built-in password auth method is now marked as **Primary** when an HCP Bound In version 0.12.0, we are releasing a new type of credential to the static credential store. You can now create and broker JSON blobs to authorized users at session establishment time. -For more information, refer to the [JSON credentials](/boundary/docs/concepts/domain-model/credentials#json) documentation. +For more information, refer to the [JSON credentials](/boundary/docs/domain-model/credentials#json) documentation. **Job run table maintenance**: A new job was added to automatically clean up completed runs from the `job_run` table. It deletes any existing completed jobs on a regular interval to help manage the size of your Boundary database. diff --git a/website/content/docs/release-notes/v0_13_0.mdx b/website/content/docs/release-notes/v0_13_0.mdx index d873e5caf..405b7c0c9 100644 --- a/website/content/docs/release-notes/v0_13_0.mdx +++ b/website/content/docs/release-notes/v0_13_0.mdx @@ -69,9 +69,9 @@ Support for LDAP CRUD operations via the Boundary admin UI is planned for an upc For more information, refer to the LDAP domain model documentation: -- [Accounts](/boundary/docs/concepts/domain-model/accounts#ldap-account-attributes-beta) -- [Auth methods](/boundary/docs/concepts/domain-model/auth-methods#ldap-auth-method-attributes-beta) -- [Managed groups](/boundary/docs/concepts/domain-model/managed-groups#ldap-managed-group-information-and-attributes-beta) +- [Accounts](/boundary/docs/domain-model/accounts#ldap-account-attributes-beta) +- [Auth methods](/boundary/docs/domain-model/auth-methods#ldap-auth-method-attributes-beta) +- [Managed groups](/boundary/docs/domain-model/managed-groups#ldap-managed-group-information-and-attributes-beta) **HCP Boundary maintenance window HCP only**: HCP Boundary automatically updates your environment when a new version of Boundary is released. You can now schedule when that maintenance occurs to ensure that it does not interrupt peak work hours. diff --git a/website/content/docs/release-notes/v0_14_0.mdx b/website/content/docs/release-notes/v0_14_0.mdx index 06befb00e..3f7420ab7 100644 --- a/website/content/docs/release-notes/v0_14_0.mdx +++ b/website/content/docs/release-notes/v0_14_0.mdx @@ -42,7 +42,7 @@ description: >- The LDAP auth method is no longer in beta, it is now fully supported. Administrators can now create, manage, and delete LDAP auth methods along with managed groups and accounts using the admin console UI.

Learn more:  - Auth methods + Auth methods @@ -104,7 +104,7 @@ description: >- You can now add additional valid principals when you create a Vault SSH signed certificate credential library. The additional principals list the names for which the certificate is valid.

Learn more:  - Vault SSH certificate credential library attributes + Vault SSH certificate credential library attributes @@ -118,7 +118,7 @@ description: >- You can now use OIDC prompts to customize the authentication and authorization flow to suit your specific needs. For more information about the OIDC specification, refer to the OIDC authentication request documentation.

Learn more:  - OIDC auth method attributes + OIDC auth method attributes @@ -347,7 +347,7 @@ description: >- As noted in the v0.12.0 release notes, the vault credential library subtype was renamed to vault-generic. The vault subtype is removed in this release, you must use vault-generic now.

Learn more:  - Credential libraries + Credential libraries @@ -368,7 +368,7 @@ description: >- As noted in the v0.12.0 release notes, targets now require a default port value. Previously, any ports that you defined as part of a host address were ignored, but allowed as part of the target definition. From this version on, if you define a port on a host address it results in an error.

Learn more:  - Targets + Targets diff --git a/website/content/docs/release-notes/v0_15_0.mdx b/website/content/docs/release-notes/v0_15_0.mdx index 55798a97f..3ea4f09f4 100644 --- a/website/content/docs/release-notes/v0_15_0.mdx +++ b/website/content/docs/release-notes/v0_15_0.mdx @@ -29,7 +29,7 @@ description: >- Storage policies codify how long session recordings must be kept, and when they should be deleted. You can configure retention periods based on your compliance needs.

- Learn more: Storage policies and Configure storage bucket policies + Learn more: Storage policies and Configure storage bucket policies @@ -348,7 +348,7 @@ description: >- As noted in the v0.14.0 and v0.12.0 release notes, targets now require a default port value. Previously, any ports that you defined as part of a host address were ignored, but allowed as part of the target definition. Now, if you define a port on a host address it results in an error. As of this release, the restriction also affects existing addresses. Any existing addresses that contain a port cannot be used as part of a target's session authorization call.

Learn more:  - Targets + Targets diff --git a/website/content/docs/release-notes/v0_16_0.mdx b/website/content/docs/release-notes/v0_16_0.mdx index 581f1fafd..b01f15b21 100644 --- a/website/content/docs/release-notes/v0_16_0.mdx +++ b/website/content/docs/release-notes/v0_16_0.mdx @@ -367,7 +367,7 @@ description: >- The include_terminated field from the list sessions command has been deprecated and will be removed in an upcoming release. Boundary will return terminated sessions in all list session responses, unless they are filtered out using the filter field. For more information, refer to the filter resource documentation.

Learn more:  - sessions list command options and Filter resource listings + sessions list command options and Filter resource listings diff --git a/website/content/docs/release-notes/v0_17_0.mdx b/website/content/docs/release-notes/v0_17_0.mdx index e5072f0d3..4ff86ed30 100644 --- a/website/content/docs/release-notes/v0_17_0.mdx +++ b/website/content/docs/release-notes/v0_17_0.mdx @@ -66,7 +66,7 @@ description: >- Prior to this version, if you wanted to edit or update worker tags, you had to do it using the worker configuration file, the CLI, or the API. Now, you can edit worker tags directly in the Boundary UI.

- Learn more: Worker tags. + Learn more: Worker tags. diff --git a/website/content/docs/release-notes/v0_18_0.mdx b/website/content/docs/release-notes/v0_18_0.mdx index daffdaeab..075e750bd 100644 --- a/website/content/docs/release-notes/v0_18_0.mdx +++ b/website/content/docs/release-notes/v0_18_0.mdx @@ -108,7 +108,7 @@ description: >- AWS host plugins now support AssumeRole. AssumeRole returns a set of temporary security credentials that you can use to access AWS resources.

- Learn more: AWS dynamic host catalogs. + Learn more: AWS dynamic host catalogs. @@ -194,7 +194,7 @@ description: >-

In version 0.18.0 and earlier, there was a maximum number of managed groups supported for an auth method. If you had over 10,000 managed groups, Boundary may have incorrectly removed a user from a group during authentication. This issue is fixed in version 0.18.1. There is no longer a maximum number of managed groups.

- Learn more:  Managed groups + Learn more:  Managed groups

Upgrade to the latest version of Boundary diff --git a/website/content/docs/release-notes/v0_19_0.mdx b/website/content/docs/release-notes/v0_19_0.mdx index 48f7ff363..17480b75a 100644 --- a/website/content/docs/release-notes/v0_19_0.mdx +++ b/website/content/docs/release-notes/v0_19_0.mdx @@ -121,7 +121,7 @@ description: >-

When you configure dynamic host catalogs, Boundary securely queries infrastructure providers at runtime to discover and configure new services. You can define rules for whether you want Boundary to automatically add any discovered hosts as members of the host set.

- Learn more: Host discovery and GCP dynamic hosts. + Learn more: Host discovery and GCP dynamic hosts. @@ -135,7 +135,7 @@ description: >- A new filter generator was added to the Admin Console UI, allowing you to more easily create worker filters for targets, credential stores, and storage buckets.

- Learn more: Worker tags. + Learn more: Worker tags. @@ -163,7 +163,7 @@ description: >- The Azure plugin now supports Azure Virtual Machine Scale Sets in both Flexible and Uniform orchestration modes for dynamic host catalogs. It automatically discovers any individual virtual machine instances that are part of the scale sets and adds them as hosts.

- Learn more: Azure dynamic host catalogs. + Learn more: Azure dynamic host catalogs. diff --git a/website/content/docs/release-notes/v0_2_0.mdx b/website/content/docs/release-notes/v0_2_0.mdx index 20585afeb..af945a0fd 100644 --- a/website/content/docs/release-notes/v0_2_0.mdx +++ b/website/content/docs/release-notes/v0_2_0.mdx @@ -26,11 +26,11 @@ get started with the new [Boundary OIDC learn tutorial](/boundary/tutorials). - **Manage sessions:** Users can manage all of their active sessions or drill down to sessions associated with a specific target. - **AutoUpdate:** AutoUpdate the Boundary Desktop app as new versions become available. -**Worker tags & filters (0.1.5):** Enable target traffic to be effectively “tied” to a given set of workers with [worker tags](/boundary/docs/concepts/filtering/worker-tags), forcing the session to occur through specified workers for a specific target. +**Worker tags & filters (0.1.5):** Enable target traffic to be effectively “tied” to a given set of workers with [worker tags](/boundary/docs/workers/worker-tags), forcing the session to occur through specified workers for a specific target. Improvements to list actions:\*\* There have been numerous improvements to listing actions since Boundary 0.1.0. -- **Resource filtering (0.1.8):** allows users to navigate their resources more easily by [filtering list actions based on resource information](/boundary/docs/concepts/filtering/resource-listing). +- **Resource filtering (0.1.8):** allows users to navigate their resources more easily by [filtering list actions based on resource information](/boundary/docs/filtering). - **Recursive listing (0.1.5):** allows users to recursively list resources across a scope. - **List authorizations (0.1.5):** allows users to see what actions they’re authorized to perform against the resources returned in a list command. diff --git a/website/content/docs/release-notes/v0_4_0.mdx b/website/content/docs/release-notes/v0_4_0.mdx index 870bd8b5d..be07e5b3a 100644 --- a/website/content/docs/release-notes/v0_4_0.mdx +++ b/website/content/docs/release-notes/v0_4_0.mdx @@ -14,7 +14,7 @@ Lastly, for instructions on how to upgrade an existing Boundary deployment to v0 ## 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) - +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/domain-model/credential-stores), [credential libraries](/boundary/docs/domain-model/credential-libraries), and [credentials](/boundary/docs/domain-model/credentials) - to support binding credentials with user sessions, as well as surfacing those credentials during session initialization on the command line and in Boundary Desktop. **`boundary connect` Credential Brokering Integration:** Additionally, we have started integration into the [boundary connect helpers](/boundary/docs/getting-started/connect-to-target), starting in this release with the Postgres helper; if the credential contains a username/password and boundary connect postgres is the helper being used, the command will automatically pass the credentials to the psql process. diff --git a/website/content/docs/release-notes/v0_8_0.mdx b/website/content/docs/release-notes/v0_8_0.mdx index bec2546d3..2ad056ea4 100644 --- a/website/content/docs/release-notes/v0_8_0.mdx +++ b/website/content/docs/release-notes/v0_8_0.mdx @@ -21,7 +21,7 @@ as well as a [health endpoint](/boundary/docs/oss/operations/health) for control **Audit Event Logs:** We are expanding the audit event logs by increasing the captured [audit events](/boundary/docs/configuration/events/overview), with support for sanitizing sensitive information from audit events. All of the events are now classified and events contain more usable data, with sensitive information redacted by default. -**UI Support for Worker Tags:** Users can now set and edit [worker tag](/boundary/docs/concepts/filtering/worker-tags) filters in the Boundary admin console. +**UI Support for Worker Tags:** Users can now set and edit [worker tag](/boundary/docs/workers/worker-tags) filters in the Boundary admin console. **Performance Improvements:** We have implemented changes to improve performance on larger deployments; such as adding a refresh button in the admin console and desktop client, and improving response times listing sessions and targets. We plan to continue these efforts as Boundary users grow their deployments! diff --git a/website/content/docs/release-notes/v0_9_0.mdx b/website/content/docs/release-notes/v0_9_0.mdx index 95fe9ef88..de299c88b 100644 --- a/website/content/docs/release-notes/v0_9_0.mdx +++ b/website/content/docs/release-notes/v0_9_0.mdx @@ -29,7 +29,7 @@ authentication method is now called KMS Workers). PKI Workers authenticate to Bo without using a shared KMS. **Static Credential Store:** In Boundary 0.9.0, we are introducing the static credential store, a basic -[credential store](/boundary/docs/concepts/domain-model/credential-stores) that is native to Boundary. These credentials +[credential store](/boundary/docs/domain-model/credential-stores) that is native to Boundary. These credentials are encrypted and stored directly in Boundary. For users interested in integrated secrets management to Boundary targets, the new basic credential store removes the dependency on HashiCorp Vault. Currently, the static credential store only supports username/password type credentials. Note: If you wish to use the Desktop Client for credential brokering, version 1.4.4 and up is required. diff --git a/website/content/docs/concepts/security/connections-tls.mdx b/website/content/docs/secure/encryption/connections-tls.mdx similarity index 99% rename from website/content/docs/concepts/security/connections-tls.mdx rename to website/content/docs/secure/encryption/connections-tls.mdx index 3ec5dfa06..a61c01f63 100644 --- a/website/content/docs/concepts/security/connections-tls.mdx +++ b/website/content/docs/secure/encryption/connections-tls.mdx @@ -272,7 +272,7 @@ mechanism is as follows: ### KMS-based worker authentication -Workers can take advantage of the [KMS](/boundary/docs/concepts/security/data-encryption) +Workers can take advantage of the [KMS](/boundary/docs/secure/encryption/data-encryption) key designated for `worker-auth` within Boundary's configuration file, which must point to the same key on the KMS for both the Controller and the Worker. Security of the connection relies on secure transmission of a single set of diff --git a/website/content/docs/concepts/security/data-encryption.mdx b/website/content/docs/secure/encryption/data-encryption.mdx similarity index 95% rename from website/content/docs/concepts/security/data-encryption.mdx rename to website/content/docs/secure/encryption/data-encryption.mdx index 646dac467..b5c2f1be8 100644 --- a/website/content/docs/concepts/security/data-encryption.mdx +++ b/website/content/docs/secure/encryption/data-encryption.mdx @@ -5,7 +5,7 @@ description: >- Learn how key management services protect the encryption keys used for securing data. Understand key lifecycle management best practices. --- -# Data security in Boundary +# Data encryption 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 @@ -16,7 +16,7 @@ Boundary supports and how they are used within the system. ## The `worker-auth-storage` KMS key The `worker-auth-storage` KMS key can be used by [Workers registered using worker-led or controller-led -methods](/boundary/docs/configuration/worker/worker-configuration) for storage of authentication +methods](/boundary/docs/workers/registration#authorization-methods) for storage of authentication keys. It is optional for workers; if not specified the authentication keys will not be encrypted on disk. This can not used by workers registered using an external KMS. @@ -41,7 +41,7 @@ The current scoped DEKs and their purposes are detailed below: - `audit`: This is used to encrypt secret values in the event log. For more information about the event log, refer to - [the events config](/boundary/docs/configuration/events). + [the events config](/boundary/docs/monitor/events). - `database`: This is the general-purpose DEK used to encrypt values within the database. Values that are encrypted are those generally considered to be @@ -111,7 +111,7 @@ been destroyed and any existing data will have been re-encrypted. This feature requires HCP Boundary or Boundary Enterprise -The `bsr` KMS key is required for [session recording](/boundary/docs/configuration/session-recording). +The `bsr` KMS key is required for [session recording](/boundary/docs/session-recording). 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. @@ -128,9 +128,9 @@ You can configure `previous-root` KMS keys for self-managed Enterprise or Commun 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 -found on the [Connections/TLS page](/boundary/docs/concepts/security/connections-tls). If +found on the [Connections/TLS page](/boundary/docs/secure/encryption/connections-tls). If a worker is registered with [worker-led or controller-led -methods](/boundary/docs/configuration/worker/worker-configuration) this is unnecessary. +methods](/boundary/docs/workers/registration#authorization-methods) this is unnecessary. You can configure `worker-auth` KMS keys for HCP, Enterprise, and Community edition deployments. However, you cannot configure `worker-auth` keys for the first set of workers that connect to your HCP workers. diff --git a/website/content/docs/configuration/session-recording/configure-storage-policy.mdx b/website/content/docs/session-recording/compliance/configure-storage-policy.mdx similarity index 95% rename from website/content/docs/configuration/session-recording/configure-storage-policy.mdx rename to website/content/docs/session-recording/compliance/configure-storage-policy.mdx index 6e9ddfd72..733df1a75 100644 --- a/website/content/docs/configuration/session-recording/configure-storage-policy.mdx +++ b/website/content/docs/session-recording/compliance/configure-storage-policy.mdx @@ -9,7 +9,7 @@ description: >- This feature requires HCP Boundary Plus or Boundary Enterprise -As of Boundary 0.15.0, retention policies can codify storage bucket lifecycle management for [session recordings][]. +Retention policies can codify storage bucket lifecycle management for [session recordings][]. A Boundary resource known as a [storage bucket][] is used to store recorded sessions. A resource known as a [storage policy][] is used to codify how long session recordings must be kept and when they should be deleted. @@ -18,7 +18,7 @@ Storage policies that are created in the global scope can be associated with any However, a storage policy created in an org scope can only be associated with that org scope. Any storage policies associated with an org scope are deleted when you delete the org itself. -For more information about using session recording to audit user sessions, refer to [Auditing](/boundary/docs/concepts/auditing). +For more information about using session recording to audit user sessions, refer to [Session recording](/boundary/docs/session-recording). ## Requirements @@ -26,7 +26,7 @@ Before you can create a storage bucket in Boundary, you must ensure that your en A Boundary worker configured for local storage is also required to set up session recording and configure recording bucket policies. -Refer to [Create a storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket) to learn more about setting up storage for session recordings. +Refer to [Create a storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket) to learn more about setting up storage for session recordings. ## Example storage policies @@ -90,7 +90,7 @@ Complete the following steps to create a storage policy in Boundary for session -delete-after-overridable true ``` - The following [attributes](/boundary/docs/concepts/domain-model/storage-policies) can be used when defining a storage policy: + The following [attributes](/boundary/docs/domain-model/storage-policy) can be used when defining a storage policy: - `name`: (Optional) An optional human readable name. - `description`: (Optional) An optional human readable description. @@ -680,7 +680,7 @@ $ curl --header "Content-Type: application/json" \ - Existing recordings within a scope or its children do not automatically have new or updated polices applied to them. Policies must be re-applied to existing recordings to take effect. Refer to the [Update storage bucket policies](/boundary/docs/configuration/session-recording/update-storage-policy) page for more details. + Existing recordings within a scope or its children do not automatically have new or updated polices applied to them. Policies must be re-applied to existing recordings to take effect. Refer to the [Update storage bucket policies](/boundary/docs/session-recording/compliance/update-storage-policy) page for more details. @@ -692,8 +692,8 @@ If `delete_after` or `delete_time` is after the current time, the session record ## Next steps -After the storage policy is configured in Boundary, new recordings within the applied scope adhere to the defined policy. To retroactively apply the configured policy to existing recordings, refer to [update storage bucket policies](/boundary/docs/configuration/session-recording/update-storage-policy). +After the storage policy is configured in Boundary, new recordings within the applied scope adhere to the defined policy. To retroactively apply the configured policy to existing recordings, refer to [update storage bucket policies](/boundary/docs/session-recording/compliance/update-storage-policy). -[storage bucket]: /boundary/docs/concepts/domain-model/storage-buckets -[storage policy]: /boundary/docs/concepts/domain-model/storage-policy -[session recordings]: /boundary/docs/concepts/domain-model/session-recordings +[storage bucket]: /boundary/docs/domain-model/storage-buckets +[storage policy]: /boundary/docs/domain-model/storage-policy +[session recordings]: /boundary/docs/domain-model/session-recordings diff --git a/website/content/docs/configuration/session-recording/update-storage-policy.mdx b/website/content/docs/session-recording/compliance/update-storage-policy.mdx similarity index 93% rename from website/content/docs/configuration/session-recording/update-storage-policy.mdx rename to website/content/docs/session-recording/compliance/update-storage-policy.mdx index 8096accc7..0adedf620 100644 --- a/website/content/docs/configuration/session-recording/update-storage-policy.mdx +++ b/website/content/docs/session-recording/compliance/update-storage-policy.mdx @@ -17,11 +17,11 @@ When you update a storage policy, new session recordings within a scope where th This page describes the process for applying updated storage policies to existing recordings within a scope. -For more information about setting up storage bucket policies, refer to the [configure storage bucket policies](/boundary/docs/configuration/session-recording/configure-storage-policy) page. +For more information about setting up storage bucket policies, refer to the [configure storage bucket policies](/boundary/docs/session-recording/compliance/configure-storage-policy) page. ## Requirements -This page continues the workflows outlined in the [configure storage bucket policies](/boundary/docs/configuration/session-recording/configure-storage-policy) page. The requirements outlined in that page are prerequisites for the workflow defined below. +This page continues the workflows outlined in the [configure storage bucket policies](/boundary/docs/session-recording/compliance/configure-storage-policy) page. The requirements outlined in that page are prerequisites for the workflow defined below. To apply an updated storage policy to existing session recordings, you first need: @@ -39,7 +39,7 @@ A storage policy defines how long the recording within a scope should retain its Over time, you may update storage policies to reflect new organizational requirements, compliance changes, or cost management strategies. While updated policies automatically apply to new session recordings within the scopes associated with that policy, existing recordings maintain the previous policies unless you apply the new policy directly to those recordings. -In the [configure storage bucket policies](/boundary/docs/configuration/session-recording/configure-storage-policy) page, the following policy was created to implement compliance with SOC-2 retention requirement of 7 years: +In the [configure storage bucket policies](/boundary/docs/session-recording/compliance/configure-storage-policy) page, the following policy was created to implement compliance with SOC-2 retention requirement of 7 years: - Name: `soc2-policy` - Description: `SOC 2 compliant storage policy for session recordings` @@ -194,7 +194,7 @@ $ curl --header "Content-Type: application/json" \ -This policy was applied to the `prod-databases` org in the [configure storage bucket policies](/boundary/docs/configuration/session-recording/configure-storage-policy) page. +This policy was applied to the `prod-databases` org in the [configure storage bucket policies](/boundary/docs/session-recording/compliance/configure-storage-policy) page. New recordings within the `prod-databases` org will automatically have the updated version of the `soc2-policy` applied. @@ -345,6 +345,6 @@ If a scope's storage policy is detached or deleted, new session recordings withi Existing session recordings will maintain their existing storage policy attributes until a new policy is re-applied, including any overriding policy from another scope. -[storage bucket]: /boundary/docs/concepts/domain-model/storage-buckets -[storage policy]: /boundary/docs/concepts/domain-model/storage-policy -[session recordings]: /boundary/docs/concepts/domain-model/session-recordings +[storage bucket]: /boundary/docs/domain-model/storage-buckets +[storage policy]: /boundary/docs/domain-model/storage-policy +[session recordings]: /boundary/docs/domain-model/session-recordings diff --git a/website/content/docs/operations/session-recordings/validate-data-store.mdx b/website/content/docs/session-recording/compliance/validate-data-store.mdx similarity index 90% rename from website/content/docs/operations/session-recordings/validate-data-store.mdx rename to website/content/docs/session-recording/compliance/validate-data-store.mdx index be7f20c7b..4a8e9401b 100644 --- a/website/content/docs/operations/session-recordings/validate-data-store.mdx +++ b/website/content/docs/session-recording/compliance/validate-data-store.mdx @@ -16,4 +16,4 @@ local disk and compares it to the plugin value. This process ensures that no tampering of BSR files occurs between the worker, plugin, and S3. The SHA256 checksum value generated by the plugin is not a part of the BSR file structure and should not be confused with how Boundary cryptographically verifies the BSR directory's contents. -For more information, refer to the [overview of configuring session recording](/boundary/docs/configuration/session-recording). \ No newline at end of file +For more information, refer to the [overview of session recording](/boundary/docs/session-recording). \ No newline at end of file diff --git a/website/content/docs/operations/session-recordings/validate-session-recordings.mdx b/website/content/docs/session-recording/compliance/validate-session-recordings.mdx similarity index 100% rename from website/content/docs/operations/session-recordings/validate-session-recordings.mdx rename to website/content/docs/session-recording/compliance/validate-session-recordings.mdx diff --git a/website/content/docs/configuration/session-recording/configure-worker-storage.mdx b/website/content/docs/session-recording/configuration/configure-worker-storage.mdx similarity index 91% rename from website/content/docs/configuration/session-recording/configure-worker-storage.mdx rename to website/content/docs/session-recording/configuration/configure-worker-storage.mdx index 6c00f1301..a0da472c0 100644 --- a/website/content/docs/configuration/session-recording/configure-worker-storage.mdx +++ b/website/content/docs/session-recording/configuration/configure-worker-storage.mdx @@ -24,9 +24,9 @@ Workers that you configure for storage must: - Have access to the external storage provider - Have an accessible directory defined by `recording_storage_path` for storing session recordings while they are in progress. On session closure, Boundary moves the local session recording to remote storage and deletes the local copy. - For HCP Boundary, refer to the [Self-managed worker configuration](/hcp/docs/boundary/self-managed-workers/session-recording) documentation. - - For Boundary Enterprise, refer to the refer to the [worker configuration](/boundary/docs/configuration/worker/worker-configuration#session-recording) documentation. + - For Boundary Enterprise, refer to the refer to the [worker configuration](/boundary/docs/workers#session-recording) documentation. - Have available disk space defined by `recording_storage_minimum_available_capacity`. If you do not configure the minimum available storage capacity, Boundary uses the default value of 500MiB. -For more information about how much space is required to store BSR files, refer to [storage considerations](/boundary/docs/configuration/session-recording#storage-considerations). +For more information about how much space is required to store BSR files, refer to [storage considerations](/boundary/docs/session-recording#storage-considerations). - Run Darwin, Windows, or Linux. The following binaries are not supported for session recording: NetBSD, OpenBSD, Solaris. ## Local storage @@ -112,4 +112,4 @@ worker { ## Next steps -After you configure worker storage, you can configure the external storage for [Amazon S3](/boundary/docs/configuration/session-recording/storage-providers/configure-s3), [MinIO](/boundary/docs/configuration/session-recording/storage-providers/configure-minio), or an [S3-compliant provider](/boundary/docs/configuration/session-recording/storage-providers/configure-s3-compliant). \ No newline at end of file +After you configure worker storage, you can configure the external storage for [Amazon S3](/boundary/docs/session-recording/configuration/storage-providers/configure-s3), [MinIO](/boundary/docs/session-recording/configuration/storage-providers/configure-minio), or an [S3-compliant provider](/boundary/docs/session-recording/configuration/storage-providers/configure-s3-compliant). \ No newline at end of file diff --git a/website/content/docs/configuration/session-recording/create-storage-bucket.mdx b/website/content/docs/session-recording/configuration/create-storage-bucket.mdx similarity index 87% rename from website/content/docs/configuration/session-recording/create-storage-bucket.mdx rename to website/content/docs/session-recording/configuration/create-storage-bucket.mdx index 36962c257..0d41d2ceb 100644 --- a/website/content/docs/configuration/session-recording/create-storage-bucket.mdx +++ b/website/content/docs/session-recording/configuration/create-storage-bucket.mdx @@ -9,23 +9,21 @@ description: >- This feature requires HCP Boundary Plus or Boundary Enterprise -User sessions can be recorded and audited using Boundary 0.13 or greater. A Boundary resource known as a [storage bucket](/boundary/docs/concepts/domain-model/storage-buckets) is used to store the recorded sessions. +You can record and audit user sessions. A Boundary resource known as a [storage bucket](/boundary/docs/domain-model/storage-buckets) is used to store the recorded sessions. The storage bucket represents a bucket in an external storage provider. Before you can enable session recording, you must create one or more storage buckets in Boundary and associate them with the external store. A storage bucket can only belong to the global scope or an org scope. A storage bucket that is associated with the global scope can be associated with any target. However, a storage bucket in an Org scope can only be associated with targets in a project from the same org scope. Any storage buckets associated with an Org scope are deleted when the org itself is deleted. -For more information about using session recording to audit user sessions, refer to [Auditing](/boundary/docs/concepts/auditing). - ## Requirements Before you create a storage bucket in Boundary, you must: -- [Configure workers for storage](/boundary/docs/configuration/session-recording/configure-worker-storage) +- [Configure workers for storage](/boundary/docs/session-recording/configuration/configure-worker-storage) - Configure one of the following storage providers: - - [Amazon S3](/boundary/docs/configuration/session-recording/storage-providers/configure-s3) - - [MinIO](/boundary/docs/configuration/session-recording/storage-providers/configure-minio) - - [S3-compliant](/boundary/docs/configuration/session-recording/storage-providers/configure-s3-compliant) + - [Amazon S3](/boundary/docs/session-recording/configuration/storage-providers/configure-s3) + - [MinIO](/boundary/docs/session-recording/configuration/storage-providers/configure-minio) + - [S3-compliant](/boundary/docs/session-recording/configuration/storage-providers/configure-s3-compliant) ## Create a storage bucket @@ -61,7 +59,7 @@ Complete the following steps to create a storage bucket in Boundary. - **Access key ID**: (Required) The access key ID that AWS generates for the IAM user to use with the storage bucket. - **Secret access key**: (Required) The secret access key that AWS generates for the IAM user to use with this storage bucket. - - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - **Disable credential rotation**: (Optional) Prevents the AWS plugin from automatically rotating credentials. Although credentials are stored encrypted in Boundary, by default the [AWS plugin](https://github.com/hashicorp/boundary-plugin-aws) attempts to rotate the credentials you provide. The given credentials are used to create a new credential, and then the original credential is revoked. @@ -79,7 +77,7 @@ Complete the following steps to create a storage bucket in Boundary. For more information, refer to the AWS documentation for [Logging IAM and AWS STS API calls with AWS CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html). - **Role tags**: An object with key-value pair attributes that is passed when you assume an IAM role. For more information, refer to the AWS documentation for [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). - - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - **Disable credential rotation**: (Required) Prevents the AWS plugin from automatically rotating credentials. This option is required if you use dynamic credentials. @@ -115,13 +113,13 @@ The required fields for creating a storage bucket depend on whether you configur -attributes ‘{“region”:”us-east-1”,”disable_credential_rotation”:true}’ ``` - Replace the values above with the following required AWS secrets and any [attributes](/boundary/docs/concepts/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: + Replace the values above with the following required AWS secrets and any [attributes](/boundary/docs/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: - `region`: (Required) The AWS region to use. - `bucket-name`: (Required) The name of the AWS bucket you want to associate with the Boundary storage bucket. - `plugin-name`: (Required) The name of the Boundary storage plugin. - `scope_id`: (Required) A storage bucket can belong to the Global scope or an Org scope. - - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - `secret`: (Required) The AWS credentials to use. - `access_key_id`: (Required) The AWS access key to use. - `secret_access_key_id`: (Required) The AWS secret access key to use. @@ -149,23 +147,23 @@ The required fields for creating a storage bucket depend on whether you configur -attributes ‘{“region”:”us-east-1”,”disable_credential_rotation”:true,"role_arn":"arn:aws:iam::123456789012:role/S3Access"}’ ``` - Replace the values above with the following required AWS secrets and any [attributes](/boundary/docs/concepts/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: + Replace the values above with the following required AWS secrets and any [attributes](/boundary/docs/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: - `region`: (Required) The AWS region to use. - `bucket-name`: (Required) The name of the AWS bucket you want to associate with the Boundary storage bucket. - `plugin-name`: (Required) The name of the Boundary storage plugin. - `scope_id`: (Required) A storage bucket can belong to the Global scope or an Org scope. - - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - `attributes` or `-attr`: Attributes of the Amazon S3 storage bucket. - `role_arn`: (Required) The ARN (Amazon Resource Name) role that is attached to the EC2 instance that the self-managed worker runs on. - - `role_external_id`: (Optional) A required value if you delegate third party access to your AWS resources. - For more information, refer to the AWS documentation for [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/ id_roles_create_for-user_externalid.html). + - `role_external_id`: (Optional) A required value if you delegate third party access to your AWS resources. + For more information, refer to the AWS documentation for [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). - `role_session_name`: (Optional) A unique identifier for the AWS session. You can use this value to control how IAM principals and applications name their role sesions when they assume an IAM role. By providing a session name, you enable tracking session actions in AWS CloudTrail logs. - For more information, refer to the AWS documentation for [Logging IAM and AWS STS API calls with AWS CloudTrail](https://docs.aws.amazon.com/IAM/ latest/UserGuide/cloudtrail-integration.html). + For more information, refer to the AWS documentation for [Logging IAM and AWS STS API calls with AWS CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html). - `role_tags`: (Optional) An object with key-value pair attributes that is passed when you assume an IAM role. - For more information, refer to the AWS documentation for [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/ id_session-tags.html). + For more information, refer to the AWS documentation for [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). @@ -254,7 +252,7 @@ Complete the following steps to create a storage bucket in Boundary. - MinIO requires a service account and its associated access keys to set up a Boundary storage bucket. Refer to the [Configure MinIO](/boundary/docs/configuration/session-recording/storage-providers/configure-minio#minio-requirements) page to learn more. + MinIO requires a service account and its associated access keys to set up a Boundary storage bucket. Refer to the [Configure MinIO](/boundary/docs/session-recording/configuration/storage-providers/configure-minio#minio-requirements) page to learn more. @@ -275,7 +273,7 @@ Complete the following steps to create a storage bucket in Boundary. - **Region**: (Optional) The region to configure the storage bucket for. - **Access key ID** (Required): The MinIO service account's access key to use with this storage bucket. - **Secret access key** (Required): The MinIO service account's secret key to use with this storage bucket. - - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - **Disable credential rotation**: (Optional) Controls whether the plugin will rotate the incoming credentials and manage a new MinIO service account. If this attribute is set to false, or not provided, the plugin will rotate the incoming credentials, using them to create a new MinIO service account, then delete the incoming credentials. 1. Click **Save**. @@ -300,12 +298,12 @@ Complete the following steps to create a storage bucket in Boundary. -secret secret_access_key="SECRET" ``` - Replace the values above with the following required secrets and any optional [attributes](/boundary/docs/concepts/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: + Replace the values above with the following required secrets and any optional [attributes](/boundary/docs/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: - `bucket-name`: (Required) Name of the MinIO bucket you want to associate with the Boundary storage bucket. - `plugin-name`: (Required) The name of the Boundary storage plugin. - `scope_id`: (Required) A storage bucket can belong to the Global scope or an Org scope. - - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - `secret`: (Required) The MinIO credentials to use. - `access_key_id` (Required): The MinIO service account's access key to use with this storage bucket. - `secret_access_key` (Required): The MinIO service account's secret key to use with this storage bucket. @@ -362,7 +360,7 @@ Complete the following steps to create a storage bucket in Boundary using an S3- - S3-compliant storage requires a service account and its associated access keys to set up a Boundary storage bucket. Refer to the [Configure S3-compliant storage](/boundary/docs/configuration/session-recording/storage-providers/configure-s3-compliant#s3-compliant-storage-provider-requirements) page to learn more. + S3-compliant storage requires a service account and its associated access keys to set up a Boundary storage bucket. Refer to the [Configure S3-compliant storage](/boundary/docs/session-recording/configuration/storage-providers/configure-s3-compliant#s3-compliant-storage-provider-requirements) page to learn more. @@ -384,7 +382,7 @@ Complete the following steps to create a storage bucket in Boundary using an S3- - **Region**: (Optional) The region to configure the storage bucket for. - **Access key ID** (Required): The storage provider's service account's access key to use with this storage bucket. - **Secret access key** (Required): The storage provider's service account's secret key to use with this storage bucket. - - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - **Worker filter**: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker to create a Boundary storage bucket. This should be a boolean expression. To generate a worker filter in the correct format, toggle the **Show filter generator** switch. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - **Disable credential rotation**: (Optional) Controls whether the plugin will rotate the incoming credentials and manage a new storage service account. If this attribute is set to false, or not provided, the plugin will rotate the incoming credentials, using them to create a new storage service account, then delete the incoming credentials. Note that credential rotation is not supported for Hitachi Content Platform, and it may not function for other S3-compatible providers. @@ -411,13 +409,13 @@ Complete the following steps to create a storage bucket in Boundary using an S3- -secret secret_access_key="SECRET" ``` - Replace the values above with the following required secrets and any optional [attributes](/boundary/docs/concepts/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: + Replace the values above with the following required secrets and any optional [attributes](/boundary/docs/domain-model/storage-buckets) you want to associate with the Boundary storage bucket: - `bucket-name`: (Required) Name of the S3-compliant storage bucket you want to associate with the Boundary storage bucket. - `plugin-name`: (Required) The name of the Boundary storage plugin. Use the `minio` plugin for S3-compatible storage. - `scope_id`: (Required) A storage bucket can belong to the Global scope or an Org scope. - - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. + - `worker-filter`: (Required) A filter expression that indicates which Boundary workers have access to the storage. The filter must match an existing worker in order to create a Boundary storage bucket. Refer to [the filter example for storage buckets](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) to learn about worker tags and filters. - `secret`: (Required) The storage provider's credentials to use. - `access_key_id` (Required): The storage provider's service account's access key to use with this storage bucket. - `secret_access_key` (Required): The storage provider's service account's secret key to use with this storage bucket. @@ -474,13 +472,14 @@ Boundary creates the storage bucket resource and provides you with the bucket's ## Next steps -After the storage bucket is created in Boundary, you can use the bucket's ID to [enable session recording on targets](/boundary/docs/configuration/session-recording/enable-session-recording). +After the storage bucket is created in Boundary, you can use the bucket's ID to [enable session recording on targets](/boundary/docs/session-recording/configuration/enable-session-recording). ## Resources The following docs are relevant to configuring storage buckets: -- [Storage bucket attributes](/boundary/docs/concepts/domain-model/storage-buckets) -- [Worker filter examples](/boundary/docs/concepts/filtering/worker-tags#example-worker-filter-for-storage-buckets) +- [Storage bucket attributes](/boundary/docs/domain-model/storage-buckets) +- [Storage bucket worker filter example](/boundary/docs/workers/filters#example-worker-filter-for-storage-buckets) - [Boundary AWS plugin](https://github.com/hashicorp/boundary-plugin-aws) -- [Boundary MinIO plugin](https://github.com/hashicorp/boundary-plugin-minio) \ No newline at end of file +- [Boundary MinIO plugin](https://github.com/hashicorp/boundary-plugin-minio) +- [Filtering and listing resources](/boundary//docs/filtering) \ No newline at end of file diff --git a/website/content/docs/configuration/session-recording/enable-session-recording.mdx b/website/content/docs/session-recording/configuration/enable-session-recording.mdx similarity index 80% rename from website/content/docs/configuration/session-recording/enable-session-recording.mdx rename to website/content/docs/session-recording/configuration/enable-session-recording.mdx index b29dd49a4..211c69b87 100644 --- a/website/content/docs/configuration/session-recording/enable-session-recording.mdx +++ b/website/content/docs/session-recording/configuration/enable-session-recording.mdx @@ -10,7 +10,7 @@ description: >- This feature requires HCP Boundary Plus or Boundary Enterprise You must enable session recording for any targets that you want to record sessions on. -When you [create a storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket), Boundary provides you with an ID. +When you [create a storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket), Boundary provides you with an ID. You use the storage bucket's ID to associate a target with the storage bucket. ## Requirements @@ -19,11 +19,11 @@ You use the storage bucket's ID to associate a target with the storage bucket. - Session recording is only supported for SSH targets at this time. - A KMS key with the purpose `bsr` must be added to the controller configuration. The key is used for encrypting data and checking the integrity of recordings. -Refer to [Create the controller configuration](/boundary/docs/install-boundary/configure-controllers#create-the-controller-configuration) and [the `bsr` KMS key](/boundary/docs/concepts/security/data-encryption#the-bsr-kms-key) documentation for more information about configuring a KMS block. +Refer to [Create the controller configuration](/boundary/docs/deploy/self-managed/configure-controllers#create-the-controller-configuration) and [the `bsr` KMS key](/boundary/docs/secure/encryption/data-encryption#the-bsr-kms-key) documentation for more information about configuring a KMS block. - The targets must be configured with an ingress or egress worker filter that includes a worker with access to the storage bucket you created. -Refer to [SSH target attributes](/boundary/docs/concepts/domain-model/targets#ssh-target-attributes) for more information. +Refer to [SSH target attributes](/boundary/docs/domain-model/targets#ssh-target-attributes) for more information. - You must enable injected application credentials on any target that you want to use for session recording. -Refer to [Configure targets with credential injection](/boundary/docs/configuration/credential-management/configure-credential-injection) for more information about injecting application credentials. +Refer to [Configure targets with credential injection](/boundary/docs/credentials/configure-credential-injection) for more information about injecting application credentials. Complete the following steps to enable session recording on a target. @@ -39,7 +39,7 @@ Complete the following steps to enable session recording on a target. - To create a new target, select **New Target**. - To edit an existing target, select the target, and then select **Edit Form**. -1. Configure the target with any relevant [attributes](/boundary/docs/concepts/domain-model/targets). +1. Configure the target with any relevant [attributes](/boundary/docs/domain-model/targets). The following setting is required for session recording: - Select **SSH** for the **Type**. @@ -53,7 +53,7 @@ The following setting is required for session recording: 1. Enable the **Record sessions for this target** option. 1. Select the storage bucket where you want to store recordings from this target. - You can also [create a new storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket). + You can also [create a new storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket). 1. Click **Save**. @@ -80,7 +80,7 @@ The following setting is required for session recording: Make sure to add the `-enable-session-recording true` flag to turn on session recording for the target. Add the `-storage-bucket-id ID` for the storage bucket you want to associate with this target. - You can configure any other [target attributes](/boundary/docs/concepts/domain-model/targets). + You can configure any other [target attributes](/boundary/docs/domain-model/targets). You can now view the target from the **Targets** page in the Boundary console. @@ -113,4 +113,4 @@ Any user session that connects to the target is automatically recorded. ## Next steps -After you have enabled session recording, you may want to [configure storage policies](/boundary/docs/configuration/session-recording/configure-storage-policy) to codify the lifecycle management of your session recordings. +After you have enabled session recording, you may want to [configure storage policies](/boundary/docs/session-recording/compliance/configure-storage-policy) to codify the lifecycle management of your session recordings. diff --git a/website/content/docs/operations/session-recordings/manage-recorded-sessions.mdx b/website/content/docs/session-recording/configuration/manage-recorded-sessions.mdx similarity index 90% rename from website/content/docs/operations/session-recordings/manage-recorded-sessions.mdx rename to website/content/docs/session-recording/configuration/manage-recorded-sessions.mdx index 53db89f61..58b136479 100644 --- a/website/content/docs/operations/session-recordings/manage-recorded-sessions.mdx +++ b/website/content/docs/session-recording/configuration/manage-recorded-sessions.mdx @@ -10,7 +10,7 @@ description: >- This feature requires HCP Boundary or Boundary Enterprise Boundary converts recorded sessions into an asciicast format so that you can play back interactive SSH sessions. -Make sure to refer to the [asciicast](/boundary/docs/operations/session-recordings#asciicast) section to understand potential limitations to the asciicast format. +Make sure to refer to the [asciicast](/boundary/docs/session-recording#asciicast) documentation to understand potential limitations to the asciicast format. You can view a list of all recorded sessions, or if you know the ID of a specific recorded session, you can find any channels associated with that recording. @@ -93,3 +93,10 @@ You can find all recorded sessions in the UI from the global scope. + +## More information + +Refer to the following topics for more information: + +- [Session recording](/boundary/docs/session-recording) +- [asciicast](/boundary/docs/session-recording#asciicast) diff --git a/website/content/docs/configuration/session-recording/storage-providers/configure-minio.mdx b/website/content/docs/session-recording/configuration/storage-providers/configure-minio.mdx similarity index 91% rename from website/content/docs/configuration/session-recording/storage-providers/configure-minio.mdx rename to website/content/docs/session-recording/configuration/storage-providers/configure-minio.mdx index 35add2959..b8591d8c8 100644 --- a/website/content/docs/configuration/session-recording/storage-providers/configure-minio.mdx +++ b/website/content/docs/session-recording/configuration/storage-providers/configure-minio.mdx @@ -17,12 +17,12 @@ Before you can create a storage bucket in Boundary, you must ensure that your en Session recording requires specific configuration for both the external storage provider and the Boundary worker. -Refer to [Configure workers for session recording](/boundary/docs/configuration/session-recording/configure-worker-storage) to learn about configuring self-managed workers for session recording. +Refer to [Configure workers for session recording](/boundary/docs/session-recording/configuration/configure-worker-storage) to learn about configuring self-managed workers for session recording. When you determine storage requirements for the external bucket, you should consider: -- [BSR storage considerations](/boundary/docs/configuration/session-recording#storage-considerations) -- [Storage bucket retention policies](/boundary/docs/configuration/session-recording/configure-storage-policy) +- [BSR storage considerations](/boundary/docs/session-recording#storage-considerations) +- [Storage bucket retention policies](/boundary/docs/session-recording/compliance/configure-storage-policy) ### MinIO requirements @@ -112,4 +112,4 @@ The following docs MinIO docs are relevant for configuring storage buckets and s ## Next steps -After you configure the external storage provider, you can [create the storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket) in Boundary. \ No newline at end of file +After you configure the external storage provider, you can [create the storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket) in Boundary. \ No newline at end of file diff --git a/website/content/docs/configuration/session-recording/storage-providers/configure-s3-compliant.mdx b/website/content/docs/session-recording/configuration/storage-providers/configure-s3-compliant.mdx similarity index 89% rename from website/content/docs/configuration/session-recording/storage-providers/configure-s3-compliant.mdx rename to website/content/docs/session-recording/configuration/storage-providers/configure-s3-compliant.mdx index 1b5fc358d..823b838c7 100644 --- a/website/content/docs/configuration/session-recording/storage-providers/configure-s3-compliant.mdx +++ b/website/content/docs/session-recording/configuration/storage-providers/configure-s3-compliant.mdx @@ -14,7 +14,7 @@ The [MinIO plugin](https://github.com/hashicorp/boundary-plugin-minio/) lets you HashiCorp has tested and confirmed that you can configure the following S3-compliant storage products for session recording using the MinIO plugin: -- [Hitachi Content Platform](https://trycontent.hitachivantara.com) +- [Hitachi Content Platform](https://www.hitachivantara.com) At the time of the 0.18.0 release, the latest tested and supported Hitachi Content Platform version is `2.6.0.0`. Newer versions may work as well, but they have not been tested. @@ -33,12 +33,12 @@ Before you can create a storage bucket in Boundary, you must ensure that your en Session recording requires specific configuration for both the external storage provider and the Boundary worker. -Refer to [Configure workers for session recording](/boundary/docs/configuration/session-recording/configure-worker-storage) to learn about configuring self-managed workers for session recording. +Refer to [Configure workers for session recording](/boundary/docs/session-recording/configuration/configure-worker-storage) to learn about configuring self-managed workers for session recording. When you determine storage requirements for the external bucket, you should consider: -- [BSR storage considerations](/boundary/docs/configuration/session-recording#storage-considerations) -- [Storage bucket retention policies](/boundary/docs/configuration/session-recording/configure-storage-policy) +- [BSR storage considerations](/boundary/docs/session-recording#storage-considerations) +- [Storage bucket retention policies](/boundary/docs/session-recording/compliance/configure-storage-policy) ### S3-compliant storage provider requirements @@ -86,7 +86,7 @@ You should be able to configure other S3-compliant storage providers to work for You must have an account with Hitachi Content Platform to create storage buckets. You can sign up for an account at the following URL: -[https://trycontent.hitachivantara.com](https://trycontent.hitachivantara.com) +[https://www.hitachivantara.com](https://www.hitachivantara.com) When you sign up for an account, Hitachi sends you the details you need to connect to the instance including the endpoint, S3 access key ID, and S3 secret key. Log in to Hitachi's S3 console to create a storage bucket, and make a note of the bucket's name. @@ -111,4 +111,4 @@ Refer to your S3-compliant storage provider's documentation for more information ## Next steps -After you configure the external storage provider, you can [create the storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket) in Boundary. \ No newline at end of file +After you configure the external storage provider, you can [create the storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket) in Boundary. \ No newline at end of file diff --git a/website/content/docs/configuration/session-recording/storage-providers/configure-s3.mdx b/website/content/docs/session-recording/configuration/storage-providers/configure-s3.mdx similarity index 91% rename from website/content/docs/configuration/session-recording/storage-providers/configure-s3.mdx rename to website/content/docs/session-recording/configuration/storage-providers/configure-s3.mdx index afdd30db4..e26155bdb 100644 --- a/website/content/docs/configuration/session-recording/storage-providers/configure-s3.mdx +++ b/website/content/docs/session-recording/configuration/storage-providers/configure-s3.mdx @@ -17,12 +17,12 @@ Before you can create a storage bucket in Boundary, you must ensure that your en Session recording requires specific configuration for both the external storage provider and the Boundary worker. -Refer to [Configure workers for session recording](/boundary/docs/configuration/session-recording/configure-worker-storage) to learn about configuring self-managed workers for session recording. +Refer to [Configure workers for session recording](/boundary/docs/session-recording/configuration/configure-worker-storage) to learn about configuring self-managed workers for session recording. When you determine storage requirements for the external bucket, you should consider: -- [BSR storage considerations](/boundary/docs/configuration/session-recording#storage-considerations) -- [Storage bucket retention policies](/boundary/docs/configuration/session-recording/configure-storage-policy) +- [BSR storage considerations](/boundary/docs/session-recording#storage-considerations) +- [Storage bucket retention policies](/boundary/docs/session-recording/compliance/configure-storage-policy) ### AWS requirements @@ -128,4 +128,4 @@ When you determine storage requirements for the external bucket, you should cons ## Next steps -After you configure the external storage provider, you can [create the storage bucket](/boundary/docs/configuration/session-recording/create-storage-bucket) in Boundary. \ No newline at end of file +After you configure the external storage provider, you can [create the storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket) in Boundary. \ No newline at end of file diff --git a/website/content/docs/troubleshoot/troubleshoot-recorded-sessions.mdx b/website/content/docs/session-recording/configuration/troubleshoot-recorded-sessions.mdx similarity index 94% rename from website/content/docs/troubleshoot/troubleshoot-recorded-sessions.mdx rename to website/content/docs/session-recording/configuration/troubleshoot-recorded-sessions.mdx index 9cb38f095..79f207b93 100644 --- a/website/content/docs/troubleshoot/troubleshoot-recorded-sessions.mdx +++ b/website/content/docs/session-recording/configuration/troubleshoot-recorded-sessions.mdx @@ -15,7 +15,7 @@ Refer to the following for information about how to troubleshoot recorded sessio **Rotation of AWS access and secret keys during a session results in stale recordings:** -In Boundary version 0.13.0, when you rotate a storage bucket's secrets, any new sessions use the new credentials. +When you rotate a storage bucket's secrets, any new sessions use the new credentials. However, previously established sessions continue to use the old credentials. As a best practice, administrators should rotate credentials in a phased manner, ensuring that all previously established sessions are completed before revoking the stale credentials. diff --git a/website/content/docs/session-recording/data/bsr-file-structure.mdx b/website/content/docs/session-recording/data/bsr-file-structure.mdx new file mode 100644 index 000000000..040880f06 --- /dev/null +++ b/website/content/docs/session-recording/data/bsr-file-structure.mdx @@ -0,0 +1,271 @@ +--- +layout: docs +page_title: BSR file data structure +description: >- + Understand the data structure in Boundary's proprietary BSR file that stores session recording data. +--- + +# BSR file data structure + +This feature requires HCP Boundary or Boundary Enterprise + +The BSR (Boundary Session Recording) defines a hierarchical directory structure of files and a binary file format. +It contains all the data transmitted between a user and a target during a single session. + +Boundary creates the top-level directory of the BSR as `.bsr`. This top level directory contains session summary +information and subdirectories for connections. + +A BSR connections directory contains a summary of connections, as well as inbound and outbound requests. +If you use a multiplexed protocol, there are subdirectories for the channels. + +Every directory contains a SHA256SUMS and SHA256SUMS.sig file, to be used for cryptographically verifying the contents of +that directory. The SHA256SUMS file contains rows of file names paired with a checksum for file contents. The +SHA256SUMS.sign is a copy of the SHA256SUMS file, signed with the BSR’s private key. For more information on verifying a +session recording, refer to [Validating the integrity of session recordings](/boundary/docs/session-recording/compliance/validate-session-recordings). + +The example BSR below is for a multiplexed session recording with the ID `sr_iNCdGSREeX`. The session recording contains one connection, +`cr_3bB78W53Y9`. Connection `cr_3bB78W53Y9` contains two channels, `chr_VUnVuVnITu` and `chr_nITuVUnVuV`. +The files in each directory are explained in the following sections. + +``` +└── sr_iNCdGSREeX.bsr + ├── SHA256SUM + ├── SHA256SUM.sig + ├── bsrKey.pub + ├── pubKeyBsrSignature.sign + ├── pubKeySelfSignature.sign + ├── session-meta.json + ├── session-recording-summary.json + ├── session-recording.meta + ├── wrappedBsrKey + ├── wrappedPrivKey + ├── cr_3bB78W53Y9.connection + │ ├── SHA256SUM + │ ├── SHA256SUM.sig + │ ├── connection-recording-summary.json + │ ├── connection-recording.meta + │ ├── requests-inbound.data + │ ├── requests-outbound.data + │ ├── chr_VUnVuVnITu.channel + │ │ ├── SHA256SUM + │ │ ├── SHA256SUM.sig + │ │ ├── channel-recording-summary.json + │ │ ├── channel-recording.meta + │ │ ├── messages-inbound.data + │ │ ├── messages-outbound.data + │ │ ├── requests-inbound.data + │ │ └── requests-outbound.data + │ ├── chr_nITuVUnVuV.channel + │ │ ├── SHA256SUM + │ │ ├── SHA256SUM.sig + │ │ ├── channel-recording-summary.json + │ │ ├── channel-recording.meta + │ │ ├── messages-inbound.data + │ │ ├── messages-outbound.data + │ │ ├── requests-inbound.data + │ │ └── requests-outbound.data + │ └── + └── + + +``` + +## BSR Session folder + +A BSR session folder contains the following files: + +- `SHA256SUM.sig` is a plaintext file that contains rows of file names paired with a checksum for file contents. +- `SHA256SUM.sig` is a signature of the plaintext `SHA256SUM` file created with the private key. +- `bsrKey.pub` is the public ed25519 key. +- `pubKeySelfSignature.sign` is a self-signature of the plaintext public ed25519 key created with its private key. +- `pubKeyBsrSignature.sign` is a signature of the plaintext public ed25519 key created with the BSR key. +- `wrappedBsrKey` is the BSR key wrapped by the external KMS AES-GCM key that you configure. +- `wrappedPrivKey` is the private ed25519 key wrapped by the external KMS AES-GCM key that you configure. +- `session-meta.json` is a JSON file that contains metadata about the session, including the session id, endpoint, +user, target, host, worker, and credentials used to access the target. The intention of this file is to provide all information +relevant to the recorded session so that the BSR provides a complete snapshot of a session even in the absence of the Boundary +control plane. +- `session-recording.meta` is a plaintext file that contains metadata about the session, including the session id, protocol, +and a connection ids. For each connection id listed, there should be a corresponding connection directory in the session directory. +- `session-recording-summary.json` is a JSON file that contains a summary of the session recording, including the session id, connection count, +start time, end time, and any errors encountered during recording of the session. + +`session-recording.meta` file example: + +``` +id: sr_iNCdGSREeX +protocol: BSSH +connection: cr_3bB78W53Y9.connection +``` + +`session-recording-summary.json` file example: + +``` +{ + "Id": "sr_iNCdGSREeX", + "ConnectionCount": 1, + "StartTime": "2023-09-19T15:05:39.343307163Z", + "EndTime": "2023-09-19T15:08:02.953159598Z", + "Errors": "" +} + +``` + +`session-meta.json` file example: + +``` +{ + "PublicId": "s_HQbVb8fJaM", + "Endpoint": "ssh://openssh-server:2222", + "User": { + "PublicId": "u_5Ry4oDiEVp", + "Scope": { + "PublicId": "global", + "Name": "global", + "Description": "Global Scope", + "Type": "global", + "ParentId": "", + "PrimaryAuthMethodId": "ampw_CdIa5KR9iw" + }, + "Name": "admin", + "Description": "Initial admin user within the \"global\" scope" + }, + "Target": { + "PublicId": "tssh_TIx4ENZMdA", + "Scope": { + "PublicId": "p_7Qe46uNMYX", + "Name": "session-recording-project", + "Description": "", + "Type": "project", + "ParentId": "o_yK7GoA6OG2", + "PrimaryAuthMethodId": "" + }, + "Name": "session-recording-target", + "Description": "", + "DefaultPort": 2222, + "DefaultClientPort": 0, + "SessionMaxSeconds": 28800, + "SessionConnectionLimit": -1, + "WorkerFilter": "", + "EgressWorkerFilter": "", + "IngressWorkerFilter": "\"pki\" in \"/tags/type\"", + "EnableSessionRecording": true, + "StorageBucketId": "sb_vqn871JdQf" + }, + "Worker": { + "PublicId": "w_ogOQt0rsuQ", + "Version": "0.13.0", + "Sha": "" + }, + "StaticHost": null, + "DynamicHost": null, + "StaticJSONCredentials": null, + "StaticUsernamePasswordCredentials": [ + { + "PublicId": "credup_gdzeB5UWJv", + "Name": "", + "Description": "", + "Username": "username", + "PasswordHmac": "PasswordHmac, + "Purposes": [ + "injected_application" + ], + "CredentialStore": { + "PublicId": "csst_agwIT97uZ7", + "ProjectId": "p_7Qe46uNMYX", + "Name": "ssh static store", + "Description": "SSH Static Cred store" + } + } + ], + "StaticSshPrivateKeyCredentials": null, + "VaultGenericLibraries": null, + "VaultSshCertificateLibraries": null +} +``` + +## BSR Connection folder + +A BSR connection folder contains the following files: + +- `SHA256SUM.sig` is a plaintext file that contains rows of file names paired with a checksum for file contents. +- `SHA256SUM.sig` is a signature of the plaintext `SHA256SUM` file created with the private key. +- `connection-recording.meta` is a plaintext file that contains metadata about the connection, including the connection id, +requests seen, channel ids, and any errors seen. For each channel id listed, there should be a corresponding channel directory in the connection directory. +- `connection-recording-summary.json` is a JSON file that contains a summary of the connection, including the connection id, +start time, end time, bytes up, bytes down, and any errors encountered during recording the connection. +- `requests-inbound.data` is a binary file containing all inbound SSH request messages transmitted for the connection. +- `requests-outbound.data` is a binary file containing all outbound SSH request messages transmitted for the connection. + +`connection-recording.meta` file example: + +``` +id: cr_W53Y93bB78 +requests: outbound +requests: inbound +channel: chr_uVVuUITnVn.channel +error: error message would be appear here +``` + +`connection-recording-summary.json` file example: + +``` +{ + "Id": "cr_W53Y93bB78", + "ChannelCount": 1, + "StartTime": "2023-07-13T20:21:49.164105381Z", + "EndTime": "2023-07-13T20:22:37.241911112Z", + "BytesUp": 125, + "BytesDown": 748, + "Errors": null +} +``` + +### BSR Channel folder + +A BSR connection folder contains the following files: + +- `SHA256SUM.sig` is a plaintext file that contains rows of file names paired with a checksum for file contents. +- `SHA256SUM.sig` is a signature of the plaintext `SHA256SUM` file created with the private key. +- `channel-recording.meta` is a plaintext file that contains metadata about the channel, including the channel id, +inbound and outbound requests seen, and inbound and outbound messages seen. +- `channel-recording-summary.json` is a JSON file that contains a summary of the channel, including the channel id, +start time, end time, bytes up, bytes down, channel type, session program, subsystem name (if applicable), exec program (if applicable), +and file transfer direction (if applicable). +- `requests-inbound.data` is a binary file containing all inbound SSH request messages transmitted for the channel. +- `requests-outbound.data` is a binary file containing all outbound SSH request messages transmitted for the channel. +- `messages-inbound.data` is a binary file containing all inbound SSH data transmitted for the channel. +- `messages-outbound.data` is a binary file containing all outbound SSH data transmitted for the channel. + +`channel-recording.meta` file example: + +``` +id: chr_uVVuUITnVn +channelType: session +messages: outbound +requests: outbound +messages: inbound +requests: inbound +``` + +`channel-recording-summary.json` file example: + +``` +{ + "ChannelSummary": { + "Id": "chr_uVVuUITnVn", + "ConnectionRecordingId": "cr_W53Y93bB78", + "StartTime": "2023-07-13T20:21:49.230916214Z", + "EndTime": "2023-07-13T20:22:37.229379944Z", + "BytesUp": 125, + "BytesDown": 748, + "ChannelType": "session" + }, + "SessionProgram": "shell", + "SubsystemName": "", + "ExecProgram": "", + "FileTransferDirection": "not applicable" +} +``` + +For more information, refer to the [overview of session recording](/boundary/docs/session-recording). diff --git a/website/content/docs/session-recording/data/read-bsr-file.mdx b/website/content/docs/session-recording/data/read-bsr-file.mdx new file mode 100644 index 000000000..6d7e7dfc6 --- /dev/null +++ b/website/content/docs/session-recording/data/read-bsr-file.mdx @@ -0,0 +1,31 @@ +--- +layout: docs +page_title: Read a BSR file +description: >- + Learn how to read the data in Boundary's proprietary BSR file that stores session recording data. +--- + +# Read a BSR file + +BSR data files are where all the data transmitted during a session is stored. BSR data files +have the file suffix `.data` and are binary files written in network byte or big-endian order. The first eight bytes of a +BSR data file always contains the following signature, which identifies the file as a BSR file: `"\x89BSR\r\n\x1a\n"`. + +Following the BSR signature, a BSR file contains “chunks” of data. Each chunk contains the same basic metadata information: +length, protocol, chunk type, direction, and a timestamp. The chunk type indicates the expected data payload. The first +chunk in a BSR file is the header chunk, and the last chunk in a BSR file is the EOF chunk. The remaining +chunks in the file depend on the protocol identified in the BSR header. + +The only protocol currently supported for session recording is SSH. Data files for SSH are prefixed with either `messages-` +or `requests-`, and suffixed with either `inbound` or `outbound` to indicate the direction the data came from. Message +files contain raw data from an SSH session and contain a header chunk, data chunks, and an EOF chunk. Request files +contain a header chunk, SSH request message chunks, and an EOF chunk. + +SSH request message chunks follow the SSH connection and channel request definitions. Boundary populates these chunks +using a protobuf definition provided here: [SSH Chunks](https://github.com/hashicorp/boundary/blob/main/internal/bsr/proto/ssh/v1/ssh_chunks.proto). + +Boundary session recording playback generates an asciinema from a session channel’s `messages-outbound.data` file. For more +information on finding and viewing BSR data using the asciinema, refer to [Find and view recorded sessions](/boundary/docs/session-recording/configuration/manage-recorded-sessions). + +While Boundary does not currently provide tooling to read other BSR .data files, the BSR definition is available in our +[community repository](https://github.com/hashicorp/boundary/tree/main/internal/bsr), and you can use it to develop external tooling. diff --git a/website/content/docs/session-recording/index.mdx b/website/content/docs/session-recording/index.mdx new file mode 100644 index 000000000..55d1eb070 --- /dev/null +++ b/website/content/docs/session-recording/index.mdx @@ -0,0 +1,164 @@ +--- +layout: docs +page_title: Session recording +description: >- + Discover resources to help you learn more about using session recording to audit user sessions and meet compliance standards for auditing. +--- + +# Session recording + +This feature requires HCP Boundary or Boundary Enterprise + +Boundary provides auditing capabilities using a feature called session recording. + +In Boundary, a session represents a set of connections between a user and a host from a target. +The session begins when an authorized user requests access to a target, and it ends when that access is terminated. +All sessions have a fixed time limit, and all connections are proxied through a worker. + +When you enable session recording on a target, a worker records any sessions that access the target. +No session data is routed through controllers during the recording stage. +The worker stores the recording on local disk during the recording phase, and then it moves the recording to an external object store when the session is terminated. + +Session recordings are stored in the BSR (Boundary Session Recording) format. +Any credentials needed to access the external object store are passed from the controller to the recording worker when the session is established. +Administrators can view the recordings to investigate security issues, review system activity, or perform regular assessments of security policies and procedures. + +You view session recordings with a session player that runs in a web browser. +The session player is an aggregation of web components that work together to present the different parts of a session recording as a logical whole. +A controller retrieves the contents of a recording from a worker with access to the external object store. +The controller decodes the contents of the recording into a format that is usable by the player. +The player then retrieves the data from the controller. + +In a multi-hop session, the worker that is configured to access the external object store is the worker that records the session. +If no worker can access the storage backend, the session is canceled and an error is returned. + +## Storage buckets + +This feature requires HCP Boundary or Boundary Enterprise + +A resource known as a [storage bucket](/boundary/docs/domain-model/storage-buckets) is used to store the recorded sessions. +The storage bucket represents a bucket in an external object store. +You can configure storage buckets on Amazon S3, MinIO, and some S3-compliant cloud vendors. + +Storing session recordings in a system external to Boundary means those recordings can be accessed, modified, deleted, and even restored independently of Boundary. +You can view any sessions that Boundary recorded in your storage provider or via the CLI. + +Before you can use a storage bucket to record sessions, you must configure a worker with local storage to act as a cache. +The entire recording is written to the local storage cache before it is uploaded. +Once the session is complete, the files are automatically synced with the external storage bucket and deleted from the worker's local storage. + +A storage bucket exists in either the Global scope or an Org scope. +A storage bucket that is associated with the Global scope can be associated with any target. +However, a storage bucket in an Org scope can only be associated with targets in a project from the same Org scope. +Any storage buckets associated with an Org scope are deleted when the Org itself is deleted. + +Deleting a storage bucket in Boundary does not delete the bucket in the external object store, nor does it delete the recorded sessions in the bucket. +The storage bucket's lifecycle does not affect the lifecycle of the bucket in the external object store. +Any session recording metadata that is attached to the storage bucket is deleted when the storage bucket is deleted. + +### Storage considerations + +The BSR captures all the data transmitted between a user and a target during a single session. As a result, the size of a BSR is dependent on user activity. At a minimum, a BSR for a session with one connection requires 8KB of space for its file for BSR keys, checksums, and metadata. + +Determining how much storage you need to allocate on workers and the external storage provider for recordings depends on user activity, but the following two examples are provided to help with storage estimates: + +- For one minute of simple shell activity, a BSR can be around 20KB in size. The storage requirements for 1,000 such sessions would be 20MB. + +- Sending 50MB of data results in a BSR around 50.1MB in size. The storage requirements for 1,000 such sessions would be 50.1 GB. + +When you estimate worker storage requirements, consider the number of concurrent sessions that will be recorded on that worker. Boundary writes the BSR to the worker's local storage while the session is active, and then moves it to the remote storage bucket when the session is closed. + +When you estimate storage requirements for the external storage provider, consider your [storage policy](/boundary/docs/domain-model/storage-policy) and how long a BSR will be retained in the external storage bucket. + + + +Boundary supports recorded session files up to 5 GB in size. +If a recorded session file is over 5 GB, the session details show the recording state as `Failed` and you may not be able to play back the session. +Be careful when you use Secure File Copy (SCP) to transfer large files during a recorded session because it can result in large recorded session files. + + + +## asciicast + +When you view recorded sessions using the CLI or Admin UI, Boundary can convert the recording into other formats for playback. +Currently Boundary supports converting the recording of an individual SSH channel into an [asciicast](https://github.com/asciinema/asciinema/blob/develop/doc/asciicast-v2.md) format to play back an interactive SSH session. + +### Limitations + +The asciicast format is well suited for the playback of interactive shell activity. +However, some aspects of the recording cannot be translated into asciicast. +For example, if an SSH session uses the `RemoteCommand` option, or is used to `exec` a command, the command is not displayed in the asciicast. +The output of the command may be displayed, though. + +If you use SSH for something other than an interactive shell, such as for file transfer, X11 forwarding, or port forwarding, Boundary does not attempt to create an asciicast. +In all cases, the SSH session is still recorded in the BSR file and you can view the BSR file in the external storage bucket. + +### Security + +When a worker converts an SSH recording into the BSR file, it iterates through each of the requests in the recording and displays some of them to the user. +If you use an environment request to set the shell variable, the request is included in the asciicast header. +You should be aware of the following security concerns that could result from this behavior: + +- asciicast only includes the last value that you send in the header, any previous values are overwritten. +An attacker may be able to use a malicious shell value at the beginning of a session, and then switch to `shell=/bin/bash` at the end of the session to conceal the malicious activity. + +- asciicast does not display other variables such as `path` in the header, but they can cause drastic changes to code execution during the SSH session. +An attacker could change the `path` variable to point to a malicious program or change the beahvior of a normal program so that it performs a malicious action. + +- asciicast silently ignores any requests that do not have an explicit handler, even though they may cause signficant changes to code execution during the SSH session. +An attacker could execute malicious code using a request without an explicit handler. + +## Session recording audit events + +Boundary emits audit events for actions performed by users. Here are **some** of the possible event field types that are emitted: + +- `timestamp` - The timestamp of the event +- `auth` - Authentication information about the user who performed the action. +- `response.details.item.connection_recordings.` + - `id` - Session recording ID. + - `channel_recordings.id` - Session recording channel ID. + - `start_time.seconds` - Start time of session recording. + - `end_time.seconds` - End time of session recording. + - `bytes_up` - Upload bytes during session. + - `bytes_down` - Download bytes during session. + - `channel_recordings.duration.seconds`- Length of time a session took, recorded in seconds. +- `request_info.client_ip` - The client IP address used by the user. +- `response.details.item.create_time_values.` + - `target.name` - The name of the targets. + - `target.id` - The ID of the target accessed during the recording. + - `target.type` - The type of protocol used. + - `target.scope.name` - Name of the scope the target accessed belongs to. + - `target.scope.parent_scope_id` - Parent ID of the scope the target accessed belongs to. +- `response.details.item.Attrs.SshTargetAttributes.` + - `storage_bucket_id.value` - Storage bucket ID attached to a target that is used for storing session recordings. + - `enable_session_recording.value` - Determines if session recording is enabled on a target. + +## Next steps + +To enable session recording, you must: + +1. [Configure workers for local storage](/boundary/docs/session-recording/configuration/configure-worker-storage) +1. Configure an external storage provider: + - [Amazon S3](/boundary/docs/session-recording/configuration/storage-providers/configure-s3) + - [MinIO](/boundary/docs/session-recording/configuration/storage-providers/configure-minio) + - [S3-compliant](/boundary/docs/session-recording/configuration/storage-providers/configure-s3-compliant) +1. [Create a storage bucket](/boundary/docs/session-recording/configuration/create-storage-bucket) +1. [Enable session recording on a target](/boundary/docs/session-recording/configuration/enable-session-recording) + +Once you enable session recording, you can [Find and view recorded sessions](/boundary/docs/session-recording/configuration/manage-recorded-sessions). + +### Implement session recording compliance standards + +After enabling session recording, you can configure retention policies for recorded sessions or validate the recorded data: + +- [Configure storage policies](/boundary/docs/session-recording/compliance/configure-storage-policy) +- [Update storage policies](/boundary/docs/session-recording/compliance/update-storage-policy) +- [Validate recorded sessions](/boundary/docs/session-recording/compliance/validate-session-recordings) +- [Validate external data store](/boundary/docs/session-recording/compliance/validate-data-store) + +### Work with BSR data files + +For more information about working with BSR files, refer to the following topics: + +- [BSR file data structure](/boundary/docs/session-recording/data/bsr-file-structure) +- [Read a BSR file](/boundary/docs/session-recording/data/read-bsr-file) diff --git a/website/content/docs/targets/configuration/configure-transparent-sessions.mdx b/website/content/docs/targets/configuration/configure-transparent-sessions.mdx new file mode 100644 index 000000000..b523b223c --- /dev/null +++ b/website/content/docs/targets/configuration/configure-transparent-sessions.mdx @@ -0,0 +1,79 @@ +--- +layout: docs +page_title: Configure transparent sessions +description: >- + Learn how to configure transparent sessions to enhance end-user workflows and simplify target access. +--- + +# Configure transparent sessions + +@include 'alerts/enterprise-only.mdx' + +Transparent sessions shift Boundary from an active connection model to a passive connection model. Boundary operates in the background instead of requiring you to remember specific resource IDs or ephemeral ports to connect to targets. + +As long as Boundary authenticates a user and the user is authorized to access the target, Boundary intercepts the DNS call and routes traffic through a session automatically. + +Transparent sessions require [aliases](/boundary/docs/targets/configuration) and the [Boundary Client Agent](/boundary/docs/client-agent). + +The Boundary Desktop client facilitates quick target discovery and session establishment using your preferred client. If you configure aliases for your targets, install the Boundary Client Agent, and ensure you are authenticated to the cluster, connections are transparent to the user. Boundary provides OS notifications to make it clear when you connect to a target using a transparent session. + +Boundary supports Windows and MacOS for transparent sessions. + +## Requirements + +Before you configure transparent sessions, you must: + +- Ensure that any previous versions of the Boundary Desktop or CLI client in your local environment are fully uninstalled before you install the Boundary clients using the latest Boundary installer. +- Download the appropriate Boundary installer for your Windows or MacOS environment from the [Install Boundary](/boundary/install#installer) page or the [releases](https://releases.hashicorp.com/boundary-installer) page. +- Install the Boundary Client Agent, CLI, and Desktop client. + - Refer to [Install the Boundary clients](/boundary/docs/deploy/self-managed/install-clients) for instructions. + - Refer to the [transparent sessions interoperability matrix](/boundary/docs/interoperability-matrix) for a list of third-party products that have been tested for use with the Boundary installer and Client Agent. +- Ensure that both IPv4 and IPv6 protocols are enabled for your environment. The [Client Agent](/boundary/docs/client-agent) requires both protocols to start and perform DNS lookups. + +You should also make sure you have the appropriate grants configured so that you can resolve aliases and establish transparent sessions. +For more information, refer to the [Grants](/boundary/docs/client-agent#grants) section in the Client Agent documentation. + + + +A known issue regarding how grants were previously created in HCP Boundary may cause you to receive a 500 error when you attempt to list resolvable aliases. +Clusters created before April 26, 2025 may be missing the following grants: + +`ids={{.User.Id}};type=user;actions=list-resolvable-aliases` + +`ids=*;type=target;actions=list,read` + +If your cluster is missing these grants, HashiCorp recommends adding them. + +For more information, refer to the [known issue](/boundary/docs/release-notes/v0_19_0#hcp-grants). + + + +## Configure targets + +The following section details how to configure targets to use transparent sessions. + + + +If you use a cluster that was created earlier than release 0.16.0, you must add the grant `list-resolvable-aliases` so that the client agent can populate the local alias cache. + +As an example, you could add the grant: + +`type=user;actions=list-resolvable-aliases;ids=*`. + +For more information, refer to the [Grants](/boundary/docs/client-agent#grants) section in the Client Agent documentation. + + + +Complete the following steps to configure targets: + +1. Authenticate to Boundary using the CLI or Desktop client. +1. [Create a new target with an alias](/boundary/docs/targets/configuration/create-target-alias#create-an-alias-during-target-creation) or [create an alias for an existing target](/boundary/docs/targets/configuration/create-target-alias#create-an-alias-for-an-existing-target). +Ensure that you have authorization to establish a session to the target. + +## Next steps + +Open the client of your choice and [connect to your target using the alias](/boundary/docs/targets/connections/transparent-sessions). + +## More information + +Refer to [Troubleshoot issues with the Client Agent](/boundary/docs/client-agent/troubleshoot) for a list of [known issues](/boundary/docs/client-agent/troubleshoot#transparent-sessions-known-issues) involving transparent sessions. diff --git a/website/content/docs/configuration/target-aliases/create-target-alias.mdx b/website/content/docs/targets/configuration/create-target-alias.mdx similarity index 96% rename from website/content/docs/configuration/target-aliases/create-target-alias.mdx rename to website/content/docs/targets/configuration/create-target-alias.mdx index 3187ff688..7793ec786 100644 --- a/website/content/docs/configuration/target-aliases/create-target-alias.mdx +++ b/website/content/docs/targets/configuration/create-target-alias.mdx @@ -9,7 +9,7 @@ description: >- An alias is a globally unique, DNS-like string that is associated with a destination resource. You can establish a session to a target by referencing its alias, instead of having to provide a target ID or target name and scope ID. -For more information about aliases, including naming conventions and best practices, refer to [Aliases](/boundary/docs/concepts/aliases). +For more information about aliases, including naming conventions and best practices, refer to [Overview of aliases](/boundary/docs/targets/configuration). You can create aliases and associate them with targets using the following methods: @@ -63,7 +63,7 @@ Complete the following steps to create a new alias and associate it with a targe -authorize-session-host-id hst_1234567890 ``` - You can use any of the following [attributes](/boundary/docs/concepts/domain-model/aliases) when you create an alias: + You can use any of the following [attributes](/boundary/docs/domain-model/aliases) when you create an alias: - `-description=` - Specifies the optional description you want to use for identification purposes. - `-destination-id=` - Specifies the ID of the target that the alias references. @@ -141,7 +141,7 @@ Complete the following steps to create a new target and new alias at the same ti -with-alias-value example.alias.boundary ``` - You can use any of the following [attributes](/boundary/docs/concepts/domain-model/targets) when you create a target: + You can use any of the following [attributes](/boundary/docs/domain-model/targets) when you create a target: - `description` - (optional) An optional description that you can use for identification purposes. @@ -171,7 +171,7 @@ A value of `-1` means the connections are unlimited. - `-with-alias-value=` - The value of the alias that you want to use to represent the target. Use this parameter to create the alias and target, and associate them with each other, at the same time. - Note that you can create SSH or TCP [target types](/boundary/docs/concepts/domain-model/targets#target-types). + Note that you can create SSH or TCP [target types](/boundary/docs/domain-model/targets#target-types). The example command in this section creates an SSH target. @@ -274,7 +274,7 @@ If you [created an alias](#create-an-alias-for-an-existing-target) without assoc -authorize-session-host-id hst_1234567890 ``` - You can use any of the following [attributes](/boundary/docs/concepts/domain-model/aliases) when you update an alias: + You can use any of the following [attributes](/boundary/docs/domain-model/aliases) when you update an alias: - `-description=` - Specifies the optional description you want to use for identification purposes. - `-destination-id=` - Specifies the ID of the target that the alias references. @@ -310,9 +310,9 @@ resource "boundary_alias_target" "example_alias_target" { Target aliases point directly to the target they are associated with. You can assign targets a host set or a direct target address. -[Host sets](/boundary/docs/concepts/domain-model/host-sets) are sets of functionally equivalent hosts, and are commonly used for deployments at scale. When Boundary authorizes a session, a target assigned a host set will select a host from the host set at random to use for all connections for the session. +[Host sets](/boundary/docs/domain-model/host-sets) are sets of functionally equivalent hosts, and are commonly used for deployments at scale. When Boundary authorizes a session, a target assigned a host set will select a host from the host set at random to use for all connections for the session. -You assign [direct target addresses](/boundary/docs/concepts/domain-model/targets#address) directly to the target. They refer to a specific network resource, like an IP address. Boundary only connects to the direct target address when it establishes a connection to the associated target. +You assign [direct target addresses](/boundary/docs/domain-model/targets#address) directly to the target. They refer to a specific network resource, like an IP address. Boundary only connects to the direct target address when it establishes a connection to the associated target. When you create a target alias, you can also assign it to a specific host. Assigning an alias to a specific host is useful if you want to avoid creating multiple targets for specific hosts using direct target addresses. diff --git a/website/content/docs/targets/configuration/index.mdx b/website/content/docs/targets/configuration/index.mdx new file mode 100644 index 000000000..69b00dbc2 --- /dev/null +++ b/website/content/docs/targets/configuration/index.mdx @@ -0,0 +1,83 @@ +--- +layout: docs +page_title: Overview +description: >- + Learn how to configure aliases and transparent sessions to enhance end-user workflows and simplify target access. +--- + +# Overview of aliases + +Target aliases simplify the connection workflow for end users by allowing them to reference targets using a globally unique DNS-like string. + +Without aliases, connecting to an end target requires you to reference the target ID, or a combination of target name and scope: + +```shell-session +$ boundary connect ssh -target-id ttcp_1234567890 +``` + +```shell-session +$ boundary connect ssh -target-name sql-database -target-scope-name -staging +``` + +With target aliases, a single globally referenced value is assigned to a target, simplifying connection workflows and enabling transparent sessions for Enterprise and HCP end users. + +```shell-session +$ boundary connect ssh sql-database-staging +``` + +## Permissions + +The existence of an alias for a Boundary resource does not change how permissions function. Anyone can attempt to use an alias to access a target, but if you do not have permission to access the target, the attempt fails. You can create an alias for a target, even if you do not have permission to access the target. + +Separating the permissions from aliases and destination resources means a different set of people can manage the aliases than the people who have permission to operate on targets. For example, you may have a project with a sensitive set of targets. You can configure Boundary to allow a select few users to manage those targets, while a different group of users manage the aliases. + +## Naming conventions + +An alias is a globally unique, DNS-like string that is associated with a destination resource. The alias `value` parameter does not have to be delimited by a suffix, and can be just a hostname. + +Examples of valid aliases include `database.boundary` and `webserver.boundary`. + +### Single word aliases and transparent sessions + +HashiCorp recommends that you do not use single-word aliases such as `webserver` as opposed to `webserver.boundary`, because single-word aliases do not work intuitively on Windows. + +Windows DNS resolution does not support resolving unqualified single word DNS hostnames. You can make the hostname fully qualified, but is not intuitive to most users. + +For example the following hostname works: + +``` +ssh mytarget. +``` + +But this hostname does not work: + +``` +ssh mytarget +``` + +For this reason, if you expect any Windows users to use an alias, it should contain a dot (`.`) anywhere in the value. + +Refer to the [transparent sessions](/boundary/docs/concepts/transparent-sessions) documentation for more information. + +### HTTPS websites + +If you create an alias for a website that uses HTTPS, the alias must match the website's hostname. +You may receive connection errors if the alias does not match the website's hostname exactly. + +For example, if you want to create an alias to connect to https://www.hashicorp.com, you must name the alias `www.hashicorp.com`. + +## Scopes + +You can only create aliases in the `global` scope. However, you can associate aliases with targets or hosts from any scope. Support for additional resource types may be added in the future. + +If you delete a project, Boundary clears the `destination_id` parameter for any aliases that resolve to targets in that project, so that they no longer function. + +Refer to the [Create target aliases](/boundary/docs/targets/configuration/create-target-alias) pages to learn more. + +## Next steps + +To use target aliases to connect to targets: + +1. [Create a target alias](/boundary/docs/targets/configuration/create-target-alias) +1. [Connect to a target using an alias](/boundary/docs/targets/connections/connect-target-alias) +1. After you set up a target alias, you can optionally [Configure transparent sessions for end users](/boundary/docs/targets/configuration/configure-transparent-sessions). HCP/ENT \ No newline at end of file diff --git a/website/content/docs/concepts/connection-workflows/connect-helpers.mdx b/website/content/docs/targets/connections/connect-helpers.mdx similarity index 100% rename from website/content/docs/concepts/connection-workflows/connect-helpers.mdx rename to website/content/docs/targets/connections/connect-helpers.mdx diff --git a/website/content/docs/configuration/target-aliases/connect-target-alias.mdx b/website/content/docs/targets/connections/connect-target-alias.mdx similarity index 73% rename from website/content/docs/configuration/target-aliases/connect-target-alias.mdx rename to website/content/docs/targets/connections/connect-target-alias.mdx index de3227e63..7e86e20d9 100644 --- a/website/content/docs/configuration/target-aliases/connect-target-alias.mdx +++ b/website/content/docs/targets/connections/connect-target-alias.mdx @@ -5,12 +5,12 @@ description: >- Learn how to connect to a target configured with an alias. --- -After you [Create a target alias](/boundary/docs/configuration/target-aliases/create-target-alias), you can refer to the alias when you establish sessions. - -With aliases, you don't have to specify the target ID, target name, or scope when you connect with Boundary. Target aliases are also required to use [transparent sessions](/boundary/docs/configuration/target-aliases/transparent-sessions). - # Connect to a target using an alias +After you [Create a target alias](/boundary/docs/targets/configuration/create-target-alias), you can refer to the alias when you establish sessions. + +With aliases, you don't have to specify the target ID, target name, or scope when you connect with Boundary. Target aliases are also required to use [transparent sessions](/boundary/docs/concepts/transparent-sessions). + You can substitute an alias whenever you could use the `-id` flag or `-target` flag in the CLI. For example, you can use the following command to connect to an SSH target with the ID `ttcp_1234567890`: @@ -27,4 +27,4 @@ $ boundary connect ssh example.alias.boundary Aliases are globally unique, so you don't need to specify the scope to connect to the target. -After you verify that you can connect to the target using an alias, you can try to connect to the target using [transparent sessions](/boundary/docs/configuration/target-aliases/transparent-sessions). HCP/ENT \ No newline at end of file +After you verify that you can connect to the target using an alias, you can try to connect to the target using [transparent sessions](/boundary/docs/targets/configuration/configure-transparent-sessions). HCP/ENT \ No newline at end of file diff --git a/website/content/docs/concepts/connection-workflows/exec-flag.mdx b/website/content/docs/targets/connections/exec-flag.mdx similarity index 100% rename from website/content/docs/concepts/connection-workflows/exec-flag.mdx rename to website/content/docs/targets/connections/exec-flag.mdx diff --git a/website/content/docs/concepts/connection-workflows/index.mdx b/website/content/docs/targets/connections/index.mdx similarity index 87% rename from website/content/docs/concepts/connection-workflows/index.mdx rename to website/content/docs/targets/connections/index.mdx index e3adf7f9d..eba3bc657 100644 --- a/website/content/docs/concepts/connection-workflows/index.mdx +++ b/website/content/docs/targets/connections/index.mdx @@ -15,7 +15,7 @@ When you run the `boundary connect` command against a target, Boundary establish The `boundary connect` command has a number of useful options, such as `-listen-port` which lets you choose the port on which the command listens for an incoming connection. Refer to the [`boundary connect`](/boundary/docs/commands/connect) documentation for a list of the available options and usage examples. -To practice using the `boundary connect` command in a development environment, refer to the **Connect to your first target** tutorial for either [HCP Boundary](/boundary/tutorials/hcp-getting-started/hcp-getting-started-connect) or the [self-managed versions](/boundary/tutorials/oss-getting-started/oss-getting-started-connect) of Boundary. +To practice using the `boundary connect` command in a development environment, refer to the **Connect to your first target** tutorial for either [HCP Boundary](/boundary/tutorials/hcp-getting-started/hcp-getting-started-connect) or the [self-managed versions](/boundary/tutorials/get-started-community/community-get-started-connect) of Boundary. ## Transparent sessions @@ -39,7 +39,7 @@ They are supported for the following connection types: - RDP - SSH -Refer to the [Connect helpers](/boundary/docs/concepts/connection-workflows/connect-helpers) documentation for more information. +Refer to the [Connect helpers](/boundary/docs/targets/connections/connect-helpers) documentation for more information. ## Exec flag @@ -47,7 +47,7 @@ In addition to the built-in connect helpers, `boundary connect` can accommodate The `-exec` flag lets you wrap Boundary TCP sessions in your preferred client. You can use this flag to create an authenticated proxy to almost anything. -Refer to the [Exec flag](/boundary/docs/concepts/connection-workflows/exec-flag) documentation for more information. +Refer to the [Exec flag](/boundary/docs/targets/connections/exec-flag) documentation for more information. ## SSH ProxyCommand @@ -58,7 +58,7 @@ Using `ProxyCommand` to execute a proxy when invoking the SSH client is a common SSH `ProxyCommand` lets you proxy an SSH connection to a target according to a configuration file that you create. You can configure the file to connect to the target ID or the target domain. -Refer to the [SSH ProxyCommand](/boundary/docs/concepts/connection-workflows/workflow-ssh-proxycommand) documentation for more information. +Refer to the [SSH ProxyCommand](/boundary/docs/targets/connections/workflow-ssh-proxycommand) documentation for more information. ## Multi-hop sessions @@ -75,4 +75,4 @@ A worker in a private network can send outbound communication to its upstream wo You can configure target worker filters with multi-hop workers to allow for fine-grained control on which workers handle ingress and egress for session 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. -Refer to the [Multi-hop sessions](/boundary/docs/concepts/connection-workflows/multi-hop) documentation for more information. \ No newline at end of file +Refer to the [Multi-hop sessions](/boundary/docs/workers/multi-hop) documentation for more information. \ No newline at end of file diff --git a/website/content/docs/targets/connections/transparent-sessions.mdx b/website/content/docs/targets/connections/transparent-sessions.mdx new file mode 100644 index 000000000..f6ee9a9ac --- /dev/null +++ b/website/content/docs/targets/connections/transparent-sessions.mdx @@ -0,0 +1,62 @@ +--- +layout: docs +page_title: Connect using transparent sessions +description: >- + Learn how to use transparent sessions to enhance end-user workflows and simplify target access. +--- + +# Connect using transparent sessions + +@include 'alerts/enterprise-only.mdx' + +Transparent sessions shift Boundary from an active connection model to a passive connection model. Boundary operates in the background instead of requiring you to remember specific resource IDs or ephemeral ports to connect to targets. + +Transparent sessions require [aliases](/boundary/docs/targets/configuration) and the [Boundary Client Agent](/boundary/docs/client-agent). + +Boundary routes your session using the Boundary Client Agent. +You can validate that Boundary routed the session by looking at the **Sessions** page in the Desktop client, by typing `boundary sessions list -recursive` in the CLI, or by looking at sessions managed by the Client Agent using `boundary client-agent sessions`. + +## Requirements + +Before you begin, ensure that you have [configured transparent sessions](/boundary/docs/targets/configuration/configure-transparent-sessions) and [created aliases](/boundary/docs/targets/configuration/create-target-alias) for any targets you want to connect to. + +The Client Agent periodically requests an updated list of aliases from the controller, so the alias may not work immediately after you create it. +The alias should be updated in the Client Agent within 2 minutes. If you still see connection issues after 2 minutes, follow the troubleshooting steps in [the Client Agent troubleshooting guide](/boundary/docs/client-agent/troubleshoot). + +## Establish a transparent session + +Without transparent sessions, you must use the [Boundary connect helpers](/boundary/docs/targets/connections/connect-helpers) to establish a session: + +```shell-session +$ boundary connect ssh -target-name sql-database -target-scope-name -staging +``` + +Alternatively, you can use the Boundary Desktop Client to start a session, and connect on a local port supplied by Boundary: + +```shell-session +$ ssh 127.0.0.1 -p 55374 +``` + +With transparent sessions, you use the target alias as the address to establish a session. If the Client Agent is runningand you have authenticated using the CLI or Boundary Desktop Client, you can use the alias to start a session: + +```shell-session +$ ssh my.alias.name +``` + +Boundary starts the session as usual, and brokers or injects any credentials you have configured. + +## Next steps + +When you have validated that transparent sessions work, you can create and establish transparent sessions to other services. + +To establish transparent sessions to other services: + +1. Make a list of the services you use. +1. Create workers as needed for network partitions. +1. Add the services to Boundary as targets. +1. [Create aliases for the targets](/boundary/docs/targets/configuration/create-target-alias). +1. Connect to the target using your client of choice. + +## More information + +Refer to [Troubleshoot issues with the Client Agent](/boundary/docs/client-agent/troubleshoot) for a list of [known issues](/boundary/docs/client-agent/troubleshoot#transparent-sessions-known-issues) involving transparent sessions. diff --git a/website/content/docs/concepts/connection-workflows/workflow-ssh-proxycommand.mdx b/website/content/docs/targets/connections/workflow-ssh-proxycommand.mdx similarity index 100% rename from website/content/docs/concepts/connection-workflows/workflow-ssh-proxycommand.mdx rename to website/content/docs/targets/connections/workflow-ssh-proxycommand.mdx diff --git a/website/content/docs/integrations/vault/index.mdx b/website/content/docs/vault/index.mdx similarity index 81% rename from website/content/docs/integrations/vault/index.mdx rename to website/content/docs/vault/index.mdx index 4a296e000..22eff5a43 100644 --- a/website/content/docs/integrations/vault/index.mdx +++ b/website/content/docs/vault/index.mdx @@ -12,7 +12,7 @@ The integration between Boundary and Vault improves two main areas of concern fo - Security posture for remote access - Workflow efficiency -Integrating Boundary and Vault achieves these goals by enabling end-users to access targets without needing to manually distribute credentials. +Integrating Boundary and Vault achieves these goals by enabling end-users to access targets without needing to manually distribute credentials. You must bring your own Vault deployment to Boundary. From a security perspective, you can configure credentials to be dynamic and ephemeral, and only valid for the lifetime of the session. Or you can attach a specific time to live (TTL) to the Vault token, resulting in a session having a finite amount of time. @@ -22,13 +22,12 @@ Timely access to resources creates improvements in workflow efficiency by removi ## Credential management -To configure credential brokering or credential injection with static credentials on Vault, please see [Manage static credentials with Vault](/boundary/docs/configuration/credential-management/static-cred-vault). +To configure credential brokering or credential injection with static credentials on Vault, please see [Manage static credentials with Vault](/boundary/docs/credentials/static-cred-vault). # Credentials -Vault can work with Boundary to be a credential [store](https://developer.hashicorp.com/boundary/docs/concepts/domain-model/credential-stores) and [library](https://developer.hashicorp.com/boundary/docs/concepts/domain-model/credential-libraries), which allows for credentials to be stored in Vault and used by Boundary. There are two configuration options: -Within Boundary, you can configure Vault as a [credential store](/boundary/docs/concepts/domain-model/credential-stores) and [credential library](/boundary/docs/concepts/domain-model/credential-libraries). +Within Boundary, you can configure Vault as a [credential store](/boundary/docs/domain-model/credential-stores) and [credential library](/boundary/docs/domain-model/credential-libraries). There are two configuration options: @@ -41,12 +40,6 @@ SSH certificates have the advantages of using Vault as the certificate authority You can inject both generic secrets and SSH certificates directly into Boundary sessions using an HCP Boundary or Boundary Enterprise deployment. - - - You must bring your own Vault deployment to Boundary. - - - ### Brokered credentials Brokered credentials let you use Boundary as a credential broker for infrastructure targets by binding credentials with user sessions. Credentials are surfaced during session initialization, after being brokered from Vault. @@ -68,7 +61,7 @@ You can inject credentials directly into sessions using HCP Boundary or Boundary Credential injection with Vault can be configured using static or dynamic credentials: - [KV secrets engine](/vault/docs/secrets/kv/kv-v2) (static credentials) -- [SSH secrects engine](/vault/docs/secrets/ssh) (dynamic credentials) +- [SSH secrets engine](/vault/docs/secrets/ssh) (dynamic credentials) You can use the KV secrets engine for static username/password secrets, or static keypair secrets. @@ -86,14 +79,16 @@ When you connect to a target that uses Vault for dynamic SSH certificates, a new Within Boundary you can configure one or more credential stores. There are two types of credential stores: -- [Static credential store](/boundary/docs/concepts/domain-model/credential-stores#static-credential-store) -- [Vault credential store](/boundary/docs/concepts/domain-model/credential-stores#vault-policies) +- [Static credential store](/boundary/docs/domain-model/credential-stores#static-credential-store) +- [Vault credential store](/boundary/docs/domain-model/credential-stores#vault-policies) A static credential store is built into Boundary if you want to manage secrets without integrating it with Vault. The Vault credential store can fetch secrets from Vault on behalf of Boundary users. -Organizations may have valid reasons for using multiple credential stores within Boundary. You can only create credential stores at the [project](/boundary/docs/concepts/domain-model/scopes#projects) scope, and each project can contain multiple credential stores. Projects within an org scope may have different requirements from their credential stores. For example, within an org scope you may have two projects: Database and Compute. These two projects may need to be isolated, and can have a dedicated credential store per project. +Organizations may have valid reasons for using multiple credential stores within Boundary. You can only create credential stores at the [project](/boundary/docs/domain-model/scopes#projects) scope, and each project can contain multiple credential stores. Projects within an org scope may have different requirements from their credential stores. For example, within an org scope you may have two projects: Database and Compute. These two projects may need to be isolated, and can have a dedicated credential store per project. -When integrated with Vault, Boundary has to be assigned a periodic, renewable, [orphan token](/boundary/docs/concepts/domain-model/credential-stores#vault-token-requirements) from Vault. Each credential needs a separate Vault token. +Credential stores may contain multiple credential libraries. This means a single Vault token can provide access to all the Vault paths defined in the credential libraries. HashiCorp recommends that you operate using the model of least privilege when setting up credential stores. + +When integrated with Vault, Boundary has to be assigned a periodic, renewable, [orphan token](/boundary/docs/domain-model/credential-stores#vault-token-requirements) from Vault. Each credential needs a separate Vault token. The following have no impact on Vault's [client count](/vault/docs/concepts/client-count/counting): @@ -102,14 +97,12 @@ The following have no impact on Vault's [client count](/vault/docs/concepts/clie - The number of sessions that get created - The number of credential libraries the credential store contains - - -Credential stores may contain multiple credential libraries. This means a single Vault token can provide access to all the Vault paths defined in the credential libraries. HashiCorp recommends that you operate using the model of least privilege when setting up credential stores. - - - ## Vault as an identity provider Boundary supports OIDC, LDAP, and username/password as [authentication methods](/boundary/docs/concepts/iam#access-management). Boundary can use Vault as an [OIDC bridge provider](/vault/tutorials/auth-methods/oidc-identity-provider). This allows Vault to delegate authentication to an external OIDC provider, such as Google Cloud, Okta, or Microsoft Entra ID. -These providers then map the authenticated user's claims to Vault policies and identities. This allows users to authenticate to Boundary with any of Vault's supported authentication methods, even ones that Boundary does not natively support. When Boundary uses Vault as an OIDC provider, each user leveraging the authentication method then counts as a Vault client. \ No newline at end of file +These providers then map the authenticated user's claims to Vault policies and identities. This allows users to authenticate to Boundary with any of Vault's supported authentication methods, even ones that Boundary does not natively support. When Boundary uses Vault as an OIDC provider, each user leveraging the authentication method then counts as a Vault client. + +## More information + +Refer to [Create a Vault credential store](/boundary/docs/credentials/static-cred-vault) for more information. \ No newline at end of file diff --git a/website/content/docs/overview/what-is-boundary.mdx b/website/content/docs/what-is-boundary.mdx similarity index 97% rename from website/content/docs/overview/what-is-boundary.mdx rename to website/content/docs/what-is-boundary.mdx index d5ae97c25..92b510aa7 100644 --- a/website/content/docs/overview/what-is-boundary.mdx +++ b/website/content/docs/what-is-boundary.mdx @@ -17,8 +17,6 @@ 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). - ## How does Boundary work? Boundary provides secure access to hosts and critical systems without distributing and managing credentials, configuring firewalls, or exposing the organization's private network. Traditionally, for users to access their resources, it's required that organizations establish and maintain SSH bastion hosts and VPNs. @@ -51,7 +49,7 @@ The core Boundary workflow consists of four stages: If you're not sure which edition is right for you, we recommend [**HCP Boundary**](https://developer.hashicorp.com/boundary/tutorials/hcp-getting-started) because it eliminates deployment operations. -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). +Regardless of which server edition of Boundary you use, all editions require the same Desktop and CLI clients, which you can download from the [Install Boundary downloads](https://developer.hashicorp.com/boundary/downloads) page. | Feature| Community | HCP | HCP | Enterprise | |---|:-:|:-:|:-:|:-:| diff --git a/website/content/docs/workers/create.mdx b/website/content/docs/workers/create.mdx new file mode 100644 index 000000000..164a8833b --- /dev/null +++ b/website/content/docs/workers/create.mdx @@ -0,0 +1,10 @@ +--- +layout: docs +page_title: Create the worker configuration +description: >- + Learn about configuring workers. View an example of a worker configuration. +--- + +# Create the worker configuration + +@include '/workers/single-worker-config.mdx' \ No newline at end of file diff --git a/website/content/docs/workers/filters.mdx b/website/content/docs/workers/filters.mdx new file mode 100644 index 000000000..e87fcbecc --- /dev/null +++ b/website/content/docs/workers/filters.mdx @@ -0,0 +1,167 @@ +--- +layout: docs +page_title: Configure a worker filter +description: >- + Learn about configuring a filter to control which workers are allowed to manage a session. +--- + +# Configure a worker filter + +You can use tags to configure a worker filter that controls which workers are allowed to perform specific functions. +Following are some examples of using these values in filters that can be applied to targets, Vault credential stores, or storage buckets: + +- Name regex: `"/name" matches "web-prod-us-east-[12]"`, which would + match workers whose names are `web-prod-us-east-1` or `web-prod-us-east-2` + +- Region: `"us-east-1" in "/tags/region"`. + +- Grouping: `("us-east-1" in "/tags/region" and "/name" == "web-prod-us-east-1") or "webservers" in "/tags/type"` + +Each tag can have multiple values, so you must use the `in` operator to match values. If you know that you have only one value, an equivalent would be `"/tags/key/0" == "value"`. + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. + +## Example worker filter for targets + +Once workers have tags, you can use these tags to control which +workers are allowed to manage a given session by specifying worker filter attributes +when you configure [targets](/boundary/docs/domain-model/targets). + +The `egress_worker_filter` attribute controls which workers are used for egress to a target. This is the worker +that accesses the target. + +The `ingress_worker_filter`HCP/ENT attribute controls which workers are used for ingress to a target. +This is the worker a client connects to when initiating a connection to a target. + + + + +Example of a filter configured on a target in the Admin UI: + +![Example of a target ingress worker filter](/img/ui/target-ingress-worker-filter_light.png#light-theme-only) +![Example of a target ingress worker filter](/img/ui/target-ingress-worker-filter_dark.png#dark-theme-only) + + + + +Example of a filter configured on a target with the CLI: + +``` +$ boundary targets update tcp -id tssh_1234567890 -egress-worker-filter='"prod" in "/tags/type"' +``` + + + + +Example of a filter configured on a target with Terraform: + +```hcl +resource "boundary_target" "aws-webservers-prod" { + type = "ssh" + name = "aws-web-prod" + description = "AWS EC2 Targets" + egress_worker_filter = "\"prod\" in \"/tags/type\"" +} +``` + + + + +## Example worker filter for Vault credential store + +Tags are used to control which workers can manage Vault requests by specifying +a `worker_filter`attribute when configuring [credential stores](/boundary/docs/domain-model/credential-stores#vault-credential-store-attributes). + +This allows the use of private Vault instances with Boundary. Workers +deployed in the same network as a private Vault instance can access and relay +Vault requests to Boundary controllers. + + + + A worker that matches the worker filter must exist before you define the Vault credential store, as it will perform the Vault calls needed to set up the credential store with Boundary. + + + + + + +Example of a worker filter configured on a Vault credential store in the Admin UI: + +![Example of a credential store worker filter](/img/ui/vault-worker-filter_light.png#light-theme-only) +![Example of a credential store worker filter](/img/ui/vault-worker-filter_dark.png#dark-theme-only) + + + + +Example of a worker filter configured on a Vault credential store with the CLI: + +``` +$ boundary credential-stores update vault -id csvlt_1234567890 -worker-filter='"vault" in "/tags/type"' +``` + + + + +Example of a worker filter configured on a Vault credential store with Terraform: + +```hcl +resource "boundary_credential_store_vault" "vault_cred_store" { + name = "Vault host credentials" + address = "http://127.0.0.1:8200" # change to Vault address + token = "s.0ufRo6XEGU2jOqnIr7OlFYP5" # change to valid Vault token + scope_id = boundary_scope.project.id # change to target scope + worker_filter = "\"vault\" in \"/tags/type\"" # change to access private Vault cluster +} +``` + + + + +## Example worker filter for storage buckets + +Storage buckets are used for session recording, which requires HCP Boundary or Boundary Enterprise + +Session recording functions are performed by Boundary workers. Workers also store recordings on Boundary storage buckets. When you create Boundary storage buckets, you can use tags to select the workers you prefer to use for session recording responsibilities. + + + + +Example of a worker filter configured on a storage bucket in the Admin UI: + +![Example of a storage bucket worker filter](/img/ui/session-rec-worker-filter_light.png#light-theme-only) +![Example of a storage bucket worker filter](/img/ui/session-rec-worker-filter_dark.png#dark-theme-only) + + + + +Example of a worker filter configured on a storage bucket with the CLI: + +``` +$ boundary storage-buckets update -id sb_1234567890 -worker-filter='"session-recording" in "/tags/type"' +``` + + + + +Example of a worker filter configured on a storage bucket with Terraform: + +```hcl +resource "boundary_storage_bucket" "aws_dynamic_credentials_example" { + name = "session-recording-storage-bucket" + scope_id = boundary_scope.org.id # change to valid scope ID + plugin_name = "aws" + bucket_name = "mybucket" # change to valid AWS S3 storage bucket name + + # the role_arn value should match the arn used as the instance profile attached to the ec2 instance + # https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html + attributes_json = jsonencode({ + "region" = "us-east-1" + "role_arn" = "arn:aws:iam::123456789012:role/S3Access" # change to valid role ARN + "disable_credential_rotation" = "true" + }) + worker_filter = "\"session-recording\" in \"/tags/type\"" # change to valid worker filter tag +} +``` + + + diff --git a/website/content/docs/workers/index.mdx b/website/content/docs/workers/index.mdx new file mode 100644 index 000000000..41bac5d42 --- /dev/null +++ b/website/content/docs/workers/index.mdx @@ -0,0 +1,123 @@ +--- +layout: docs +page_title: Worker configuration overview +description: >- + Learn about worker configuration for proxies, storage, and tags. Understand how multi-hop configurations let you chain workers together in private networks. +--- + +# Overview of workers + +Workers are primarily used as network proxies for Boundary sessions, they allow you to access private targets. Instead of exposing a private network to the public, or allowing users to have access to entire private networks, workers create a direct network tunnel between users and targets. + +Workers are services that can run on a container or virtual machine. You should deploy them strategically within networks to provide access to targets. +In all editions of Boundary, workers are fully self-managed and can be deployed anywhere. +In HCP Boundary, HCP-managed workers are automatically deployed with the cluster. + +All workers within Boundary use certificates and encryption keys to identify +themselves and protect data in transit. However, there are three different +ways to register them so that registration of workers can fit into any workflow: controller-led, worker-led, and via external KMS. + +You must register workers using the worker-led or controller-led methods in the system with an API call. These workers require storage on disk to store the current set of credentials. Workers using an external KMS auto-register after authenticating. This makes them an easy mechanism to use for automatic scaling. +This also means they do not need to store +credentials locally; the KMS re-authenticates them each time they connect. + + + +Before version 0.15 of Boundary, there were two different types of workers, PKI & KMS workers. +If you are using pre-0.15 workers with pre-0.15 upstream configurations, please switch the documentation version to `0.13.x` - `0.14.x`. This will ensure you have the correct information. + + + +## Signals + +The `SIGHUP` signal causes a worker to reload its configuration file to pick up any updates for the `initial_upstreams` and `tags` values. +Boundary ignores other updated values. + +The `SIGTERM` and `SIGINT` signals initiate a graceful shutdown on a worker. The worker waits for any sessions to drain +before shutting down. Workers in a graceful shutdown state do not receive any new work, including session proxying, from the control plane. + +## Session recording + +This feature requires HCP Boundary or Boundary Enterprise + +Session recording requires at least one worker with access to local and remote storage. +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 deleted locally. + +The `recording_storage_minimum_available_capacity` value determines the minimum amount of storage space that is required for workers to perform session recording operations. If a worker is at or below the storage threshold, Boundary does not use the worker to record sessions or play back recordings. + +Development example: + +```hcl +worker { + auth_storage_path="/var/lib/boundary" + initial_upstreams = ["10.0.0.1"] + recording_storage_path="/local/storage/directory" + recording_storage_minimum_available_capacity="500MB" +} +``` + +## Multi-hop sessions + +This feature requires HCP Boundary or Boundary Enterprise + +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, you must connect two or more workers to each other in some +configuration. There are no limits on the number of workers allowed in a +multi-hop session configuration. + +It helps to think of “upstream” and “downstream” nodes in the context of +multi-hop. If you view controllers as the “top” node of a multi-hop chain, any +worker connected to a node is "downstream" of that node. The node that any +particular worker connects to (whether another worker or a controller) is the +"upstream" of that node. For example, in the diagram below, Worker 2’s upstream +is Worker 1, and its downstream is Worker 3. + +![multi-hop workers](/img/multi-hop-workers.png) + +You can deploy multi-hop workers in scenarios where inbound network traffic is +not allowed. A worker in a private network can send outbound communication to +its upstream worker, and create a reverse proxy to establish a session. + +You can configure target worker filters with multi-hop workers to allow for +fine-grained control on which workers handle ingress and egress for session +traffic to a target. Ingress worker filters specify the workers you use to initiate a session, and egress worker filters specify the workers you use to access targets. + +## Common worker parameters + +@include '/configuration-reference/workers/common-worker-parameters.mdx' + + +## Complete configuration example + +@include '/configuration-reference/workers/complete-configuration-example.mdx' + +## Tutorials + +Refer to the [worker management](/boundary/tutorials/worker-management) tutorials for practice managing workers, configuring multi-hop sessions, and creating worker-aware targets. + +Refer to the [Self-managed worker registration with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-workers) tutorial to learn how to register and manage workers. + +Refer to the [Manage multi-hop sessions with HCP Boundary](/boundary/tutorials/hcp-administration/hcp-manage-multi-hop) tutorial to learn how to configure a multi-hop session. + +## More information + +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. + +To configure and register a worker, refer to the following topics: + +- [Create the worker configuration](/boundary/docs/workers/create) +- [Register workers](/boundary/docs/workers/registration) + +Refer to the following topics for more information about configuring workers for specific applications or workflows: + +- [Overview of multi-hop sessions](/boundary/docs/workers/multi-hop) + - [Configure multi-hop sessions for Boundary Enterprise](/boundary/docs/workers/multi-hop/enterprise) + - [Configure multi-hop sessions for HCP Boundary](/boundary/docs/workers/multi-hop/hcp) +- [Overview of session recording](/boundary/docs/session-recording) + - [Configure workers for session recording](/boundary/docs/session-recording/configuration/configure-worker-storage) +- [Configure workers for access to Vault](/boundary/docs/workers/filters#example-worker-filter-for-vault-credential-store) +- [Configure workers for dynamic host discovery from cloud providers](/boundary/docs/hosts) +- [Route traffic through a worker](/boundary/docs/workers/worker-tags) +- [Configure a worker filter](/boundary/docs/workers/filters) +- [Configure self-managed workers for HCP Boundary](/hcp/docs/boundary/self-managed-workers) diff --git a/website/content/docs/workers/multi-hop/enterprise.mdx b/website/content/docs/workers/multi-hop/enterprise.mdx new file mode 100644 index 000000000..ca021c98b --- /dev/null +++ b/website/content/docs/workers/multi-hop/enterprise.mdx @@ -0,0 +1,30 @@ +--- +layout: docs +page_title: Create multi-hop sessions for Boundary Enterprise +description: >- + Configure multi-hop sessions for Boundary Enterprise. Chain together two or more workers across multiple networks to reach a target without exposing private networks. +--- + +# Configure multi-hop sessions for Boundary Enterprise + +This feature requires HCP Boundary or Boundary Enterprise + +For Boundary Enterprise, you can configure ingress, intermediary, and egress workers to take advantage of multi-hop worker capabilities. + +Note that "ingress," "intermediary," and "egress" are general ways to describe how the respective worker interacts with resources. +A worker can serve more than one of those roles at a time. +Refer to [Multi-hop sessions](/boundary/docs/workers/multi-hop) for more information. + +Complete the steps below to configure ingress, intermediate, and egress workers for Boundary Enterprise. + +## Ingress worker configuration + +@include '/workers/ingress-worker-config.mdx' + +## Intermediate worker configuration + +@include '/workers/intermediate-worker-config.mdx' + +## Egress worker configuration + +@include '/workers/egress-worker-config.mdx' diff --git a/website/content/docs/workers/multi-hop/hcp.mdx b/website/content/docs/workers/multi-hop/hcp.mdx new file mode 100644 index 000000000..f6f07a1e7 --- /dev/null +++ b/website/content/docs/workers/multi-hop/hcp.mdx @@ -0,0 +1,65 @@ +--- +layout: docs +page_title: Create multi-hop sessions for HCP +description: >- + Configure multi-hop sessions for HCP Boundary. Chain together two or more workers across multiple networks to reach a target without exposing private networks. +--- + +# Configure multi-hop sessions for HCP Boundary + +This feature requires HCP Boundary or Boundary Enterprise + +Many organizations have strict network policies that prohibit all inbound traffic into their networks. In these scenarios, you can use HCP-managed workers as the ingress workers. To establish a connection into the network, a self-managed worker configured as an egress worker initiates an outbound connection to the HCP-managed worker, creating a persistent connection. As a result, when end users connect to a target, the end user's connection would hop from the Boundary client to the HCP-managed worker (ingress worker) to the self-managed worker (egress worker) to the target (or other intermediary workers if needed). + +## Configure HCP-managed workers for ingress + +To configure end user traffic to ingress through HCP-managed workers, you must configure the self-managed worker (enterprise version). On your self-managed worker that you use for egress to the HCP-managed worker, set the configuration file with the following parameters: +- `hcp_boundary_cluster_id` - The HCP Boundary cluster ID, which can be found in the HCP Boundary cluster's URL. +- Omit the `public_addr` parameter. A public address is not needed since the self-managed worker initiates the connection to HCP-managed workers. +- Omit the `initial_upstreams` parameter. This is not needed because the `hcp_boundary_cluster_id` parameter is sufficent to indicate the HCP-managed workers as the upstream. +- Include a [worker tag](/boundary/docs/workers/worker-tags) in the `worker` stanza which will be used to select multi-hop routes for each target. + +### Example self-managed worker configuration: +``` +hcp_boundary_cluster_id = "7acdefe2c-1234-4ff1-b710-123456789876" + +listener "tcp" { + address = "0.0.0.0:9202" + purpose = "proxy" +} + +worker { + auth_storage_path = "/home/ubuntu/boundary/worker1" + tags { + tag = ["multihop"] + } + recording_storage_path = "/tmp/worker1" +} +``` +## Allow-list outbound network traffic to HCP-managed workers + +Some organizations require explicit destination addresses set in their network firewall rules for any outbound traffic. In this scenario, you should use the fully qualified domain name (FQDN) of the HCP-managed workers: + +``` +.proxy.boundary.hashicorp.cloud +``` + +where the `cluster_uuid` is the HCP Boundary cluster ID. You can find your HCP Boundary cluster ID in the HCP Boundary cluster's URL. + + + + The Boundary cluster ID is derived from the Boundary address. For example, if + your cluster URL is: + + `https://abcd1234-e567-f890-1ab2-cde345f6g789.boundary.hashicorp.cloud` + + Then your cluster id is `abcd1234-e567-f890-1ab2-cde345f6g789`. + + + +## Route end user traffic to targets through HCP-managed workers + +To route traffic through the HCP-managed workers, you should set the egress filters of each target to match the tag set in the self-managed worker's configuration file. You do not need to set additional ingress filters on the targets. + +![Multi-hop egress worker filter](/img/ui/multi-hop-egress-filter_light.png#light-theme-only) +![Multi-hop egress worker filter](/img/ui/multi-hop-egress-filter_dark.png#dark-theme-only) \ No newline at end of file diff --git a/website/content/docs/concepts/connection-workflows/multi-hop.mdx b/website/content/docs/workers/multi-hop/index.mdx similarity index 64% rename from website/content/docs/concepts/connection-workflows/multi-hop.mdx rename to website/content/docs/workers/multi-hop/index.mdx index 84d6889e1..fb6168218 100644 --- a/website/content/docs/concepts/connection-workflows/multi-hop.mdx +++ b/website/content/docs/workers/multi-hop/index.mdx @@ -69,63 +69,6 @@ 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. -## Use HCP-managed workers as ingress workers - -Many organizations have strict network policies that prohibit all inbound traffic into their networks. In these scenarios, you can use HCP-managed workers as the ingress workers. To establish a connection into the network, a self-managed worker configured as an egress worker initiates an outbound connection to the HCP-managed worker, creating a persistent connection. As a result, when end users connect to a target, the end user's connection would hop from the Boundary client to the HCP-managed worker (ingress worker) to the self-managed worker (egress worker) to the target (or other intermediary workers if needed). - -### Configure HCP-managed workers for ingress - -To configure end user traffic to ingress through HCP-managed workers, you must configure the self-managed worker (enterprise version). On your self-managed worker that you use for egress to the HCP-managed worker, set the configuration file with the following parameters: -- `hcp_boundary_cluster_id` - The HCP Boundary cluster ID, which can be found in the HCP Boundary cluster's URL. -- Omit the `public_addr` parameter. A public address is not needed since the self-managed worker initiates the connection to HCP-managed workers. -- Omit the `initial_upstreams` parameter. This is not needed because the `hcp_boundary_cluster_id` parameter is sufficent to indicate the HCP-managed workers as the upstream. -- Include a [worker tag](/boundary/docs/concepts/filtering/worker-tags#target-worker-filtering) in the `worker` stanza which will be used to select multi-hop routes for each target. - -### Example self-managed worker configuration: -``` -hcp_boundary_cluster_id = "7acdefe2c-1234-4ff1-b710-123456789876" - -listener "tcp" { - address = "0.0.0.0:9202" - purpose = "proxy" -} - -worker { - auth_storage_path = "/home/ubuntu/boundary/worker1" - tags { - tag = ["multihop"] - } - recording_storage_path = "/tmp/worker1" -} -``` -### Allow-list outbound network traffic to HCP-managed workers - -Some organizations require explicit destination addresses set in their network firewall rules for any outbound traffic. In this scenario, you should use the fully qualified domain name (FQDN) of the HCP-managed workers: - -``` -.proxy.boundary.hashicorp.cloud -``` - -where the `cluster_uuid` is the HCP Boundary cluster ID. You can find your HCP Boundary cluster ID in the HCP Boundary cluster's URL. - - - - The Boundary cluster ID is derived from the Boundary address. For example, if - your cluster URL is: - - `https://abcd1234-e567-f890-1ab2-cde345f6g789.boundary.hashicorp.cloud` - - Then your cluster id is `abcd1234-e567-f890-1ab2-cde345f6g789`. - - - -### Route end user traffic to targets through HCP-managed workers - -To route traffic through the HCP-managed workers, you should set the egress filters of each target to match the tag set in the self-managed worker's configuration file. You do not need to set additional ingress filters on the targets. - -![Multi-hop egress worker filter](/img/ui/multi-hop-egress-filter_light.png#light-theme-only) -![Multi-hop egress worker filter](/img/ui/multi-hop-egress-filter_dark.png#dark-theme-only) - ## Multi-hop worker requirements When you configure multi-hop sessions, there is an "ingress" worker, an "egress" @@ -153,4 +96,11 @@ upstream worker and outbound access to the destination host or service. ## Complete worker configuration -For the full set of worker parameters and a complete configuration example, refer to the [worker stanza](/boundary/docs/configuration/worker) documentation. +For the full set of worker parameters and a complete configuration example, refer to the [worker stanza](/boundary/docs/configuration/workers) documentation. + +## Next steps + +Refer to the following topics to configure multi-hop sessions: + +- [Configure multi-hop sessions for Boundary Enterprise](/boundary/docs/workers/multi-hop/enterprise) +- [Configure multi-hop sessions for HCP Boundary](/boundary/docs/workers/multi-hop/hcp) diff --git a/website/content/docs/configuration/worker/worker-configuration.mdx b/website/content/docs/workers/registration.mdx similarity index 80% rename from website/content/docs/configuration/worker/worker-configuration.mdx rename to website/content/docs/workers/registration.mdx index a741aabeb..1b569913b 100644 --- a/website/content/docs/configuration/worker/worker-configuration.mdx +++ b/website/content/docs/workers/registration.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Worker configuration +page_title: Register workers description: >- - Learn about authorizing workers to the controller and configuring workers for session recording storage. View a complete worker configuration example. + Learn about authorizing workers to the controller. View a worker configuration example. --- -# Worker configuration +# Register workers Workers authenticate to Boundary using an activation token. They require an accessible directory defined by `auth_storage_path` for credential storage and @@ -20,7 +20,6 @@ worker { } ``` - ## Authorization methods There are three mechanisms that can be used to initially register a worker to the cluster, Controller-Led, Worker-Led, and registration through an external KMS. @@ -128,7 +127,7 @@ In the examples above we are encoding key bytes directly in the configuration file. This is because we are using the `aead` method where you directly supply a key; in production you'd want to use a KMS such as AWS KMS, GCP CKMS, Azure KeyVault, or HashiCorp Vault. For a complete guide to all available KMS types, -see our [KMS documentation](/boundary/docs/configuration/kms). +refer to [Data encryption in Boundary](/boundary/docs/secure/encryption/data-encryption). ## Complete configuration example @@ -168,14 +167,13 @@ kms "aead" { } ``` -[`initial_upstreams`](/boundary/docs/configuration/worker#initial_upstreams) +[`initial_upstreams`](/boundary/docs/configuration/workers#initial_upstreams) are used to connect to upstream Boundary clusters. ## Resources For more on how `tags{}` in the above configuration are used to facilitate -routing to the correct target, refer to the [Worker -Tags](/boundary/docs/concepts/filtering/worker-tags) page. +routing to the correct target, refer to [Route traffic through a worker](/boundary/docs/workers/worker-tags). ## KMS configuration @@ -192,28 +190,8 @@ kms "aead" { } ``` -## Session recording - -This feature requires HCP Boundary or Boundary Enterprise - -[Session recording](/boundary/docs/configuration/session-recording) requires at least one Worker with access to local and remote storage. -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 deleted locally. - -The `recording_storage_minimum_available_capacity` value determines the minimum amount of storage space that is required for workers to perform session recording operations. If a worker is at or below the storage threshold, Boundary does not use the worker to record sessions or play back recordings. - -Development example: - -```hcl -worker { - auth_storage_path="/var/lib/boundary" - initial_upstreams = ["10.0.0.1"] - recording_storage_path="/local/storage/directory" - recording_storage_minimum_available_capacity="500MB" -} -``` - -The `name` and `description` fields are not valid configuration fields for workers that use worker-led or controller-led authorization. You can only set these fields through the API and they are only valid for workers that use the [KMS authorization method](/boundary/docs/configuration/worker/worker-configuration#kms-led-authorization-authentication-flow). +The `name` and `description` fields are not valid configuration fields for workers that use worker-led or controller-led authorization. You can only set these fields through the API and they are only valid for workers that use the [KMS authorization method](/boundary/docs/workers/registration#kms-led-authorization-authentication-flow). diff --git a/website/content/docs/concepts/filtering/worker-tags.mdx b/website/content/docs/workers/worker-tags.mdx similarity index 67% rename from website/content/docs/concepts/filtering/worker-tags.mdx rename to website/content/docs/workers/worker-tags.mdx index 38edd9be3..55cb4538b 100644 --- a/website/content/docs/concepts/filtering/worker-tags.mdx +++ b/website/content/docs/workers/worker-tags.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Filtering - worker tags +page_title: Route traffic through a worker description: >- Learn about using worker tags to designate worker roles. Examples include serving specific regions or functions, such as credential stores or storage buckets. --- -# Worker tags +# Route traffic through a worker This page describes how to use worker tags and filters to control which workers are allowed to handle a given resource. You can use filters to control traffic @@ -13,6 +13,8 @@ locally. As an example, you can use filters to ensure that traffic going into a public cloud is only handled by workers running within that same cloud. Tags can also be used determine which worker should perform session recording duties. +Refer to [Filtering and listing resources](/boundary/docs/filtering) for more information about Boundary's filter syntax and best practices. + You can configure worker tags using the worker config file, the Admin UI, the CLI, or the API. Select a tag below to view examples. @@ -386,157 +388,8 @@ Following are some examples of using these values in filters that can be applied - Grouping: `("us-east-1" in "/tags/region" and "/name" == "web-prod-us-east-1") or "webservers" in "/tags/type"` - +Each tag can have multiple values, so you must use the `in` operator to match values. If you know that you have only one value, an equivalent would be `"/tags/key/0" == "value"`. - Each tag can have multiple values, so you must use the `in` operator to match values. If you know that you have only one value, an equivalent would be `"/tags/key/0" == "value"`. +## Next steps - - -### Example worker filter for targets - -Once workers have tags, you can use these tags to control which -workers are allowed to manage a given session by specifying worker filter attributes -when you configure [targets](/boundary/docs/concepts/domain-model/targets). - -The `egress_worker_filter` attribute controls which workers are used for egress to a target. This is the worker -that accesses the target. - -The `ingress_worker_filter`HCP/ENT attribute controls which workers are used for ingress to a target. -This is the worker a client connects to when initiating a connection to a target. - - - - - -Example of a filter configured on a target in the Admin UI: - -![Example of a target ingress worker filter](/img/ui/target-ingress-worker-filter_light.png#light-theme-only) -![Example of a target ingress worker filter](/img/ui/target-ingress-worker-filter_dark.png#dark-theme-only) - - - - -Example of a filter configured on a target with the CLI: - -``` -$ boundary targets update tcp -id tssh_1234567890 -egress-worker-filter='"prod" in "/tags/type"' -``` - - - - -Example of a filter configured on a target with Terraform: - -```hcl -resource "boundary_target" "aws-webservers-prod" { - type = "ssh" - name = "aws-web-prod" - description = "AWS EC2 Targets" - egress_worker_filter = "\"prod\" in \"/tags/type\"" -} -``` - - - - -### Example worker filter for Vault credential store - -Tags are used to control which [workers] can manage Vault requests by specifying -a `worker_filter`attribute when configuring [credential stores]. - -This allows the use of private Vault instances with Boundary. Workers -deployed in the same network as a private Vault instance can access and relay -Vault requests to Boundary controllers. - - - - A worker that matches the worker filter must exist before you define the Vault credential store, as it will perform the Vault calls needed to set up the credential store with Boundary. - - - -[workers]: /boundary/docs/configuration/worker/worker-configuration -[credential stores]: /boundary/docs/concepts/domain-model/credential-stores#vault-credential-store-attributes - - - - -Example of a worker filter configured on a Vault credential store in the Admin UI: - -![Example of a credential store worker filter](/img/ui/vault-worker-filter_light.png#light-theme-only) -![Example of a credential store worker filter](/img/ui/vault-worker-filter_dark.png#dark-theme-only) - - - - -Example of a worker filter configured on a Vault credential store with the CLI: - -``` -$ boundary credential-stores update vault -id csvlt_1234567890 -worker-filter='"vault" in "/tags/type"' -``` - - - - -Example of a worker filter configured on a Vault credential store with Terraform: - -```hcl -resource "boundary_credential_store_vault" "vault_cred_store" { - name = "Vault host credentials" - address = "http://127.0.0.1:8200" # change to Vault address - token = "s.0ufRo6XEGU2jOqnIr7OlFYP5" # change to valid Vault token - scope_id = boundary_scope.project.id # change to target scope - worker_filter = "\"vault\" in \"/tags/type\"" # change to access private Vault cluster -} -``` - - - - -### Example worker filter for storage buckets - -Storage buckets are used for session recording, which requires HCP Boundary or Boundary Enterprise - -Session recording functions are performed by Boundary workers. Workers also store recordings on Boundary storage buckets. When you create Boundary storage buckets, you can use tags to select the workers you prefer to use for session recording responsibilities. - - - - -Example of a worker filter configured on a storage bucket in the Admin UI: - -![Example of a storage bucket worker filter](/img/ui/session-rec-worker-filter_light.png#light-theme-only) -![Example of a storage bucket worker filter](/img/ui/session-rec-worker-filter_dark.png#dark-theme-only) - - - - -Example of a worker filter configured on a storage bucket with the CLI: - -``` -$ boundary storage-buckets update -id sb_1234567890 -worker-filter='"session-recording" in "/tags/type"' -``` - - - - -Example of a worker filter configured on a storage bucket with Terraform: - -```hcl -resource "boundary_storage_bucket" "aws_dynamic_credentials_example" { - name = "session-recording-storage-bucket" - scope_id = boundary_scope.org.id # change to valid scope ID - plugin_name = "aws" - bucket_name = "mybucket" # change to valid AWS S3 storage bucket name - - # the role_arn value should match the arn used as the instance profile attached to the ec2 instance - # https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html - attributes_json = jsonencode({ - "region" = "us-east-1" - "role_arn" = "arn:aws:iam::123456789012:role/S3Access" # change to valid role ARN - "disable_credential_rotation" = "true" - }) - worker_filter = "\"session-recording\" in \"/tags/type\"" # change to valid worker filter tag -} -``` - - - +You can [configure a worker filter](/boundary/docs/workers/filters) to control which workers are allowed to manage a given session, act as a Vault credential store, or store session recordings. diff --git a/website/content/partials/configuration-reference/events/common-audit_config-examples.mdx b/website/content/partials/configuration-reference/events/common-audit_config-examples.mdx new file mode 100644 index 000000000..59f5df639 --- /dev/null +++ b/website/content/partials/configuration-reference/events/common-audit_config-examples.mdx @@ -0,0 +1,32 @@ +This example is equivalent to the default settings if no `audit_config` stanza +is provided. + +```hcl +audit_config { + audit_filter_overrides { + sensitive = "redact" + secret = "redact" + } +} +``` + +This example will HMAC sensitive fields, and encrypt secrets. + +```hcl +audit_config { + audit_filter_overrides { + sensitive = "hmac-sha256" + secret = "encrypt" + } +} +``` + +This example will not apply a filter to sensitive fields. + +```hcl +audit_config { + audit_filter_overrides { + sensitive = "" + } +} +``` \ No newline at end of file diff --git a/website/content/partials/configuration-reference/events/common-audit_config-parameters.mdx b/website/content/partials/configuration-reference/events/common-audit_config-parameters.mdx new file mode 100644 index 000000000..1e30194f0 --- /dev/null +++ b/website/content/partials/configuration-reference/events/common-audit_config-parameters.mdx @@ -0,0 +1,2 @@ +- `audit_filter_overrides` - Specifies overrides for the filter operations that + are applied to audit events. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/events/common-audit_filter_overrides-parameters.mdx b/website/content/partials/configuration-reference/events/common-audit_filter_overrides-parameters.mdx new file mode 100644 index 000000000..b581da6d5 --- /dev/null +++ b/website/content/partials/configuration-reference/events/common-audit_filter_overrides-parameters.mdx @@ -0,0 +1,5 @@ +- `sensitive` `(string: "", "encrypt", "hmac-sha256", "redact")` - Specifies + the filter operation to apply to fields that are classified as sensitive. + +- `secret` `(string: "", "encrypt", "hmac-sha256", "redact")` - Specifies + the filter operation to apply to fields that are classified as secret. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/events/common-sink-intro.mdx b/website/content/partials/configuration-reference/events/common-sink-intro.mdx new file mode 100644 index 000000000..bbf0546ca --- /dev/null +++ b/website/content/partials/configuration-reference/events/common-sink-intro.mdx @@ -0,0 +1,29 @@ +These parameters are shared across all sink types: + +- `name` - Specify a name for the sink. + +- `description` - Specify a description for the sink. + +- `event_types` - Specifies a list of event types that will be sent to the sink. + Can be `*`, `audit`, `error`, `observation`, `system`, or `telemetry`. + +- `event_source_url` - Specifies an optional event source URL for the sink. If + not specified, the default source will be composed of the + `https://hashicorp.com/boundary.io/ServerName/Path/FileName`. + +- `allow_filters` - Specifies a set of predicates for including an event in the + sink. If any filter matches, the event will be included. For more information, + on using filters see: [event filtering](/boundary/docs/monitor/events/filter-events) + +- `deny_filters` - Specifies a set predicates for excluding an event in the + sink. If any filter matches, the event will be excluded. For more information + on using filters see: [event filtering](/boundary/docs/monitor/events/filter-events) + +- `format` - Specifies the format for the sink. Can be `cloudevents-json`, + `cloudevents-text`, `hclog-json`, or `hclog-text`. + +- `type` - Specifies the type of sink. Can be `stderr` or `file`. + +- `audit_config` - Specifies configuration for the processing of audit events + for the sink. This is ignored if the sink is not configured to receive + `audit` events. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/events/default-events-stanza.mdx b/website/content/partials/configuration-reference/events/default-events-stanza.mdx new file mode 100644 index 000000000..121315da1 --- /dev/null +++ b/website/content/partials/configuration-reference/events/default-events-stanza.mdx @@ -0,0 +1,15 @@ +If no event stanza is specified then the following default is used: + +```hcl +events { + audit_enabled = false + observations_enabled = true + sysevents_enabled = true + telemetry_enabled = false + sink "stderr" { + name = "default" + event_types = ["*"] + format = "cloudevents-json" + } +} +``` diff --git a/website/content/partials/configuration-reference/events/events-stanza-intro.mdx b/website/content/partials/configuration-reference/events/events-stanza-intro.mdx new file mode 100644 index 000000000..28527587a --- /dev/null +++ b/website/content/partials/configuration-reference/events/events-stanza-intro.mdx @@ -0,0 +1,40 @@ +The `events` stanza configures Boundary events-specific parameters. + +Example: + +```hcl +events { + observations_enabled = true + sysevents_enabled = true + telemetry_enabled = false + sink "stderr" { + name = "all-events" + description = "All events sent to stderr" + event_types = ["*"] + format = "hclog-text" + } + sink { + name = "obs-sink" + description = "Observations sent to a file" + event_types = ["observation"] + format = "cloudevents-json" + file { + path = "/var/log/boundary" + file_name = "events.ndjson" + } + } +} +``` + +- `audit_enabled` - Specifies if audit events should be emitted. + +- `observations_enabled` - Specifies if observation events should be emitted. + +- `sysevents_enabled` - Specifies if system events should be emitted. + +- `telemetry_enabled` - Specifies if telemetry events should be emitted. +To receive telemetry events, you must also set `observations_enabled` to `true`. + +- `sink` - Specifies the configuration of an event sink. Currently, two types of +sink are supported: [file](/boundary/docs/monitor/events/file) and [stderr](/boundary/docs/monitor/events/stderr). If no sinks are configured then all +events will be sent to a default stderr sink. Events may be sent to multiple sinks. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/events/file-parameters.mdx b/website/content/partials/configuration-reference/events/file-parameters.mdx new file mode 100644 index 000000000..1893d1e8f --- /dev/null +++ b/website/content/partials/configuration-reference/events/file-parameters.mdx @@ -0,0 +1,13 @@ +These parameters are only valid for a `file` sink. + +- `file_name` - Specifies the file name for the sink. + +- `path` - Optionally specifies the file path for the sink. + +- `rotate_bytes` - Optionally specifies the number of bytes that should trigger rotation of + a file sink. + +- `rotate_duration` - Optionally specifies how often a file sink should be rotated. + +- `rotate_max_files` - Optionally specifies how many historical rotated files should be kept + for a file sink. diff --git a/website/content/partials/configuration-reference/events/file-sink-intro.mdx b/website/content/partials/configuration-reference/events/file-sink-intro.mdx new file mode 100644 index 000000000..d67424876 --- /dev/null +++ b/website/content/partials/configuration-reference/events/file-sink-intro.mdx @@ -0,0 +1,18 @@ +The file sink configures Boundary to send events to a file. + +```hcl +sink { + name = "obs-sink" + description = "Observations sent to a file" + event_types = ["observation"] + format = "cloudevents-json" + file { + path = "/var/log/boundary" + file_name = "events.ndjson" + } + } +``` + +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`. diff --git a/website/content/partials/configuration-reference/events/stderr-intro.mdx b/website/content/partials/configuration-reference/events/stderr-intro.mdx new file mode 100644 index 000000000..b988c1e06 --- /dev/null +++ b/website/content/partials/configuration-reference/events/stderr-intro.mdx @@ -0,0 +1,11 @@ +The stderr sink configures Boundary to send events to a stderr. + +```hcl + +sink "stderr" { + name = "all-events" + description = "All events sent to stderr" + event_types = ["*"] + format = "hclog-text" +} +``` \ No newline at end of file diff --git a/website/content/partials/configuration-reference/events/stderr-parameters.mdx b/website/content/partials/configuration-reference/events/stderr-parameters.mdx new file mode 100644 index 000000000..70801571a --- /dev/null +++ b/website/content/partials/configuration-reference/events/stderr-parameters.mdx @@ -0,0 +1 @@ +There are parameters are only valid for a `stderr` sink. \ No newline at end of file diff --git a/website/content/docs/configuration/listener/index.mdx b/website/content/partials/configuration-reference/listeners/listener-purpose.mdx similarity index 66% rename from website/content/docs/configuration/listener/index.mdx rename to website/content/partials/configuration-reference/listeners/listener-purpose.mdx index 2f5b93347..9c0579f50 100644 --- a/website/content/docs/configuration/listener/index.mdx +++ b/website/content/partials/configuration-reference/listeners/listener-purpose.mdx @@ -1,19 +1,3 @@ ---- -layout: docs -page_title: Listener configuration -description: >- - Learn about TCP and Unix listener configuration settings. Understand where to change the default addresses and ports on which Boundary responds to requests. ---- - -# `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 - 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. diff --git a/website/content/partials/configuration-reference/listeners/tcp-configure-custom-http-response-headers.mdx b/website/content/partials/configuration-reference/listeners/tcp-configure-custom-http-response-headers.mdx new file mode 100644 index 000000000..b5395d7df --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-configure-custom-http-response-headers.mdx @@ -0,0 +1,83 @@ +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 +set custom http headers that are appropriate to their applications. Examples of such headers are +`"Strict-Transport-Security"` and `"Content-Security-Policy"` which are known HTTP headers, and could be +configured to harden the security of an application communicating with the Boundary endpoints. Note that +vulnerability scans often examine such security related HTTP headers. In addition, you can configure +application-specific custom headers. For example, `"X-Custom-Header"` has been configured in the example +below. + +```hcl +listener "tcp" { + custom_api_response_headers { + "default" = { + "Strict-Transport-Security" = ["max-age=31536000; includeSubDomains"], + "X-Custom-Header" = ["Custom Header Default Value"], + }, + "2xx" = { + "X-Custom-Header" = ["Custom Header Value 1", "Custom Header Value 2"], + }, + "301" = { + "Strict-Transport-Security" = ["max-age=31536000"], + }, + } + custom_ui_response_headers { + "default" = { + "Strict-Transport-Security" = ["max-age=31536000; includeSubDomains"], + "Content-Security-Policy" = ["default-src 'none'; script-src 'self' 'wasm-unsafe-eval'; frame-src 'self'; font-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self'; media-src 'self'; manifest-src 'self'; style-src-attr 'self'; frame-ancestors 'self'"], + "X-Custom-Header" = ["Custom Header Default Value"], + }, + "2xx" = { + "X-Custom-Header" = ["Custom Header Value 1", "Custom Header Value 2"], + }, + "301" = { + "Strict-Transport-Security" = ["max-age=31536000"], + "Content-Security-Policy" = ["default-src 'none'; script-src 'none'; connect-src 'none'"], + }, + } +} +``` + +Note that Boundary requires `script-src 'wasm-unsafe-eval'` for playback of session recordings. + +In situations where a header is defined under several status code subsections, +Boundary returns the header matching the most specific response code. For example, +with the config example below, a `307` response would return `307 Custom header value`, +while a `306` would return `3xx Custom header value`. + +```hcl +listener "tcp" { + custom_api_response_headers { + "default" = { + "X-Custom-Header" = ["default Custom header value"] + }, + "3xx" = { + "X-Custom-Header" = ["3xx Custom header value"] + }, + "307" = { + "X-Custom-Header" = ["307 Custom header value"] + } + } +} +``` + +There may also be situations where default or collective status headers have been defined, +but you do not want them returned for a specific status code. You can unset headers at any +level by defining the headers as an empty list. + +```hcl +listener "tcp" { + custom_api_response_headers { + "default" = { + "X-Custom-Header" = ["default Custom header value"] + }, + "3xx" = { + "X-Custom-Header" = ["3xx Custom header value"] + }, + "307" = { + // Do not return this header for 307 responses + "X-Custom-Header" = [] + } + } +} +``` diff --git a/website/content/partials/configuration-reference/listeners/tcp-configure-tls.mdx b/website/content/partials/configuration-reference/listeners/tcp-configure-tls.mdx new file mode 100644 index 000000000..166b91321 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-configure-tls.mdx @@ -0,0 +1,9 @@ +This example shows enabling a TLS listener. + +```hcl +listener "tcp" { + purpose = "api" + tls_cert_file = "/etc/certs/Boundary.crt" + tls_key_file = "/etc/certs/Boundary.key" +} +``` \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/tcp-custom-api-response-headers.mdx b/website/content/partials/configuration-reference/listeners/tcp-custom-api-response-headers.mdx new file mode 100644 index 000000000..b1b675e49 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-custom-api-response-headers.mdx @@ -0,0 +1,18 @@ +- `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 + the status code value. For an example, refer to the + [Listeners custom http response headers](#listener-s-custom-response-headers) + section. + +- `` `(key-value-map: {})` - A map of string header names + to an array of string values. These headers are set only when the response status + code falls under the collective status code. + For example, `"2xx" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` + is set when the http response status code is `"200"`, `"204"`, etc. This overrides + headers defined at the `default` level. + +- `` `(key-value-map: {})` - A map of string header names + to an array of string values. These headers are set only when the specific status + code is returned. For example, `"200" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` + is set when the http response status code is `"200"`. This overrides headers defined at + the `default` and `collective status code` level. diff --git a/website/content/partials/configuration-reference/listeners/tcp-custom-response-headers.mdx b/website/content/partials/configuration-reference/listeners/tcp-custom-response-headers.mdx new file mode 100644 index 000000000..57c907c84 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-custom-response-headers.mdx @@ -0,0 +1,13 @@ +Boundary supports defining custom HTTP response headers for all requests on any Boundary controller. +Headers are defined based on the returned status code. For example, you can define a list of +custom response headers for the `200` status code, and another list of custom response headers for +the `307` status code, and so on. You can also define headers based on the hundred-level status +code. For example, a list of headers applied to the `4xx` code will be applied to 400, 401, 404, and +all other 400-level status codes. The more specific the status, the higher priority it has. +Default headers are overwritten by hundred-level headers, which are overwritten by status-specific +headers. + +There are two different config parameters that define headers: `custom_api_response_headers` and +`custom_ui_response_headers`. API headers apply to API endpoints, currently all paths starting +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. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/tcp-custom-ui-response-headers.mdx b/website/content/partials/configuration-reference/listeners/tcp-custom-ui-response-headers.mdx new file mode 100644 index 000000000..c08ae12e6 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-custom-ui-response-headers.mdx @@ -0,0 +1,18 @@ +- `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 + the status code value. For an example, refer to the + [Listeners custom http response headers](#listener-s-custom-response-headers) + section. + +- `` `(key-value-map: {})` - A map of string header names + to an array of string values. These headers are set only when the response status + code falls under the collective status code. + For example, `"2xx" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` + is set when the http response status code is `"200"`, `"204"`, etc. This overrides + headers defined at the `default` level. + +- `` `(key-value-map: {})` - A map of string header names + to an array of string values. These headers are set only when the specific status + code is returned. For example, `"200" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` + is set when the http response status code is `"200"`. This overrides headers defined at + the `default` and `collective status code` level. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/tcp-general-parameters.mdx b/website/content/partials/configuration-reference/listeners/tcp-general-parameters.mdx new file mode 100644 index 000000000..6859b23c3 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-general-parameters.mdx @@ -0,0 +1,58 @@ +- `purpose` `(string: "")` - Specifies the purpose. Can be `api`, `cluster`, + `proxy`, or `ops`. + +- `address` `(string: "127.0.0.1:9200")` – Specifies the address to bind to for + listening. + +- `http_idle_timeout` `(string: "5m")` - Specifies the maximum amount of time to + wait for the next request when keep-alives are enabled. If `http_idle_timeout` + is zero, the value of `http_read_timeout` is used. If both are zero, the value + of `http_read_header_timeout` is used. This is specified using a label suffix + like `"30s"` or `"1h"`. + +- `http_read_header_timeout` `(string: "10s")` - Specifies the amount of time + allowed to read request headers. This is specified using a label suffix like + `"30s"` or `"1h"`. + +- `http_read_timeout` `(string: "30s")` - Specifies the maximum duration for + 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 + 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"`. + + + +- `max_request_duration` `(string: "90s")` – Specifies the maximum + request duration allowed before Boundary cancels the request. This overrides + `default_max_request_duration` for this listener. + +- `cors_enabled` `(boolean: true)` - Specifies if CORS should be enabled, which + allows Boundary to support external browser-based clients (not including admin + UI), such as Boundary Desktop. If not specified, CORS will be enabled with an + allowed origin that grants access to Boundary Desktop, unless overridden with + `cors_disable_default_allowed_origin_values`. + +- `cors_disable_default_allowed_origin_values` `(boolean: false)` - Specifies + that Boundary should not append default allowed origin values to any specified + in `cors_allowed_origins`, such as Boundary Desktop's origin. This also + disables the behavior of enabling CORS if `cors_enabled` is not specified. + +- `cors_allowed_origins` `(array(string): ["serve://boundary"])` - An array of + allowed CORS origins. Origins must include protocol, host, and port (if port + is different than the default for the specified protocol). To allow all + origins, set to `['*']`. By default, Boundary Desktop's origin + `serve://boundary` is appended to any values included here, unless + `cors_disable_default_allowed_origin_values` is specified. + +- `cors_allowed_headers` `(array(string): [])` – An array specifying headers + that are permitted to be on cross-origin requests. Headers set via this + parameter will be appended to the list of headers that Boundary allows by + default, such as `"Content-Type"`, `"X-Requested-With"`, and + `"Authorization"`. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/tcp-intro.mdx b/website/content/partials/configuration-reference/listeners/tcp-intro.mdx new file mode 100644 index 000000000..e97eef8e3 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-intro.mdx @@ -0,0 +1,12 @@ +The TCP listener configures Boundary to listen on a TCP address/port. + +```hcl +listener "tcp" { + purpose = "api" + address = "127.0.0.1:9200" +} +``` + +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. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/tcp-listen-on-mulitple-interfaces.mdx b/website/content/partials/configuration-reference/listeners/tcp-listen-on-mulitple-interfaces.mdx new file mode 100644 index 000000000..057a1aaa9 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-listen-on-mulitple-interfaces.mdx @@ -0,0 +1,17 @@ +This example shows Boundary listening on a private interface, as well as localhost. + +```hcl +listener "tcp" { + purpose = "api" + address = "127.0.0.1:9200" +} + +listener "tcp" { + purpose = "cluster" + address = "10.0.0.5:9201" +} +``` + +[golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go +[api-addr]: /boundary/docs/configuration#api_addr +[cluster-addr]: /boundary/docs/configuration#cluster_addr diff --git a/website/content/partials/configuration-reference/listeners/tcp-telemetry.mdx b/website/content/partials/configuration-reference/listeners/tcp-telemetry.mdx new file mode 100644 index 000000000..2fe5806d7 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-telemetry.mdx @@ -0,0 +1,2 @@ +- `unauthenticated_metrics_access` `(string: "false")` - If set to true, allows + unauthenticated access to the `/v1/sys/metrics` endpoint. diff --git a/website/content/partials/configuration-reference/listeners/tcp-tls.mdx b/website/content/partials/configuration-reference/listeners/tcp-tls.mdx new file mode 100644 index 000000000..0e146d156 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/tcp-tls.mdx @@ -0,0 +1,69 @@ +The `tls` parameters are valid for `api` and `ops` listeners. The `cluster` +and `proxy` connections use their own ephemeral TLS stacks. For more +information, refer to [TLS in Boundary](/boundary/docs/secure/encryption/connections-tls). + +- `tls_disable` `(string: "false")` – Specifies if TLS will be disabled. Boundary + assumes TLS by default, so you must explicitly disable TLS to opt-in to + insecure communication. + +- `tls_cert_file` `(string: )` – + Specifies the path to the certificate for TLS. To configure the listener to + use a CA certificate, concatenate the primary certificate and the CA + certificate together. The primary certificate should appear first in the + combined file. On `SIGHUP`, the path set here _at Boundary startup_ will be + used for reloading the certificate; modifying this value while Boundary is + running will have no effect for `SIGHUP`s. + +- `tls_key_file` `(string: )` – + Specifies the path to the private key for the certificate. If the key file is + encrypted, you will be prompted to enter the passphrase on server startup. The + passphrase must stay the same between key files when reloading your + configuration using `SIGHUP`. On `SIGHUP`, the path set here _at Boundary + startup_ will be used for reloading the certificate; modifying this value + while Boundary is running will have no effect for `SIGHUP`s. + +- `tls_min_version` `(string: "tls12")` – Specifies the minimum supported + version of TLS. Accepted values are "tls10", "tls11", "tls12" or "tls13". + + TLS 1.1 and lower are generally considered insecure. + +- `tls_max_version` `(string: "tls13")` – Specifies the maximum supported + version of TLS, useful if appliances (e.g. load balancers) are not yet capable + of higher levels. Accepted values are "tls10", "tls11", "tls12" or "tls13". + + TLS 1.1 and lower are generally considered insecure. + +- `tls_cipher_suites` `(string: "")` – Override the default list of supported + ciphersuites (which varies by TLS version) with the the specified + comma-delimited list. The list of all available ciphersuites is available in + the [Golang TLS documentation][golang-tls]. + +- `tls_prefer_server_cipher_suites` `(string: "false")` – Specifies to prefer the + server's ciphersuite over the client ciphersuites. + +- `tls_require_and_verify_client_cert` `(string: "false")` – Turns on client + authentication for this listener; the listener will require a presented + client cert that successfully validates against system CAs. + +- `tls_client_ca_file` `(string: "")` – PEM-encoded Certificate Authority file + used for checking the authenticity of client. + + \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/unix-configure-tls.mdx b/website/content/partials/configuration-reference/listeners/unix-configure-tls.mdx new file mode 100644 index 000000000..ca5b86c09 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/unix-configure-tls.mdx @@ -0,0 +1,10 @@ +This example shows enabling a TLS listener. + +```hcl +listener "unix" { + purpose = "api" + address = "/var/run/boundary-api.sock" + tls_cert_file = "/etc/certs/Boundary.crt" + tls_key_file = "/etc/certs/Boundary.key" +} +``` \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/unix-general-parameters.mdx b/website/content/partials/configuration-reference/listeners/unix-general-parameters.mdx new file mode 100644 index 000000000..077f2266e --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/unix-general-parameters.mdx @@ -0,0 +1,57 @@ +- `purpose` `(string: "")` - Specifies the purpose. Can be `api`, `ops` or `cluster`. + +- `address` `(string: "")` – Specifies the address (filesystem path) to bind to + for listening. + +- `http_idle_timeout` `(string: "5m")` - Specifies the maximum amount of time to + wait for the next request when keep-alives are enabled. If `http_idle_timeout` + is zero, the value of `http_read_timeout` is used. If both are zero, the value + of `http_read_header_timeout` is used. This is specified using a label suffix + like `"30s"` or `"1h"`. + +- `http_read_header_timeout` `(string: "10s")` - Specifies the amount of time + allowed to read request headers. This is specified using a label suffix like + `"30s"` or `"1h"`. + +- `http_read_timeout` `(string: "30s")` - Specifies the maximum duration for + 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 + 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"`. + + + +- `max_request_duration` `(string: "90s")` – Specifies the maximum + request duration allowed before Boundary cancels the request. This overrides + `default_max_request_duration` for this listener. + +- `cors_enabled` `(boolean: true)` - Specifies if CORS should be enabled, which + allows Boundary to support external browser-based clients (not including admin + UI), such as Boundary Desktop. If not specified, CORS will be enabled with an + allowed origin that grants access to Boundary Desktop, unless overridden with + `cors_disable_default_allowed_origin_values`. + +- `cors_disable_default_allowed_origin_values` `(boolean: false)` - Specifies + that Boundary should not append default allowed origin values to any specified + in `cors_allowed_origins`, such as Boundary Desktop's origin. This also + disables the behavior of enabling CORS if `cors_enabled` is not specified. + +- `cors_allowed_origins` `(array(string): ["serve://boundary"])` - An array of + allowed CORS origins. Origins must include protocol, host, and port (if port + is different than the default for the specified protocol). To allow all + origins, set to `['*']`. By default, Boundary Desktop's origin + `serve://boundary` is appended to any values included here, unless + `cors_disable_default_allowed_origin_values` is specified. + +- `cors_allowed_headers` `(array(string): [])` – An array specifying headers + that are permitted to be on cross-origin requests. Headers set via this + parameter will be appended to the list of headers that Boundary allows by + default, such as `"Content-Type"`, `"X-Requested-With"`, and + `"Authorization"`. diff --git a/website/content/partials/configuration-reference/listeners/unix-intro.mdx b/website/content/partials/configuration-reference/listeners/unix-intro.mdx new file mode 100644 index 000000000..4cb8043f0 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/unix-intro.mdx @@ -0,0 +1,15 @@ +The `unix` listener configures Boundary to listen on a Unix domain socket. + +It is only available for listeners for `api` and `cluster` purpose. +Unix sockets cannot currently be used for `"proxy"` purpose on a worker. + +```hcl +listener "unix" { + purpose = "api" + address = "/var/run/boundary-api.sock" +} +``` + +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. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/unix-listen-on-multiple-interfaces.mdx b/website/content/partials/configuration-reference/listeners/unix-listen-on-multiple-interfaces.mdx new file mode 100644 index 000000000..516632918 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/unix-listen-on-multiple-interfaces.mdx @@ -0,0 +1,13 @@ +This example shows Boundary listening on a private interface, as well as localhost. + +```hcl +listener "tcp" { + purpose = "api" + address = "/var/run/boundary-api.sock" +} + +listener "tcp" { + purpose = "cluster" + address = "/var/run/boundary-cluster.sock" +} +``` diff --git a/website/content/partials/configuration-reference/listeners/unix-telemetry.mdx b/website/content/partials/configuration-reference/listeners/unix-telemetry.mdx new file mode 100644 index 000000000..3413e442c --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/unix-telemetry.mdx @@ -0,0 +1,2 @@ +- `unauthenticated_metrics_access` `(string: "false")` - If set to true, allows + unauthenticated access to the `/v1/sys/metrics` endpoint. \ No newline at end of file diff --git a/website/content/partials/configuration-reference/listeners/unix-tls-parameters.mdx b/website/content/partials/configuration-reference/listeners/unix-tls-parameters.mdx new file mode 100644 index 000000000..eecf09325 --- /dev/null +++ b/website/content/partials/configuration-reference/listeners/unix-tls-parameters.mdx @@ -0,0 +1,70 @@ +The `tls` parameters are valid for `api` and `ops` listeners. `cluster` +and `proxy` connections use their own ephemeral TLS stacks. For more +information, refer to [TLS in Boundary](/boundary/docs/secure/encryption/connections-tls). + +- `tls_disable` `(string: "false")` – Specifies if TLS will be disabled. Boundary + assumes TLS by default, so you must explicitly disable TLS to opt-in to + insecure communication. + +- `tls_cert_file` `(string: )` – + Specifies the path to the certificate for TLS. To configure the listener to + use a CA certificate, concatenate the primary certificate and the CA + certificate together. The primary certificate should appear first in the + combined file. On `SIGHUP`, the path set here _at Boundary startup_ will be + used for reloading the certificate; modifying this value while Boundary is + running will have no effect for `SIGHUP`s. + +- `tls_key_file` `(string: )` – + Specifies the path to the private key for the certificate. If the key file is + encrypted, you will be prompted to enter the passphrase on server startup. The + passphrase must stay the same between key files when reloading your + configuration using `SIGHUP`. On `SIGHUP`, the path set here _at Boundary + startup_ will be used for reloading the certificate; modifying this value + while Boundary is running will have no effect for `SIGHUP`s. + +- `tls_min_version` `(string: "tls12")` – Specifies the minimum supported + version of TLS. Accepted values are "tls10", "tls11", "tls12" or "tls13". + + TLS 1.1 and lower are generally considered insecure. + +- `tls_max_version` `(string: "tls13")` – Specifies the maximum supported + version of TLS, useful if appliances (e.g. load balancers) are not yet capable + of higher levels. Accepted values are "tls10", "tls11", "tls12" or "tls13". + + TLS 1.1 and lower are generally considered insecure. + +- `tls_cipher_suites` `(string: "")` – Override the default list of supported + ciphersuites (which varies by TLS version) with the the specified + comma-delimited list. The list of all available ciphersuites is available in + the [Golang TLS documentation][golang-tls]. + +- `tls_prefer_server_cipher_suites` `(string: "false")` – Specifies to prefer the + server's ciphersuite over the client ciphersuites. + +- `tls_require_and_verify_client_cert` `(string: "false")` – Turns on client + authentication for this listener; the listener will require a presented + client cert that successfully validates against system CAs. + +- `tls_client_ca_file` `(string: "")` – PEM-encoded Certificate Authority file + used for checking the authenticity of client. + + diff --git a/website/content/partials/configuration-reference/workers/common-worker-parameters.mdx b/website/content/partials/configuration-reference/workers/common-worker-parameters.mdx new file mode 100644 index 000000000..f22e681f8 --- /dev/null +++ b/website/content/partials/configuration-reference/workers/common-worker-parameters.mdx @@ -0,0 +1,78 @@ +The following fields apply to all registration mechanisms. + +```hcl +worker { + public_addr = "5.1.23.198" + + # Local storage path required if session recording is enabled + recording_storage_path = "tmp/boundary/" + + # Minimum available disk space required in the local storage path if session recording is enabled + recording_storage_minimum_available_capacity = "500MB" + + # Mutually exclusive with hcp_boundary_cluster_id + initial_upstreams = [ + "10.0.0.1", + "10.0.0.2", + ] + + tags { + type = ["prod", "webservers"] + region = ["us-east-1"] + } + + # HCP Boundary only + # hcp_boundary_cluster_id = "....." +} +``` + +- `public_addr` - Specifies the public host or IP address (and optionally port) + where clients can reach the worker for proxying. By default, it uses the + address of the listener marked for `proxy` purpose. This is useful for cloud + environments that do not bind a publicly accessible IP directly to a NIC on + the host, such as an Amazon EIP. + + You should omit this parameter in multi-hop configurations if this self-managed worker connects to an upstream HCP-managed worker. + + This value can reference any of the following: + - a direct address string + - read an address from a file on disk (file://) + - read an address from an environment variable (env://) + +- `initial_upstreams` - A list of hosts/IP addresses and optionally ports for + reaching the Boundary cluster. The port will default to `:9201` if not + specified. This value can be a direct access string array with the addresses, + or it can refer to a file on disk (`file://`) from which the addresses will be + read, or an environment variable (`env://`) from which to read the addresses. When + using environment variable or file, their contents must formatted as a JSON array: + `["127.0.0.1", "192.168.0.1", "10.0.0.1"]` + + Self-managed workers connecting to HCP Boundary require the [`hcp_boundary_cluster_id`](/boundary/docs/configuration/worker/#hcp_boundary_cluster_id) parameter instead of `initial upstreams`, unless you are configuring an HCP-managed worker as an ingress worker. + If you configure a self-managed worker with both `initial_upstreams` and `hcp_boundary_cluster_id`, the worker configuration fails. + +- `hcp_boundary_cluster_id` - A string required to configure workers using worker-led or controller-led registration + to connect to your HCP Boundary cluster rather than specifying +`initial_upstreams`. This parameter is valid only for workers using the worker-led or controller-led + registration method and for workers directly connected to HCP Boundary. + +- `recording_storage_path` - A path to the local storage for recorded sessions. + Boundary stores session recordings in the local storage while they are in progress. + When the session is complete, Boundary moves the local session recording to remote storage and deletes the local copy. + +- `recording_storage_minimum_available_capacity` - A value measured in bytes that + defines the worker's local storage state. Boundary compares this value to the available local disk space found in the `recording_storage_path` and determines if a worker can perform session recording operations. + The supported suffixes are kb, kib, mb, mib, gb, gib, tb, tib, which are not case sensitive. Example: 2GB, 2gb, 2GiB, 2gib. + The possible storage states based on the `recording_storage_minimum_available_capacity` are: + - Available - The worker has storage above the threshold and can proxy sessions that have session recording enabled. + - Low storage - The worker has storage below the threshold. It allows existing sessions to continue without interruption but prevents proxying new sessions that have session recording enabled. The worker cannot record new sessions or play back existing recordings. + - Critically low storage - The worker falls below half the storage threshold. It forcefully closes existing sessions with session recording. The worker cannot record new sessions or play back existing recordings. + - Out of storage - The worker is out of local disk space. It cannot record new sessions or play back existing recordings. The worker enters an unrecoverable state, requiring an administrator to intervene and resolve the issue. + - Not configured - The worker lacks a configured local storage path. + - Unknown - The worker starts with this default local storage state. This state indicates that the worker's local storage state is not yet known. + +- `tags` - A map of key-value pairs where values are an array of strings. Most + commonly used for [filtering](/boundary/docs/filtering) targets a + worker can proxy via [worker + tags](/boundary/docs/workers/worker-tags). On `SIGHUP`, the tags + set here will be re-parsed and new values used. It can also be a string + referring to a file on disk (`file://`) or an environment variable (`env://`). diff --git a/website/content/partials/configuration-reference/workers/complete-configuration-example.mdx b/website/content/partials/configuration-reference/workers/complete-configuration-example.mdx new file mode 100644 index 000000000..1f9711037 --- /dev/null +++ b/website/content/partials/configuration-reference/workers/complete-configuration-example.mdx @@ -0,0 +1,43 @@ +```hcl +listener "tcp" { + purpose = "proxy" + tls_disable = true + address = "127.0.0.1" +} + +worker { + # Path for worker storage, assuming worker-led or controller-led registration. Must be unique across workers + auth_storage_path="/boundary/demo-worker-1" + + # Local storage path required if session recording is enabled + recording_storage_path = "tmp/boundary/" + + # Minimum available disk space required in the local storage path if session recording is enabled + recording_storage_minimum_available_capacity = "500MB" + + # Workers typically need to reach upstreams on :9201 + initial_upstreams = [ + "10.0.0.1", + "10.0.0.2", + "10.0.0.3", + ] + + public_addr = "myhost.mycompany.com" + + tags { + type = ["prod", "webservers"] + region = ["us-east-1"] + } +} + +# The following KMS config is an example only +# Use a production KMS such as AWS KMS for production installs +kms "aead" { + purpose = "worker-auth-storage" + aead_type = "aes-gcm" + key = "X+IJMVT6OnsrIR6G/9OTcJSX+lM9FSPN" + key_id = "worker-auth-storage" +} + + +``` \ No newline at end of file diff --git a/website/content/partials/workers/egress-worker-config.mdx b/website/content/partials/workers/egress-worker-config.mdx new file mode 100644 index 000000000..5ebe243e3 --- /dev/null +++ b/website/content/partials/workers/egress-worker-config.mdx @@ -0,0 +1,102 @@ +Create the `egress-worker.hcl` file with the relevant configuration information: + + + +```hcl +# disable memory from being swapped to disk +disable_mlock = true + +# listener denoting this is a worker proxy +listener "tcp" { + address = "0.0.0.0:9202" + purpose = "proxy" +} + +# worker block for configuring the specifics of the +# worker service +worker { + public_addr = "" + initial_upstreams = [":9202"] + auth_storage_path = "/var/lib/boundary" + tags { + type = ["worker3", "egress"] + } +} + +# Events (logging) configuration. This +# configures logging for ALL events to both +# stderr and a file at /var/log/boundary/.log +events { + audit_enabled = true + sysevents_enabled = true + observations_enable = true + sink "stderr" { + name = "all-events" + description = "All events sent to stderr" + event_types = ["*"] + format = "cloudevents-json" + } + sink { + name = "file-sink" + description = "All events sent to a file" + event_types = ["*"] + format = "cloudevents-json" + file { + path = "/var/log/boundary" + file_name = "egress-worker.log" + } + audit_config { + audit_filter_overrides { + sensitive = "redact" + secret = "redact" + } + } + } +} + +# kms block for encrypting the authentication PKI material +kms "awskms" { + purpose = "worker-auth-storage" + region = "us-east-1" + kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey5" + endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" +} +``` + + + +Refer to the list below for explanations of the parameters used in the example above: + +- `disable mlock (bool: false)` - Disables the server from executing the `mlock` syscall, which prevents memory from being swapped to the disk. +This is fine for local development and testing. +However, it is not recommended for production unless the systems running Boundary use only encrypted swap or do not use swap at all. +Boundary only supports memory locking on UNIX-like systems that support `mlock()` syscall like Linux and FreeBSD. + + On Linux, to give the Boundary executable the ability to use `mlock` syscall without running the process as root, run the following command: + + `sudo setcap cap_ipc_lock=+ep $(readlink -f $(which boundary))` + + If you use a Linux distribution with a modern version of systemd, you can add the following directive to the **"[Service]"** configuration section: + + `LimitMEMLOCK=infinity` + +- `listener` - Configures the listeners on which Boundary serves traffic (API cluster and proxy). +- `worker` - Configures the worker. +If present, `boundary server` starts a worker subprocess. +- `events` - Configures event-specific parameters. + + The example events configuration above is exhaustive and writes all events to both `stderr` and a file. + This configuration may or may not work for your organization's logging solution. + +- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/secure/encryption/data-encryption). + + Refer to the links below for configuration information for the different cloud KMS blocks: + + - [AWS](/boundary/docs/configuration/kms/awskms) + - [Azure](/boundary/docs/configuration/kms/azurekeyvault) + - [GCP](/boundary/docs/configuration/kms/gcpckms) + - [OCI](/boundary/docs/configuration/kms/ocikms) + - [AliCloud](/boundary/docs/configuration/kms/alicloudkms) + - [Vault Transit](/boundary/docs/configuration/kms/transit) + +Refer to the documentation for additional [top-level configuration options](/boundary/docs/configuration) and additional [worker-specific options](/boundary/docs/configuration/workers). \ No newline at end of file diff --git a/website/content/partials/workers/ingress-worker-config.mdx b/website/content/partials/workers/ingress-worker-config.mdx new file mode 100644 index 000000000..499e27759 --- /dev/null +++ b/website/content/partials/workers/ingress-worker-config.mdx @@ -0,0 +1,66 @@ +Create the `ingress-worker.hcl` file with the relevant configuration information: + + + +```hcl +# disable memory from being swapped to disk +disable_mlock = true + +# listener denoting this is a worker proxy +listener "tcp" { + address = "0.0.0.0:9202" + purpose = "proxy" +} + +# worker block for configuring the specifics of the +# worker service +worker { + public_addr = "" + initial_upstreams = [":9201"] + auth_storage_path = "/var/lib/boundary" + tags { + type = ["worker1", "upstream"] + } +} + +# Events (logging) configuration. This +# configures logging for ALL events to both +# stderr and a file at /var/log/boundary/.log +events { + audit_enabled = true + sysevents_enabled = true + observations_enable = true + sink "stderr" { + name = "all-events" + description = "All events sent to stderr" + event_types = ["*"] + format = "cloudevents-json" + } + sink { + name = "file-sink" + description = "All events sent to a file" + event_types = ["*"] + format = "cloudevents-json" + file { + path = "/var/log/boundary" + file_name = "ingress-worker.log" + } + audit_config { + audit_filter_overrides { + sensitive = "redact" + secret = "redact" + } + } + } +} + +# kms block for encrypting the authentication PKI material +kms "awskms" { + purpose = "worker-auth-storage" + region = "us-east-1" + kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey3" + endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" +} +``` + + \ No newline at end of file diff --git a/website/content/partials/workers/intermediate-worker-config.mdx b/website/content/partials/workers/intermediate-worker-config.mdx new file mode 100644 index 000000000..10c4d2ef3 --- /dev/null +++ b/website/content/partials/workers/intermediate-worker-config.mdx @@ -0,0 +1,66 @@ +Create the `intermediate-worker.hcl` file with the relevant configuration information: + + + +```hcl +# disable memory from being swapped to disk +disable_mlock = true + +# listener denoting this is a worker proxy +listener "tcp" { + address = "0.0.0.0:9202" + purpose = "proxy" +} + +# worker block for configuring the specifics of the +# worker service +worker { + public_addr = "" + initial_upstreams = [":9202"] + auth_storage_path = "/var/lib/boundary" + tags { + type = ["worker2", "intermediate"] + } +} + +# Events (logging) configuration. This +# configures logging for ALL events to both +# stderr and a file at /var/log/boundary/.log +events { + audit_enabled = true + sysevents_enabled = true + observations_enable = true + sink "stderr" { + name = "all-events" + description = "All events sent to stderr" + event_types = ["*"] + format = "cloudevents-json" + } + sink { + name = "file-sink" + description = "All events sent to a file" + event_types = ["*"] + format = "cloudevents-json" + file { + path = "/var/log/boundary" + file_name = "intermediate-worker.log" + } + audit_config { + audit_filter_overrides { + sensitive = "redact" + secret = "redact" + } + } + } +} + +# kms block for encrypting the authentication PKI material +kms "awskms" { + purpose = "worker-auth-storage" + region = "us-east-1" + kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey4" + endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" +} +``` + + \ No newline at end of file diff --git a/website/content/partials/workers/single-worker-config.mdx b/website/content/partials/workers/single-worker-config.mdx new file mode 100644 index 000000000..f61fe2771 --- /dev/null +++ b/website/content/partials/workers/single-worker-config.mdx @@ -0,0 +1,102 @@ +Create the `egress-worker.hcl` file with the relevant configuration information: + + + +```hcl +# disable memory from being swapped to disk +disable_mlock = true + +# listener denoting this is a worker proxy +listener "tcp" { + address = "0.0.0.0:9202" + purpose = "proxy" +} + +# worker block for configuring the specifics of the +# worker service +worker { + public_addr = "" + initial_upstreams = [":9201"] + auth_storage_path = "/var/lib/boundary" + tags { + type = ["worker", "egress"] + } +} + +# Events (logging) configuration. This +# configures logging for ALL events to both +# stderr and a file at /var/log/boundary/.log +events { + audit_enabled = true + sysevents_enabled = true + observations_enable = true + sink "stderr" { + name = "all-events" + description = "All events sent to stderr" + event_types = ["*"] + format = "cloudevents-json" + } + sink { + name = "file-sink" + description = "All events sent to a file" + event_types = ["*"] + format = "cloudevents-json" + file { + path = "/var/log/boundary" + file_name = "egress-worker.log" + } + audit_config { + audit_filter_overrides { + sensitive = "redact" + secret = "redact" + } + } + } +} + +# kms block for encrypting the authentication PKI material +kms "awskms" { + purpose = "worker-auth-storage" + region = "us-east-1" + kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey5" + endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" +} +``` + + + +Refer to the list below for explanations of the parameters used in the example above: + +- `disable mlock (bool: false)` - Disables the server from executing the `mlock` syscall, which prevents memory from being swapped to the disk. +This is fine for local development and testing. +However, it is not recommended for production unless the systems running Boundary use only encrypted swap or do not use swap at all. +Boundary only supports memory locking on UNIX-like systems that support `mlock()` syscall like Linux and FreeBSD. + + On Linux, to give the Boundary executable the ability to use `mlock` syscall without running the process as root, run the following command: + + `sudo setcap cap_ipc_lock=+ep $(readlink -f $(which boundary))` + + If you use a Linux distribution with a modern version of systemd, you can add the following directive to the **"[Service]"** configuration section: + + `LimitMEMLOCK=infinity` + +- `listener` - Configures the listeners on which Boundary serves traffic (API cluster and proxy). +- `worker` - Configures the worker. +If present, `boundary server` starts a worker subprocess. +- `events` - Configures event-specific parameters. + + The example events configuration above is exhaustive and writes all events to both `stderr` and a file. + This configuration may or may not work for your organization's logging solution. + +- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/secure/encryption/data-encryption). + + Refer to the links below for configuration information for the different cloud KMS blocks: + + - [AWS](/boundary/docs/configuration/kms/awskms) + - [Azure](/boundary/docs/configuration/kms/azurekeyvault) + - [GCP](/boundary/docs/configuration/kms/gcpckms) + - [OCI](/boundary/docs/configuration/kms/ocikms) + - [AliCloud](/boundary/docs/configuration/kms/alicloudkms) + - [Vault Transit](/boundary/docs/configuration/kms/transit) + +Refer to the documentation for additional [top-level configuration options](/boundary/docs/configuration) and additional [worker-specific options](/boundary/docs/configuration/workers). \ No newline at end of file diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index b59e7b495..535d032ac 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -1,55 +1,53 @@ [ { - "title": "Introduction", + "heading": "Get started" + }, + { + "title": "What is Boundary?", + "path": "what-is-boundary" + }, + { + "title": "Why choose Boundary?", "routes": [ - { - "title": "What is Boundary?", - "path": "overview/what-is-boundary" - }, { "title": "Use cases", "path": "overview/use-cases" }, { - "title": "Boundary vs. other software", - "routes": [ - { - "title": "Overview", - "path": "overview/vs/other-software" - }, - { - "title": "Zero trust", - "path": "overview/vs/zero-trust" - }, - { - "title": "Bastion hosts", - "path": "overview/vs/bastion-hosts" - }, - { - "title": "VPNs", - "path": "overview/vs/vpn" - }, - { - "title": "Privileged access management", - "path": "overview/vs/pam" - }, - { - "title": "Software-defined perimeter", - "path": "overview/vs/sdp" - }, - { - "title": "Secrets management tools", - "path": "overview/vs/secrets-management" - } - ] + "title": "Zero trust", + "path": "overview/zero-trust" + }, + { + "title": "Bastion hosts", + "path": "overview/bastion-hosts" + }, + { + "title": "VPNs", + "path": "overview/vpn" + }, + { + "title": "Privileged access management", + "path": "overview/pam" + }, + { + "title": "Software-defined perimeter", + "path": "overview/sdp" + }, + { + "title": "Secrets management tools", + "path": "overview/secrets-management" + }, + { + "title": "Frequently asked questions", + "path": "overview/faq" } ] }, { - "title": "Get started", + "title": "Quickstart", "routes": [ { - "title": "Overview", + "title": "Get started", "path": "getting-started" }, { @@ -65,7 +63,7 @@ "routes": [ { "title": "Overview", - "path": "getting-started/dev-mode/dev-mode" + "path": "getting-started/dev-mode" }, { "title": "Run and log in", @@ -80,112 +78,11 @@ ] }, { - "title": "Install Boundary", + "title": "Key concepts", "routes": [ { - "title": "Overview", - "path": "install-boundary" - }, - { - "title": "Architecture", - "routes": [ - { - "title": "System requirements", - "path": "install-boundary/architecture/system-requirements" - }, - { - "title": "Recommended architecture", - "path": "install-boundary/architecture/recommended-architecture" - }, - { - "title": "Fault tolerance", - "path": "install-boundary/architecture/fault-tolerance" - }, - { - "title": "High availability", - "path": "install-boundary/architecture/high-availability" - } - ] - }, - { - "title": "Deploy Boundary", - "path": "install-boundary/deploy" - }, - { - "title": "Configure controllers", - "path": "install-boundary/configure-controllers" - }, - { - "title": "Configure workers", - "path": "install-boundary/configure-workers" - }, - { - "title": "Initialize Boundary", - "path": "install-boundary/initialize" - }, - { - "title": "Install Boundary clients", - "path": "install-boundary/install-clients" - }, - { - "title": "Systemd install", - "hidden": true, - "path": "install-boundary/systemd" - }, - { - "title": "Terraform patterns", - "routes": [ - { - "title": "Overview", - "path": "install-boundary/terraform-patterns" - }, - { - "title": "Scopes", - "path": "install-boundary/terraform-patterns/terraform-scopes" - }, - { - "title": "Users and auth methods", - "path": "install-boundary/terraform-patterns/terraform-users-and-auth-methods" - }, - { - "title": "Groups and RBAC", - "path": "install-boundary/terraform-patterns/terraform-groups-and-rbac" - }, - { - "title": "Hosts and host management", - "path": "install-boundary/terraform-patterns/terraform-hosts-and-host-management" - }, - { - "title": "Credentials and credential stores", - "path": "install-boundary/terraform-patterns/terraform-credentials-and-credential-stores" - }, - { - "title": "Session recording", - "badge": { - "text": "HCP/ENT", - "type": "outlined", - "color": "neutral" - }, - "path": "install-boundary/terraform-patterns/terraform-session-recording" - }, - { - "title": "Targets", - "path": "install-boundary/terraform-patterns/terraform-targets" - } - ] - } - ] - }, - { - "title": "Concepts", - "routes": [ - { - "title": "Overview", - "path": "concepts" - }, - { - "title": "Workers", - "path": "concepts/workers" + "title": "Auditing", + "path": "concepts/auditing" }, { "title": "Identity and access management", @@ -195,6 +92,10 @@ "title": "Credential management", "path": "concepts/credential-management" }, + { + "title": "Workers", + "path": "concepts/workers" + }, { "title": "Aliases", "path": "concepts/aliases" @@ -207,51 +108,307 @@ "color": "neutral" }, "path": "concepts/transparent-sessions" + } + ] + }, + { + "title": "Architecture", + "routes": [ + { + "title": "System requirements", + "path": "architecture/system-requirements" }, { - "title": "Auditing", - "path": "concepts/auditing" + "title": "Recommended architecture", + "path": "architecture/recommended-architecture" }, { - "title": "Host discovery", + "title": "Fault tolerance", + "path": "architecture/fault-tolerance" + }, + { + "title": "High availability", + "path": "architecture/high-availability" + } + ] + }, + { + "divider": true + }, + { + "heading": "Boundary operations" + }, + { + "title": "Deploy Boundary", + "routes": [ + { + "title": "In a self-managed environment", "routes": [ { "title": "Overview", - "path": "concepts/host-discovery" + "path": "deploy/self-managed" }, { - "title": "AWS dynamic hosts", - "path": "concepts/host-discovery/aws" + "title": "Install Boundary", + "path": "deploy/self-managed/install" }, { - "title": "Azure dynamic hosts", - "path": "concepts/host-discovery/azure" + "title": "Configure controllers", + "path": "deploy/self-managed/configure-controllers" }, { - "title": "GCP dynamic hosts", - "path": "concepts/host-discovery/gcp" + "title": "Deploy workers", + "path": "deploy/self-managed/deploy-workers" + }, + { + "title": "Initialize Boundary", + "path": "deploy/self-managed/initialize" + }, + { + "title": "Install Boundary clients", + "path": "deploy/self-managed/install-clients" + }, + { + "title": "Systemd install", + "hidden": true, + "path": "deploy/self-managed/systemd" } ] }, { - "title": "Connection workflows", + "title": "On HashiCorp Cloud Platform (HCP)", + "href": "hcp/get-started/deploy-and-login" + }, + { + "title": "Using Terraform", "routes": [ { "title": "Overview", - "path": "concepts/connection-workflows" + "path": "deploy/terraform-patterns" }, { - "title": "Connect helpers", - "path": "concepts/connection-workflows/connect-helpers" + "title": "Configure scopes", + "path": "deploy/terraform-patterns/terraform-scopes" }, { - "title": "Exec flag", - "path": "concepts/connection-workflows/exec-flag" + "title": "Configure users and auth methods", + "path": "deploy/terraform-patterns/terraform-users-and-auth-methods" }, { - "title": "SSH ProxyCommand", - "path": "concepts/connection-workflows/workflow-ssh-proxycommand" + "title": "Configure groups and RBAC", + "path": "deploy/terraform-patterns/terraform-groups-and-rbac" }, + { + "title": "Configure hosts and host management", + "path": "deploy/terraform-patterns/terraform-hosts-and-host-management" + }, + { + "title": "Configure credentials and credential stores", + "path": "deploy/terraform-patterns/terraform-credentials-and-credential-stores" + }, + { + "title": "Configure session recording", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + }, + "path": "deploy/terraform-patterns/terraform-session-recording" + }, + { + "title": "Configure targets", + "path": "deploy/terraform-patterns/terraform-targets" + } + ] + } + ] + }, + { + "title": "Secure Boundary", + "routes": [ + { + "title": "Encrypt resources", + "routes": [ + { + "title": "Data encryption", + "path": "secure/encryption/data-encryption" + }, + { + "title": "Connections/TLS", + "path": "secure/encryption/connections-tls" + } + ] + } + ] + }, + { + "title": "Monitor Boundary", + "routes": [ + { + "title": "Overview", + "path": "monitor" + }, + { + "title": "Configure listener addresses and ports", + "routes": [ + { + "title": "Listeners", + "path": "monitor/listeners" + }, + { + "title": "TCP listeners", + "path": "monitor/listeners/tcp" + }, + { + "title": "Unix listeners", + "path": "monitor/listeners/unix" + } + ] + }, + { + "title": "Monitor metrics", + "path": "monitor/metrics" + }, + { + "title": "Monitor health", + "path": "monitor/health" + }, + { + "title": "Monitor events", + "routes": [ + { + "title": "Filter events", + "path": "monitor/events/filter-events" + }, + { + "title": "Events parameters", + "path": "monitor/events/events" + }, + { + "title": "Common sink parameters", + "path": "monitor/events/common" + }, + { + "title": "File sink", + "path": "monitor/events/file" + }, + { + "title": "Stderr sink", + "path": "monitor/events/stderr" + } + ] + } + ] + }, + { + "title": "Upgrade Boundary", + "href": "https://developer.hashicorp.com/boundary/tutorials/self-managed-deployment/upgrade-version" + }, + { + "title": "Release notes", + "routes": [ + { + "title": "v0.19.0", + "path": "release-notes/v0_19_0" + }, + { + "title": "v0.18.0", + "path": "release-notes/v0_18_0" + }, + { + "title": "v0.17.0", + "path": "release-notes/v0_17_0" + }, + { + "title": "v0.16.0", + "path": "release-notes/v0_16_0" + }, + { + "title": "v0.15.0", + "path": "release-notes/v0_15_0" + }, + { + "title": "v0.14.0", + "path": "release-notes/v0_14_0" + }, + { + "title": "v0.13.0", + "path": "release-notes/v0_13_0" + }, + { + "title": "v0.12.0", + "path": "release-notes/v0_12_0" + }, + { + "title": "v0.11.0", + "path": "release-notes/v0_11_0" + }, + { + "title": "v0.10.0", + "path": "release-notes/v0_10_0" + }, + { + "title": "v0.9.0", + "path": "release-notes/v0_9_0" + }, + { + "title": "v0.8.0", + "path": "release-notes/v0_8_0" + }, + { + "title": "v0.7.0", + "path": "release-notes/v0_7_0" + }, + { + "title": "v0.6.0", + "path": "release-notes/v0_6_0" + }, + { + "title": "v0.5.0", + "path": "release-notes/v0_5_0" + }, + { + "title": "v0.4.0", + "path": "release-notes/v0_4_0" + }, + { + "title": "v0.3.0", + "path": "release-notes/v0_3_0" + }, + { + "title": "v0.2.0", + "path": "release-notes/v0_2_0" + }, + { + "title": "v0.1.0", + "path": "release-notes/v0_1_0" + } + ] + }, + { + "divider": true + }, + { + "heading": "Secure access" + }, + { + "title": "Configure workers", + "routes": [ + { + "title": "Overview", + "path": "workers" + }, + { + "title": "Create the worker configuration", + "path": "workers/create" + }, + { + "title": "Register workers", + "path": "workers/registration" + }, + { + "title": "Configure multi-hop sessions", + "routes": [ { "title": "Multi-hop sessions", "badge": { @@ -259,352 +416,106 @@ "type": "outlined", "color": "neutral" }, - "path": "concepts/connection-workflows/multi-hop" - } - ] - }, - { - "title": "Security", - "routes": [ - { - "title": "Overview", - "path": "concepts/security" + "path": "workers/multi-hop" }, { - "title": "Data encryption", - "path": "concepts/security/data-encryption" - }, - { - "title": "Connections/TLS", - "path": "concepts/security/connections-tls" - } - ] - }, - { - "title": "Domain model", - "routes": [ - { - "title": "Overview", - "path": "concepts/domain-model" - }, - { - "title": "Accounts", - "path": "concepts/domain-model/accounts" - }, - { - "title": "Aliases", - "path": "concepts/domain-model/aliases" - }, - { - "title": "Auth methods", - "path": "concepts/domain-model/auth-methods" - }, - { - "title": "Credentials", - "path": "concepts/domain-model/credentials" - }, - { - "title": "Credential libraries", - "path": "concepts/domain-model/credential-libraries" - }, - { - "title": "Credential stores", - "path": "concepts/domain-model/credential-stores" - }, - { - "title": "Groups", - "path": "concepts/domain-model/groups" - }, - { - "title": "Hosts", - "path": "concepts/domain-model/hosts" - }, - { - "title": "Host catalogs", - "path": "concepts/domain-model/host-catalogs" - }, - { - "title": "Host sets", - "path": "concepts/domain-model/host-sets" - }, - { - "title": "Managed groups", - "path": "concepts/domain-model/managed-groups" - }, - { - "title": "Scopes", - "path": "concepts/domain-model/scopes" - }, - { - "title": "Sessions", - "path": "concepts/domain-model/sessions" - }, - { - "title": "Session connections", - "path": "concepts/domain-model/session-connections" - }, - { - "title": "Session recordings", + "title": "On Boundary Enterprise", "badge": { "text": "HCP/ENT", "type": "outlined", "color": "neutral" }, - "path": "concepts/domain-model/session-recordings" + "path": "workers/multi-hop/enterprise" }, { - "title": "Storage buckets", + "title": "On HashiCorp Cloud Platform (HCP)", "badge": { "text": "HCP/ENT", "type": "outlined", "color": "neutral" }, - "path": "concepts/domain-model/storage-buckets" - }, - { - "title": "Storage policies", - "badge": { - "text": "HCP/ENT", - "type": "outlined", - "color": "neutral" - }, - "path": "concepts/domain-model/storage-policy" - }, - { - "title": "Targets", - "path": "concepts/domain-model/targets" - }, - { - "title": "Roles", - "path": "concepts/domain-model/roles" - }, - { - "title": "Users", - "path": "concepts/domain-model/users" + "path": "workers/multi-hop/hcp" } ] }, { - "title": "Filtering", - "routes": [ - { - "title": "Overview", - "path": "concepts/filtering" - }, - { - "title": "Managed groups", - "path": "concepts/filtering/managed-groups" - }, - { - "title": "Resource listing", - "path": "concepts/filtering/resource-listing" - }, - { - "title": "Worker tags", - "path": "concepts/filtering/worker-tags" - }, - { - "title": "Events", - "path": "concepts/filtering/events" - } - ] + "title": "Route traffic through a worker", + "path": "workers/worker-tags" + }, + { + "title": "Configure a worker filter", + "path": "workers/filters" } ] }, { - "title": "Configuration", + "title": "Configure hosts", "routes": [ { - "title": "Overview/top-level parameters", - "path": "configuration" + "title": "Host discovery", + "path": "hosts" }, { - "title": "Worker", - "routes": [ - { - "title": "Overview", - "path": "configuration/worker" - }, - { - "title": "Configuration", - "path": "configuration/worker/worker-configuration" - } - ] + "title": "Sync AWS hosts", + "path": "hosts/aws" }, { - "title": "Listener", - "routes": [ - { - "title": "Overview", - "path": "configuration/listener" - }, - { - "title": "TCP", - "path": "configuration/listener/tcp" - }, - { - "title": "Unix", - "path": "configuration/listener/unix" - } - ] + "title": "Sync Azure hosts", + "path": "hosts/azure" }, { - "title": "KMS", - "routes": [ - { - "title": "Overview", - "path": "configuration/kms" - }, - { - "title": "AEAD", - "path": "configuration/kms/aead" - }, - { - "title": "AWS KMS", - "path": "configuration/kms/awskms" - }, - { - "title": "AliCloud KMS", - "path": "configuration/kms/alicloudkms" - }, - { - "title": "Azure Key Vault", - "path": "configuration/kms/azurekeyvault" - }, - { - "title": "GCP Cloud KMS", - "path": "configuration/kms/gcpckms" - }, - { - "title": "OCI KMS", - "path": "configuration/kms/ocikms" - }, - { - "title": "Vault transit", - "path": "configuration/kms/transit" - } - ] - }, + "title": "Sync GCP hosts", + "path": "hosts/gcp" + } + ] + }, + { + "title": "Configure targets", + "routes": [ { - "title": "Credential management", + "title": "Set up a target", "routes": [ { - "title": "Overview", - "path": "configuration/credential-management" + "title": "Aliases", + "path": "targets/configuration" }, { - "title": "Create a static credential store", - "path": "configuration/credential-management/static-cred-boundary" + "title": "Create a target alias", + "path": "targets/configuration/create-target-alias" }, { - "title": "Create a Vault credential store", - "path": "configuration/credential-management/static-cred-vault" - }, - { - "title": "Configure targets with credential brokering", - "path": "configuration/credential-management/configure-credential-brokering" - }, - { - "title": "Configure targets with credential injection", - "path": "configuration/credential-management/configure-credential-injection", + "title": "Configure transparent sessions", "badge": { "text": "HCP/ENT", "type": "outlined", "color": "neutral" - } + }, + "path": "targets/configuration/configure-transparent-sessions" } ] }, { - "title": "Identity and access management", + "title": "Connect to a target", "routes": [ { - "title": "Overview", - "path": "configuration/identity-access-management" + "title": "Connection workflows", + "path": "targets/connections" }, { - "title": "Assignable permissions", - "path": "configuration/identity-access-management/assignable-permissions" + "title": "Connect helpers", + "path": "targets/connections/connect-helpers" }, { - "title": "Permission grant formats", - "path": "configuration/identity-access-management/permission-grant-formats" + "title": "Exec flag", + "path": "targets/connections/exec-flag" }, { - "title": "Manage roles", - "href": "common-workflows/manage-roles" - }, - { - "title": "Resource table", - "path": "configuration/identity-access-management/resource-table" - } - ] - }, - { - "title": "Session recordings", - "badge": { - "text": "HCP/ENT", - "type": "outlined", - "color": "neutral" - }, - "routes": [ - { - "title": "Overview", - "path": "configuration/session-recording" - }, - { - "title": "Configure workers for storage", - "path": "configuration/session-recording/configure-worker-storage" - }, - { - "title": "Configure storage provider", - "routes": [ - { - "title": "Amazon S3", - "path": "configuration/session-recording/storage-providers/configure-s3" - }, - { - "title": "MinIO", - "path": "configuration/session-recording/storage-providers/configure-minio" - }, - { - "title": "S3-compliant", - "path": "configuration/session-recording/storage-providers/configure-s3-compliant" - } - ] - }, - { - "title": "Create storage buckets", - "path": "configuration/session-recording/create-storage-bucket" - }, - { - "title": "Enable session recording", - "path": "configuration/session-recording/enable-session-recording" - }, - { - "title": "Configure storage policies", - "path": "configuration/session-recording/configure-storage-policy" - }, - { - "title": "Update storage policies", - "path": "configuration/session-recording/update-storage-policy" - } - ] - }, - { - "title": "Aliases and transparent sessions", - "routes": [ - { - "title": "Overview", - "path": "configuration/target-aliases" - }, - { - "title": "Create a target alias", - "path": "configuration/target-aliases/create-target-alias" + "title": "SSH ProxyCommand", + "path": "targets/connections/workflow-ssh-proxycommand" }, { "title": "Connect using a target alias", - "path": "configuration/target-aliases/connect-target-alias" + "path": "targets/connections/connect-target-alias" }, { "title": "Connect using transparent sessions", @@ -613,107 +524,34 @@ "type": "outlined", "color": "neutral" }, - "path": "configuration/target-aliases/transparent-sessions" - }, - { - "title": "Transparent sessions interoperability matrix", - "badge": { - "text": "HCP/ENT", - "type": "outlined", - "color": "neutral" - }, - "path": "configuration/target-aliases/interoperability-matrix" - } - ] - }, - { - "title": "Events", - "routes": [ - { - "title": "Overview", - "path": "configuration/events" - }, - { - "title": "Common sink parameters", - "path": "configuration/events/common" - }, - { - "title": "File sink", - "path": "configuration/events/file" - }, - { - "title": "Stderr sink", - "path": "configuration/events/stderr" - } - ] - }, - { - "title": "Controller", - "path": "configuration/controller" - }, - { - "title": "Plugins", - "path": "configuration/plugins" - } - ] - }, - { - "title": "Operations", - "routes": [ - { - "title": "Overview", - "path": "operations" - }, - { - "title": "Metrics", - "path": "operations/metrics" - }, - { - "title": "Health endpoint", - "path": "operations/health" - }, - { - "title": "Session recordings", - "badge": { - "text": "HCP/ENT", - "type": "outlined", - "color": "neutral" - }, - "routes": [ - { - "title": "Overview", - "path": "operations/session-recordings" - }, - { - "title": "Find and view recorded sessions", - "path": "operations/session-recordings/manage-recorded-sessions" - }, - { - "title": "Validate recorded sessions", - "path": "operations/session-recordings/validate-session-recordings" - }, - { - "title": "Validate external data store", - "path": "operations/session-recordings/validate-data-store" + "path": "targets/connections/transparent-sessions" } ] } ] }, { - "title": "Troubleshoot", + "title": "Configure credentials", "routes": [ { - "title": "Common error messages", - "path": "troubleshoot/common-errors" + "title": "Credentials in Boundary", + "path": "credentials" }, { - "title": "FAQ", - "path": "troubleshoot/faq" + "title": "Create a static credential store", + "path": "credentials/static-cred-boundary" }, { - "title": "Recorded sessions", - "path": "troubleshoot/troubleshoot-recorded-sessions", + "title": "Create a Vault credential store", + "path": "credentials/static-cred-vault" + }, + { + "title": "Configure targets with credential brokering", + "path": "credentials/configure-credential-brokering" + }, + { + "title": "Configure targets with credential injection", + "path": "credentials/configure-credential-injection", "badge": { "text": "HCP/ENT", "type": "outlined", @@ -723,32 +561,416 @@ ] }, { - "title": "Common workflows", - "hidden": true, + "title": "Monitor access", + "routes": [ + { + "title": "Session recording", + "path": "session-recording", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Record and play back session activity", + "routes": [ + { + "title": "Configure workers for storage", + "path": "session-recording/configuration/configure-worker-storage", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Configure storage provider", + "routes": [ + { + "title": "Amazon S3", + "path": "session-recording/configuration/storage-providers/configure-s3", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "MinIO", + "path": "session-recording/configuration/storage-providers/configure-minio", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "S3-compliant", + "path": "session-recording/configuration/storage-providers/configure-s3-compliant", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + }, + { + "title": "Create storage buckets", + "path": "session-recording/configuration/create-storage-bucket", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Enable session recording", + "path": "session-recording/configuration/enable-session-recording", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Find and view recorded sessions", + "path": "session-recording/configuration/manage-recorded-sessions", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Troubleshoot recorded sessions", + "path": "session-recording/configuration/troubleshoot-recorded-sessions", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + }, + { + "title": "Implement session recording compliance standards", + "routes": [ + { + "title": "Configure storage policies", + "path": "session-recording/compliance/configure-storage-policy", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Update storage policies", + "path": "session-recording/compliance/update-storage-policy", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Validate recorded sessions", + "path": "session-recording/compliance/validate-session-recordings", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Validate external data store", + "path": "session-recording/compliance/validate-data-store", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + }, + { + "title": "Work with BSR data files", + "routes": [ + { + "title": "BSR file data structure", + "path": "session-recording/data/bsr-file-structure", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Read a BSR file", + "path": "session-recording/data/read-bsr-file", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + } + ] + }, + { + "title": "Configure role-based access", + "routes": [ + { + "title": "Permissions", + "path": "rbac" + }, + { + "title": "Assignable permissions", + "path": "rbac/assignable-permissions" + }, + { + "title": "Permission grant formats", + "path": "rbac/permission-grant-formats" + }, + { + "title": "Manage access with roles", + "path": "rbac/manage-roles" + }, + { + "title": "Resource tables", + "path": "rbac/resource-table" + }, + { + "title": "Manage access to resources dynamically", + "routes": [ + { + "title": "Manage principals", + "path": "rbac/users/manage-users-groups" + }, + { + "title": "Filter managed groups", + "path": "rbac/users/managed-groups" + } + ] + } + ] + }, + { + "divider": true + }, + { + "heading": "Integrations" + }, + { + "title": "Vault", + "path": "vault" + }, + { + "divider": true + }, + { + "heading": "Enterprise solutions" + }, + { + "title": "HCP Boundary", "routes": [ { "title": "Overview", - "path": "common-workflows" + "path": "hcp", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } }, { - "title": "Manage roles", - "path": "common-workflows/manage-roles" + "title": "Get started", + "routes": [ + { + "title": "Deploy and log in", + "path": "hcp/get-started/deploy-and-login", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Connect to a target", + "path": "hcp/get-started/connect-to-target", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] }, { - "title": "Manage scopes", - "path": "common-workflows/manage-scopes" + "title": "Documentation", + "href": "https://cloud.hashicorp.com/docs/boundary", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + }, + { + "title": "Boundary Enterprise", + "routes": [ + { + "title": "Overview", + "path": "enterprise", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } }, { - "title": "Manage sessions", - "path": "common-workflows/manage-sessions" + "title": "Licensing", + "path": "enterprise/licensing", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } }, { - "title": "Manage targets", - "path": "common-workflows/manage-targets" + "title": "Automated license reporting", + "path": "enterprise/automated-license-reporting", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } }, { - "title": "Manage users and groups", - "path": "common-workflows/manage-users-groups" + "title": "Supported versions policy", + "path": "enterprise/supported-versions", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Deployment guide", + "href": "https://developer.hashicorp.com/boundary/tutorials/enterprise/ent-deployment-guide", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Reference architecture", + "href": "https://developer.hashicorp.com/boundary/tutorials/enterprise/ent-reference-architecture", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + }, + { + "divider": true + }, + { + "heading": "Clients" + }, + { + "title": "Client Agent", + "routes": [ + { + "title": "Overview", + "path": "client-agent", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Configure the Client Agent", + "path": "client-agent/configuration", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Manage the Client Agent", + "path": "client-agent/manage", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Troubleshoot issues", + "path": "client-agent/troubleshoot", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + }, + { + "title": "Conflicting software", + "path": "client-agent/conflicting-software", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + } + } + ] + }, + { + "title": "Client cache", + "path": "client-cache" + }, + { + "title": "Desktop", + "href": "https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-desktop-app" + }, + { + "title": "Go SDK", + "path": "go-sdk" + }, + { + "divider": true + }, + { + "heading": "Reference documentation" + }, + { + "title": "API", + "routes": [ + { + "title": "Overview", + "path": "api" + }, + { + "title": "Rate limiting", + "path": "api/rate-limiting" + }, + { + "title": "List pagination", + "path": "api/pagination" + }, + { + "title": "API documentation", + "href": "https://developer.hashicorp.com/boundary/api-docs" } ] }, @@ -995,6 +1217,10 @@ "title": "Overview", "path": "commands/connect" }, + { + "title": "cassandra", + "path": "commands/connect/cassandra" + }, { "title": "http", "path": "commands/connect/http" @@ -1007,10 +1233,6 @@ "title": "mysql", "path": "commands/connect/mysql" }, - { - "title": "cassandra", - "path": "commands/connect/cassandra" - }, { "title": "postgres", "path": "commands/connect/postgres" @@ -1705,72 +1927,263 @@ ] }, { - "title": "API and clients", + "title": "Domain model", "routes": [ { "title": "Overview", - "path": "api-clients" + "path": "domain-model" }, { - "title": "API", - "routes": [ - { - "title": "Overview", - "path": "api-clients/api" - }, - { - "title": "Rate limiting", - "path": "api-clients/api/rate-limiting" - }, - { - "title": "List pagination", - "path": "api-clients/api/pagination" - } - ] + "title": "Accounts", + "path": "domain-model/accounts" }, { - "title": "Client Agent", + "title": "Aliases", + "path": "domain-model/aliases" + }, + { + "title": "Auth methods", + "path": "domain-model/auth-methods" + }, + { + "title": "Credentials", + "path": "domain-model/credentials" + }, + { + "title": "Credential libraries", + "path": "domain-model/credential-libraries" + }, + { + "title": "Credential stores", + "path": "domain-model/credential-stores" + }, + { + "title": "Groups", + "path": "domain-model/groups" + }, + { + "title": "Hosts", + "path": "domain-model/hosts" + }, + { + "title": "Host catalogs", + "path": "domain-model/host-catalogs" + }, + { + "title": "Host sets", + "path": "domain-model/host-sets" + }, + { + "title": "Managed groups", + "path": "domain-model/managed-groups" + }, + { + "title": "Roles", + "path": "domain-model/roles" + }, + { + "title": "Scopes", + "path": "domain-model/scopes" + }, + { + "title": "Sessions", + "path": "domain-model/sessions" + }, + { + "title": "Session connections", + "path": "domain-model/session-connections" + }, + { + "title": "Session recordings", "badge": { "text": "HCP/ENT", "type": "outlined", "color": "neutral" }, - "path": "api-clients/client-agent" + "path": "domain-model/session-recordings" }, { - "title": "Go SDK", - "path": "api-clients/go-sdk" + "title": "Storage buckets", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + }, + "path": "domain-model/storage-buckets" + }, + { + "title": "Storage policies", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + }, + "path": "domain-model/storage-policy" + }, + { + "title": "Targets", + "path": "domain-model/targets" + }, + { + "title": "Users", + "path": "domain-model/users" + } + ] + }, + { + "title": "Configuration parameters", + "routes": [ + { + "title": "Top-level parameters", + "path": "configuration" + }, + { + "title": "Controllers", + "path": "configuration/controller" + }, + { + "title": "Events", + "routes": [ + { + "title": "Events", + "path": "configuration/events" + }, + { + "title": "Common sink parameters", + "path": "configuration/events/common-sink-parameters" + }, + { + "title": "File sink", + "path": "configuration/events/file-sink" + }, + { + "title": "Stderr sink", + "path": "configuration/events/stderr-sink" + } + ] + }, + { + "title": "KMS", + "routes": [ + { + "title": "Overview", + "path": "configuration/kms" + }, + { + "title": "AEAD", + "path": "configuration/kms/aead" + }, + { + "title": "AliCloud KMS", + "path": "configuration/kms/alicloudkms" + }, + { + "title": "AWS KMS", + "path": "configuration/kms/awskms" + }, + { + "title": "Azure Key Vault", + "path": "configuration/kms/azurekeyvault" + }, + { + "title": "GCP Cloud KMS", + "path": "configuration/kms/gcpckms" + }, + { + "title": "OCI KMS", + "path": "configuration/kms/ocikms" + }, + { + "title": "Vault transit", + "path": "configuration/kms/transit" + } + ] + }, + { + "title": "Listeners", + "routes": [ + { + "title": "Overview", + "path": "configuration/listeners" + }, + { + "title": "TCP", + "path": "configuration/listeners/tcp-listeners" + }, + { + "title": "Unix", + "path": "configuration/listeners/unix-listeners" + } + ] + }, + { + "title": "Plugins", + "path": "configuration/plugins" + }, + { + "title": "Workers", + "path": "configuration/workers" + } + ] + }, + { + "title": "Filtering and listing resources", + "path": "filtering" + }, + { + "title": "Common error messages", + "path": "errors" + }, + { + "title": "Transparent sessions interoperability matrix", + "badge": { + "text": "HCP/ENT", + "type": "outlined", + "color": "neutral" + }, + "path": "interoperability-matrix" + }, + { + "title": "Common workflows", + "hidden": true, + "routes": [ + { + "title": "Overview", + "path": "common-workflows" + }, + { + "title": "Manage scopes", + "path": "common-workflows/manage-scopes" + }, + { + "title": "Manage sessions", + "path": "common-workflows/manage-sessions" + }, + { + "title": "Manage targets", + "path": "common-workflows/manage-targets" + } + ] + }, + { + "title": "API and clients", + "hidden": true, + "routes": [ + { + "title": "Overview", + "hidden": true, + "path": "api-clients" }, { "title": "Desktop", "hidden": true, "path": "api-clients/desktop" - }, - { - "title": "Desktop", - "href": "https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-desktop-app" - }, - { - "title": "Client cache", - "path": "api-clients/client-cache" - } - ] - }, - { - "title": "Integrations", - "routes": [ - { - "title": "Overview", - "path": "integrations" - }, - { - "title": "Vault", - "path": "integrations/vault" } ] }, { "title": "Develop Boundary", + "hidden": true, "routes": [ { "title": "Overview", @@ -1786,9 +2199,6 @@ } ] }, - { - "divider": true - }, { "title": "Boundary Community Edition", "hidden": true, @@ -1798,143 +2208,5 @@ "path": "community" } ] - }, - { - "title": "HCP Boundary", - "routes": [ - { - "title": "Overview", - "path": "hcp" - }, - { - "title": "Get started", - "routes": [ - { - "title": "Deploy and login", - "path": "hcp/get-started/deploy-and-login" - }, - { - "title": "Connect to target", - "path": "hcp/get-started/connect-to-target" - } - ] - }, - { - "title": "Documentation", - "href": "https://cloud.hashicorp.com/docs/boundary/" - } - ] - }, - { - "divider": true - }, - { - "title": "Boundary Enterprise", - "routes": [ - { - "title": "Overview", - "path": "enterprise" - }, - { - "title": "Licensing", - "path": "enterprise/licensing" - }, - { - "title": "Automated license reporting", - "path": "enterprise/automated-license-reporting" - }, - { - "title": "Supported versions policy", - "path": "enterprise/supported-versions" - } - ] - }, - { - "divider": true - }, - { - "title": "Release notes", - "routes": [ - { - "title": "Overview", - "path": "release-notes" - }, - { - "title": "v0.19.0", - "path": "release-notes/v0_19_0" - }, - { - "title": "v0.18.0", - "path": "release-notes/v0_18_0" - }, - { - "title": "v0.17.0", - "path": "release-notes/v0_17_0" - }, - { - "title": "v0.16.0", - "path": "release-notes/v0_16_0" - }, - { - "title": "v0.15.0", - "path": "release-notes/v0_15_0" - }, - { - "title": "v0.14.0", - "path": "release-notes/v0_14_0" - }, - { - "title": "v0.13.0", - "path": "release-notes/v0_13_0" - }, - { - "title": "v0.12.0", - "path": "release-notes/v0_12_0" - }, - { - "title": "v0.11.0", - "path": "release-notes/v0_11_0" - }, - { - "title": "v0.10.0", - "path": "release-notes/v0_10_0" - }, - { - "title": "v0.9.0", - "path": "release-notes/v0_9_0" - }, - { - "title": "v0.8.0", - "path": "release-notes/v0_8_0" - }, - { - "title": "v0.7.0", - "path": "release-notes/v0_7_0" - }, - { - "title": "v0.6.0", - "path": "release-notes/v0_6_0" - }, - { - "title": "v0.5.0", - "path": "release-notes/v0_5_0" - }, - { - "title": "v0.4.0", - "path": "release-notes/v0_4_0" - }, - { - "title": "v0.3.0", - "path": "release-notes/v0_3_0" - }, - { - "title": "v0.2.0", - "path": "release-notes/v0_2_0" - }, - { - "title": "v0.1.0", - "path": "release-notes/v0_1_0" - } - ] } -] \ No newline at end of file +] diff --git a/website/redirects.js b/website/redirects.js index cecf9cd74..af6081fa1 100644 --- a/website/redirects.js +++ b/website/redirects.js @@ -8,13 +8,39 @@ module.exports = [ // vercel's redirect documentation: https://vercel.com/docs/project-configuration#project-configuration/redirects // example redirect: // { - // source: '/boundary/docs/some/path', - // destination: '/boundary/docs/some/other/path', - // permanent: true, + // "source": "/boundary/docs/some/path", + // "destination": "/boundary/docs/some/other/path", + // "permanent": true, // }, { - source: '/boundary/docs/what-is-boundary', - destination: '/boundary/docs/overview/what-is-boundary', + source: '/boundary/docs/overview/what-is-boundary', + destination: '/boundary/docs/what-is-boundary', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/what-is-boundary', + destination: '/boundary/docs/:version/overview/what-is-boundary', + permanent: true, + }, + { + source: '/boundary/docs/concepts/index', + destination: '/boundary/docs/what-is-boundary', + permanent: true, + }, + { + source: '/boundary/docs/roadmap', + destination: '/boundary/docs/what-is-boundary', + permanent: true, + }, + { + source: '/boundary/docs/oss', + destination: '/boundary/docs/what-is-boundary', + permanent: true, + }, + { + source: '/boundary/docs/community', + destination: '/boundary/docs/what-is-boundary', permanent: true, }, { @@ -23,18 +49,90 @@ module.exports = [ permanent: true, }, { - source: '/boundary/docs/roadmap', - destination: 'boundary/docs/overview/what-is-boundary', + source: '/boundary/docs/:version(v0\\.(?:10)\\.x)/overview/use-cases', + destination: '/boundary/docs/:version/use-cases', permanent: true, }, { - source: '/boundary/docs/getting-started/connect-to-target', - destination: '/boundary/docs/hcp/get-started/connect-to-target', + source: '/boundary/docs/overview/vs/other-software', + destination: '/boundary/docs/overview/use-cases', permanent: true, }, { - source: '/boundary/docs/getting-started/deploy-and-login', - destination: '/boundary/docs/hcp/get-started/deploy-and-login', + source: '/boundary/docs/overview/vs/zero-trust', + destination: '/boundary/docs/overview/zero-trust', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/overview/zero-trust', + destination: '/boundary/docs/:version/overview/vs/zero-trust', + permanent: true, + }, + { + source: '/boundary/docs/overview/vs/bastion-hosts', + destination: '/boundary/docs/overview/bastion-hosts', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/overview/bastion-hosts', + destination: '/boundary/docs/:version/overview/vs/bastion-hosts', + permanent: true, + }, + { + source: '/boundary/docs/overview/vs/vpn', + destination: '/boundary/docs/overview/vpn', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/overview/vpn', + destination: '/boundary/docs/:version/overview/vs/vpn', + permanent: true, + }, + { + source: '/boundary/docs/overview/vs/pam', + destination: '/boundary/docs/overview/pam', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/overview/pam', + destination: '/boundary/docs/:version/overview/vs/pam', + permanent: true, + }, + { + source: '/boundary/docs/overview/vs/sdp', + destination: '/boundary/docs/overview/sdp', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/overview/sdp', + destination: '/boundary/docs/:version/overview/vs/sdp', + permanent: true, + }, + { + source: '/boundary/docs/overview/vs/secrets-management', + destination: '/boundary/docs/overview/secrets-management', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:11|12|13|14|15|16|17|18)\\.x)/overview/secrets-management', + destination: '/boundary/docs/:version/overview/vs/secrets-management', + permanent: true, + }, + { + source: '/boundary/docs/troubleshoot/faq', + destination: '/boundary/docs/overview/faq', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:12|13|14|15|16|17|18)\\.x)/overview/faq', + destination: '/boundary/docs/:version/troubleshoot/faq', permanent: true, }, { @@ -47,6 +145,450 @@ module.exports = [ destination: '/boundary/docs/getting-started', permanent: true, }, + { + source: '/boundary/docs/oss/installing/dev-mode', + destination: '/boundary/docs/getting-started/dev-mode', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/getting-started/dev-mode', + destination: '/boundary/docs/:version/oss/installing/dev-mode', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/getting-started/dev-mode', + destination: '/boundary/docs/:version/getting-started/dev-mode/dev-mode', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/run-and-login', + destination: '/boundary/docs/getting-started/dev-mode/run-and-login', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/getting-started/dev-mode/run-and-login', + destination: '/boundary/docs/:version/oss/installing/run-and-login', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/connect-to-dev-target', + destination: + '/boundary/docs/getting-started/dev-mode/connect-to-dev-target', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/getting-started/dev-mode/connect-to-dev-target', + destination: '/boundary/docs/:version/oss/installing/connect-to-dev-target', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/system-requirements', + destination: '/boundary/docs/architecture/system-requirements', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14)\\.x)/architecture/system-requirements', + destination: '/boundary/docs/:version/install-boundary/system-requirements', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/architecture/system-requirements', + destination: '/boundary/docs/architecture/system-requirements', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/architecture/system-requirements', + destination: + '/boundary/docs/:version/install-boundary/architecture/system-requirements', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/postgres', + destination: '/boundary/docs/architecture/system-requirements', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/postgres', + destination: '/boundary/docs/architecture/system-requirements', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/architecture/recommended-architecture', + destination: '/boundary/docs/architecture/recommended-architecture', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/architecture/recommended-architecture', + destination: + '/boundary/docs/:version/install-boundary/architecture/recommended-architecture', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/reference-architectures', + destination: '/boundary/docs/architecture/recommended-architecture', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/architecture/recommended-architecture', + destination: + '/boundary/docs/:version/oss/installing/reference-architectures', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/recommended-architecture', + destination: '/boundary/docs/architecture/recommended-architecture', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14)\\.x)/architecture/recommended-architecture', + destination: + '/boundary/docs/:version/install-boundary/recommended-architecture', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/architecture/fault-tolerance', + destination: '/boundary/docs/architecture/fault-tolerance', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/architecture/fault-tolerance', + destination: + '/boundary/docs/:version/install-boundary/architecture/fault-tolerance', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/fault-tolerance', + destination: '/boundary/docs/architecture/fault-tolerance', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14)\\.x)/architecture/fault-tolerance', + destination: '/boundary/docs/:version/install-boundary/fault-tolerance', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/architecture/high-availability', + destination: '/boundary/docs/architecture/high-availability', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/architecture/high-availability', + destination: + '/boundary/docs/:version/install-boundary/architecture/high-availability', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/high-availability', + destination: '/boundary/docs/architecture/high-availability', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/architecture/high-availability', + destination: '/boundary/docs/:version/oss/installing/high-availability', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8)\\.x)/architecture/high-availability', + destination: '/boundary/docs/:version/installing/high-availability', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/high-availability', + destination: '/boundary/docs/architecture/high-availability', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14)\\.x)/architecture/high-availability', + destination: '/boundary/docs/:version/install-boundary/high-availability', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary', + destination: '/boundary/docs/deploy/self-managed', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/deploy/self-managed', + destination: '/boundary/docs/:version/install-boundary', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/install', + destination: '/boundary/docs/deploy/self-managed/install', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17)\\.x)/deploy/self-managed/install', + destination: '/boundary/docs/:version/install-boundary/install', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/deploy', + destination: '/boundary/docs/deploy/self-managed/install', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:18)\\.x)/deploy/self-managed/install', + destination: '/boundary/docs/:version/install-boundary/deploy', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/self-managed/deploy', + destination: '/boundary/docs/deploy/self-managed/install', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/configure-controllers', + destination: '/boundary/docs/deploy/self-managed/configure-controllers', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/deploy/self-managed/configure-controllers', + destination: + '/boundary/docs/:version/install-boundary/configure-controllers', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/configure-workers', + destination: '/boundary/docs/deploy/self-managed/deploy-workers', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/deploy/self-managed/deploy-workers', + destination: '/boundary/docs/:version/install-boundary/configure-workers', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/initialize', + destination: '/boundary/docs/deploy/self-managed/initialize', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/self-managed/initialize', + destination: '/boundary/docs/:version/install-boundary/initialize', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/no-gen-resources', + destination: '/boundary/docs/deploy/self-managed/initialize', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/deploy/self-managed/initialize', + destination: '/boundary/docs/:version/oss/installing/no-gen-resources', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/no-gen-resources', + destination: '/boundary/docs/deploy/self-managed/initialize', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14)\\.x)/deploy/self-managed/initialize', + destination: '/boundary/docs/:version/install-boundary/no-gen-resources', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8)\\.x)/deploy/self-managed/initialize', + destination: '/boundary/docs/:version/installing/no-gen-resources', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/install-clients', + destination: '/boundary/docs/deploy/self-managed/install-clients', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:18)\\.x)/deploy/self-managed/install-clients', + destination: '/boundary/docs/:version/install-boundary/install-clients', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/self-managed/install-clients', + destination: '/boundary/docs/deploy/self-managed/install-clients', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/systemd', + destination: '/boundary/docs/deploy/self-managed/systemd', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/self-managed/systemd', + destination: '/boundary/docs/deploy/self-managed/systemd', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing/systemd', + destination: '/boundary/docs/deploy/self-managed/systemd', + permanent: true, + }, + { + source: '/boundary/docs/oss/installing', + destination: '/boundary/docs/deploy', + permanent: true, + }, + { + source: '/boundary/docs/getting-started/connect-to-target', + destination: '/boundary/docs/hcp/get-started/connect-to-target', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/hcp/get-started/connect-to-target', + destination: '/boundary/docs/:version/getting-started/connect-to-target', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8)\\.x)/targets/connections', + destination: '/boundary/docs/:version/getting-started/connect-to-target', + permanent: true, + }, + { + source: '/boundary/docs/getting-started/deploy-and-login', + destination: '/boundary/docs/hcp/get-started/deploy-and-login', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/hcp/get-started/deploy-and-login', + destination: '/boundary/docs/:version/getting-started/deploy-and-login', + permanent: true, + }, + { + source: '/boundary/docs/install-boundary/terraform-patterns', + destination: '/boundary/docs/deploy/terraform-patterns', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns', + destination: '/boundary/docs/:version/install-boundary/terraform-patterns', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores', + destination: + '/boundary/docs/deploy/terraform-patterns/terraform-credentials-and-credential-stores', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns/terraform-credentials-and-credential-stores', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-credentials-and-credential-stores', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-groups-and-rbac', + destination: + '/boundary/docs/deploy/terraform-patterns/terraform-groups-and-rbac', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns/terraform-groups-and-rbac', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-groups-and-rbac', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-hosts-and-host-management', + destination: + '/boundary/docs/deploy/terraform-patterns/terraform-hosts-and-host-management', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns/terraform-hosts-and-host-management', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-hosts-and-host-management', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-scopes', + destination: '/boundary/docs/deploy/terraform-patterns/terraform-scopes', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns/terraform-scopes', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-scopes', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-session-recording', + destination: + '/boundary/docs/deploy/terraform-patterns/terraform-session-recording', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns/terraform-session-recording', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-session-recording', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-targets', + destination: '/boundary/docs/deploy/terraform-patterns/terraform-targets', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-pattern/terraform-targets', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-targets', + permanent: true, + }, + { + source: + '/boundary/docs/install-boundary/terraform-patterns/terraform-users-and-auth-methods', + destination: + '/boundary/docs/deploy/terraform-patterns/terraform-users-and-auth-methods', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/deploy/terraform-patterns/terraform-users-and-auth-methods', + destination: + '/boundary/docs/:version/install-boundary/terraform-patterns/terraform-users-and-auth-methods', + permanent: true, + }, { source: '/boundary/docs/oss/developing/building', destination: '/boundary/docs/developing/building', @@ -63,120 +605,876 @@ module.exports = [ permanent: true, }, { - source: '/boundary/docs/oss/installing/connect-to-dev-target', - destination: - '/boundary/docs/getting-started/dev-mode/connect-to-dev-target', + source: '/boundary/docs/concepts/security/data-encryption', + destination: '/boundary/docs/secure/encryption/data-encryption', permanent: true, }, { - source: '/boundary/docs/oss/installing/dev-mode', - destination: '/boundary/docs/getting-started/dev-mode/dev-mode', + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/secure/encryption/data-encryption', + destination: '/boundary/docs/:version/concepts/security/data-encryption', permanent: true, }, { - source: '/boundary/docs/oss/installing/run-and-login', - destination: '/boundary/docs/getting-started/dev-mode/run-and-login', + source: '/boundary/docs/concepts/security', + destination: '/boundary/docs/secure/encryption/data-encryption', permanent: true, }, { - source: '/boundary/docs/oss/operations/health', - destination: '/boundary/docs/operations/health', + source: '/boundary/docs/concepts/security/connections-tls', + destination: '/boundary/docs/secure/encryption/connections-tls', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/secure/encryption/connections-tls', + destination: '/boundary/docs/:version/concepts/security/connections-tls', permanent: true, }, { source: '/boundary/docs/oss/operations', - destination: '/boundary/docs/operations', + destination: '/boundary/docs/monitor', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/monitor', + destination: '/boundary/docs/:version/oss/operations', + permanent: true, + }, + { + source: '/boundary/docs/operations', + destination: '/boundary/docs/monitor', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/monitor', + destination: '/boundary/docs/:version/operations', + permanent: true, + }, + { + source: '/boundary/docs/configuration/listener', + destination: '/boundary/docs/monitor/listeners', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/listeners', + destination: '/boundary/docs/:version/configuration/listener', + permanent: true, + }, + { + source: '/boundary/docs/configuration/listener/tcp', + destination: '/boundary/docs/monitor/listeners/tcp', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/listeners/tcp', + destination: '/boundary/docs/:version/configuration/listener/tcp', + permanent: true, + }, + { + source: '/boundary/docs/configuration/listener/unix', + destination: '/boundary/docs/monitor/listeners/unix', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/listeners/unix', + destination: '/boundary/docs/:version/configuration/listener/unix', permanent: true, }, { source: '/boundary/docs/oss/operations/metrics', - destination: '/boundary/docs/operations/metrics', + destination: '/boundary/docs/monitor/metrics', permanent: true, }, { - source: '/boundary/docs/install-boundary/install', - destination: '/boundary/docs/install-boundary/deploy', + source: '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/monitor/metrics', + destination: '/boundary/docs/:version/oss/operations/metrics', permanent: true, }, { - source: '/boundary/docs/install-boundary/fault-tolerance', - destination: '/boundary/docs/install-boundary/architecture/fault-tolerance', + source: '/boundary/docs/operations/metrics', + destination: '/boundary/docs/monitor/metrics', permanent: true, }, { - source: '/boundary/docs/oss/installing/high-availability', - destination: '/boundary/docs/install-boundary/architecture/high-availability', + source: + '/boundary/docs/:version(v0\\.(?:8|13|14|15|16|17|18)\\.x)/monitor/metrics', + destination: '/boundary/docs/:version/operations/metrics', permanent: true, }, { - source: '/boundary/docs/install-boundary/high-availability', - destination: '/boundary/docs/install-boundary/architecture/high-availability', + source: '/boundary/docs/operations/health', + destination: '/boundary/docs/monitor/health', permanent: true, }, { - source: '/boundary/docs/oss/installing', - destination: '/boundary/docs/install-boundary', + source: + '/boundary/docs/:version(v0\\.(?:8|13|14|15|16|17|18)\\.x)/monitor/health', + destination: '/boundary/docs/:version/operations/health', permanent: true, }, { - source: '/boundary/docs/oss/installing/no-gen-resources', - destination: '/boundary/docs/install-boundary/no-gen-resources', + source: '/boundary/docs/oss/operations/health', + destination: '/boundary/docs/monitor/health', permanent: true, }, { - source: '/boundary/docs/install-boundary/no-gen-resources', - destination: '/boundary/docs/install-boundary/initialize', + source: '/boundary/docs/:version(v0\\.(?:9|10|11|12)\\.x)/monitor/health', + destination: '/boundary/docs/:version/oss/operations/health', permanent: true, }, { - source: '/boundary/docs/oss/installing/postgres', - destination: '/boundary/docs/install-boundary/architecture/system-requirements', + source: '/boundary/docs/configuration/events', + destination: '/boundary/docs/monitor/events/events', permanent: true, }, { - source: '/boundary/docs/install-boundary/postgres', - destination: '/boundary/docs/install-boundary/architecture/system-requirements', + source: + '/boundary/docs/:version(v0\\.(?:10|11|12|13|14|15|16|17|18)\\.x)/monitor/events/events', + destination: '/boundary/docs/:version/configuration/events', permanent: true, }, { - source: '/boundary/docs/install-boundary/system-requirements', - destination: '/boundary/docs/install-boundary/architecture/system-requirements', + source: + '/boundary/docs/:version(v0\\.(?:5|6|7|8|9)\\.x)/monitor/events/events', + destination: '/boundary/docs/:version/configuration/events/overview', permanent: true, }, { - source: '/boundary/docs/oss/installing/reference-architectures', - destination: '/boundary/docs/install-boundary/architecture/recommended-architecture', + source: '/boundary/docs/concepts/filtering/events', + destination: '/boundary/docs/monitor/events/filter-events', permanent: true, }, { - source: '/boundary/docs/install-boundary/recommended-architecture', - destination: 'boundary/docs/install-boundary/architecture/recommended-architecture', + source: + '/boundary/docs/:version(v0\\.(?:5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/events/filter-events', + destination: '/boundary/docs/:version/concepts/filtering/events', permanent: true, }, { - source: '/boundary/docs/oss/installing/systemd', - destination: '/boundary/docs/install-boundary/systemd', + source: '/boundary/docs/configuration/events/common', + destination: '/boundary/docs/monitor/events/common', permanent: true, }, { - source: '/boundary/docs/oss', - destination: '/boundary/docs/community', + source: + '/boundary/docs/:version(v0\\.(?:5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/events/common', + destination: '/boundary/docs/:version/configuration/events/common', + permanent: true, + }, + { + source: '/boundary/docs/configuration/events/file', + destination: '/boundary/docs/monitor/events/file', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/events/file', + destination: '/boundary/docs/:version/configuration/events/file', + permanent: true, + }, + { + source: '/boundary/docs/configuration/events/stderr', + destination: '/boundary/docs/monitor/events/stderr', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/monitor/events/stderr', + destination: '/boundary/docs/:version/configuration/events/stderr', + permanent: true, + }, + { + source: '/boundary/docs/release-notes', + destination: '/boundary/docs', + permanent: true, + }, + { + source: '/boundary/docs/configuration/worker', + destination: '/boundary/docs/workers', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|10|11|12|13|14|15|16|17|18)\\.x)/workers', + destination: '/boundary/docs/:version/configuration/worker', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:9)\\.x)/workers', + destination: '/boundary/docs/:version/configuration/worker/overview', + permanent: true, + }, + { + source: '/boundary/docs/configuration/worker/worker-configuration', + destination: '/boundary/docs/workers/registration', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/workers/registration', + destination: + '/boundary/docs/:version/configuration/worker/worker-configuration', + permanent: true, + }, + { + source: '/boundary/docs/configuration/worker/kms-worker', + destination: '/boundary/docs/workers/registration', + permanent: true, + }, + { + source: '/boundary/docs/configuration/worker/pki-worker', + destination: '/boundary/docs/workers/registration', + permanent: true, + }, + { + source: '/boundary/docs/concepts/connection-workflows/multi-hop', + destination: '/boundary/docs/workers/multi-hop', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/workers/multi-hop', + destination: + '/boundary/docs/:version/concepts/connection-workflows/multi-hop', + permanent: true, + }, + { + source: '/boundary/docs/concepts/filtering/worker-tags', + destination: '/boundary/docs/workers/worker-tags', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/workers/worker-tags', + destination: '/boundary/docs/:version/concepts/filtering/worker-tags', permanent: true, }, { source: '/boundary/docs/concepts/service-discovery', - destination: '/boundary/docs/concepts/host-discovery', + destination: '/boundary/docs/hosts', permanent: true, }, { - source: '/boundary/docs/operations/manage-recorded-sessions', - destination: '/boundary/docs/operations/session-recordings', + source: '/boundary/docs/:version(v0\\.(?:8|9|10|11|12)\\.x)/hosts', + destination: '/boundary/docs/:version/concepts/service-discovery', + permanent: true, + }, + { + source: '/boundary/docs/concepts/host-discovery', + destination: '/boundary/docs/hosts', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/hosts', + destination: '/boundary/docs/:version/concepts/host-discovery', + permanent: true, + }, + { + source: '/boundary/docs/concepts/host-discovery/aws', + destination: '/boundary/docs/hosts/aws', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/hosts/aws', + destination: '/boundary/docs/:version/concepts/host-discovery/aws', + permanent: true, + }, + { + source: '/boundary/docs/concepts/host-discovery/azure', + destination: '/boundary/docs/hosts/azure', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/hosts/azure', + destination: '/boundary/docs/:version/concepts/host-discovery/azure', + permanent: true, + }, + { + source: '/boundary/docs/concepts/host-discovery/gcp', + destination: '/boundary/docs/hosts/gcp', + permanent: true, + }, + { + source: '/boundary/docs/configuration/target-aliases', + destination: '/boundary/docs/targets/configuration', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:18)\\.x)/targets/configuration', + destination: '/boundary/docs/:version/configuration/target-aliases', + permanent: true, + }, + { + source: '/boundary/docs/configuration/target-aliases/connect-target-alias', + destination: '/boundary/docs/targets/connections/connect-target-alias', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:18)\\.x)/targets/connections/connect-target-alias', + destination: + '/boundary/docs/:version/configuration/target-aliases/connect-target-alias', + permanent: true, + }, + { + source: '/boundary/docs/configuration/target-aliases/create-target-alias', + destination: '/boundary/docs/targets/configuration/create-target-alias', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:18)\\.x)/targets/configuration/create-target-alias', + destination: + '/boundary/docs/:version/configuration/target-aliases/create-target-alias', + permanent: true, + }, + { + source: '/boundary/docs/configuration/target-aliases/transparent-sessions', + destination: + '/boundary/docs/targets/configuration/configure-transparent-sessions', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:18)\\.x)/targets/configuration/configure-transparent-sessions', + destination: + '/boundary/docs/:version/configuration/target-aliases/transparent-sessions', + permanent: true, + }, + { + source: '/boundary/docs/concepts/connection-workflows', + destination: '/boundary/docs/targets/connections', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/targets/connections', + destination: '/boundary/docs/:version/concepts/connection-workflows', + permanent: true, + }, + { + source: '/boundary/docs/concepts/connection-workflows/connect-helpers', + destination: '/boundary/docs/targets/connections/connect-helpers', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/targets/connections/connect-helpers', + destination: + '/boundary/docs/:version/concepts/connection-workflows/connect-helpers', + permanent: true, + }, + { + source: '/boundary/docs/concepts/connection-workflows/exec-flag', + destination: '/boundary/docs/targets/connections/exec-flag', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/targets/connections/exec-flag', + destination: + '/boundary/docs/:version/concepts/connection-workflows/exec-flag', permanent: true, }, { source: '/boundary/docs/common-workflows/workflow-ssh-proxycommand', - destination: + destination: '/boundary/docs/targets/connections/workflow-ssh-proxycommand', + permanent: true, + }, + { + source: '/boundary/docs/concepts/connection-workflows/workflow-ssh-proxycommand', + destination: '/boundary/docs/targets/connections/workflow-ssh-proxycommand', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/targets/connections/workflow-ssh-proxycommand', + destination: + '/boundary/docs/:version/concepts/connection-workflows/workflow-ssh-proxycommand', + permanent: true, + }, + { + source: '/boundary/docs/configuration/credential-management', + destination: '/boundary/docs/credentials', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/credentials', + destination: '/boundary/docs/:version/configuration/credential-management', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/credential-management/configure-credential-brokering', + destination: '/boundary/docs/credentials/configure-credential-brokering', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/credentials/configure-credential-brokering', + destination: + '/boundary/docs/:version/configuration/credential-management/configure-credential-brokering', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/credential-management/configure-credential-injection', + destination: '/boundary/docs/credentials/configure-credential-injection', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/credentials/configure-credential-injection', + destination: + '/boundary/docs/:version/configuration/credential-management/configure-credential-injection', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/credential-management/static-cred-boundary', + destination: '/boundary/docs/credentials/static-cred-boundary', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/credentials/static-cred-boundary', + destination: + '/boundary/docs/:version/configuration/credential-management/static-cred-boundary', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/credential-management/static-cred-vault', + destination: '/boundary/docs/credentials/static-cred-vault', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/credentials/static-cred-vault', + destination: + '/boundary/docs/:version/configuration/credential-management/static-cred-vault', + permanent: true, + }, + { + source: '/boundary/docs/configuration/session-recording', + destination: '/boundary/docs/session-recording', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/session-recording', + destination: '/boundary/docs/:version/configuration/session-recording', + permanent: true, + }, + { + source: '/boundary/docs/operations/session-recordings', + destination: '/boundary/docs/session-recording', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/configure-worker-storage', + destination: + '/boundary/docs/session-recording/configuration/configure-worker-storage', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:16|17|18)\\.x)/session-recording/configuration/configure-worker-storage', + destination: + '/boundary/docs/:version/configuration/session-recording/configure-worker-storage', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15)\\.x)/session-recording/configuration/configure-worker-storage', + destination: + '/boundary/docs/:version/configuration/session-recording/create-storage-bucket', + permanent: true, + }, + { + source: '/boundary/docs/configuration/session-recording/storage-providers', + destination: + '/boundary/docs/session-recording/configuration/storage-providers', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/storage-providers/configure-s3', + destination: + '/boundary/docs/session-recording/configuration/storage-providers/configure-s3', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:16|17|18)\\.x)/session-recording/configuration/storage-providers/configure-s3', + destination: + '/boundary/docs/:version/configuration/session-recording/storage-providers/configure-s3', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/storage-providers/configure-minio', + destination: + '/boundary/docs/session-recording/configuration/storage-providers/configure-minio', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:16|17|18)\\.x)/session-recording/configuration/storage-providers/configure-minio', + destination: + '/boundary/docs/:version/configuration/session-recording/storage-providers/configure-minio', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/storage-providers/configure-s3-compliant', + destination: + '/boundary/docs/session-recording/configuration/storage-providers/configure-s3-compliant', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:17|18)\\.x)/session-recording/configuration/storage-providers/configure-s3-compliant', + destination: + '/boundary/docs/:version/configuration/session-recording/storage-providers/configure-s3-compliant', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/create-storage-bucket', + destination: + '/boundary/docs/session-recording/configuration/create-storage-bucket', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/session-recording/configuration/create-storage-bucket', + destination: + '/boundary/docs/:version/configuration/session-recording/create-storage-bucket', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/enable-session-recording', + destination: + '/boundary/docs/session-recording/configuration/enable-session-recording', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/session-recording/configuration/enable-session-recording', + destination: + '/boundary/docs/:version/configuration/session-recording/enable-session-recording', + permanent: true, + }, + { + source: + '/boundary/docs/operations/session-recordings/manage-recorded-sessions', + destination: + '/boundary/docs/session-recording/configuration/manage-recorded-sessions', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/session-recording/configuration/manage-recorded-sessions', + destination: + '/boundary/docs/:version/operations/session-recordings/manage-recorded-sessions', + permanent: true, + }, + { + source: '/boundary/docs/troubleshoot/troubleshoot-recorded-sessions', + destination: + '/boundary/docs/session-recording/configuration/troubleshoot-recorded-sessions', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/session-recording/configuration/troubleshoot-recorded-sessions', + destination: + '/boundary/docs/:version/troubleshoot/troubleshoot-recorded-sessions', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/configure-storage-policy', + destination: + '/boundary/docs/session-recording/compliance/configure-storage-policy', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/session-recording/compliance/configure-storage-policy', + destination: + '/boundary/docs/:version/configuration/session-recording/configure-storage-policy', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/session-recording/update-storage-policy', + destination: + '/boundary/docs/session-recording/compliance/update-storage-policy', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/session-recording/compliance/update-storage-policy', + destination: + '/boundary/docs/:version/configuration/session-recording/update-storage-policy', + permanent: true, + }, + { + source: '/boundary/docs/operations/session-recordings/validate-data-store', + destination: + '/boundary/docs/session-recording/compliance/validate-data-store', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/session-recording/compliance/validate-data-store', + destination: + '/boundary/docs/:version/operations/session-recordings/validate-data-store', + permanent: true, + }, + { + source: + '/boundary/docs/operations/session-recordings/validate-session-recordings', + destination: + '/boundary/docs/session-recording/compliance/validate-session-recordings', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:14|15|16|17|18)\\.x)/session-recording/compliance/validate-session-recordings', + destination: + '/boundary/docs/:version/operations/session-recordings/validate-session-recordings', + permanent: true, + }, + { + source: '/boundary/docs/configuration/identity-access-management', + destination: '/boundary/docs/rbac', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:17|18)\\.x)/rbac', + destination: + '/boundary/docs/:version/configuration/identity-access-management', + permanent: true, + }, + { + source: '/boundary/docs/concepts/security/permissions', + destination: '/boundary/docs/rbac', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|1|14|15|16)\\.x)/rbac', + destination: '/boundary/docs/:version/concepts/security/permissions', + permanent: true, + }, + { + source: + '/boundary/docs/concepts/security/permissions/assignable-permissions', + destination: '/boundary/docs/rbac/assignable-permissions', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:8|9|10|11|12|1|14|15|16)\\.x)/rbac/assignable-permissions', + destination: + '/boundary/docs/:version/concepts/security/permissions/assignable-permissions', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/identity-access-management/assignable-permissions', + destination: '/boundary/docs/rbac/assignable-permissions', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:17|18)\\.x)/rbac/assignable-permissions', + destination: + '/boundary/docs/:version/configuration/identity-access-management/assignable-permissions', + permanent: true, + }, + { + source: + '/boundary/docs/concepts/security/permissions/permission-grant-formats', + destination: '/boundary/docs/rbac/permission-grant-formats', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:8|9|10|11|12|1|14|15|16)\\.x)/rbac/permission-grant-formats', + destination: + '/boundary/docs/:version/concepts/security/permissions/permission-grant-formats', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/identity-access-management/permission-grant-formats', + destination: '/boundary/docs/rbac/permission-grant-formats', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:17|18)\\.x)/rbac/permission-grant-formats', + destination: + '/boundary/docs/:version/configuration/identity-access-management/permission-grant-formats', + permanent: true, + }, + { + source: '/boundary/docs/common-workflows/manage-roles', + destination: '/boundary/docs/rbac/manage-roles', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|1|14|15|16|17|18)\\.x)/rbac/manage-roles', + destination: '/boundary/docs/:version/common-workflows/manage-roles', + permanent: true, + }, + { + source: '/boundary/docs/concepts/security/permissions/resource-table', + destination: '/boundary/docs/rbac/resource-table', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:8|9|10|11|12|1|14|15|16)\\.x)/rbac/resource-table', + destination: + '/boundary/docs/:version/concepts/security/permissions/resource-table', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/identity-access-management/resource-table', + destination: '/boundary/docs/rbac/resource-table', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:17|18)\\.x)/rbac/resource-table', + destination: + '/boundary/docs/:version/configuration/identity-access-management/resource-table', + permanent: true, + }, + { + source: '/boundary/docs/common-workflows/manage-users-groups', + destination: '/boundary/docs/rbac/users/manage-users-groups', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|1|14|15|16|17|18)\\.x)/rbac/users/manage-users-groups', + destination: '/boundary/docs/:version/common-workflows/manage-users-groups', + permanent: true, + }, + { + source: '/boundary/docs/concepts/filtering/oidc-managed-groups', + destination: '/boundary/docs/rbac/users/managed-groups', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:4|5|6|7|8|9|10|11|12|13|14|15)\\.x)/rbac/users/managed-groups', + destination: + '/boundary/docs/:version/concepts/filtering/oidc-managed-groups', + permanent: true, + }, + { + source: '/boundary/docs/concepts/filtering/managed-groups', + destination: '/boundary/docs/rbac/users/managed-groups', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:16|17|18)\\.x)/rbac/users/managed-groups', + destination: '/boundary/docs/:version/concepts/filtering/managed-groups', + permanent: true, + }, + { + source: '/boundary/docs/integrations', + destination: '/boundary/docs', + permanent: true, + }, + { + source: '/boundary/docs/integrations/vault', + destination: '/boundary/docs/vault', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/vault', + destination: '/boundary/docs/:version/integrations/vault', + permanent: true, + }, + { + source: '/boundary/docs/api-clients/go-sdk', + destination: '/boundary/docs/go-sdk', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/go-sdk', + destination: '/boundary/docs/:version/api-clients/go-sdk', + permanent: true, + }, + { + source: '/boundary/docs/api-clients/client-agent', + destination: '/boundary/docs/client-agent', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:18)\\.x)/client-agent', + destination: '/boundary/docs/:version/api-clients/client-agent', + permanent: true, + }, + { + source: '/boundary/docs/api-clients/client-cache', + destination: '/boundary/docs/client-cache', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/client-cache', + destination: '/boundary/docs/:version/api-clients/client-cache', + permanent: true, + }, + { + source: '/boundary/docs/api-clients/api', + destination: '/boundary/docs/api', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/api', + destination: '/boundary/docs/:version/api-clients/api', + permanent: true, + }, + { + source: '/boundary/docs/api-clients/api/pagination', + destination: '/boundary/docs/api/pagination', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/api/pagination', + destination: '/boundary/docs/:version/api-clients/api/pagination', + permanent: true, + }, + { + source: '/boundary/docs/api-clients/api/rate-limiting', + destination: '/boundary/docs/api/rate-limiting', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/api/rate-limiting', + destination: '/boundary/docs/:version/api-clients/api/rate-limiting', permanent: true, }, { @@ -185,43 +1483,277 @@ module.exports = [ permanent: true, }, { - source: '/boundary/docs/concepts/service-discovery', - destination: '/boundary/docs/concepts/host-discovery', + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12)\\.x)/commands', + destination: '/boundary/docs/:version/api-clients/cli', permanent: true, }, { - source: '/boundary/docs/concepts/filtering/oidc-managed-groups', - destination: '/boundary/docs/concepts/filtering/managed-groups', + source: '/boundary/docs/concepts/domain-model', + destination: '/boundary/docs/domain-model', permanent: true, }, { - source: '/boundary/docs/configuration/worker/kms-worker', - destination: '/boundary/docs/configuration/worker/worker-configuration', + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model', + destination: '/boundary/docs/:version/concepts/domain-model', permanent: true, }, { - source: '/boundary/docs/configuration/worker/pki-worker', - destination: '/boundary/docs/configuration/worker/worker-configuration', + source: '/boundary/docs/concepts/domain-model/accounts', + destination: '/boundary/docs/domain-model/accounts', permanent: true, }, { - source: '/boundary/docs/concepts/security/permissions/resource-table', - destination: '/boundary/docs/configuration/identity-access-management/resource-table', + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/accounts', + destination: '/boundary/docs/:version/concepts/domain-model/accounts', permanent: true, }, { - source: '/boundary/docs/concepts/security/permissions/assignable-permissions', - destination: '/boundary/docs/configuration/identity-access-management/assignable-permisisons', + source: '/boundary/docs/concepts/domain-model/aliases', + destination: '/boundary/docs/domain-model/aliases', permanent: true, }, { - source: '/boundary/docs/concepts/security/permissions/permission-grant-formats', - destination: '/boundary/docs/configuration/identity-access-management/permission-grant-formats', + source: + '/boundary/docs/:version(v0\\.(?:16|17|18)\\.x)/domain-model/aliases', + destination: '/boundary/docs/:version/concepts/domain-model/aliases', permanent: true, }, { - source: '/boundary/docs/concepts/security/permissions', - destination: '/boundary/docs/configuration/identity-access-management', + source: '/boundary/docs/concepts/domain-model/auth-methods', + destination: '/boundary/docs/domain-model/auth-methods', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/auth-methods', + destination: '/boundary/docs/:version/concepts/domain-model/auth-methods', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/credentials', + destination: '/boundary/docs/domain-model/credentials', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/credentials', + destination: '/boundary/docs/:version/concepts/domain-model/credentials', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/credential-libraries', + destination: '/boundary/docs/domain-model/credential-libraries', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/credential-libraries', + destination: + '/boundary/docs/:version/concepts/domain-model/credential-libraries', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/credential-stores', + destination: '/boundary/docs/domain-model/credential-stores', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/credential-stores', + destination: + '/boundary/docs/:version/concepts/domain-model/credential-stores', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/groups', + destination: '/boundary/docs/domain-model/groups', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/groups', + destination: '/boundary/docs/:version/concepts/domain-model/groups', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/hosts', + destination: '/boundary/docs/domain-model/hosts', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/hosts', + destination: '/boundary/docs/:version/concepts/domain-model/hosts', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/host-catalogs', + destination: '/boundary/docs/domain-model/host-catalogs', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/host-catalogs', + destination: '/boundary/docs/:version/concepts/domain-model/host-catalogs', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/host-sets', + destination: '/boundary/docs/domain-model/host-sets', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/host-sets', + destination: '/boundary/docs/:version/concepts/domain-model/host-sets', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/managed-groups', + destination: '/boundary/docs/domain-model/managed-groups', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/managed-groups', + destination: '/boundary/docs/:version/concepts/domain-model/managed-groups', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/roles', + destination: '/boundary/docs/domain-model/roles', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/roles', + destination: '/boundary/docs/:version/concepts/domain-model/roles', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/scopes', + destination: '/boundary/docs/domain-model/scopes', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/scopes', + destination: '/boundary/docs/:version/concepts/domain-model/scopes', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/sessions', + destination: '/boundary/docs/domain-model/sessions', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/sessions', + destination: '/boundary/docs/:version/concepts/domain-model/sessions', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/session-connections', + destination: '/boundary/docs/domain-model/session-connections', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/session-connections', + destination: + '/boundary/docs/:version/concepts/domain-model/session-connections', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/session-recordings', + destination: '/boundary/docs/domain-model/session-recordings', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/domain-model/session-recordings', + destination: + '/boundary/docs/:version/concepts/domain-model/session-recordings', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/storage-buckets', + destination: '/boundary/docs/domain-model/storage-buckets', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:13|14|15|16|17|18)\\.x)/domain-model/storage-buckets', + destination: + '/boundary/docs/:version/concepts/domain-model/storage-buckets', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/storage-policy', + destination: '/boundary/docs/domain-model/storage-policy', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:15|16|17|18)\\.x)/domain-model/storage-policy', + destination: '/boundary/docs/:version/concepts/domain-model/storage-policy', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/targets', + destination: '/boundary/docs/domain-model/targets', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/targets', + destination: '/boundary/docs/:version/concepts/domain-model/targets', + permanent: true, + }, + { + source: '/boundary/docs/concepts/domain-model/users', + destination: '/boundary/docs/domain-model/users', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/domain-model/users', + destination: '/boundary/docs/:version/concepts/domain-model/users', + permanent: true, + }, + { + source: '/boundary/docs/concepts/filtering', + destination: '/boundary/docs/filtering', + permanent: true, + }, + { + source: + '/boundary/docs/:version(v0\\.(?:1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18)\\.x)/filtering', + destination: '/boundary/docs/:version/concepts/filtering', + permanent: true, + }, + { + source: '/boundary/docs/concepts/filtering/resource-listing', + destination: '/boundary/docs/filtering', + permanent: true, + }, + { + source: '/boundary/docs/troubleshoot/common-errors', + destination: '/boundary/docs/errors', + permanent: true, + }, + { + source: '/boundary/docs/:version(v0\\.(?:12|13|14|15|16|17|18)\\.x)/errors', + destination: '/boundary/docs/:version/troubleshoot/common-errors', + permanent: true, + }, + { + source: + '/boundary/docs/configuration/target-aliases/interoperability-matrix', + destination: '/boundary/docs/interoperability-matrix/index', permanent: true, }, ]