Boundary documentation: modified Boundary's overview page (#2264)
* modified overview page * updated text and image * fixed spelling errors * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> * cleaned up content * Update website/content/docs/what-is-boundary.mdx Co-authored-by: XingLu Wang <95828202+xingluw@users.noreply.github.com> * incorporate feedback * updated image * updated background color * modified font * Update website/content/docs/what-is-boundary.mdx Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> Co-authored-by: XingLu Wang <95828202+xingluw@users.noreply.github.com>
This commit is contained in:
6 files changed
+132
-91
No files matched your search
@@ -7,62 +7,7 @@ description: |-
|
||||
|
||||
# Concepts
|
||||
|
||||
Boundary is a tool for managing identity-based access for modern, dynamic
|
||||
infrastructure. Just as infrastructure itself can be complex, at first glance
|
||||
Boundary can seem complex as well. As a result, it's helpful to understand how
|
||||
Boundary organizes security principals and resources, as well as how it allows
|
||||
you define granular permissions to those principals. A glossary of terms is
|
||||
contained in the [domain model](/docs/concepts/domain-model) section.
|
||||
This section covers some concepts that are imporant to understand Boundary usage and operation. Every page in this section is recommended reading for anyone consuming or operating
|
||||
Boundary. For a glossary of terms, refer to the [domain model](/docs/concepts/domain-model) section.
|
||||
|
||||
# Identity & Permission Management
|
||||
|
||||
Identity is a core concept in Boundary. Identity is represented by two types of
|
||||
resources, mapping to common security principals:
|
||||
|
||||
- [Users](/docs/concepts/domain-model/users), which represent distinct entities
|
||||
that can be tied to authentication accounts
|
||||
- [Groups](/docs/concepts/domain-model/groups), which are collections of Users
|
||||
that allow for easier access management
|
||||
|
||||
[Roles](/docs/concepts/domain-model/roles) map users and groups to a set of
|
||||
[grants](/docs/concepts/security/permissions), which provide the ability to
|
||||
perform actions within the system.
|
||||
|
||||
# Resource Management
|
||||
|
||||
Boundary enables flexible management of the hosts and services for which it can
|
||||
broker access. Boundary administrators define [host
|
||||
catalogs](/docs/concepts/domain-model/host-catalogs) that contain information
|
||||
about [hosts](/docs/concepts/domain-model/hosts). These hosts are then collected
|
||||
into [host sets](/docs/concepts/domain-model/host-sets) which represent sets of
|
||||
equivalent hosts. Finally, [targets](/docs/concepts/domain-model/targets) tie
|
||||
together host sets with connection information. Final access to a resource is
|
||||
granted via [roles](/docs/concepts/domain-model/roles) that provide
|
||||
authorization to create sessions against these targets.
|
||||
|
||||
# Filtering
|
||||
|
||||
Some parts of Boundary support filters for various purposes. For a description
|
||||
of the filter syntax, see the [filtering](/docs/concepts/filtering) page. See
|
||||
the docs pages for the individual resources or capabilities where filters are
|
||||
supported for the specific inputs and examples with those inputs.
|
||||
|
||||
# Next Steps
|
||||
|
||||
There are several options for deploying Boundary:
|
||||
|
||||
1. HCP Boundary as a fully-managed service
|
||||
2. Boundary OSS for self-managed deployments
|
||||
3. Dev mode for testing and learning purposes
|
||||
|
||||
Boundary can be deployed easily as a managed service using the HashiCorp Cloud
|
||||
Platform. Refer to the [Getting Started](/docs/getting-started) section to learn
|
||||
more about HCP Boundary.
|
||||
|
||||
To learn more about Boundary OSS and self-managed deployments, refer to the
|
||||
[Boundary OSS](/docs/oss) docs.
|
||||
|
||||
Boundary can be run locally in [Dev mode](/docs/oss/installing/dev-mode). Refer
|
||||
to the [Connect to Your First
|
||||
Target](/docs/oss/installing/connect-to-dev-target) section to learn about
|
||||
creating targets and initiating a sessions in dev mode.
|
||||
Please use the navigation to the left to learn more about a topic.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Use Cases
|
||||
description: A list of Boundary use cases
|
||||
---
|
||||
|
||||
# Use Cases
|
||||
|
||||
Before understanding use cases, it's useful to know [what Boundary is](/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
|
||||
|
||||
Boundary’s access-on-demand workflow securely connects trusted identities to infrastructure services based on granular, admin-defined permission grants. Boundary removes the need to create or store credentials when accessing services. In this way, Boundary can be used to extend or replace many traditional access solutions like VPNs.
|
||||
|
||||
Traditional access solutions do not employ the the Zero-Trust philosophy - meaning they fail to authenticate and authorize users’ access and actions continuously, and often lack granular access controls.
|
||||
|
||||
## Multi-Cloud Access
|
||||
|
||||
Having different access workflows for various infrastructure and identity providers doesn’t scale well for administrators or users. Multi-cloud organizations have a growing need to standardize access through a single workflow. Boundary creates a centralized layer of identity-based authentication and authorization to manage access to the infrastructure, regardless of the platform on which it resides.
|
||||
|
||||
## Single Sign-on with Integrated Secrets Management
|
||||
|
||||
Boundary enables a single sign-on access model with authentication from trusted identity providers, such as Azure Active Directory, Auth0, and Okta. Once authenticated, users may create sessions with integrated credential management from HashiCorp Vault without the need to re-authenticate.
|
||||
|
||||
## Session Monitoring
|
||||
|
||||
Boundary provides session monitoring capabilities that give security administrators visibility into user access. Sessions are logged and consumable via the Boundary administrator UI as well as business intelligence (BI) and security information and event management (SIEM) tools.
|
||||
@@ -6,56 +6,98 @@ description: And introduction to Boundary
|
||||
|
||||
# What is Boundary?
|
||||
|
||||
Welcome to Boundary! This introduction section covers what Boundary is, the problem Boundary intends to solve, and how Boundary compares to other software. If you want to dive into using Boundary, head over to the [Getting Started](/docs/getting-started) section.
|
||||
|
||||
Boundary is an intelligent proxy that creates granular, identity-based access controls for dynamic infrastructure. Boundary’s workflow layers security controls and integrations at multiple levels to monitor and manage user access through:
|
||||
HashiCorp Boundary is a tool for managing identity-based access for modern, dynamic infrastructure. Boundary’s workflow layers security controls and integrations on multiple levels monitoring and managing user access through:
|
||||
|
||||
- Tightly scoped identity-based permissions
|
||||
- Just-in-time network and credential access for sessions via [HashiCorp Vault](https://vaultproject.io/)
|
||||
- "Just-in-time" network and credential access for sessions via [HashiCorp Vault](https://vaultproject.io/)
|
||||
- Single sign-on to target services and applications via external identity providers
|
||||
- Access-as-code to automate the configuration of user permissions
|
||||
- Automated discovery of target systems
|
||||
- Session monitoring and management for access created via Boundary.
|
||||
|
||||
## Boundary Goals
|
||||
Boundary's foundation is based on the following important concepts.
|
||||
|
||||
**Zero Trust Security**: The foundation of Boundary is an identity-based, “Zero-Trust”, access model. Zero-Trust means user access is continuously authenticated and only authorized when rules and policies tied to the user’s identity are verified.
|
||||
|
||||
**A Consistent Workflow for Access**: Boundary connects the user securely to their infrastructure regardless of cloud platform, target environment, or identity provider. Boundary creates a consistent workflow for user authentication and authorization to create secure, ephemeral sessions that can be monitored and managed by administrators.
|
||||
- **Zero Trust Security:** Zero-Trust is an identity-based access model where the user access is continuously authenticated. Access is only authorized when the established rules and policies tied to the user’s identity are verified.
|
||||
- **Consistent Workflow for Access:** Once the user is verified and granted access, Boundary securely connects the user securely to their infrastructure regardless of cloud platform, target environment, or identity provider. This foundation provides continuous user authentication and authorization workflows within ephemeral sessions, which administrators can monitor and manage securely.
|
||||
- **Extensibility with the Ecosystem:** Modern organizations often require a multilayered access matrix constructed of identity providers, policy engines, secrets management tools, target types, and cloud providers that integrate and allow users to reside within access workflows requiring vendor lock-in. Boundary does not require vendor lock-in and supports the user's vendor-of-choice.
|
||||
|
||||
|
||||
|
||||
**Extensibility with the Ecosystem**: Modern organizations have a multilayered matrix of identity providers, policy engines, secrets management tools, target types, and cloud providers that must integrate and reside within the access workflow. Boundary's extensible ecosystem supports the user's vendor-of-choice in this access workflow.
|
||||
## How does Boundary work?
|
||||
|
||||
Boundary provides secure access to hosts and critical systems without distributing and managing credentidals, 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. The illustration below displays Boundary's core workflow.
|
||||
|
||||
|
||||
|
||||
The core Boundary workflow consists of four stages:
|
||||
|
||||
- **User Authentication:** The user logs in with a trusted identity (based on the rules and policies) with a trust identity platform such as Azure Active Directory, Okta, Ping, or any other trust identify platforms supporting OpenID Connect.
|
||||
- **Granular Authorization:** Boundary authenticates and authorizes users based on their roles and logical services, and tightly controls access and actions performed against systems.
|
||||
- **User-selected dynamic catalogs**: The user selects their application or host from dynamic host catalogs.
|
||||
- **Access:** Boundary streamlines connection to hosts by automating discovery and access configuration as workloads are deployed and changed.
|
||||
|
||||
|
||||
## Why Boundary?
|
||||
|
||||
With the many varying infrastructure services and tooling used in increasingly dynamic environments, organizations must have secure access to all targets within and beyond their perimeter.
|
||||
|
||||
Boundary provides a simple way for verified users to have secure access to cloud
|
||||
and self-managed infrastructures without exposing your network or the use of
|
||||
managing credentials. Boundary is a workflow that enables just-in-time,
|
||||
and self-managed infrastructures without exposing networks or
|
||||
managing credentials. Boundary's workflow enables "just-in-time",
|
||||
role-based access for dynamic infrastructure.
|
||||
|
||||
## Boundary Use-Cases
|
||||
The key features and concepts of Boundary include:
|
||||
|
||||
### Zero Trust access
|
||||
### Identity & Permission Management
|
||||
|
||||
Boundary’s access-on-demand workflow securely connects trusted identities to infrastructure services based on granular, admin-defined permission grants. Boundary removes the need to create or store credentials when accessing services. In this way, Boundary can be used to extend or replace many traditional access solutions like VPNs.
|
||||
Identity is a core concept in Boundary. Identity is represented by two types of
|
||||
resources, mapping to common security principals:
|
||||
|
||||
Traditional access solutions do not employ the the Zero-Trust philosophy - meaning they fail to authenticate and authorize users’ access and actions continuously, and often lack granular access controls.
|
||||
- [Users](/docs/concepts/domain-model/users), which represent distinct entities
|
||||
that can be tied to authentication accounts
|
||||
- [Groups](/docs/concepts/domain-model/groups), which are collections of users
|
||||
that allow for easier access management
|
||||
|
||||
### Multi-Cloud Access
|
||||
[Roles](/docs/concepts/domain-model/roles) map users and groups to a set of
|
||||
[grants](/docs/concepts/security/permissions), which provides the ability to
|
||||
perform actions within the system.
|
||||
|
||||
Having different access workflows for various infrastructure and identity providers doesn’t scale well for administrators or users. Multi-cloud organizations have a growing need to standardize access through a single workflow. Boundary creates a centralized layer of identity-based authentication and authorization to manage access to the infrastructure, regardless of the platform on which it resides.
|
||||
### Resource Management
|
||||
|
||||
### Single Sign-on with Integrated Secrets Management
|
||||
Boundary enables flexible management of the hosts and services to
|
||||
broker access. Boundary administrators define [host
|
||||
catalogs](/docs/concepts/domain-model/host-catalogs) containing information
|
||||
about [hosts](/docs/concepts/domain-model/hosts). The cataloged hosts are collected
|
||||
into [host sets](/docs/concepts/domain-model/host-sets) that represent sets of
|
||||
equivalent hosts. Finally, [targets](/docs/concepts/domain-model/targets) tie
|
||||
together host sets with connection information. Access to a resource is
|
||||
granted via [roles](/docs/concepts/domain-model/roles) that provide
|
||||
authorization to create sessions against these targets.
|
||||
|
||||
Boundary enables a single sign-on access model with authentication from trusted identity providers, such as Azure Active Directory, Auth0, and Okta. Once authenticated, users may create sessions with integrated credential management from HashiCorp Vault without the need to re-authenticate.
|
||||
### Filtering
|
||||
|
||||
### Session Monitoring
|
||||
Parts of Boundary support filters for various purposes. For a description
|
||||
of the filter syntax, see the [filtering](/docs/concepts/filtering) page. See
|
||||
the docs pages for the individual resources or capabilities where filters are
|
||||
supported for the specific inputs and examples with those inputs.
|
||||
|
||||
Boundary provides session monitoring capabilities that give security administrators visibility into user access. Sessions are logged and consumable via the Boundary administrator UI as well as business intelligence (BI) and security information and event management (SIEM) tools.
|
||||
-> **Tip**: Learn more about Boundary [use cases](/docs/use-cases).
|
||||
|
||||
## What is HCP Boundary?
|
||||
|
||||
Boundary offers two types of deployment options. A first option is an *OSS self-managed* deployment solution as discussed above. A self-managed approach enables organizations to proxy all session data through their own network while still providing the convenience of a managed service. A second option is an *HCP-managed* deployment solution where both the control plan and worker nodes are managed by HashiCorp. With this managed solution, an option of private workers is offered. **HCP Boundary** is a fully-managed, cloud-based workflow that enables secure connections to remote hosts and critical systems across cloud and on-premise environments. Refer to the [HCP Boundary](https://cloud.hashicorp.com/docs/boundary
|
||||
) documentation to learn more.
|
||||
|
||||
-> **Hands On:** Try the [Create a Boundary Instance on HCP](https://learn.hashicorp.com/tutorials/boundary/hcp-getting-started-create?in=boundary/hcp-getting-started) tutorial to deploy an HCP Boundary instance.
|
||||
|
||||
## Tutorial
|
||||
|
||||
Refer to HashicCorp Learn for [Boundary](https://learn.hashicorp.com/boundary) to gain access to Boundary's series of featured tutorials to learn how to set up, configure, and administer Boundary.
|
||||
Refer to the [Boundary tutorials](https://learn.hashicorp.com/boundary) to learn how to set up, configure, and administer Boundary.
|
||||
|
||||
## Community
|
||||
|
||||
We welcome questions, suggestions, and contributions from the community.
|
||||
|
||||
- Ask questions in [HashiCorp Discuss](https://discuss.hashicorp.com/c/boundary/50).
|
||||
- Read our [contributing guide](https://github.com/hashicorp/boundary/blob/main/CONTRIBUTING.md).
|
||||
- [Submit an issue](https://github.com/hashicorp/boundary/issues) for bugs and feature requests.
|
||||
@@ -3,6 +3,10 @@
|
||||
"title": "What is Boundary?",
|
||||
"path": "what-is-boundary"
|
||||
},
|
||||
{
|
||||
"title": "Use Cases",
|
||||
"path": "use-cases"
|
||||
},
|
||||
{
|
||||
"title": "Getting Started",
|
||||
"routes": [
|
||||
|
||||
Generated
+33
-11
@@ -862,10 +862,14 @@
|
||||
"version": "11.1.2",
|
||||
"resolved": "https://registry.npmjs.org/@next/swc-darwin-arm64/-/swc-darwin-arm64-11.1.2.tgz",
|
||||
"integrity": "sha512-hZuwOlGOwBZADA8EyDYyjx3+4JGIGjSHDHWrmpI7g5rFmQNltjlbaefAbiU5Kk7j3BUSDwt30quJRFv3nyJQ0w==",
|
||||
"cpu": ["arm64"],
|
||||
"cpu": [
|
||||
"arm64"
|
||||
],
|
||||
"dev": true,
|
||||
"optional": true,
|
||||
"os": ["darwin"],
|
||||
"os": [
|
||||
"darwin"
|
||||
],
|
||||
"peer": true,
|
||||
"engines": {
|
||||
"node": ">= 10"
|
||||
@@ -875,10 +879,14 @@
|
||||
"version": "11.1.2",
|
||||
"resolved": "https://registry.npmjs.org/@next/swc-darwin-x64/-/swc-darwin-x64-11.1.2.tgz",
|
||||
"integrity": "sha512-PGOp0E1GisU+EJJlsmJVGE+aPYD0Uh7zqgsrpD3F/Y3766Ptfbe1lEPPWnRDl+OzSSrSrX1lkyM/Jlmh5OwNvA==",
|
||||
"cpu": ["x64"],
|
||||
"cpu": [
|
||||
"x64"
|
||||
],
|
||||
"dev": true,
|
||||
"optional": true,
|
||||
"os": ["darwin"],
|
||||
"os": [
|
||||
"darwin"
|
||||
],
|
||||
"peer": true,
|
||||
"engines": {
|
||||
"node": ">= 10"
|
||||
@@ -888,10 +896,14 @@
|
||||
"version": "11.1.2",
|
||||
"resolved": "https://registry.npmjs.org/@next/swc-linux-x64-gnu/-/swc-linux-x64-gnu-11.1.2.tgz",
|
||||
"integrity": "sha512-YcDHTJjn/8RqvyJVB6pvEKXihDcdrOwga3GfMv/QtVeLphTouY4BIcEUfrG5+26Nf37MP1ywN3RRl1TxpurAsQ==",
|
||||
"cpu": ["x64"],
|
||||
"cpu": [
|
||||
"x64"
|
||||
],
|
||||
"dev": true,
|
||||
"optional": true,
|
||||
"os": ["linux"],
|
||||
"os": [
|
||||
"linux"
|
||||
],
|
||||
"peer": true,
|
||||
"engines": {
|
||||
"node": ">= 10"
|
||||
@@ -901,10 +913,14 @@
|
||||
"version": "11.1.2",
|
||||
"resolved": "https://registry.npmjs.org/@next/swc-win32-x64-msvc/-/swc-win32-x64-msvc-11.1.2.tgz",
|
||||
"integrity": "sha512-e/pIKVdB+tGQYa1cW3sAeHm8gzEri/HYLZHT4WZojrUxgWXqx8pk7S7Xs47uBcFTqBDRvK3EcQpPLf3XdVsDdg==",
|
||||
"cpu": ["x64"],
|
||||
"cpu": [
|
||||
"x64"
|
||||
],
|
||||
"dev": true,
|
||||
"optional": true,
|
||||
"os": ["win32"],
|
||||
"os": [
|
||||
"win32"
|
||||
],
|
||||
"peer": true,
|
||||
"engines": {
|
||||
"node": ">= 10"
|
||||
@@ -2927,7 +2943,9 @@
|
||||
"resolved": "https://registry.npmjs.org/concat-stream/-/concat-stream-1.6.2.tgz",
|
||||
"integrity": "sha512-27HBghJxjiZtIk3Ycvn/4kbJk/1uZuJFfuPEns6LaEvpvG1f0hTea8lilrouyo9mVc2GWdcEZ8OLoGmSADlrCw==",
|
||||
"dev": true,
|
||||
"engines": ["node >= 0.8"],
|
||||
"engines": [
|
||||
"node >= 0.8"
|
||||
],
|
||||
"optional": true,
|
||||
"peer": true,
|
||||
"dependencies": {
|
||||
@@ -5236,7 +5254,9 @@
|
||||
"dev": true,
|
||||
"hasInstallScript": true,
|
||||
"optional": true,
|
||||
"os": ["darwin"],
|
||||
"os": [
|
||||
"darwin"
|
||||
],
|
||||
"peer": true,
|
||||
"engines": {
|
||||
"node": "^8.16.0 || ^10.6.0 || >=11.0.0"
|
||||
@@ -13012,7 +13032,9 @@
|
||||
"dev": true,
|
||||
"hasInstallScript": true,
|
||||
"optional": true,
|
||||
"os": ["darwin"],
|
||||
"os": [
|
||||
"darwin"
|
||||
],
|
||||
"peer": true,
|
||||
"dependencies": {
|
||||
"bindings": "^1.5.0",
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 82 KiB |
Reference in new issue
Block a user