c05fa66096
Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> Co-authored-by: XingLu Wang <95828202+xingluw@users.noreply.github.com> Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com> Co-authored-by: irenarindos <irena.rindos@gmail.com> Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com> Co-authored-by: Louis Ruch <louisruch@gmail.com> Co-authored-by: XingLu Wang <xinglu.wang@hashicorp.com> Co-authored-by: XingLu Wang <95828202+xingluw@users.noreply.github.com>
69 lines
2.8 KiB
Plaintext
69 lines
2.8 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Concepts
|
|
description: |-
|
|
An introduction to Boundary concepts and architecture.
|
|
---
|
|
|
|
# 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.
|
|
|
|
# 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.
|