Add API/CLI standards docs and some cleanup elsewhere (#488)
This commit is contained in:
Jeff Mitchell authored and 
GitHub committed
1 parent
5f939bff34
commit
c5fff0ae4d
5 files changed
+174
-9
No files matched your search
@@ -0,0 +1,82 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: API Standards
|
||||
sidebar_title: API Standards
|
||||
description: |-
|
||||
Boundary's API standards
|
||||
---
|
||||
|
||||
# Overview
|
||||
|
||||
Boundary's HTTP API adheres to a set of standards that are rigidly followed. At its core, it is a standards-compliant JSON API for both input and output.
|
||||
|
||||
Before reading this page, it is useful to understand Boundary's [domain model](/docs/concetps/domain-model) to be aware of the terminology used here.
|
||||
|
||||
Boundary's API is also described via OpenAPI v2; the version corresponding to any tag of Boundary's source code can be found in Boundary's [GitHub repository](https://github.com/hashicorp/boundary/blob/main/internal/gen/controller.swagger.json).
|
||||
|
||||
Boundary's current API version is 1; all API paths begin with `/v1/`.
|
||||
|
||||
## Status Codes
|
||||
|
||||
* `2XX`: Boundary returns a code between `200` and `299` on success. Generally this is `200`, but implementations should be prepared to accept any `2XX` status code as indicating success. If a call returns a `2XX` code that is not `200`, it will follow well-understood semantics for those status codes.
|
||||
* `400`: Boundary returns `400` when a command cannot be completed due to invalid user input, except for a properly-formatted identifier that does not map to an existing resource, which will return a `404` as discussed below.
|
||||
* `401`: Boundary returns `401` if no authentication token is provided or if the provided token is invalid. A valid token that simply does not have permission for a resource will return a `403` instead. A token that is invalid or missing, but where the anonymous user (`u_anon`) is able to successfully perform the action, will not return a `401` but instead will return the result of the action.
|
||||
* `403`: Boundary returns `403` if a provided token was valid but does not have the grants required to perform the requested action.
|
||||
* `404`: Boundary returns `404` if a resource cannot be found. Note that this happens _prior_ to authentication/authorization checking in nearly all cases as the resource information (such as its scope, available actions, etc.) is a required part of that check. As a result, an action against a resource that does not exist will return a `404` instead of a `401` or `403`. While this could be considered an information leak, since IDs are randomly generated and this only discloses whether an ID is valid, it's tolerable.
|
||||
* `405`: Boundary returns a `405` to indicate that the method is not implemented for the given resource.
|
||||
* `500`: Boundary returns `500` if an error occurred that is not (directly) tied to invalid user input. If a `500` is generated, information about the error will be logged to Boundary's server log but is not generally provided to the client.
|
||||
|
||||
## Path Layout
|
||||
|
||||
Boundary follows a predictable path layout. There are two fundamental types of URL paths, each supporting a different set of operations.
|
||||
|
||||
### Collections
|
||||
|
||||
Collections of resources are top level paths with plural English names for the resource, e.g. `/roles` and `/hosts`. Collections support the following operations:
|
||||
|
||||
* Creation of new resources within that collection
|
||||
* Listing of resources within that collection
|
||||
|
||||
All collection operations require supplying the enclosing resource. Depending on the collection type, this will be one of the following:
|
||||
|
||||
* A scope, indicating the scope in which an operation should take place. For instance, a POST to `/roles` would need to indicate whether the role should be created within the `global` scope or some organization scope like `o_1234567890`.
|
||||
* A parent resource of the appropriate type. For instance, hosts and host sets are child resources of host catalogs. When creating a new host set within a host catalog, a POST to `/host-sets` would need to indicate the host catalog ID with which the host-set should be associated.
|
||||
|
||||
### Resources
|
||||
|
||||
Resources themselves are defined by ID specifiers within a collection path, e.g. `/roles/r_1234567890`. Resources support the following operations:
|
||||
|
||||
* Reading a resource's properties
|
||||
* Updating a resource's properties
|
||||
* Deleting a resource
|
||||
* Custom methods specific to a resource type
|
||||
|
||||
Depending on the resource type, various parameters may be available. Some are common across all resource types (e.g. `name` and `description`); others are available only for specific types. Further, some concrete-types of abstract resources include an opaque `attributes` JSON object with type-specific values.
|
||||
|
||||
For instance, an authentication method is an abstract type; a `password` authentication method is a concrete implementation of that type. When creating such an auth method, a `type` parameter will indicate that it should be the `password` type, while values specific to the `password` type auth method, such as minimum password length, will be contained within an `attributes` object.
|
||||
|
||||
## Methods
|
||||
|
||||
The following method conventions are used within Boundary's API:
|
||||
|
||||
### GET
|
||||
|
||||
`GET` is used for reading a resource or listing resources in a collection. The behavior depends on whether the `GET` is issued against a collection (`/roles`) or a singular resource (`/roles/r_1234567890`). In the former case it lists resources within the collection; in the latter it performs a read on that particular resource.
|
||||
|
||||
### POST
|
||||
|
||||
`POST` is used for creating a resource or performing custom actions against a resoruce. When creating a resource, `POST` is used against a collection (`/roles`). When performing a custom action, `POST` is used against a particular resource (`/roles/r_1234567890:set-principals`).
|
||||
|
||||
### PATCH
|
||||
|
||||
`PATCH` is used to update a resource's parameters. The following are behaviors to be aware of when using `PATCH`:
|
||||
|
||||
* In nearly all cases, a `version` parameter is required. This is used for check-and-set, to ensure that the update operation is being performed against a known resource. The version parameter is returned from a `GET` operation on the resource so the current version, along with the resource's other current values, can be looked up at any time.
|
||||
* Passing a JSON `null` for a parameter has the effect of reverting that parameter to its default. For some parameters (e.g. `name`) this will simply clear the value (as the default `name` for a resource is empty); for other parameters this will revert to the current defaults within Boundary.
|
||||
* All parameters specified as part of a `PATCH` operation will be considered to be parameters that should be updated.
|
||||
|
||||
For clients that have difficulty choosing which parameters to include in a request, for most paths an alternative form is allowed where the parameters of the resource can be specified in a JSON object under the key `item` and an `update_mask` parameter containing a comma-separate list of field names that should actually be used for the update operation is included.
|
||||
|
||||
### DELETE
|
||||
|
||||
`DELETE` is used for deleting a specific resource, and is only used against a particular resource path.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: CLI Standards
|
||||
sidebar_title: CLI Standards
|
||||
description: |-
|
||||
Boundary's CLI standards
|
||||
---
|
||||
|
||||
# Overview
|
||||
|
||||
Boundary's CLI has predictable behavior throughout its various commands. This page details these standards to help users make better use of the CLI.
|
||||
|
||||
## Parameter Handling
|
||||
|
||||
All parameters specified on the CLI are specified as a Go-style flag with a single dash, e.g. `-id`. The arguments to those flags can be specified via an equals sign, as in `-id=r_1234567890`, or a space, like `-id r_1234567890`.
|
||||
|
||||
To see available parameters, pass the `-h` flag to any command.
|
||||
|
||||
Flags are semi-position dependent. The flags must come _after_ the command definition, but are otherwise order independent.
|
||||
|
||||
For instance, the following are equivalent:
|
||||
|
||||
* `boundary roles create -scope-id global -name foo`
|
||||
* `boundary roles create -name foo -scope-id global`
|
||||
|
||||
But the following results in an error:
|
||||
|
||||
* `boundary roles -name foo -scope-id global create`
|
||||
|
||||
This applies to `-h` as well!
|
||||
|
||||
### Connection Options
|
||||
|
||||
Every command that results in an API call contains a set of flags that control connection options, which control TLS and other settings for the connection.
|
||||
|
||||
### Client Options
|
||||
|
||||
Every command that results in an API call contains a set of flags that control client options. Some notable options:
|
||||
|
||||
* `output-curl-string`: This will format the command that would have been run as a string using `curl` that can be used directly on the command line. This is a great way to discover how CLI functions map to API calls.
|
||||
* `token-name`: When the CLI authenticates, it stores the token in the platform-specific OS credential store. By using the `token-name` parameter, more than one token can be stored at a time. Specifying this parameter at authentication time uses the given name as part of the key for storage; specifying it for any other command will cause the corresponding token to be used for that call.
|
||||
* `recovery-config`: This is used to specify a configuration file that contains the information necessary to access a KMS configured to be used for the recovery workflow within a Boundary controller.
|
||||
|
||||
### Output Options
|
||||
|
||||
Nearly every command supports having its success output be formatted as JSON via `-format json`. For commands that result in an API call, the JSON output will be the exact output from the controller. If using the output of the CLI in scripts or as parameters to other tools, _always_ use formatted output. The default text output is meant for human users and the formatting or the information included within that output from the original JSON may change at any time.
|
||||
|
||||
## Mapping to Collections and Sub-Types
|
||||
|
||||
Generally speaking, Boundary's CLI commands map to the collections they operate on. For instance, when operating on roles, the command will be `boundary roles ...`.
|
||||
|
||||
As a result, the patterns for reading, deleting, and listing are predictable:
|
||||
|
||||
* `boundary <collection> read`
|
||||
* `boundary <collection> delete`
|
||||
* `boundary <collection> list`
|
||||
|
||||
`read` and `delete` will always operate on a particular resource identifier, so will always take in an `-id` parameter. `list` operates on collections so will either take a `-scope-id` parameter or, depending on type, a higher level resource identifier, e.g. `-auth-method-id`.
|
||||
|
||||
Creating and updating resources may take an extra parameter if the resource type is abstract, that is, if the type cannot be operated on directly but must be operated on through an implementation. As an example, a role is not an abstract type, and does not have various implementations of it. As a result, a role can be operated on directly:
|
||||
|
||||
* `boundary roles create`
|
||||
* `boundary roles update`.
|
||||
|
||||
However, a target can be one of many types of targets, and a concrete implementation of a target is a `tcp` type of target. Therefore an extra parameter is required when creating or updating a target:
|
||||
|
||||
* `boundary targets tcp create`
|
||||
* `boundary targets tcp update`
|
||||
|
||||
This allows the CLI to perform proper presentation and validation of parameters and functions for the given type.
|
||||
|
||||
Similar to `read`, `update` operates on an existing target so will always take an `-id` parameter. Similar to `list`, `create` operates on a collection so will either take a `-scope-id` parameter or a parameter defining the parent resource.
|
||||
|
||||
## Completion
|
||||
|
||||
Boundary's CLI supports autocompletion. For Bash, the following line in a `~/.bash_profile` or similar file will work:
|
||||
|
||||
`complete -C /path/to/boundary boundary`
|
||||
|
||||
This will allow tab completion of commands, flags, and in some cases the parameters to those flags.
|
||||
@@ -8,4 +8,6 @@ description: |-
|
||||
|
||||
# Overview
|
||||
|
||||
Users can configure Boundary via command line, admin console, terraform, or the SDK. This section covers what configuration resources are avaialble, and how they're releated. For details on using a specific method, please see that method's specific documentation.
|
||||
Boundary has a rich domain model consisting of resources that represent IAM principals, infrastructure, and the means to tie them together. This section contains information about the various resources within the domain and how they relate to each other.
|
||||
|
||||
When getting started with Boundary, the first resource to look at should probably be [Scopes](/docs/concepts/domain-model/scopes). Every other resources is either contained within a scope, or contained within another resource that is itself contained within a scope. That page can help you understand the structure of resources within Boundary.
|
||||
@@ -8,22 +8,21 @@ description: |-
|
||||
|
||||
|
||||
# Concepts
|
||||
Boundary is a tool for managing identity-based access for modern, dynamic infrastructure. It's helpful to understand how Boundary organizes principals and resources as well as how it allows you define granular permissions for principals' allowed actions and access. A glossary of terms are broken down in our [domain model](/docs/concepts/domain-model).
|
||||
|
||||
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 management is a core concept in Boundary. Boundary manages
|
||||
* [Users](/docs/concepts/domain-model/users), which are the entities authorized to access Boundary.
|
||||
* [Groups](/docs/concepts/domain-model/groups), which are collections of users which share permissions.
|
||||
Identity is a core concept in Boundary. Identity is represented by two types of resources, mapping to common security principals:
|
||||
|
||||
Users and Groups can be assigned permissions by assigning them to [roles](/docs/concepts/domain-model/roles). Roles can have their permissions granularly defined with [grants](/docs/concepts/domain-model/grants).
|
||||
* [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/domain-model/grants), which provide the ability to perform actions within the system.
|
||||
|
||||
# Resource Management
|
||||
Boundary enables flexible management of hosts and services without the use of an end-agent. Boundary administrators define [targets](/docs/concepts/domain-model/targets) which expose one or more [hosts](/docs/concepts/domain-model/hosts) with connection info. Access to resource can be assigned to [roles](/docs/concepts/domain-model/roles) through a [grant](/docs/concepts/domain-model/grants).
|
||||
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.
|
||||
|
||||
# Next Steps
|
||||
Be sure Boundary is able to run locally with the instructions at [Getting Started](/docs/getting-started). Then, learn how to create targets and initiate a session with [Connect to Your First Target](/docs/getting-started/connect-to-target).
|
||||
|
||||
# Further Reading
|
||||
For more information see our general recommendations for [deployment architecture](/docs/installing/production) and be sure to stay tuned for our [security model](/docs/concepts/security-model).
|
||||
For more information see our general recommendations for [deployment architecture](/docs/installing/production), and see the [security model](/docs/concepts/security-model) documentation for an explanation of the security foundations of Boundary.
|
||||
@@ -31,6 +31,8 @@ export default [
|
||||
{
|
||||
category: 'concepts',
|
||||
content: [
|
||||
'api-standards',
|
||||
'cli-standards',
|
||||
'security-model',
|
||||
{
|
||||
category: 'domain-model',
|
||||
|
||||
Reference in new issue
Block a user