docs: Rename service discovery (#3375)

* docs: Rename service discovery

* docs: Fix level 2 heading

website/content/docs/concepts/host-discovery.mdx

@@ -1,58 +1,57 @@
 ---
 layout: docs
-page_title: Service Discovery
+page_title: Host discovery
 description: |-
-  An overview of service discovery in Boundary
+  An overview of host discovery in Boundary
 ---
 
-# Service Discovery
+# Host discovery
 
-## Overview
-Traditionally, connecting to remote hosts and services requires knowledge of 
-the endpoint’s connection info (e.g. the IP address and port of the service). 
+Traditionally, connecting to remote hosts and services requires knowledge of
+the endpoint’s connection info (e.g. the IP address and port of the service).
 This creates complexity when managing the onboarding of new resources at scale
 or dealing with dynamic services whose connection info frequently changes.
 
-**Service discovery** focuses on automating the process of onboarding new or 
-changed infrastructure resources – and their connection info – to Boundary 
+**Host discovery** focuses on automating the process of onboarding new or
+changed infrastructure resources – and their connection info – to Boundary
 as hosts.
 
-# Automating Service Discovery in Boundary
+## Automating host discovery in Boundary
 
-Boundary supports target/service discovery in three primary workflows: 
+Boundary supports target/host discovery in three primary workflows:
 
-**[Manual configuration](/boundary/tutorials/oss-administration/oss-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 
+**[Manual configuration](/boundary/tutorials/oss-administration/oss-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.
 
-**[Service discovery via configuration as code with Terraform](/boundary/tutorials/oss-getting-started/oss-getting-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). 
-This allows for dynamic configuration of a host and target without the need 
-for prior knowledge of the target’s connection info. 
+**[Host discovery via configuration as code with Terraform](/boundary/tutorials/oss-getting-started/oss-getting-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).
+This allows for dynamic configuration of a host and target without the need
+for prior knowledge of the target’s connection info.
 
-**[Runtime service discovery via dynamic host catalogs](/boundary/tutorials/access-management/azure-host-catalogs)**: 
-Boundary dynamic host catalogs automate the ingestion of resources from 
-infrastructure providers into Boundary. Boundary hosts are automatically 
-created, updated and added to host sets in order to reflect the connection 
-information maintained in these providers. This removes the need to know 
-host connection info or reapply infrastructure as code templates to 
+**[Runtime host discovery via dynamic host catalogs](/boundary/tutorials/access-management/azure-host-catalogs)**:
+Boundary dynamic host catalogs automate the ingestion of resources from
+infrastructure providers into Boundary. Boundary hosts are automatically
+created, updated and added to host sets in order to reflect the connection
+information maintained in these providers. This removes the need to know
+host connection info or reapply infrastructure as code templates to
 configure new or changed resources.
 
-# Dynamic Host Catalogs
-Dynamic host catalogs are an agentless workflow for Boundary to 
-securely query infrastructure providers at runtime to discover and configure 
-new services. Boundary dynamic host catalogs are written in go-plugin and run 
-as separate processes. Boundary administrators can define rules for which 
-external resources should be ingested into the catalog by 
+## Dynamic host catalogs
+Dynamic host catalogs are an agentless workflow for Boundary to
+securely query infrastructure providers at runtime to discover and configure
+new services. Boundary dynamic host catalogs are written in go-plugin and run
+as separate processes. Boundary administrators can define rules for which
+external resources should be ingested into the catalog by
 [creating dynamic host](/boundary/docs/concepts/domain-model/host-sets)
- sets with an attributes filter. Attributes specify the fields which the plugin 
+ sets with an attributes filter. Attributes specify the fields which the plugin
  should use to lookup which hosts should be members of this host set.
 
-Currently, Boundary supports dynamic host catalog implementations for AWS and 
-Azure and we will continue to grow this ecosystem to support additional providers. 
+Currently, Boundary supports dynamic host catalog implementations for AWS and
+Azure and we will continue to grow this ecosystem to support additional providers.
 
 You can get started with dynamic host catalogs [here](/boundary/tutorials/access-management/azure-host-catalogs).

website/content/docs/overview/vs/pam.mdx

@@ -22,7 +22,7 @@ It provides automation-friendly workflows for managing users and credentials, as
 - **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.
-- **[Service discovery](/boundary/docs/concepts/service-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/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.
 
 _Can Boundary replace a PAM solution?_
 

website/content/docs/overview/vs/sdp.mdx

@@ -8,4 +8,4 @@ description: Compares Boundary to using a Software Defined Perimeter solution
 
 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 service discovery](/boundary/docs/concepts/service-discovery), and [access auditing](/hcp/docs/boundary/audit-logging) to name a few.
+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.

website/data/docs-nav-data.json

@@ -137,8 +137,8 @@
         "path": "concepts/iam"
       },
       {
-        "title": "Service Discovery",
-        "path": "concepts/service-discovery"
+        "title": "Host Discovery",
+        "path": "concepts/host-discovery"
       },
       {
         "title": "Credential Management",

website/redirects.js

@@ -128,4 +128,9 @@ module.exports = [
     destination: '/boundary/docs/install-boundary/systemd',
     permanent: true,
   },
+  {
+    source: '/boundary/docs/concepts/service-discovery',
+    destination: '/boundary/docs/concepts/host-discovery',
+    permanent: true,
+  },
 ]