From aeda1d0d2e7ea395dac868e402dd36b214e92731 Mon Sep 17 00:00:00 2001 From: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> Date: Thu, 29 Jun 2023 11:20:39 -0400 Subject: [PATCH] docs: Rename service discovery (#3375) * docs: Rename service discovery * docs: Fix level 2 heading --- ...rvice-discovery.mdx => host-discovery.mdx} | 71 +++++++++---------- website/content/docs/overview/vs/pam.mdx | 2 +- website/content/docs/overview/vs/sdp.mdx | 2 +- website/data/docs-nav-data.json | 4 +- website/redirects.js | 5 ++ 5 files changed, 44 insertions(+), 40 deletions(-) rename website/content/docs/concepts/{service-discovery.mdx => host-discovery.mdx} (60%) diff --git a/website/content/docs/concepts/service-discovery.mdx b/website/content/docs/concepts/host-discovery.mdx similarity index 60% rename from website/content/docs/concepts/service-discovery.mdx rename to website/content/docs/concepts/host-discovery.mdx index 8d145531ec..83aa66f130 100644 --- a/website/content/docs/concepts/service-discovery.mdx +++ b/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. - -**[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 +**[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 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). diff --git a/website/content/docs/overview/vs/pam.mdx b/website/content/docs/overview/vs/pam.mdx index 9bddf5ebbc..9e76d3b0e6 100644 --- a/website/content/docs/overview/vs/pam.mdx +++ b/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?_ diff --git a/website/content/docs/overview/vs/sdp.mdx b/website/content/docs/overview/vs/sdp.mdx index 96b95daac2..70395d6b0e 100644 --- a/website/content/docs/overview/vs/sdp.mdx +++ b/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. \ 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/concepts/host-discovery), and [access auditing](/hcp/docs/boundary/audit-logging) to name a few. \ No newline at end of file diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index 9058c7a25f..1112754023 100644 --- a/website/data/docs-nav-data.json +++ b/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", diff --git a/website/redirects.js b/website/redirects.js index 58478db7b9..3b6ed31bed 100644 --- a/website/redirects.js +++ b/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, + }, ]