diff --git a/website/content/docs/install-boundary/fault-tolerance.mdx b/website/content/docs/install-boundary/architecture/fault-tolerance.mdx similarity index 100% rename from website/content/docs/install-boundary/fault-tolerance.mdx rename to website/content/docs/install-boundary/architecture/fault-tolerance.mdx diff --git a/website/content/docs/install-boundary/high-availability.mdx b/website/content/docs/install-boundary/architecture/high-availability.mdx similarity index 100% rename from website/content/docs/install-boundary/high-availability.mdx rename to website/content/docs/install-boundary/architecture/high-availability.mdx diff --git a/website/content/docs/install-boundary/recommended-architecture.mdx b/website/content/docs/install-boundary/architecture/recommended-architecture.mdx similarity index 100% rename from website/content/docs/install-boundary/recommended-architecture.mdx rename to website/content/docs/install-boundary/architecture/recommended-architecture.mdx diff --git a/website/content/docs/install-boundary/configure-controllers.mdx b/website/content/docs/install-boundary/configure-controllers.mdx index 0bfed2d397..45f1c08824 100644 --- a/website/content/docs/install-boundary/configure-controllers.mdx +++ b/website/content/docs/install-boundary/configure-controllers.mdx @@ -289,12 +289,16 @@ Refer to the documentation for additional [top-level configuration options](/bou Before you can start Boundary, you must initialize the database from one Boundary controller. This operation is only required once; it will execute the required database migrations for the Boundary cluster to operate. -The following command with the included flags creates initial resources in Boundary as an example. -For finer control over these resources, remvoe the flags. +```bash +boundary database init -config /etc/boundary.d/controller.hcl +``` -Run the following command to initialize the database: +Boundary will automatically generate a number of resources to make getting started easier. Default scopes, auth methods, +user, account, and targets are just some of the resources Boundary will generate unless you tell it not to. These +resources, however, are not required. You can choose to skip the creation of these initial resources by adding some +flags. -```hcl +```bash boundary database init \ -skip-auth-method-creation \ -skip-host-resources-creation \ @@ -303,9 +307,9 @@ boundary database init \ -config /etc/boundary.d/controller.hcl ``` -You can use the help output for the `init` command to view the flags available to skip the creation of any auto-generated resources: +For additional options, view the help documentation. -```hcl +```bash boundary database init -h ``` @@ -322,5 +326,5 @@ 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. This allows you to configure targets within those scopes and manage them. -We recommend that you use the [KMS recovery workflow](/boundary/docs/install-boundary/no-gen-resources#recovery-kms-workflow) to log in to Boundary for the first time. -Refer to [Creating your first login account](/boundary/docs/install-boundary/no-gen-resources/#creating-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. +We recommend 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/#creating-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. diff --git a/website/content/docs/install-boundary/no-gen-resources.mdx b/website/content/docs/install-boundary/initialize.mdx similarity index 70% rename from website/content/docs/install-boundary/no-gen-resources.mdx rename to website/content/docs/install-boundary/initialize.mdx index b390865182..d70edb4e08 100644 --- a/website/content/docs/install-boundary/no-gen-resources.mdx +++ b/website/content/docs/install-boundary/initialize.mdx @@ -1,25 +1,24 @@ --- layout: docs -page_title: Running Boundary in non-dev environments +page_title: Initialize Boundary description: |- - How to install boundary in non-dev environments. + Creating your first login account --- -# Install Boundary without generated resources +# Initialize Boundary -What are generated resources? When you run `boundary dev` or `boundary database init`, Boundary automatically -generates a number of resources to make getting started easier. Default scopes, auth methods, user, account, and -targets are just some of the resources Boundary will generate unless you tell it not to. +Before you initialize Boundary, you should have [initialized a database](/boundary/docs/install-boundary/configure-controllers#initialize-the-database). -In a production or long-running environment, these resources are not necessary, but without them, managing -Boundary from scratch isn't straight forward. How do you create your first user and login to administer a Boundary -deployment that has no authentication methods, users, accounts, etc.? This section describes how to get your freshly -deployed Boundary installation off the ground for non-dev environments. +This document describes how to access Boundary for the first time and create the necessary resources to log in as a +user in Boundary. -## Recovery KMS workflow +## Log in with Recovery KMS -Initializing Boundary without generated resources starts with your Boundary configuration file. Specifically, -the controller configuration specifies three KMS blocks: +In order to access a new Boundary instance for the first time, you will need to use the recovery KMS defined in the +controller configuration file. Here is an example snippet of a configuration file that uses hard-coded AEAD keys. + +~> **Note:** In a production environment, it is recommended to use a cloud provider's KMS such as [AWS KMS](/boundary/docs/configuration/kms/awskms) +to manage the keys Boundary uses to encrypt sensitive information. ```hcl @@ -46,14 +45,9 @@ kms "aead" { ``` -In this example, we're using hardcoded AEAD keys, but in a real world non-dev deployment, you -should use your cloud provider's KMS such as [AWS KMS](/boundary/docs/configuration/kms/awskms) to manage the keys Boundary -uses to encrypt sensitive information. - -The KMS block we're focused on is the `recovery` block. This block specifies the key used to "recover" Boundary -but you can also use it to authenticate to Boundary and manage it as a "global" super user. This allows -you to authenticate from the CLI or from Terraform in order to manage Boundary without any generated -resources. +The KMS with the `recovery` purpose is used to "recovery" Boundary, allowing you to authenticate to Boundary and managed +it as a super user. It also allows you to authenticate from the CLI or from Terraform in order to manage BOundary +without any generated resources. To authenticate to Boundary using the recovery KMS workflow: @@ -63,7 +57,7 @@ To authenticate to Boundary using the recovery KMS workflow: To use the recovery workflow on the CLI, you must pass the `-recovery-config ` flag or set the environment variable for `BOUNDARY_RECOVERY_CONFIG` for every command ran. Authentication takes place for every command -ran when using the recovery workflow, there is no `boundary authenticate` step: +ran when using the recovery workflow. `boundary authenticate` does not apply when using the recovery KMS. ```bash $ cat << EOF > /tmp/recovery.hcl @@ -75,6 +69,7 @@ kms "aead" { } EOF +# Example command $ boundary users create -recovery-config /tmp/recovery.hcl ... ``` @@ -103,44 +98,16 @@ EOT - -## Initialize the database - -Before you can start Boundary, the database must be initialized. It's useful to look at the help output for the init command: - -``` -$ boundary database init -h -... -``` - -From this command, you can see the flags available to skip the creation of auto-generated resources. - -To initialize the Boundary database without generated resources: - -``` -$ boundary database init \ - -skip-auth-method-creation \ - -skip-host-resources-creation \ - -skip-scopes-creation \ - -skip-target-creation \ - -config /etc/boundary.hcl -``` - -When you start Boundary, you will effectively have a blank sheet to work against. The initial migrations in the database have been run (note that this includes creating special users like `u_anon` and the `global` scope) and the internal keyrings have been initialized. From here, it's required that -you use the KMS recovery workflow described above to create at a minimum an auth method, a user, an account, and a -role with sufficient grants. Otherwise, you need to continue to use the recovery workflow for management. It's important -to realize that this is effectively a global super user type of workflow and comes with security concerns. - ## Create your first login account -This section covers how to configure your first auth method, user, account, and role to login to Boundary without -the recovery KMS workflow. In this example, we're going to make an admin user for the global and project level +This section covers how to configure your first auth method, user, account, and role to log in to Boundary without +the recovery KMS workflow. In this example, we are going to make an admin user for the global and project level scopes we create. This will allow our user to configure targets within those scopes and manage them. ### Create org and project scopes -In this example, we're going to create an org and project scope and skip creating an administrator and admin role -for each scope. We're going to specify a role for managing these scopes by selected users in a later step. +First, create an org and project scope and skip creating an administrator and admin role for each scope. We are going to +specify a role for managing these scopes by selected users in a later step. @@ -294,8 +261,8 @@ resource "boundary_user" "myuser" { ### Create roles to manage scopes -The following describes the four baseline roles you'll need to create to manage resources within the org and project -scopes created above. These roles are similar to the roles created for you if generation had not been skipped during `boundary database init` when executed with the `-skip-initial-login-role-creation` flag, Declaring roles explicitly +The following describes the four baseline roles you will need to create in order to manage resources within the org and project +scopes that were created. These roles are similar to the roles automatically created for you if generation had not been skipped during `boundary database init` when executed with the `-skip-initial-login-role-creation` flag, Declaring roles explicitly allows you to manage them independently and fully within Terraform or via the CLI. In doing so, you can precisely define their access. The following example creates 4 roles: @@ -480,7 +447,7 @@ resource "boundary_role" "project_admin" { ### Log in as your new user -```shell-session +```bash boundary authenticate password \ -auth-method-id ``` diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index c1aff63369..2c19b0edf1 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -52,14 +52,14 @@ "title": "Overview", "path": "getting-started" }, - { - "title": "Self-managed Boundary quick start", - "href": "https://developer.hashicorp.com/boundary/tutorials/oss-getting-started/" - }, { "title": "HCP Boundary quick start", "href": "https://developer.hashicorp.com/boundary/tutorials/hcp-getting-started/" }, + { + "title": "Self-managed Boundary quick start", + "href": "https://developer.hashicorp.com/boundary/tutorials/oss-getting-started/" + }, { "title": "Dev mode quick start", "routes": [ @@ -86,17 +86,26 @@ "title": "Overview", "path": "install-boundary" }, - { - "title": "Recommended architecture", - "path": "install-boundary/recommended-architecture" - }, { "title": "System requirements", "path": "install-boundary/system-requirements" }, { - "title": "Fault tolerance recommendations", - "path": "install-boundary/fault-tolerance" + "title": "Architecture", + "routes": [ + { + "title": "Recommended architecture", + "path": "install-boundary/architecture/recommended-architecture" + }, + { + "title": "Fault tolerance recommendations", + "path": "install-boundary/architecture/fault-tolerance" + }, + { + "title": "Configure high availability", + "path": "install-boundary/architecture/high-availability" + } + ] }, { "title": "Install Boundary", @@ -111,17 +120,13 @@ "path": "install-boundary/configure-workers" }, { - "title": "Non-dev environments", - "path": "install-boundary/no-gen-resources" + "title": "Initialize Boundary", + "path": "install-boundary/initialize" }, { "title": "Systemd install", "hidden": true, "path": "install-boundary/systemd" - }, - { - "title": "Configure high availability", - "path": "install-boundary/high-availability" } ] }, @@ -1515,7 +1520,6 @@ } ] }, - { "title": "Develop Boundary", "routes": [ diff --git a/website/redirects.js b/website/redirects.js index 954a05ae44..152fd95174 100644 --- a/website/redirects.js +++ b/website/redirects.js @@ -108,6 +108,11 @@ module.exports = [ destination: '/boundary/docs/install-boundary/no-gen-resources', permanent: true, }, + { + source: '/boundary/docs/install-boundary/no-gen-resources', + destination: '/boundary/docs/install-boundary/initialize', + permanent: true, + }, { source: '/boundary/docs/oss/installing/postgres', destination: '/boundary/docs/install-boundary/system-requirements',