docs: Deletes website content from repo (#6426)
This commit is contained in:
Dan Heath authored and 
GitHub committed
1 parent
2678013391
commit
c1eae29f24
553 files changed
-61489
No files matched your search
@@ -1,18 +0,0 @@
|
||||
# This file is for unifying the coding style for different editors and IDEs
|
||||
# editorconfig.org
|
||||
|
||||
root = true
|
||||
|
||||
[*]
|
||||
end_of_line = lf
|
||||
charset = utf-8
|
||||
insert_final_newline = true
|
||||
trim_trailing_whitespace = true
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
[Makefile]
|
||||
indent_style = tab
|
||||
|
||||
[{*.md,*.json}]
|
||||
max_line_length = null
|
||||
@@ -1,3 +0,0 @@
|
||||
NEXT_PUBLIC_ALGOLIA_APP_ID=YY0FFNI7MF
|
||||
NEXT_PUBLIC_ALGOLIA_INDEX=product_BOUNDARY
|
||||
NEXT_PUBLIC_ALGOLIA_SEARCH_ONLY_API_KEY=8308498decdf72e11590fc6356e5fdde
|
||||
@@ -1 +0,0 @@
|
||||
HASHI_ENV=production
|
||||
@@ -1,4 +0,0 @@
|
||||
module.exports = {
|
||||
...require('@hashicorp/platform-cli/config/.eslintrc'),
|
||||
ignorePatterns: ['public/'],
|
||||
}
|
||||
@@ -1,6 +0,0 @@
|
||||
node_modules
|
||||
.DS_Store
|
||||
.next
|
||||
out
|
||||
.mdx-data
|
||||
website-preview/
|
||||
@@ -1 +0,0 @@
|
||||
v22
|
||||
@@ -1,9 +0,0 @@
|
||||
/**
|
||||
* Copyright IBM Corp. 2020, 2025
|
||||
* SPDX-License-Identifier: BUSL-1.1
|
||||
*/
|
||||
|
||||
module.exports = {
|
||||
...require('@hashicorp/platform-cli/config/stylelint.config'),
|
||||
/* Specify overrides here */
|
||||
}
|
||||
@@ -1,10 +0,0 @@
|
||||
# Proprietary License
|
||||
|
||||
This license is temporary while a more official one is drafted. However,
|
||||
this should make it clear:
|
||||
|
||||
The text contents of this website are MPL 2.0 licensed.
|
||||
|
||||
The design contents of this website are proprietary and may not be reproduced
|
||||
or reused in any way other than to run the website locally. The license for
|
||||
the design is owned solely by HashiCorp, Inc.
|
||||
@@ -1,61 +0,0 @@
|
||||
######################################################
|
||||
# NOTE: This file is managed by the Digital Team's #
|
||||
# Terraform configuration @ hashicorp/mktg-terraform #
|
||||
######################################################
|
||||
|
||||
.DEFAULT_GOAL := website
|
||||
|
||||
# Set the preview mode for the website shell to "developer" or "io"
|
||||
PREVIEW_MODE ?= developer
|
||||
REPO ?= boundary
|
||||
|
||||
# Enable setting alternate docker tool, e.g. 'make DOCKER_CMD=podman'
|
||||
DOCKER_CMD ?= docker
|
||||
|
||||
CURRENT_GIT_BRANCH=$$(git rev-parse --abbrev-ref HEAD)
|
||||
LOCAL_CONTENT_DIR=
|
||||
PWD=$$(pwd)
|
||||
|
||||
DOCKER_IMAGE="hashicorp/dev-portal"
|
||||
DOCKER_IMAGE_LOCAL="dev-portal-local"
|
||||
DOCKER_RUN_FLAGS=-it \
|
||||
--publish "3000:3000" \
|
||||
--rm \
|
||||
--tty \
|
||||
--volume "$(PWD)/content:/app/content" \
|
||||
--volume "$(PWD)/public:/app/public" \
|
||||
--volume "$(PWD)/data:/app/data" \
|
||||
--volume "$(PWD)/redirects.js:/app/redirects.js" \
|
||||
--volume "$(PWD)/../internal/gen:/internal/gen" \
|
||||
--volume "next-dir:/app/website-preview/.next" \
|
||||
--volume "$(PWD)/.env:/app/.env" \
|
||||
--volume "$(PWD)/.env.development:/app/website-preview/.env.development" \
|
||||
--volume "$(PWD)/.env.local:/app/website-preview/.env.local" \
|
||||
-e "REPO=$(REPO)" \
|
||||
-e "PREVIEW_FROM_REPO=$(REPO)" \
|
||||
-e "IS_CONTENT_PREVIEW=true" \
|
||||
-e "LOCAL_CONTENT_DIR=$(LOCAL_CONTENT_DIR)" \
|
||||
-e "CURRENT_GIT_BRANCH=$(CURRENT_GIT_BRANCH)" \
|
||||
-e "PREVIEW_MODE=$(PREVIEW_MODE)"
|
||||
|
||||
# Default: run this if working on the website locally to run in watch mode.
|
||||
.PHONY: website
|
||||
website:
|
||||
@echo "==> Downloading latest Docker image..."
|
||||
@$(DOCKER_CMD) pull $(DOCKER_IMAGE)
|
||||
@echo "==> Starting website..."
|
||||
@$(DOCKER_CMD) run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE)
|
||||
|
||||
# Use this if you have run `website/build-local` to use the locally built image.
|
||||
.PHONY: website/local
|
||||
website/local:
|
||||
@echo "==> Starting website from local image..."
|
||||
@$(DOCKER_CMD) run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE_LOCAL)
|
||||
|
||||
# Run this to generate a new local Docker image.
|
||||
.PHONY: website/build-local
|
||||
website/build-local:
|
||||
@echo "==> Building local Docker image"
|
||||
@$(DOCKER_CMD) build https://github.com/hashicorp/dev-portal.git\#main \
|
||||
-t $(DOCKER_IMAGE_LOCAL)
|
||||
|
||||
@@ -1,538 +0,0 @@
|
||||
# Boundary Documentation Website
|
||||
|
||||
[!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation, which were located in this repository under `/website`, are now located in [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs), colocated with all other product documentation. Contributions to this content should be done in the `web-unified-docs` repo, and not this one. Changes made to `/website` content in this repo will not be reflected on the developer.hashicorp.com website.
|
||||
|
||||
This subdirectory contains the content for the [Boundary Website](https://developer.hashicorp.com/boundary/).
|
||||
|
||||
<!--
|
||||
This readme file contains several blocks of generated text, to make it easier to share common information
|
||||
across documentation website readmes. To generate these blocks from their source, run `npm run generate:readme`
|
||||
|
||||
Any edits to the readme are welcome outside the clearly noted boundaries of the blocks. Alternately, a
|
||||
block itself can be safely "forked" from the central implementation simply by removing the "BEGIN" and
|
||||
"END" comments from around it.
|
||||
-->
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Boundary Documentation Website](#boundary-documentation-website)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Contributions Welcome!](#contributions-welcome)
|
||||
- [Running the Site Locally](#running-the-site-locally)
|
||||
- [Editing Markdown Content](#editing-markdown-content)
|
||||
- [Creating New Pages](#creating-new-pages)
|
||||
- [Markdown Enhancements](#markdown-enhancements)
|
||||
- [Custom Components](#custom-components)
|
||||
- [Tabs](#tabs)
|
||||
- [Enterprise Alert](#enterprise-alert)
|
||||
- [Other Components](#other-components)
|
||||
- [Syntax Highlighting](#syntax-highlighting)
|
||||
- [Editing Navigation Sidebars](#editing-navigation-sidebars)
|
||||
- [Index-less Categories](#index-less-categories)
|
||||
- [Custom or External Links](#custom-or-external-links)
|
||||
- [Editing/Enabling the Alert Banner](#editingenabling-the-alert-banner)
|
||||
- [Changing the Release Version](#changing-the-release-version)
|
||||
- [Displaying a Prerelease](#displaying-a-prerelease)
|
||||
- [Redirects](#redirects)
|
||||
- [Browser Support](#browser-support)
|
||||
- [Deployment](#deployment)
|
||||
|
||||
<!-- BEGIN: contributions -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Contributions Welcome!
|
||||
|
||||
If you find a typo or you feel like you can improve the HTML, CSS, or JavaScript, we welcome contributions. Feel free to open issues or pull requests like any normal GitHub project, and we'll merge it in 🚀
|
||||
|
||||
<!-- END: contributions -->
|
||||
|
||||
## Running the Site Locally
|
||||
|
||||
The website can be run locally through [node.js](https://nodejs.org). It works with any supported version. Node.js [can be installed quickly and easily via universal binary](https://nodejs.org).
|
||||
|
||||
The first time you are running the site, you will need to run the command `npm install` to install dependencies. Any time after this, `npm start` can be used to run the site locally. It can be seen at `http://localhost:3000`. We also provide a Docker-based workflow to run the site locally. Just run `make`! As you change content, the website will automatically reload to show the latest content.
|
||||
|
||||
<!-- BEGIN: editing-markdown -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Editing Markdown Content
|
||||
|
||||
Documentation content is written in [Markdown](https://www.markdownguide.org/cheat-sheet/) and you'll find all files listed under the `/content` directory.
|
||||
|
||||
To create a new page with Markdown, create a file ending in `.mdx` in a `content/<subdirectory>`. The path in the content directory will be the URL route. For example, `content/docs/hello.mdx` will be served from the `/docs/hello` URL.
|
||||
|
||||
> **Important**: Files and directories will only be rendered and published to the website if they are [included in sidebar data](#editing-navigation-sidebars). Any file not included in sidebar data will not be rendered or published.
|
||||
|
||||
This file can be standard Markdown and also supports [YAML frontmatter](https://middlemanapp.com/basics/frontmatter/). YAML frontmatter is optional, there are defaults for all keys.
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: 'My Title'
|
||||
description: "A thorough, yet succinct description of the page's contents"
|
||||
---
|
||||
```
|
||||
|
||||
The significant keys in the YAML frontmatter are:
|
||||
|
||||
- `title` `(string)` - This is the title of the page that will be set in the HTML title.
|
||||
- `description` `(string)` - This is a description of the page that will be set in the HTML description.
|
||||
|
||||
> ⚠️ If there is a need for a `/api/*` url on this website, the url will be changed to `/api-docs/*`, as the `api` folder is reserved by next.js.
|
||||
|
||||
### Validating Content
|
||||
|
||||
Content changes are automatically validated against a set of rules as part of the pull request process. If you want to run these checks locally to validate your content before comitting your changes, you can run the following command:
|
||||
|
||||
```
|
||||
npm run content-check
|
||||
```
|
||||
|
||||
If the validation fails, actionable error messages will be displayed to help you address detected issues.
|
||||
|
||||
### Creating New Pages
|
||||
|
||||
There is currently a small bug with new page creation - if you create a new page and link it up via subnav data while the server is running, it will report an error saying the page was not found. This can be resolved by restarting the server.
|
||||
|
||||
### Markdown Enhancements
|
||||
|
||||
There are several custom markdown plugins that are available by default that enhance [standard markdown](https://commonmark.org/) to fit our use cases. This set of plugins introduces a couple instances of custom syntax, and a couple specific pitfalls that are not present by default with markdown, detailed below:
|
||||
|
||||
- > **Warning**: We are deprecating the current [paragraph alerts](https://github.com/hashicorp/remark-plugins/tree/master/plugins/paragraph-custom-alerts#paragraph-custom-alerts), in favor of the newer [MDX Inline Alert](#inline-alerts) components. The legacy paragraph alerts are represented by the symbols `~>`, `->`, `=>`, or `!>`.
|
||||
- If you see `@include '/some/path.mdx'`, this is a [markdown include](https://github.com/hashicorp/remark-plugins/tree/master/plugins/include-markdown#include-markdown-plugin). It's worth noting as well that all includes resolve from `website/content/partials` by default, and that changes to partials will not live-reload the website.
|
||||
- If you see `# Headline ((#slug))`, this is an example of an [anchor link alias](https://github.com/hashicorp/remark-plugins/tree/je.anchor-link-adjustments/plugins/anchor-links#anchor-link-aliases). It adds an extra permalink to a headline for compatibility and is removed from the output.
|
||||
- Due to [automatically generated permalinks](https://github.com/hashicorp/remark-plugins/tree/je.anchor-link-adjustments/plugins/anchor-links#anchor-links), any text changes to _headlines_ or _list items that begin with inline code_ can and will break existing permalinks. Be very cautious when changing either of these two text items.
|
||||
|
||||
Headlines are fairly self-explanatory, but here's an example of how to list items that begin with inline code look.
|
||||
|
||||
```markdown
|
||||
- this is a normal list item
|
||||
- `this` is a list item that begins with inline code
|
||||
```
|
||||
|
||||
Its worth noting that _only the inline code at the beginning of the list item_ will cause problems if changed. So if you changed the above markup to...
|
||||
|
||||
```markdown
|
||||
- lsdhfhksdjf
|
||||
- `this` jsdhfkdsjhkdsfjh
|
||||
```
|
||||
|
||||
...while it perhaps would not be an improved user experience, no links would break because of it. The best approach is to **avoid changing headlines and inline code at the start of a list item**. If you must change one of these items, make sure to tag someone from the digital marketing development team on your pull request, they will help to ensure as much compatibility as possible.
|
||||
|
||||
### Custom Components
|
||||
|
||||
A number of custom [mdx components](https://mdxjs.com/) are available for use within any `.mdx` file. Each one is documented below:
|
||||
|
||||
#### Inline Alerts
|
||||
|
||||
There are custom MDX components available to author alert data. [See the full documentation here](https://developer.hashicorp.com/swingset/components/mdxinlinealert). They render as colored boxes to draw the user's attention to some type of aside.
|
||||
|
||||
```mdx
|
||||
## Alert types
|
||||
|
||||
### Tip
|
||||
|
||||
<Tip>
|
||||
To provide general information to the user regarding the current context or
|
||||
relevant actions.
|
||||
</Tip>
|
||||
|
||||
### Highlight
|
||||
|
||||
<Highlight>
|
||||
To provide general or promotional information to the user prominently.
|
||||
</Highlight>
|
||||
|
||||
### Note
|
||||
|
||||
<Note>
|
||||
To help users avoid an issue. Provide guidance and actions if possible.
|
||||
</Note>
|
||||
|
||||
### Warning
|
||||
|
||||
<Warning>
|
||||
To indicate critical issues that need immediate action or help users
|
||||
understand something critical.
|
||||
</Warning>
|
||||
|
||||
## Title override prop
|
||||
|
||||
<Note title="Hashiconf 2027">To provide general information.</Note>
|
||||
```
|
||||
|
||||
#### Tabs
|
||||
|
||||
The `Tabs` component creates tabbed content of any type, but is often used for code examples given in different languages. Here's an example of how it looks from the Vagrant documentation website:
|
||||
|
||||
|
||||
|
||||
> Please refer to the [Swingset](https://react-components.vercel.app/?component=Tabs) documentation for the latest examples and API reference.
|
||||
|
||||
It can be used as such within a markdown file:
|
||||
|
||||
````mdx
|
||||
Normal **markdown** content.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="CLI command">
|
||||
<!-- Intentionally skipped line.. -->
|
||||
```shell-session
|
||||
$ command ...
|
||||
```
|
||||
<!-- Intentionally skipped line.. -->
|
||||
</Tab>
|
||||
<Tab heading="API call using cURL">
|
||||
|
||||
```shell-session
|
||||
$ curl ...
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Continued normal markdown content
|
||||
````
|
||||
|
||||
The intentionally skipped line is a limitation of the mdx parser which is being actively worked on. All tabs must have a heading, and there is no limit to the number of tabs, though it is recommended to go for a maximum of three or four.
|
||||
|
||||
#### Enterprise Alert
|
||||
|
||||
This component provides a standard way to call out functionality as being present only in the enterprise version of the software. It can be presented in two contexts, inline or standalone. Here's an example of standalone usage from the Consul docs website:
|
||||
|
||||
|
||||
|
||||
The standalone component can be used as such in markdown files:
|
||||
|
||||
```mdx
|
||||
# Page Headline
|
||||
|
||||
<EnterpriseAlert />
|
||||
|
||||
Continued markdown content...
|
||||
```
|
||||
|
||||
It can also receive custom text contents if you need to change the messaging but wish to retain the style. This will replace the text `This feature is available in all versions of Consul Enterprise.` with whatever you add. For example:
|
||||
|
||||
```mdx
|
||||
# Page Headline
|
||||
|
||||
<EnterpriseAlert>
|
||||
My custom text here, and <a href="#">a link</a>!
|
||||
</EnterpriseAlert>
|
||||
|
||||
Continued markdown content...
|
||||
```
|
||||
|
||||
It's important to note that once you are adding custom content, it must be html and can not be markdown, as demonstrated above with the link.
|
||||
|
||||
Now let's look at inline usage, here's an example:
|
||||
|
||||
|
||||
|
||||
And here's how it could be used in your markdown document:
|
||||
|
||||
```mdx
|
||||
### Some Enterprise Feature <EnterpriseAlert inline />
|
||||
|
||||
Continued markdown content...
|
||||
```
|
||||
|
||||
It's also worth noting that this component will automatically adjust to the correct product colors depending on the context.
|
||||
|
||||
#### Other Components
|
||||
|
||||
Other custom components can be made available on a per-site basis, the above are the standards. If you have questions about custom components that are not documented here, or have a request for a new custom component, please reach out to @hashicorp/digital-marketing.
|
||||
|
||||
### Syntax Highlighting
|
||||
|
||||
When using fenced code blocks, the recommendation is to tag the code block with a language so that it can be syntax highlighted. For example:
|
||||
|
||||
````
|
||||
```
|
||||
// BAD: Code block with no language tag
|
||||
```
|
||||
|
||||
```javascript
|
||||
// GOOD: Code block with a language tag
|
||||
```
|
||||
````
|
||||
|
||||
Check out the [supported languages list](https://prismjs.com/#supported-languages) for the syntax highlighter we use if you want to double check the language name.
|
||||
|
||||
It is also worth noting specifically that if you are using a code block that is an example of a terminal command, the correct language tag is `shell-session`. For example:
|
||||
|
||||
🚫**BAD**: Using `shell`, `sh`, `bash`, or `plaintext` to represent a terminal command
|
||||
|
||||
````
|
||||
```shell
|
||||
$ terraform apply
|
||||
```
|
||||
````
|
||||
|
||||
✅**GOOD**: Using `shell-session` to represent a terminal command
|
||||
|
||||
````
|
||||
```shell-session
|
||||
$ terraform apply
|
||||
```
|
||||
````
|
||||
|
||||
<!-- END: editing-markdown -->
|
||||
|
||||
<!-- BEGIN: editing-docs-sidebars -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Editing Navigation Sidebars
|
||||
|
||||
The structure of the sidebars are controlled by files in the [`/data` directory](data). For example, [data/docs-nav-data.json](data/docs-nav-data.json) controls the **docs** sidebar. Within the `data` folder, any file with `-nav-data` after it controls the navigation for the given section.
|
||||
|
||||
The sidebar uses a simple recursive data structure to represent _files_ and _directories_. The sidebar is meant to reflect the structure of the docs within the filesystem while also allowing custom ordering. Let's look at an example. First, here's our example folder structure:
|
||||
|
||||
```text
|
||||
.
|
||||
├── docs
|
||||
│ └── directory
|
||||
│ ├── index.mdx
|
||||
│ ├── file.mdx
|
||||
│ ├── another-file.mdx
|
||||
│ └── nested-directory
|
||||
│ ├── index.mdx
|
||||
│ └── nested-file.mdx
|
||||
```
|
||||
|
||||
Here's how this folder structure could be represented as a sidebar navigation, in this example it would be the file `website/data/docs-nav-data.json`:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"title": "Directory",
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
"path": "directory"
|
||||
},
|
||||
{
|
||||
"title": "File",
|
||||
"path": "directory/file"
|
||||
},
|
||||
{
|
||||
"title": "Another File",
|
||||
"path": "directory/another-file"
|
||||
},
|
||||
{
|
||||
"title": "Nested Directory",
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
"path": "directory/nested-directory"
|
||||
},
|
||||
{
|
||||
"title": "Nested File",
|
||||
"path": "directory/nested-directory/nested-file"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
A couple more important notes:
|
||||
|
||||
- Within this data structure, ordering is flexible, but hierarchy is not. The structure of the sidebar must correspond to the structure of the content directory. So while you could put `file` and `another-file` in any order in the sidebar, or even leave one or both of them out, you could not decide to un-nest the `nested-directory` object without also un-nesting it in the filesystem.
|
||||
- The `title` property on each node in the `nav-data` tree is the human-readable name in the navigation.
|
||||
- The `path` property on each leaf node in the `nav-data` tree is the URL path where the `.mdx` document will be rendered, and the
|
||||
- Note that "index" files must be explicitly added. These will be automatically resolved, so the `path` value should be, as above, `directory` rather than `directory/index`. A common convention is to set the `title` of an "index" node to be `"Overview"`.
|
||||
|
||||
Below we will discuss a couple of more unusual but still helpful patterns.
|
||||
|
||||
### Index-less Categories
|
||||
|
||||
Sometimes you may want to include a category but not have a need for an index page for the category. This can be accomplished, but as with other branch and leaf nodes, a human-readable `title` needs to be set manually. Here's an example of how an index-less category might look:
|
||||
|
||||
```text
|
||||
.
|
||||
├── docs
|
||||
│ └── indexless-category
|
||||
│ └── file.mdx
|
||||
```
|
||||
|
||||
```json
|
||||
// website/data/docs-nav-data.json
|
||||
[
|
||||
{
|
||||
"title": "Indexless Category",
|
||||
"routes": [
|
||||
{
|
||||
"title": "File",
|
||||
"path": "indexless-category/file"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### Custom or External Links
|
||||
|
||||
Sometimes you may have a need to include a link that is not directly to a file within the docs hierarchy. This can also be supported using a different pattern. For example:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"name": "Directory",
|
||||
"routes": [
|
||||
{
|
||||
"title": "File",
|
||||
"path": "directory/file"
|
||||
},
|
||||
{
|
||||
"title": "Another File",
|
||||
"path": "directory/another-file"
|
||||
},
|
||||
{
|
||||
"title": "Tao of HashiCorp",
|
||||
"href": "https://www.hashicorp.com/tao-of-hashicorp"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
If the link provided in the `href` property is external, it will display a small icon indicating this. If it's internal, it will appear the same way as any other direct file link.
|
||||
|
||||
<!-- END: editing-docs-sidebars -->
|
||||
|
||||
## Editing/Enabling the Alert Banner
|
||||
|
||||
The data and visibility of the alert banner are controlled by the `alert-banner.js` file in the [`/data` directory](data). The following data can be edited in this file:
|
||||
|
||||
- `ALERT_BANNER_ACTIVE`: Determines if the banner is visible (when set to `true`) or not (when set to `false`).
|
||||
- `tag`: Copy for the bordered text on the left side of the alert.
|
||||
- `text`: Copy for the center text of the alert.
|
||||
- `url`: Where the alert links to when clicked.
|
||||
|
||||
<!-- BEGIN: releases -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Changing the Release Version
|
||||
|
||||
To change the version displayed for download on the website, head over to `data/version.js` and change the number there. It's important to note that the version number must match a version that has been released and is live on `releases.hashicorp.com` -- if it does not, the website will be unable to fetch links to the binaries and will not compile. So this version number should be changed _only after a release_.
|
||||
|
||||
### Displaying a Prerelease
|
||||
|
||||
If there is a prerelease of any type that should be displayed on the downloads page, this can be done by editing `pages/downloads/index.jsx`. By default, the download component might look something like this:
|
||||
|
||||
```jsx
|
||||
<ProductDownloader
|
||||
product="<Product>"
|
||||
version={VERSION}
|
||||
downloads={downloadData}
|
||||
community="/resources"
|
||||
/>
|
||||
```
|
||||
|
||||
To add a prerelease, an extra `prerelease` property can be added to the component as such:
|
||||
|
||||
```jsx
|
||||
<ProductDownloader
|
||||
product="<Product>"
|
||||
version={VERSION}
|
||||
downloads={downloadData}
|
||||
community="/resources"
|
||||
prerelease={{
|
||||
type: 'release candidate', // the type of prerelease: beta, release candidate, etc.
|
||||
name: 'v1.0.0', // the name displayed in text on the website
|
||||
version: '1.0.0-rc1', // the actual version tag that was pushed to releases.hashicorp.com
|
||||
}}
|
||||
/>
|
||||
```
|
||||
|
||||
This configuration would display something like the following text on the website, emphasis added to the configurable parameters:
|
||||
|
||||
```
|
||||
A {{ release candidate }} for <Product> {{ v1.0.0 }} is available! The release can be <a href='https://releases.hashicorp.com/<product>/{{ 1.0.0-rc1 }}'>downloaded here</a>.
|
||||
```
|
||||
|
||||
You may customize the parameters in any way you'd like. To remove a prerelease from the website, simply delete the `prerelease` parameter from the above component.
|
||||
|
||||
<!-- END: releases -->
|
||||
|
||||
<!-- BEGIN: redirects -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Redirects
|
||||
|
||||
This website structures URLs based on the filesystem layout. This means that if a file is moved, removed, or a folder is re-organized, links will break. If a path change is necessary, it can be mitigated using redirects. It's important to note that redirects should only be used to cover for external links -- if you are moving a path which internal links point to, the internal links should also be adjusted to point to the correct page, rather than relying on a redirect.
|
||||
|
||||
To add a redirect, head over to the `redirects.js` file - the format is fairly simple - there's a `source` and a `destination` - fill them both in, indicate that it's a permanent redirect or not using the `permanent` key, and that's it. Let's look at an example:
|
||||
|
||||
```
|
||||
{
|
||||
source: '/foo',
|
||||
destination: '/bar',
|
||||
permanent: true
|
||||
}
|
||||
```
|
||||
|
||||
This redirect rule will send all incoming links to `/foo` to `/bar`. For more details on the redirects file format, [check out the docs on vercel](https://vercel.com/docs/configuration#project/redirects). All redirects will work both locally and in production exactly the same way, so feel free to test and verify your redirects locally. In the past testing redirects has required a preview deployment -- this is no longer the case. Please note however that if you add a redirect while the local server is running, you will need to restart it in order to see the effects of the redirect.
|
||||
|
||||
There is still one caveat though: redirects do not apply to client-side navigation. By default, all links in the navigation and docs sidebar will navigate purely on the client side, which makes navigation through the docs significantly faster, especially for those with low-end devices and/or weak internet connections. In the future, we plan to convert all internal links within docs pages to behave this way as well. This means that if there is a link on this website to a given piece of content that has changed locations in some way, we need to also _directly change existing links to the content_. This way, if a user clicks a link that navigates on the client side, or if they hit the url directly and the page renders from the server side, either one will work perfectly.
|
||||
|
||||
Let's look at an example. Say you have a page called `/docs/foo` which needs to be moved to `/docs/nested/foo`. Additionally, this is a page that has been around for a while and we know there are links into `/docs/foo.html` left over from our previous website structure. First, we move the page, then adjust the docs sidenav, in `data/docs-navigation.js`. Find the category the page is in, and move it into the appropriate subcategory. Next, we add to `_redirects` as such. The `.html` version is covered automatically.
|
||||
|
||||
```js
|
||||
{ source: '/foo', destination: '/nested/foo', permanent: true }
|
||||
```
|
||||
|
||||
Next, we run a global search for internal links to `/foo`, and make sure to adjust them to be `/nested/foo` - this is to ensure that client-side navigation still works correctly. _Adding a redirect alone is not enough_.
|
||||
|
||||
One more example - let's say that content is being moved to an external website. A common example is guides moving to `learn.hashicorp.com`. In this case, we take all the same steps, except that we need to make a different type of change to the `docs-navigation` file. If previously the structure looked like:
|
||||
|
||||
```js
|
||||
{
|
||||
category: 'docs',
|
||||
content: [
|
||||
'foo'
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
If we no longer want the link to be in the side nav, we can simply remove it. If we do still want the link in the side nav, but pointing to an external destination, we need to slightly change the structure as such:
|
||||
|
||||
```js
|
||||
{
|
||||
category: 'docs',
|
||||
content: [
|
||||
{ title: 'Foo Title', href: 'https://learn.hashicorp.com/<product>/foo' }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
As the majority of items in the side nav are internal links, the structure makes it as easy as possible to represent these links. This alternate syntax is the most concise manner than an external link can be represented. External links can be used anywhere within the docs sidenav.
|
||||
|
||||
It's also worth noting that it is possible to do glob-based redirects, for example matching `/docs/*`, and you may see this pattern in the redirects file. This type of redirect is much higher risk and the behavior is a bit more nuanced, so if you need to add a glob redirect, please reach out to the website maintainers and ask about it first.
|
||||
|
||||
<!-- END: redirects -->
|
||||
|
||||
<!-- BEGIN: browser-support -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Browser Support
|
||||
|
||||
We support the following browsers targeting roughly the versions specified.
|
||||
|
||||
|  |  |  |  |  |
|
||||
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
|
||||
| **Latest** | **Latest** | **Latest** | **Latest** | **Latest** |
|
||||
|
||||
<!-- END: browser-support -->
|
||||
|
||||
<!-- BEGIN: deployment -->
|
||||
<!-- Generated text, do not edit directly -->
|
||||
|
||||
## Deployment
|
||||
|
||||
This website is hosted on Vercel and configured to automatically deploy anytime you push code to the `stable-website` branch. Any time a pull request is submitted that changes files within the `website` folder, a deployment preview will appear in the github checks which can be used to validate the way docs changes will look live. Deployments from `stable-website` will look and behave the same way as deployment previews.
|
||||
|
||||
<!-- END: deployment -->
|
||||
@@ -1,207 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Boundary Desktop overview
|
||||
description: >-
|
||||
Learn how to install the Boundary Desktop application to browse and connect to targets.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Boundary Desktop
|
||||
|
||||
Boundary Desktop is a standalone application that provides a simple interface
|
||||
for browsing and connecting to targets on your local computer (macOS and Windows
|
||||
currently supported). Launch a session in Boundary Desktop and then make a connection
|
||||
using your favorite tooling.
|
||||
|
||||
## Get started
|
||||
|
||||
-> If you're running Boundary for the first time, [download the latest binary](/boundary/downloads)
|
||||
and run it in `dev` mode locally so you can have a server to run against:
|
||||
|
||||
```shell-session
|
||||
$ boundary dev
|
||||
```
|
||||
|
||||
### Install Boundary Desktop
|
||||
|
||||
1. Download the latest .dmg installer or .exe archive from our [releases page](https://releases.hashicorp.com/boundary-desktop). Alternatively, if you're a homebrew user, you can run `brew install hashicorp-boundary-desktop`
|
||||
1. In macOS, double-click the downloaded .dmg to run the installer by draggin and dropping Boundary into the applications folder
|
||||
|
||||
1. In Windows, extract downloaded archive and find .exe to launch
|
||||
|
||||
### Run Boundary Desktop
|
||||
|
||||
1. Open the Boundary Desktop application
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
1. You'll be prompted for the Boundary server origin, this is the URL for the client
|
||||
to connect to the Boundary API. If you are running a local `dev` mode server, this
|
||||
URL will be `http://localhost:9200`
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
1. You can now login to Boundary. We're using a `dev` mode server in this example with the
|
||||
username `admin` and the password `password`
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
1. After logging in, you should see the targets your user is authorized to connect to. Since
|
||||
we are using a `dev` mode server we see the default generated target for `127.0.0.1:22`
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Connect!
|
||||
|
||||
-> The rest of this example assumes you're running Boundary in `dev` mode.
|
||||
|
||||
1. Click on `connect` next to the default target. A pop-up window will display the local
|
||||
address of the proxy and the ephemeral port for the session
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
1. Navigate to the `Sessions` pane and you'll see this session is in `pending` state because we
|
||||
haven't made a connection to it yet (but will!)
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
-> The next step assumes you have a SSH server running that the default target will connect to.
|
||||
|
||||
1. On the CLI, `ssh` to the target using the local ephemeral port created in the previous step
|
||||
|
||||
```shell-session
|
||||
$ ssh -p 49250 127.0.0.1
|
||||
The authenticity of host '[127.0.0.1]:49250 ([127.0.0.1]:49250)' can't be established.
|
||||
ECDSA key fingerprint is SHA256:glO05n2iT8Roqak5G63gMKnW8qsE0lxy0MPWcWC7iqg.
|
||||
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
|
||||
Warning: Permanently added '[127.0.0.1]:49250' (ECDSA) to the list of known hosts.
|
||||
Password:
|
||||
Last login: Thu Feb 11 17:49:09 2021
|
||||
$
|
||||
```
|
||||
|
||||
1. Navigate back to the sessions view and you'll see this session is now active
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
1. Click `Cancel` to cancel the session and you'll see the status go to `canceling` briefly, then `terminated`
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows">
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
1. Navigate back to the CLI and you'll see your SSH session has closed
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: API/Clients
|
||||
description: >-
|
||||
Discover resources to learn more about Boundary's API and clients.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# API and clients
|
||||
|
||||
Boundary is a purely-API-driven system. This section contains information
|
||||
describing its API norms and the clients that HashiCorp provide (apart from the
|
||||
web UI), which include a Go SDK and a Desktop client.
|
||||
@@ -1,115 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: API overview
|
||||
description: >-
|
||||
Learn about Boundary's HTTP API standards, status codes, path layout, methods, and headers. Understand how rate limiting helps manage system resources.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Boundary API overview
|
||||
|
||||
Boundary's API is a JSON-based HTTP API that 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](/boundary/docs/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).
|
||||
|
||||
<Note>
|
||||
|
||||
Refer to the [API page](/boundary/api-docs) for a rendered version of this generated API definition.
|
||||
|
||||
</Note>
|
||||
|
||||
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. Any `delete` actions return `204` on success.
|
||||
- `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 as it allows for far simpler and more robust client implementation.
|
||||
- `405`: Boundary returns a `405` to indicate that the method (HTTP verb or custom action) is not implemented for the given resource.
|
||||
- `429`: Boundary returns a `429` if any of the API rate limit quotas have been exhausted for the resource and action. It includes the `Retry-After` header so that the client knows how long to wait before making a new request.
|
||||
- `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.
|
||||
- `503`: Boundary returns a `503` if it is unable to store a quota due to the API rate limit being exceeded. It includes the `Retry-After` header so that the client knows how long to wait before making a new request.
|
||||
|
||||
## 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 an org-level 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 auth method is an abstract type; a `password` auth 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 resource. 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.
|
||||
|
||||
### DELETE
|
||||
|
||||
`DELETE` is used for deleting a specific resource, and is only used against a particular resource path.
|
||||
|
||||
## HTTP headers
|
||||
|
||||
Clients that make requests to the controller API can inspect HTTP response headers to understand the configured limits and current usage.
|
||||
Responses may contain the following headers:
|
||||
|
||||
- `RateLimit` - Provides the current limit, number of remaining requests, and the time at which the quota will reset for the limit that is closest to being exhausted for the requested resource and action.
|
||||
- `RateLimit-Policy` - Describes the limits for the requested resource and action.
|
||||
- `X-Correlation-ID` - Identifies a transaction over a series of requests and responses.
|
||||
The `X-Correlation-ID` header is a universally unique identifier (UUIDv4).
|
||||
If you provide an `X-Correlation-ID` header in an HTTP request, Boundary logs that value for all audit events related to the request.
|
||||
It then uses that value as the header when it makes related requests to an external system, such as Vault, so that you can correlate the event between the product logs.
|
||||
If you do not provide an `X-Correlation-ID` header, Boundary generates a unique value for each incoming request.
|
||||
|
||||
## Manage system resources
|
||||
|
||||
If your controllers try to process every API request, they may either run out of resources or overwhelm the database server.
|
||||
Boundary features API rate limiting to help prevent system resources from being overwhlemed by too many simultaneous requests.
|
||||
For more information, refer to [API rate limiting](/boundary/docs/api/rate-limiting).
|
||||
|
||||
When you search for Boundary resources using the `list` operation, you could potentially receive a very large number of results.
|
||||
Boundary uses an API pagination feature to enable you to search and filter large lists of search results without overwhelming your system resources.
|
||||
Refer to [API list pagination](/boundary/docs/api/pagination) for more information about pagination and using the local cache for searches.
|
||||
@@ -1,109 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: API list pagination
|
||||
description: >-
|
||||
Learn about API pagination and how the cache works in Boundary to prevent system resources from being overwhelmed and to help you find resources.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# API list pagination
|
||||
|
||||
Boundary uses an API pagination feature to support searching and filtering large lists of results without overwhelming your system resources.
|
||||
|
||||
## Introduction
|
||||
|
||||
When you perform a `list` operation on a resource, the API request returns the first 1000 results, by default.
|
||||
You can request the next page of results by repeating the `list` command and including a parameter with a token provided by Boundary.
|
||||
|
||||
## Initial pagination
|
||||
|
||||
When you run a `list` operation on a resource, the initial results are sorted in descending order by creation time and public ID (most recently created first).
|
||||
Boundary returns the maximum number of responses along with the top-level fields `response_type` and `list_token`.
|
||||
If the `response_type` is `delta`, it means there are more items available in the list.
|
||||
|
||||
List tokens contain general metadata associated with the ongoing pagination.
|
||||
To request the next page of results, run the `list` operation again and include the `list_token` that Boundary provided in the last response.
|
||||
Boundary returns the next page of results with new `response_type` and `list_token` values.
|
||||
|
||||
|
||||
|
||||
You can continue viewing new pages of results using the `list_token` values until the `response_type` reads `complete`.
|
||||
If you compose an invalid token, you receive an invalid token error.
|
||||
|
||||
## Request updated and deleted resources
|
||||
|
||||
When the `response_type` reads `complete`, you have viewed all the results that were available when you ran the initial `list` operation.
|
||||
You can now request any resources that were updated or deleted since you started paginating.
|
||||
|
||||
To refresh the cached list results, make another `list` request using the `list_token` from the previous response.
|
||||
Boundary returns a `response_type` and `list_token` as part of the response, similarly to when you ran the initial operation.
|
||||
If the `response_type` is `delta`, it means there are more items available in the list.
|
||||
You can use the `list_token` as a parameter to continue viewing new pages of results until the `response_type` reads `complete`.
|
||||
|
||||
Boundary also includes the top-level response `removed_ids` as part of the refresh operation.
|
||||
The `removed_ids` response contains the IDs of any resources that were deleted since you began paginating the results of the previous `list` operation.
|
||||
Any resources that have been deleted are included on the first page of results.
|
||||
|
||||
After 30 days, the `list_token` expires and you must make a new `list` request without the token to regenerate the full list of results.
|
||||
If you make a `list` request using a token that has a `create_time` older than 30 days, Boundary treats it as an invalid token and returns an error.
|
||||
|
||||
## Response structure
|
||||
|
||||
All `list` endpoints support the following parameters:
|
||||
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not include a value, or if you include a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
|
||||
Boundary returns the following response parameters:
|
||||
|
||||
- `response_type` - Defines whether the response is a `delta` or `complete` listing.
|
||||
The value is `delta` until the last page is returned, at which point it will be `complete`.
|
||||
- `list_token` - An opaque token which is included in subsequent listing requests after the initial one, so that the client can continue to paginate the results.
|
||||
- `sort_by` - The column name that the returned items should be sorted on.
|
||||
This attribute is included in the response, so that the sort order for each endpoint is explicit.
|
||||
- `sort_dir` - The direction in which the returned items are sorted.
|
||||
Responses can include `desc` for descending, or `asc` for ascending.
|
||||
- `items` - The list of items.
|
||||
- `est_item_count` - An unsigned integer that indicates the total number of items that are available in the list of results.
|
||||
This number may be an estimate, since the number of items may change during the pagination process.
|
||||
|
||||
### Example response
|
||||
|
||||
```json
|
||||
{
|
||||
"response_type": "<delta|complete>",
|
||||
"list_token": "<opaque-token>",
|
||||
"sort_by": "created_time",
|
||||
"sort_dir": "desc",
|
||||
"est_item_count": 1000,
|
||||
"items": [
|
||||
{
|
||||
"id": "ttcp_1234567890",
|
||||
"scope_id": "p_1234567890"
|
||||
},
|
||||
{
|
||||
"id": "ttcp_2234567890",
|
||||
"scope_id": "p_1234567890"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Constraints and limitations
|
||||
|
||||
In scenarios where updates are so frequent that the results may change while the refresh operation runs, those updates may not appear at all in the refreshed list.
|
||||
If you make frequent updates to a resource, or if you are updating data while you run a `list` operation, HashiCorp recommends that you generate the full list of results instead of performing a refresh.
|
||||
|
||||
Workers are not included in refresh operations because the updates they send to the controller are too frequent to be captured in a refresh.
|
||||
To update a list of worker resources, you must regenerate the full list of results.
|
||||
|
||||
When you refresh the list of results, you may notice duplicate items in the list.
|
||||
This is a fundamental tradeoff when you search across multiple database transactions.
|
||||
@@ -1,204 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: API rate limiting
|
||||
description: >-
|
||||
Learn how API rate limiting lets you configure limits on the rates of API requests in Boundary to help manage resources and prevent them from being overwhelmed.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Rate limiting
|
||||
|
||||
If your controllers try to process every API request, it can lead to situations when the controllers are overwhelmed with requests.
|
||||
The controllers may either run out of resources or overwhelm the database server and exhaust its resources.
|
||||
API rate limiting lets you configure limits on the rate of API requests to help manage your resources and prevent them from being overwhelmed.
|
||||
|
||||
## Quotas
|
||||
|
||||
Boundary creates quotas to track the number of requests in a given time period.
|
||||
By default, Boundary tracks the number of requests by auth token, IP address, and the overall total.
|
||||
Boundary reserves a portion of its memory for tracking quotas to ensure that it does not consume too much memory if there is a sudden burst of requests.
|
||||
|
||||
If Boundary is unable to store a quota, it limits the request with a 503 HTTP status code.
|
||||
You can configure the maximum number of quotas Boundary allows using the `api_rate_limit_max_quotas` variable.
|
||||
There are also two metrics that allow you to monitor quota tracking:
|
||||
|
||||
- `boundary_controller_api_ratelimiter_quota_storage_capacity`
|
||||
- `boundary_controller_api_ratelimiter_quota_storage_usage`
|
||||
|
||||
## Default limits
|
||||
|
||||
API rate limiting is enforced on the controllers.
|
||||
There are separate configurable limits for each combination of resource and action.
|
||||
By default, the limits for `list` actions are:
|
||||
|
||||
- 150 requests per 30 seconds per auth token
|
||||
- 1,500 requests per 30 seconds per IP address
|
||||
- 1,500 requests per 30 seconds in total
|
||||
|
||||
The default limits for all other actions are:
|
||||
|
||||
- 3,000 requests per 30 seconds per auth token
|
||||
- 30,000 requests per 30 seconds per IP address
|
||||
- 30,000 requests per 30 seconds in total
|
||||
|
||||
You can override the default settings and configure other specific limitations using the `api_rate_limit` stanza in the controller configuration.
|
||||
|
||||
## Rate limiting HTTP headers
|
||||
|
||||
Clients that make requests to the controller API can inspect HTTP response headers to understand the configured limits and current usage.
|
||||
Each response contains the `RateLimit` and `RateLimit-Policy` headers.
|
||||
|
||||
If the request is rate limited, Boundary sends the client a 429 HTTP status code with a `Retry-After` header.
|
||||
The `Retry-After` header contains the number of seconds the client should wait before it sends the request again.
|
||||
|
||||
For more information, refer to [HTTP headers](/boundary/docs/api#http-headers).
|
||||
|
||||
## More information
|
||||
|
||||
Refer to the [controller stanza](/boundary/docs/configuration/controller#api_rate_limit) documentation for the specific `api_rate_limit` configuration options.
|
||||
Some example configurations are listed below.
|
||||
|
||||
### Rate limiting configuration examples
|
||||
|
||||
The following example shows a simple configuration where the same limits are applied to all resources and examples:
|
||||
|
||||
```hcl
|
||||
controller {
|
||||
# Total limit for all resources and actions
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["*"]
|
||||
per = "total"
|
||||
limit = 500
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Limit for all IP addresses to all resources and actions to prevent a
|
||||
# malicious host that is fabricating tokens or spamming unauthed endpoints
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["*"]
|
||||
per = "ip-address"
|
||||
limit = 100
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Limit for all authed requests to prevent one user
|
||||
# from consuming all of the total limit
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["*"]
|
||||
per = "auth-token"
|
||||
limit = 100
|
||||
period = "1s"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The following example shows a configuration that disables rate limiting.
|
||||
You may want to disable rate limiting if you already use an external system like a reverse proxy to apply rate limiting:
|
||||
|
||||
```hcl
|
||||
controller {
|
||||
api_rate_limit_disable = true
|
||||
}
|
||||
```
|
||||
|
||||
The following example uses the default settings for most endpoints, but configures a single override:
|
||||
|
||||
```hcl
|
||||
controller {
|
||||
api_rate_limit {
|
||||
resources = ["target"]
|
||||
actions = ["list"]
|
||||
per = "auth-token"
|
||||
limit = 10
|
||||
period = "1s"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The following example is more complex.
|
||||
Initially it sets some defaults to apply to all resources and actions.
|
||||
Then it configures some specific endpoints with different limits.
|
||||
|
||||
```hcl
|
||||
controller {
|
||||
# Total limit for all resources and actions
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["*"]
|
||||
per = "total"
|
||||
limit = 500
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Total limit for all list operations,
|
||||
# sets an overall cap on the list action since it is relatively expensive
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["list"]
|
||||
per = "total"
|
||||
limit = 200
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Limit for IP address to all resources and actions
|
||||
# to prevent a malicious host that is fabricating tokens
|
||||
# or spamming unauthed endpoints
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["*"]
|
||||
per = "ip-address"
|
||||
limit = 50
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Limit of all authed requests, this essentially sets a default
|
||||
# for all authed requests to prevent one user from consuming
|
||||
# all of the total list limit set above. Any limits that follow
|
||||
# can override the default for specific sets of resources and actions
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["*"]
|
||||
per = "auth-token"
|
||||
limit = 100
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Limit of all list operations by auth token to set a sane default
|
||||
# since they are generally more expensive
|
||||
api_rate_limit {
|
||||
resources = ["*"]
|
||||
actions = ["list"]
|
||||
per = "auth-token"
|
||||
limit = 50
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
# Limit for targets and sessions list by auth token. These are resources
|
||||
# that clients will want to list frequently, but might be more expensive
|
||||
# if there is a large number of them for each user. Having a lower limit
|
||||
# encourages the use of refresh tokens and caching.
|
||||
api_rate_limit {
|
||||
resources = ["target", "session"]
|
||||
actions = ["list"]
|
||||
per = "auth-token"
|
||||
limit = 20
|
||||
period = "1s"
|
||||
}
|
||||
|
||||
#Limit for authorize session by auth token
|
||||
api_rate_limit {
|
||||
resources = ["target"]
|
||||
actions = ["authorize-session"]
|
||||
per = "auth-token"
|
||||
limit = 150
|
||||
period = "1s"
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Fault tolerance recommendations
|
||||
description: >-
|
||||
Understand Boundary fault tolerance recommendations to increase availability, reduce risk. Minimize the impact of node, availability zone, and regional failures.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Fault tolerance recommendations
|
||||
|
||||
Review the following fault tolerance recommendations to ensure increased availability and reduced risk.
|
||||
|
||||
## Node failure
|
||||
|
||||
Boundary controllers store all state and configuration within a PostgreSQL database that must not be deployed on the controller nodes.
|
||||
When a controller node fails, users are still able to interact with other Boundary controllers, assuming the presence of additional nodes behind a load balancer.
|
||||
|
||||
Boundary workers are used as either proxies or reverse proxies.
|
||||
Boundary workers routinely communicate with Boundary controllers to report their health.
|
||||
In the event of a Boundary worker node failure, it is a best practice to have at least three Boundary workers per network boundary, per type (ingress and egress).
|
||||
Therefore, the controller assigns a user's proxy session to an active Boundary worker node.
|
||||
|
||||
## Availability zone failure
|
||||
|
||||
By deploying Boundary controllers in the recommended architecture across three availability zones with load balancing in front of them, the Boundary control plane can survive outages in up to two availability zones.
|
||||
|
||||
The best practice for deploying Boundary workers is to have at least one worker deployed per availability zone.
|
||||
In the case of an availability zone outage, if the networking service is still up, users will have their attempted session connection proxied through a worker in a different availability zone and then onto the target, granted the proper security rules are in place to allow for cross subnet/availability zone communication.
|
||||
|
||||
## Regional failures
|
||||
|
||||
Generally speaking, when there is a failure in an entire cloud region, the resources running in that region are most likely inaccessible, especially if the networking service is affected.
|
||||
|
||||
To continue to serve Boundary controller requests in the event of a regional outage, there must be a deployment like the one outlined in this guide in a different region.
|
||||
The nodes in the secondary region must be able to communicate with the PostgreSQL database, which can be accomplished with multi-regional database technologies from the various cloud providers (for example AWS RDS Read Replicas, where a read replica can be promoted to a primary in the event the primary resides in a failed region).
|
||||
|
||||
Another point of consideration is how to handle load balancing Boundary controller requests to regions that are not in a failed state.
|
||||
Services like AWS Global Accelerator for AWS, Cross-Region Load Balancer for Azure, and GCP Cloud Load Balancer for GCP all provide this level of functionality with some configuration.
|
||||
|
||||
Refer to your cloud provider's documentation for additional information regarding multi-region disaster recovery strategies for PostgreSQL.
|
||||
|
||||
In the case of a regional outage, if a Boundary worker cannot reach its upstream worker, cannot reach a controller, a user cannot reach the worker, or any combination of the above, the user is not able to establish a proxied session to the target.
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: High availability installation
|
||||
description: >-
|
||||
Learn about network requirements and architecture to set up Boundary for high availability, including database, load balancer, and configuration best practices.
|
||||
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# High availability installation
|
||||
|
||||
Installing Boundary as a high availability service requires certain infrastructure considerations. At the most basic level, running 3 controller and 3 worker instances gives a fundamental level of high availability for the control plane (controller), as well as bandwidth for a number of sessions on the data plane (worker). Both server types should be run in a fault-tolerant configuration, that is, in a self-healing environment such as an auto-scaling group. The documentation here does not cover self-healing infrastructure and assumes the operator has their preferred scheduling methods for these environments.
|
||||
|
||||
## Network requirements
|
||||
|
||||
The following ports should be available:
|
||||
|
||||
- Clients must have access to the Controller's `api` port (default 9200)
|
||||
- Clients must have access to the Worker's port (default 9202)
|
||||
- Workers must have access to the Controller's `cluster` port (default 9201)
|
||||
- Workers must have a route and port access to the hosts defined within the system to provide connectivity
|
||||
|
||||
## Architecture
|
||||
|
||||
The general architecture for the server infrastructure requires 3 controllers and 3 workers. Note that it is possible to run a controller and worker within the same process, but the guide here assumes separate deployments. The documentation here uses virtual machines running on Amazon EC2 as the example environment, but this use case can be extrapolated to almost any cloud platform to suit operator needs:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in
|
||||
3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate availability zones, with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independent [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity.
|
||||
|
||||
The workers must be able to establish a connection to the hosts with which they interact. In the architecture above, we place them in the public subnet so our remote client can establish a session between them and the target VM.
|
||||
|
||||
Boundary requires an external [Postgres](https://www.postgresql.org/) and [KMS](https://aws.amazon.com/kms/). In the example above, we're using AWS managed services for these components. For Postgres, we're using [RDS](https://aws.amazon.com/rds/) and for KMS we're using Amazon's [Key Management Service](https://aws.amazon.com/kms/).
|
||||
|
||||
### Database
|
||||
|
||||
Boundary controllers must be able to reach the PostgreSQL database.
|
||||
If you use a high availability (HA) configuration, then the controllers must have access to the PostgreSQL server infrastructure.
|
||||
|
||||
For more information about configuring the Postgres database for HA, refer to the [Postgres high availability, load balancing, and replication documentation](https://www.postgresql.org/docs/current/high-availability.html).
|
||||
If you use a managed service, refer to your provider's PostgreSQL high availability documentation.
|
||||
|
||||
### API and console load balancer
|
||||
|
||||
Load balancing the controller allows operators to secure the ingress to the Boundary system. We recommend placing all Boundary servers in private networks and using load balancing techniques to expose services such as the API and administrative console to public networks. In the high availability architecture, we recommend load balancing using a layer 7 load balancer and further constraining ingress to that load balancer with layer 4 constraints such as [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) or [IP tables](https://wiki.archlinux.org/index.php/Iptables).
|
||||
|
||||
For general configuration, we recommend the following:
|
||||
|
||||
- HTTPS listener with valid TLS certificate for the domain it's serving or TLS passthrough
|
||||
- Health checks should use TCP port 9200
|
||||
|
||||
### Controller configuration
|
||||
|
||||
When running Boundary controller as a service we recommend storing the file at `/etc/boundary.d/boundary-controller.hcl`. A `boundary` user and group should exist to manage this configuration file and to further restrict who can read and modify it.
|
||||
|
||||
For detailed configuration options, see our [configuration docs](/boundary/docs/configuration).
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Recommended architecture
|
||||
description: >-
|
||||
Learn about the recommended architectures for two main Boundary user workflows: an administrator configuring Boundary and an end user connecting to a target.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Recommended architecture
|
||||
|
||||
Boundary has two main user workflows to consider when you deploy it to production.
|
||||
|
||||
## Administrative workflow
|
||||
|
||||
The first is the Boundary administration workflow, where an administrator uses either the Boundary CLI or GUI to configure Boundary.
|
||||
In this scenario, the administrator interfaces solely with the Boundary controllers, and a load balancer can be used to balance requests across multiple controllers.
|
||||
The Boundary controllers do not directly communicate with one another, all configuration and state is managed through an RDBMS, in this case PostgreSQL.
|
||||
|
||||
The following diagram shows the recommended architecture for deploying Boundary controller nodes within a single region:
|
||||
|
||||
|
||||
|
||||
Boundary controllers are stateless and do not operate using consensus protocols such as Raft.
|
||||
They are therefore able to withstand failure scenarios where only one node is accessible.
|
||||
|
||||
If deploying Boundary to three availability zones is not possible, you can use the same architecture across one or two availability zones, at the expense of reliability risk in case of an availability zone outage.
|
||||
|
||||
## Connect to a target workflow
|
||||
|
||||
The second workflow is a user connecting to a Boundary target.
|
||||
In this scenario, the user initiates a session connecting to a target they have been granted access to using either the Boundary CLI or desktop application.
|
||||
|
||||
1. If the user is not authenticated, they must first authenticate by communicating with the Boundary controllers and any relied-upon OIDC IdP, if necessary.
|
||||
1. Once authenticated, the user's session can be initiated and a tunnel is built from their client to an ingress worker.
|
||||
If there are multiple layers of network boundaries, a tunnel is built from the ingress worker to an egress worker.
|
||||
1. The last step is traffic being proxied through the egress worker to the target.
|
||||
|
||||
It is ideal to have multiple ingress and egress workers with the same configurations within each network boundary to provide high availability.
|
||||
Load balancing the Boundary workers is not recommended, as the Boundary control plane handles session scaling and balancing when users start sessions.
|
||||
|
||||
The following diagram shows the recommended architecture for deploying Boundary workers:
|
||||
|
||||
|
||||
|
||||
The Boundary controllers also depend on a PostgreSQL database.
|
||||
This database should be deployed in a fashion where it is reachable by all Boundary controller nodes.
|
||||
|
||||
## Community reference architectures
|
||||
|
||||
A number of community-supported reference architectures for non-dev deployments can be found in Boundary's dedicated [reference architecture repo](https://github.com/hashicorp/boundary-reference-architecture).
|
||||
|
||||
While some initial reference deployments have been seeded by the Boundary team, the seeded examples are for demonstration purposes only and are intended convey how to get Boundary up and running on popular cloud and container platforms.
|
||||
|
||||
We highly encourage organizations who use Boundary in production environments to contribute configurations to the repo so that the community may benefit from them.
|
||||
@@ -1,234 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: System requirements
|
||||
description: >-
|
||||
Learn about Boundary system requirements including recommendations for hardware sizing, network connectivity, traffic encryption, databases, and load balancers.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# System requirements
|
||||
|
||||
This topic contains specific recommendations for system requirements.
|
||||
|
||||
<Note>
|
||||
|
||||
All specifications outlined in this topic are minimum recommendations without
|
||||
any reservations towards vertical scaling, redundancy, or other site reliability
|
||||
needs.
|
||||
|
||||
All resource requirements are directly proportional to the operations
|
||||
performed by the Boundary cluster, and the end users' level of usage.
|
||||
|
||||
</Note>
|
||||
|
||||
To match your requirements and maximize the stability of your Boundary
|
||||
controller and worker instances, perform load tests and monitor
|
||||
resource usage including reported matrices from Boundary's telemetry.
|
||||
|
||||
Refer to [Monitor Boundary](/boundary/docs/monitor) for
|
||||
more information.
|
||||
|
||||
## Hardware sizing for Boundary servers
|
||||
|
||||
Refer to the tables below for sizing recommendations for controller nodes and
|
||||
worker nodes, as well as small and large use cases based on expected usage.
|
||||
|
||||
Controller nodes
|
||||
|
||||
| Size | CPU | Memory | Disk capacity | Network throughput |
|
||||
|-------|------------|----------------|---------------|--------------------|
|
||||
| Small | 2 - 4 core | 8 - 16 GB RAM | 50+ GB | Minimum 5 Gbps |
|
||||
| Large | 4 - 8 core | 32 - 64 GB RAM | 100+ GB | Minimum 10 Gbps |
|
||||
|
||||
Worker nodes
|
||||
|
||||
| Size | CPU | Memory | Disk capacity | Network throughput |
|
||||
|-------|------------|----------------|---------------|--------------------|
|
||||
| Small | 2 - 4 core | 8 - 16 GB RAM | 50+ GB | Minimum 10 Gbps |
|
||||
| Large | 4 - 8 core | 32 - 64 GB RAM | 100+ GB | Minimum 10 Gbps |
|
||||
|
||||
To ensure predictable performance, we recommend that you
|
||||
avoid "burstable" CPU and storage options whose performance may degrade
|
||||
under continuous load.
|
||||
|
||||
## Hardware considerations
|
||||
|
||||
The Boundary controller and worker nodes perform two different tasks.
|
||||
The Boundary controller nodes handle requests for authentication and
|
||||
configuration.
|
||||
The Boundary worker nodes proxy client connections to Boundary
|
||||
targets which may require additional resources.
|
||||
|
||||
Depending on the number of clients connecting to Boundary targets at any given
|
||||
time, Boundary workers can become memory or file descriptor constrained.
|
||||
As your users create new sessions, the Boundary worker node opens more sockets and
|
||||
ultimately creates additional file descriptors. Monitor both the
|
||||
file descriptor usage and the memory consumption of each Boundary worker node.
|
||||
|
||||
## Network considerations
|
||||
|
||||
The amount of network bandwidth used by the Boundary controllers and workers
|
||||
depends on your specific usage patterns.
|
||||
For the Boundary controller, even a high request volume does not
|
||||
translate to a large amount of network bandwidth consumption.
|
||||
|
||||
Boundary worker nodes proxy client sessions to Boundary targets. The
|
||||
bandwidth consumption depends on the amount of potential clients,
|
||||
the number of sessions created, and the amount of data transferred
|
||||
between the user and the Boundary targets.
|
||||
|
||||
It is also important to consider bandwidth requirements to other external
|
||||
systems such as monitoring and logging collectors.
|
||||
It may be necessary to increase the size of the virtual machine to take
|
||||
advantage of additional throughput in certain circumstances.
|
||||
|
||||
Refer to the following pages for provider-specific virtual machine networking
|
||||
limitations:
|
||||
|
||||
- [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)
|
||||
- [Azure](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-machine-network-throughput/)
|
||||
- [GCP](https://cloud.google.com/compute/docs/network-bandwidth/)
|
||||
|
||||
## Network connectivity
|
||||
|
||||
The following table outlines the default ingress network connectivity
|
||||
requirements for Boundary cluster nodes.
|
||||
|
||||
If you restrict network egress, ensure you allow outgoing access from:
|
||||
|
||||
- The Boundary controllers to any external integration providers (for example,
|
||||
OIDC authentication providers) as well as external log handlers, metrics
|
||||
collection, and security and configuration management providers.
|
||||
|
||||
- The Boundary workers to controllers and any upstream workers.
|
||||
|
||||
<Note>
|
||||
|
||||
If any of the default port mappings do not meet your organization's
|
||||
requirements, you can update the default listening ports using the resource's
|
||||
[listener](/boundary/docs/monitor/listeners) stanza.
|
||||
|
||||
</Note>
|
||||
|
||||
|
||||
|
||||
| Source | Destination | Default destination port | protocol | Purpose |
|
||||
| --------------- | --------------------------- | ------------------------ | --------- | -------------------------------------- |
|
||||
| Client machines | Controller load balancer | 443 | tcp | Request distribution |
|
||||
| Load balancer | Controller servers | 9200 | tcp | Boundary API |
|
||||
| Load balancer | Controller servers | 9203 | tcp | Health checks |
|
||||
| Worker servers | Controller load balancer | 9201 | tcp | Session authorization, credentials, etc |
|
||||
| Controllers | PostgreSQL | 5432 | tcp | Storing system state |
|
||||
| Client machines | Worker servers \* | 9202 | tcp | Session proxying |
|
||||
| Worker servers | Boundary targets\* | various | tcp | Session proxying |
|
||||
| Client machines | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying |
|
||||
| Egress workers | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying |
|
||||
| Egress workers | Boundary targets \*\* | various | tcp | Multi-hop session proxying |
|
||||
|
||||
\* In this scenario, the client connects directly to one worker, which then
|
||||
proxies the connection to the Boundary target.
|
||||
|
||||
** Multi-hop sessions start reverse proxy tunnels when the downstream workers
|
||||
start and connect to upstream workers.
|
||||
|
||||
There are four steps when a client requests to connect to a target that requires
|
||||
a multi-hop path:
|
||||
|
||||
1. The client connects to an ingress worker.
|
||||
|
||||
1. The ingress worker connects with the next-downstream or egress worker through
|
||||
that worker's established reverse-proxy tunnel. This step may be repeated
|
||||
multiple times if there are multiple worker connections in the middle of the
|
||||
tunnel chain.
|
||||
|
||||
1. The final downstream egress worker connects to the Boundary target.
|
||||
|
||||
1. The client can now send data through the tunnel chain.
|
||||
|
||||
A multi-hop worker that acts as a downstream can start a tunnel to one or
|
||||
more upstream workers, specified in the `initial_upstreams` list in the
|
||||
worker configuration.
|
||||
|
||||
## Network traffic encryption
|
||||
|
||||
You should encrypt connections to the Boundary control plane at the controller
|
||||
nodes using standard PKI HTTPS TLS.
|
||||
|
||||
You can use either a layer 4 load balancer to pass through traffic to the
|
||||
Boundary controllers, or a layer 7 load balancer with no configured TLS
|
||||
termination.
|
||||
|
||||
## Database recommendations
|
||||
|
||||
Boundary clusters depend on a PostgreSQL database for managing state and
|
||||
configuration.
|
||||
Ensure you are using a version of PostgreSQL covered under [Boundary's supported
|
||||
version
|
||||
policy](https://developer.hashicorp.com/boundary/docs/enterprise/supported-versions#postgresql-support-policy).
|
||||
|
||||
Each major cloud provider offers a managed PostgreSQL database service:
|
||||
|
||||
| Cloud provider | Managed database service |
|
||||
|----------------|-----------------------------------------------------------------------------------------|
|
||||
| AWS | [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/) |
|
||||
| Azure | [Azure database for PostgreSQL](https://azure.microsoft.com/en-us/products/postgresql/) |
|
||||
| GCP | [Cloud SQL for PostgreSQL](https://cloud.google.com/sql/postgresql) |
|
||||
|
||||
### Database network requirements
|
||||
|
||||
Boundary controllers must be able to reach the PostgreSQL database.
|
||||
Worker nodes do not need access to the database.
|
||||
|
||||
### Database users and roles
|
||||
|
||||
Database initialization requires elevated privileges.
|
||||
When you initialize the database with the `boundary database init` command, the
|
||||
Boundary database user requires the `superuser` role plus `all privileges` on
|
||||
the Boundary database.
|
||||
|
||||
Once the database initialization is complete, the database user for a Boundary
|
||||
controller requires permissions for [data
|
||||
manipulation](https://www.postgresql.org/docs/current/dml.html) operations
|
||||
(select, insert, update, and delete).
|
||||
|
||||
### Required PostgreSQL modules
|
||||
|
||||
Boundary has a dependency on the PostgreSQL
|
||||
[pgcrypto](https://www.postgresql.org/docs/11/pgcrypto.html) module and
|
||||
[citext](https://www.postgresql.org/docs/11/citext.html), which are part of the
|
||||
standard modules supplied with PostgreSQL. Refer to the PostgreSQL documentation
|
||||
for more information.
|
||||
|
||||
## Load balancer recommendations
|
||||
|
||||
For the highest levels of reliability and stability, we recommend that you use
|
||||
some load balancing technology to distribute requests to your Boundary
|
||||
controller nodes.
|
||||
|
||||
Boundary workers do not require any load balancing.
|
||||
The Boundary controller manages load balancing for the Boundary workers when
|
||||
clients initiate sessions to Boundary targets.
|
||||
|
||||
To monitor the health of Boundary controller nodes, configure the load balancer
|
||||
to poll the `/health` API endpoint to detect the status of the node and direct
|
||||
traffic accordingly.
|
||||
|
||||
Each major cloud provider offers one or more managed load balancing services:
|
||||
|
||||
| Cloud | Layer | Layer | Managing load balancing service |
|
||||
|-------|---------------------|-------|----------------------------------------------------------------------------------------------------------------|
|
||||
| AWS | Network | 4 | [Network load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) |
|
||||
| AWS | Application | 7 | [Application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) |
|
||||
| Azure | Network | 4 | [Azure load balancer](https://learn.microsoft.com/en-us/azure/load-balancer/) |
|
||||
| Azure | Application | 7 | [Azure application gateway](https://learn.microsoft.com/en-us/azure/application-gateway/) |
|
||||
| GCP | Network/Application | 4/7 | [Cloud load balancing](https://cloud.google.com/load-balancing/docs/load-balancing-overview) |
|
||||
|
||||
There are also a number of self-hosted options, as well as service discovery
|
||||
systems like Consul.
|
||||
|
||||
Refer to the [listener stanza
|
||||
documentation](/boundary/docs/monitor/listeners/) for more information.
|
||||
@@ -1,164 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Configure the Client Agent
|
||||
description: >-
|
||||
Learn how to configure the Boundary Client Agent to intercept DNS requests, allowing Boundary to proxy connections transparently.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Configure the Client Agent
|
||||
|
||||
@include 'alerts/enterprise-only.mdx'
|
||||
|
||||
The default configuration included with the Boundary Client Agent upon installation will be suitable for most users. If you want to make changes to the configuration, the configuration file is located in the following directory:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
`/Library/Application Support/HashiCorp/Boundary/boundary-client-agent.hcl`
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
`C:\Program Files\Hashicorp Boundary\boundary-client-agent.hcl`
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Configuration settings
|
||||
|
||||
The configuration file contains the following fields:
|
||||
|
||||
- `alias_refresh_interval` - Specifies how often to refresh the alias cache. The default value is 1 minute.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
alias_refresh_interval="60s"
|
||||
```
|
||||
|
||||
- `dns_request_timeout` - Specifies for how long the Client Agent DNS request handling, including any recursion, is allowed to run before it is canceled.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
dns_request_timeout="300s"
|
||||
```
|
||||
|
||||
- `interface_to_use` - Specifies the interface to use instead of the default.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
interface_to_use="en1"
|
||||
```
|
||||
|
||||
- `log_file` - Specifies where to write the Boundary Client Agent log file to.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
log_file="/Library/Application\ /Support/HashiCorp/Boundary/boundary-client-agent.log"
|
||||
```
|
||||
|
||||
- `log_level` - Specifies the verbosity of the Client Agent logs.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
log_level="DEBUG"
|
||||
```
|
||||
|
||||
- `log_to_stdout` - Logs to STDOUT in addition to the `boundary-client-agent.log` file.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
log_to_stdout=false
|
||||
```
|
||||
|
||||
- `override_upstream_dns_servers` - Lists the DNS servers that should be used for recursing non-Boundary requests, overriding those configured on the system.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
override_upstream_dns_servers = ["8.8.8.8", "8.8.4.4"]
|
||||
```
|
||||
|
||||
- `state_file` - Specifies where to write the Boundary Client Agent state file to. This is an ephemeral file which is removed on successful shutdown.
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
state_file="/Library/Application\ /Support/HashiCorp/Boundary/boundary-client-agent-state.json"
|
||||
```
|
||||
|
||||
- `v4_prefix` - Specifies an alternate prefix to use for generating IPs. Currently must be between /8 and /16
|
||||
|
||||
Example:
|
||||
```hcl
|
||||
v4_prefix=1.1.1.1/8
|
||||
```
|
||||
|
||||
## Change the configuration
|
||||
|
||||
Complete the following steps to change the configuration of the Client Agent:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
1. As a privileged user, open the Boundary Client Agent configuration file in the editor of your choice.
|
||||
By default, it is located in the following directory:
|
||||
|
||||
`/Library/Application Support/HashiCorp/Boundary/boundary-client-agent.hcl`
|
||||
|
||||
1. Change the configuration settings, and save the file.
|
||||
|
||||
<Note>
|
||||
|
||||
You must restart the Client Agent to update some configuration settings.
|
||||
However, when you restart the Client Agent, it closes any existing sessions.
|
||||
Other configuration settings can be updated by only reloading the configuration file, which does not affect any existing sessions.
|
||||
|
||||
</Note>
|
||||
|
||||
1. Either reload the configuration file or restart the Client Agent.
|
||||
|
||||
You can change the following configuration values by reloading the configuration file, which will not disrupt any existing sessions:
|
||||
|
||||
- `dns_request_timeout`
|
||||
- `log_file`
|
||||
- `log_level`
|
||||
- `state_file`
|
||||
- `override_upstream_dns_servers`
|
||||
- `v4_prefix`
|
||||
|
||||
Run the following command to reload the configuration file:
|
||||
|
||||
```shell-session
|
||||
$ sudo pkill -1 boundary-client-agent
|
||||
```
|
||||
|
||||
If you want to update another configuration value, you can restart the Client Agent using the following commands, however it will close any existing sessions:
|
||||
|
||||
```shell-session
|
||||
$ sudo launchctl stop com.hashicorp.boundary.boundary-client-agent
|
||||
$ sudo launchctl start com.hashicorp.boundary.boundary-client-agent
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
1. As a privileged user, open the Boundary Client Agent configuration file in the editor of your choice.
|
||||
By default, it is located in the following directory:
|
||||
|
||||
`C:\Program Files\Hashicorp Boundary\boundary-client-agent.hcl`
|
||||
|
||||
1. Change the configuration settings, and save the file.
|
||||
1. Run the following commands to restart the Client Agent.
|
||||
|
||||
```shell-session
|
||||
net stop BoundaryClientAgent
|
||||
net start BoundaryClientAgent
|
||||
```
|
||||
|
||||
Note that when you restart the Client Agent, it closes any existing sessions.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -1,237 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Client Agent conflicting software
|
||||
description: >-
|
||||
Learn how possible conflicts that third-party tools may have with the Boundary Client Agent. Explore possible solutions and workarounds.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Client Agent software conflicts
|
||||
|
||||
Some software is known to cause conflicts with the Boundary Client Agent.
|
||||
Refer to the [transparent sessions interoperability matrix](/boundary/docs/interoperability-matrix) for a list of the third-party products that have been tested for use with the Boundary Client Agent.
|
||||
|
||||
The following sections are an incomplete list of potential conflicts and any available workarounds for issues.
|
||||
|
||||
## Cloudflare WARP client
|
||||
|
||||
The Cloudflare WARP client uses a local DNS server to direct traffic.
|
||||
It has built-in checks to prevent it from being run alongside other software that uses the same mechanism.
|
||||
This includes the Boundary Client Agent.
|
||||
If you try to use the Client Agent with the Cloudflare WARP client, it may work, or you may see an error like this one:
|
||||
|
||||
```
|
||||
Status: Unable to Connect
|
||||
Error reason: DNS Proxy Failure
|
||||
Error code: CF_DNS_PROXY_FAILURE
|
||||
Error description: The WARP Agent must be the only process responsible for DNS resolution on the device. One or more processes are already bound to port 53: boundary-client-agent.
|
||||
Learn more: https://cfl.re/CF_DNS_PROXY_FAILURE
|
||||
```
|
||||
|
||||
You can still install both the Cloudflare WARP client and the Boundary Client Agent on the same machine.
|
||||
The two products can coexist as long as the WARP client starts first.
|
||||
Starting the WARP client first binds it to alternate IPs and leaves the domain available for Boundary.
|
||||
|
||||
## Docker Desktop (MacOS)
|
||||
|
||||
Docker Desktop sometimes creates a local DNS listener that prevents the Client Agent from running.
|
||||
If you run Docker Desktop 4.26 or later, you must clear the `Use kernel networking for UDP` option.
|
||||
Otherwise, the Client Agent refuses to start.
|
||||
|
||||
## Huntress EDR client (Windows)
|
||||
|
||||
Host isolation and release do not work as expected in Windows when you use the Huntress EDR client with the Boundary Client Agent.
|
||||
The Huntress EDR client for Windows uses the Windows Filtering Platform (WFP) to isolate devices by blocking all non-essential traffic. This behavior conflicts with the Boundary Client Agent during device isolation.
|
||||
Specifically, the Boundary Client Agent replaces the default DNS resolver with its own, which can prevent fallback to a secondary DNS when the primary (Boundary) DNS fails during isolation.
|
||||
As a result, Huntress is unable to maintain server communication, leaving the device stuck in an isolated state. Huntress cannot isolate and release devices properly in Windows under these conditions.
|
||||
|
||||
As a temporary workaround, you can manually configure a secondary DNS (e.g., 8.8.8.8). However, this secondary DNS setting is overwritten when you pause or resume the Boundary Client Agent, so you must configure it again each time.
|
||||
|
||||
This issue does not affect macOS devices, where Boundary and Huntress coexist without additional configuration.
|
||||
|
||||
## Internet Sharing (MacOS)
|
||||
|
||||
Enabling **Internet Sharing** on MacOS causes the system's DNS resolver (`mDNSResponder`) to bind to all interfaces on port 53, preventing the Client Agent from starting. Disable **Internet Sharing** before you run the Client Agent.
|
||||
|
||||
## OpenVPN
|
||||
|
||||
When you run OpenVPN at the same time as the Client Agent, it can create a DNS conflict.
|
||||
If you are unable to establish a transparent session while using OpenVPN, you may need to explicitly specify a network interface and upstream DNS server(s) to use.
|
||||
|
||||
To configure the DNS server(s) to use, use the `override_upstream_dns_servers` configuration option:
|
||||
|
||||
```hcl
|
||||
# The DNS servers must be specified as an IP, or an IP:Port.
|
||||
# If no port is provided, port 53 is assumed.
|
||||
# The order of the entries specifies the priority.
|
||||
# We recommended providing both the VPN DNS servers
|
||||
# and the default DNS servers, so that DNS requests can
|
||||
# be resolved even when the VPN is not active.
|
||||
override_upstream_dns_servers = [
|
||||
"10.0.0.1", # Example primary VPN DNS server
|
||||
"10.0.0.2", # Example secondary VPN DNS server
|
||||
"8.8.8.8", # Fallback default DNS server
|
||||
"8.8.4.4:53", # Fallback default DNS server with a custom port
|
||||
]
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
The `override_upstream_dns_servers` is used for all non-Boundary DNS requests.
|
||||
If you only provide the VPN DNS servers, the Client Agent will not be able to resolve any DNS requests when the VPN is not active.
|
||||
|
||||
</Note>
|
||||
|
||||
If you configured OpenVPN to push DNS servers to the client, it may create additional conflicts.
|
||||
Refer to the sections below for more information about how this configuration affects MacOS and Windows systems.
|
||||
|
||||
### MacOS
|
||||
|
||||
When OpenVPN is configured to push DNS servers to the client, the client-side service monitors and updates the system DNS settings.
|
||||
As a result, OpenVPN may attempt to override the Client Agent's configuration.
|
||||
This scenario can create an unstable network environment and lead to disruptions in user connectivity and service access.
|
||||
There is no workaround for this scenario at this time.
|
||||
|
||||
### Windows
|
||||
|
||||
When OpenVPN is configured to push DNS servers to the client, it creates `DNSClientNrptRule` entries in Windows that control DNS routing independently of the interface priority.
|
||||
Although the Client Agent updates the interface's DNS settings, it does not manage the Name Resolution Policy Table (NRPT).
|
||||
As a result, the OpenVPN rules may override the Client Agent's configuration.
|
||||
This scenario may lead to conflicts, and there is no supported workaround at this time.
|
||||
|
||||
## Palo Alto Networking Global Protect VPN
|
||||
|
||||
If you are unable to establish a transparent session while using the Palo Alto Networking Global Protect VPN, you may need to explicitly specify a network interface and the upstream DNS server(s) to use.
|
||||
|
||||
By default, the Client Agent reads the primary network interface's DNS server configuration and uses that information to resolve domains that are not configured as aliases in Boundary.
|
||||
If the VPN configuration includes custom DNS servers, this information may not be available to the Client Agent, so you must explicitly specify the DNS server(s) to use.
|
||||
|
||||
To configure the DNS server(s) to use, use the `override_upstream_dns_servers` configuration option:
|
||||
|
||||
```hcl
|
||||
# The DNS servers must be specified as an IP, or an IP:Port.
|
||||
# If no port is provided, port 53 is assumed.
|
||||
# The order of the entries specifies the priority.
|
||||
# We recommended providing both the VPN DNS servers
|
||||
# and the default DNS servers, so that DNS requests can
|
||||
# be resolved even when the VPN is not active.
|
||||
override_upstream_dns_servers = [
|
||||
"10.0.0.1", # Example primary VPN DNS server
|
||||
"10.0.0.2", # Example secondary VPN DNS server
|
||||
"8.8.8.8", # Fallback default DNS server
|
||||
"8.8.4.4:53", # Fallback default DNS server with a custom port
|
||||
]
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
The `override_upstream_dns_servers` is used for all non-Boundary DNS requests.
|
||||
If you only provide the VPN DNS servers, the Client Agent will not be able to resolve any DNS requests when the VPN is not active.
|
||||
|
||||
</Note>
|
||||
|
||||
### Primary network interfaces
|
||||
|
||||
By default, the Client Agent creates IPs on the primary network interface to serve its DNS server.
|
||||
Refer to the tabs below for possible conflicts for each supported operating system.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
When you run the Client Agent alongside the PAN-GP VPN, the primary network interface will likely be set to a `tun` type interface, which the Client Agent cannot use for its IP addresses.
|
||||
You may see errors such as the following in the `boundary-client-agent.log` file or the `boundary client-agent status` command response:
|
||||
|
||||
```
|
||||
[ERROR] macos.addIP: error adding ipv4 address: ifconfig: ioctl (SIOCAIFADDR): Destination address required
|
||||
```
|
||||
|
||||
To work around the default `tun` interface, you must provide an explicit network interface using the `interface_to_use` configuration option. For example:
|
||||
|
||||
```hcl
|
||||
interface_to_use=en0
|
||||
```
|
||||
|
||||
The `interface_to_use` option allows the Client Agent to create the IPs it needs to serve the DNS server and proxy traffic.
|
||||
You must restart the Client Agent for it to update its configuration with the new setting.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
On Windows, the Client Agent may be able to create the IPs that it needs on the primary network interface, but it fails to establish any transparent sessions. You may see the following message:
|
||||
|
||||
```
|
||||
[INFO] default route change detected, restarting
|
||||
```
|
||||
|
||||
You must explicitly specify a network interface to use other than the primary one. You can list available network interfaces using the Powershell command `Get-NetAdapter`, or the older `route print` command. You must find the index of the interface you would normally use to connect to the internet. In this example, the interface index is `11`:
|
||||
|
||||
```
|
||||
PS C:\> Get-NetAdapter
|
||||
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
|
||||
---- -------------------- ------- ------ ---------- ---------
|
||||
Ethernet Parallels VirtIO Ethernet Adapter 11 Up 00-1C-42-B3-F2-75 10 Gbps
|
||||
Ethernet 2 PANGP Virtual Ethernet Adapter Secure 24 Up 02-50-41-00-00-01 2 Gbps
|
||||
```
|
||||
|
||||
Alternatively, if you use `route print`, refer to the following example:
|
||||
|
||||
```
|
||||
PS C:\> route print
|
||||
===========================================================================
|
||||
Interface List
|
||||
24...02 50 41 00 00 01 ......PANGP Virtual Ethernet Adapter Secure
|
||||
11...00 1c 42 b3 f2 75 ......Parallels VirtIO Ethernet Adapter
|
||||
1...........................Software Loopback Interface 1
|
||||
===========================================================================
|
||||
````
|
||||
|
||||
Your configuration should look like this:
|
||||
|
||||
```hcl
|
||||
interface_to_use=11
|
||||
```
|
||||
|
||||
You must restart the Client Agent for it to update its configuration with the new setting.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Parallels Desktop (MacOS VM on MacOS Host)
|
||||
|
||||
Running a MacOS VM in Parallels Desktop with shared networking causes the system's DNS resolver (`mDNSResponder`) to bind to all interfaces, blocking port 53 and preventing the Client Agent from starting.
|
||||
|
||||
As a workaround, you can configure Parallels Desktop to use a different network mode.
|
||||
Select an alternative network configuration such as **Host-Only**, **Default Adapter**, or **Wi-Fi** instead of **Shared Network**.
|
||||
Refer to the Parallels Desktop documentation for more information.
|
||||
|
||||
## Cisco AnyConnect VPN
|
||||
|
||||
When the Cisco AnyConnect VPN is active at the same time as the Boundary Client Agent, DNS resolution may fail for Boundary aliases.
|
||||
|
||||
The Boundary Client Agent by default uses the IPv4 range `100.x.x.x` for its local proxies. The Cisco AnyConnect VPN treats this range as a **secured range**, which forces DNS queries to resolve through the VPN instead of the Boundary Client Agent. As a result, Boundary aliases cannot be resolved.
|
||||
|
||||
You can configure the Boundary Client Agent to use a different IPv4 prefix by setting the `v4_prefix` option in the client configuration file. This setting overrides the default `100.x.x.x` range and avoids the conflict with Cisco AnyConnect VPN.
|
||||
|
||||
For example:
|
||||
```hcl
|
||||
v4_prefix = "172.16.0.0/12"
|
||||
```
|
||||
<Note>
|
||||
|
||||
You can set the `v4_prefix` to any valid RFC1918 private IPv4 range, as long as it does not overlap with ranges secured by the VPN. Common options include:
|
||||
|
||||
- `10.0.0.0/8`
|
||||
- `172.16.0.0/12`
|
||||
|
||||
Choose a range that best fits your environment.
|
||||
|
||||
</Note>
|
||||
|
||||
## Uninstall the Client Agent on Mac
|
||||
|
||||
If you used the Mac installer, you can run `/Library/Application Support/HashiCorp/Boundary Uninstaller.app` to uninstall Boundary.
|
||||
The uninstaller removes any installed components, including the Desktop client, CLI, and the Boundary Client Agent.
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Client Agent overview
|
||||
description: >-
|
||||
Learn how the Boundary Client Agent intercepts DNS requests as the primary resolver on the system, allowing Boundary to proxy connections transparently.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Boundary Client Agent
|
||||
|
||||
@include 'alerts/enterprise-only.mdx'
|
||||
|
||||
The Boundary Client Agent is Boundary's DNS daemon.
|
||||
When the Boundary Client Agent runs alongside an authenticated Boundary client, the agent establishes itself as the primary resolver on the system and intercepts DNS requests.
|
||||
|
||||
If you enter a hostname that matches a Boundary alias that the client is authorized to establish a session to, Boundary automatically generates the session and transparently proxies the connection on your behalf.
|
||||
If the Boundary Client Agent cannot find an alias, or if there are any issues with authentication, network connectivity, or latency, the Client Agent defers DNS resolution to the previously configured DNS resolvers.
|
||||
|
||||
<Note>
|
||||
|
||||
You must enable both IPv4 and IPv6 protocols for your environment to ensure the Client Agent can start and perform DNS lookups.
|
||||
|
||||
</Note>
|
||||
|
||||
## Security
|
||||
|
||||
When you successfully authorize a session on a Boundary controller, the response includes a list of any brokered credentials, which include the decoded secrets.
|
||||
When the Boundary Client Agent receives a DNS request, Boundary creates a new session.
|
||||
An OS user can only connect to an authorized session managed by the Boundary Client Agent daemon if they are the same OS user that added the Boundary auth token used for authorizing the session.
|
||||
|
||||
<Note>
|
||||
|
||||
Currently, you cannot authenticate to multiple Boundary controllers at once.
|
||||
If you authenticate to a different Boundary controller, any existing sessions are terminated and any new transparent sessions would be established with the new controller.
|
||||
|
||||
</Note>
|
||||
|
||||
The Boundary Client Agent stores the credentials and some other information related to the session in memory.
|
||||
The in-memory store removes the session information:
|
||||
|
||||
- when the session ends.
|
||||
- if the auth token stored in the Boundary expires.
|
||||
- if the current OS user authenticates with a different Boundary user.
|
||||
- if the current OS user authenticates to a new Boundary controller.
|
||||
- if the Boundary Client Agent is paused.
|
||||
- if the Boundary Client Agent is terminated.
|
||||
|
||||
API requests are authenticated in the same way as session proxy access.
|
||||
|
||||
Credential brokering is supported for transparent sessions.
|
||||
A notification appears when you establish a session against a target that is configured with credential brokering.
|
||||
You can retrieve the credentials later using the following command:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent sessions
|
||||
```
|
||||
|
||||
### Grants
|
||||
|
||||
In a production environment, you may want to provide the least amount of privileges necessary for users.
|
||||
For a Boundary user to be able to use the Client Agent to establish a transparent session, they must:
|
||||
|
||||
- be able to authenticate using an auth method.
|
||||
- have read permissions for their auth token.
|
||||
- have permission to establish a session to one or more targets.
|
||||
|
||||
You can use the following grant strings to grant those permissions:
|
||||
|
||||
```
|
||||
type=auth-method;ids=*;actions=authorize
|
||||
type=target;ids=*;actions=authorize-session
|
||||
type=auth-token;ids=*;actions=read:self
|
||||
```
|
||||
|
||||
HashiCorp highly recommends that you also grant users the permission to list resolvable aliases, as the Client Agent periodically fetches a list of aliases to match incoming DNS requests against.
|
||||
Without that permission, every DNS request on the system is sent to the Boundary controller, which can easily overwhelm it.
|
||||
|
||||
You can use the following grant string to grant the permission to list resolvable aliases:
|
||||
|
||||
```
|
||||
type=user;ids=*;actions=list-resolvable-aliases
|
||||
```
|
||||
|
||||
<Warning>
|
||||
|
||||
A known issue regarding how grants were previously created in HCP Boundary may cause you to receive a 500 error when you attempt to list resolvable aliases.
|
||||
Clusters created before April 26, 2025 may be missing the following grants:
|
||||
|
||||
`ids={{.User.Id}};type=user;actions=list-resolvable-aliases`
|
||||
|
||||
`ids=*;type=target;actions=list,read`
|
||||
|
||||
If your cluster is missing these grants, HashiCorp recommends adding them.
|
||||
|
||||
For more information, refer to the [known issue](/boundary/docs/release-notes/v0_19_0#hcp-grants).
|
||||
|
||||
</Warning>
|
||||
|
||||
## More information
|
||||
|
||||
Refer to the following topics for more information:
|
||||
|
||||
- [Aliases](/boundary/docs/concepts/aliases)
|
||||
- [Transparent sessions](/boundary/docs/concepts/transparent-sessions)
|
||||
|
||||
## Next steps
|
||||
|
||||
Refer to the following topics for more information about installing, configuring, and using the Client Agent:
|
||||
|
||||
- [Install Boundary clients](/boundary/docs/deploy/self-managed/install-clients)
|
||||
- [Configure the Client Agent](/boundary/docs/client-agent/configuration)
|
||||
- [Manage the Client Agent](/boundary/docs/client-agent/manage)
|
||||
- [Troubleshoot issues with the Client Agent](/boundary/docs/client-agent/troubleshoot)
|
||||
- [Client Agent software conflicts](/boundary/docs/client-agent/conflicting-software)
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Manage the Client Agent
|
||||
description: >-
|
||||
Learn how to manage the Boundary Client Agent to intercept DNS requests, allowing Boundary to proxy connections transparently.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Manage the Client Agent
|
||||
|
||||
Refer to the following sections for more information about managing the Client Agent.
|
||||
You can monitor the Client Agent's status and retrieve information about any transparent sessions.
|
||||
If you want to temporarily defer DNS resolution to any previously configured DNS resolvers, you can pause the Client Agent.
|
||||
You can also disable the Client Agent, if you no longer want to use it for DNS resolution.
|
||||
|
||||
## Monitor status and sessions
|
||||
|
||||
You can check the status of the Client Agent to ensure it is running.
|
||||
Use the following command to check the Client Agent's status:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent status
|
||||
```
|
||||
|
||||
You can retrieve information about the sessions that the Client Agent is managing.
|
||||
Use the following command to list any sessions currently being managed by the Client Agent, as well as any brokered credentials for those sessions:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent sessions
|
||||
```
|
||||
|
||||
Note that this command does not list sessions that are not managed by the Client Agent. Use `boundary sessions list -recursive` to see all sessions.
|
||||
|
||||
## Pause the Client Agent
|
||||
|
||||
You can temporarily disable the Boundary Client Agent by pausing it with the following command:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent pause
|
||||
```
|
||||
|
||||
When the Client Agent is paused, it does not intercept any DNS requests, and you are unable to use transparent sessions.
|
||||
|
||||
To resume the Client Agent, use the following command:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent resume
|
||||
```
|
||||
|
||||
## Disable the Client Agent
|
||||
|
||||
If you want to disable the Boundary Client Agent, you can stop it with the following commands:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
```shell-session
|
||||
$ sudo launchctl bootout system /Library/LaunchDaemons/com.hashicorp.boundary.boundary-client-agent.plist
|
||||
```
|
||||
|
||||
Unloading the Boundary Client Agent removes its launch daemon configuration. To restart the Client Agent, use:
|
||||
|
||||
```shell-session
|
||||
$ sudo launchctl bootstrap system /Library/LaunchDaemons/com.hashicorp.boundary.boundary-client-agent.plist
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
```shell-session
|
||||
net stop BoundaryClientAgent
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -1,288 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Troubleshoot the Client Agent
|
||||
description: >-
|
||||
Troubleshoot issues with the Boundary Client Agent to ensure it is functioning properly.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Troubleshoot issues with the Client Agent
|
||||
|
||||
The following sections can help you to troubleshoot the Client Agent's behavior. You should proceed through these steps from top to bottom.
|
||||
|
||||
## Check the status of the Client Agent
|
||||
|
||||
If you experience unexpected behavior, you should first check on the status of the Client Agent.
|
||||
You can check the status using the Boundary CLI or the Desktop Client. To check the Client Agent status through the Boundary CLI, use the following command:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent status
|
||||
|
||||
Status:
|
||||
Address:
|
||||
https://boundary.corp.com
|
||||
Auth Token Expiration: 167h58m9s
|
||||
Auth Token Id: at_GBqZUK2ihv
|
||||
Status: running
|
||||
Version: 0.0.1-e561e69839cce148ee5045684bce5b7168c65026
|
||||
```
|
||||
|
||||
In the Desktop Client, you can find the status of the Client Agent by navigating to **Settings**, and then scrolling to the **Boundary Client Agent** section.
|
||||
|
||||
The status command includes various information about the Client Agent, including the runtime status.
|
||||
In this example, the runtime status is "running".
|
||||
If the status is "paused", the Client Agent is not currently intercepting DNS requests and must be resumed.
|
||||
Users can pause the Client Agent, and it will also pause itself if it detects a large number of network failures in a short period of time.
|
||||
|
||||
The status also allows you to see whether the current user is authenticated.
|
||||
If the response looks like the example above, including showing an auth token ID and expiration, your current user is authenticated.
|
||||
If not, you may need to first authenticate to the Client Agent using the CLI or Desktop Client.
|
||||
|
||||
The status also sometimes contains a list of errors that have been encountered by the Client Agent.
|
||||
The list is ordered by most recent first.
|
||||
These errors can help you understand why the Client Agent may not be behaving as expected.
|
||||
Please see the section below on common error messages to help diagnose specific errors.
|
||||
Note that this list of errors will not be cleared until the next reboot, so it may not necessarily be a sign of something being wrong.
|
||||
|
||||
If the status command returns an error, the Client Agent may not be running.
|
||||
You can attempt to start the Client Agent using the following commands:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
```shell-session
|
||||
$ sudo launchctl start com.hashicorp.boundary.boundary-client-agent
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
```shell-session
|
||||
net start BoundaryClientAgent
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Resume the Client Agent
|
||||
|
||||
You can resume the Client Agent using either the Boundary CLI or the Desktop Client. In the CLI, run the following command to resume the Client Agent:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent resume
|
||||
The Client Agent has been successfully resumed.
|
||||
```
|
||||
|
||||
In the Desktop Client, you can resume the Client Agent by selecting the **Resume** button in the **Boundary Client Agent** section of the settings.
|
||||
Once the Client Agent has resumed, test if it has started working as expected again.
|
||||
|
||||
## Inspect the log file
|
||||
|
||||
If you are not able to diagnose the problem by looking at the status or resuming the Client Agent, another step can be to inspect the log file produced by the Client Agent.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
The log file should be located in `/Library/Application Support/HashiCorp/Boundary/boundary-client-agent.log`.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
The log file should be located in `C:\Windows\Logs\boundary-client-agent.log`.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Once you have found the log file, you can look through it to see if you can understand why the Client Agent is not working as expected.
|
||||
The list below provides some common errors and explanations.
|
||||
|
||||
It may be necessary to increase the logging verbosity of the Client Agent.
|
||||
You can increase the verbosity by setting the `log_level` option in the configuration file to `"DEBUG"`.
|
||||
See the section on changing the configuration for more information.
|
||||
|
||||
## Establish the behavior of the local DNS configuration
|
||||
|
||||
The Client Agent works by intercepting DNS requests before they are sent to your regular DNS server.
|
||||
If the DNS requests on your system are not sent to the right place, or they are not being answered appropriately, transparent sessions will not work.
|
||||
|
||||
You can use the `nslookup` command to understand where the DNS requests are being sent.
|
||||
Start by sending a DNS request for `hashicorp.com`:
|
||||
|
||||
```shell-session
|
||||
$ nslookup hashicorp.com
|
||||
;; Truncated, retrying in TCP mode.
|
||||
Server: 100.88.241.86
|
||||
Address: 100.88.241.86#53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: hashicorp.com
|
||||
Address: 76.76.21.21
|
||||
```
|
||||
|
||||
The important part here is the `Server` field, which contains an IP in the CGNAT range (from `100.64.0.0` to `100.127.255.255`).
|
||||
This is a good indication that the Client Agent DNS server is being used as expected.
|
||||
|
||||
Next, you can try to make a DNS request to an alias that you expect to work. The following example makes a DNS request to an alias with a value of `mytarget.boundary.dev`:
|
||||
|
||||
```shell-session
|
||||
$ nslookup mytarget.boundary.dev
|
||||
;; Truncated, retrying in TCP mode.
|
||||
Server: fc00:a20a::d7bf:c059
|
||||
Address: fc00:a20a::d7bf:c059#53
|
||||
|
||||
Name: mytarget.boundary.dev
|
||||
Address: 100.84.164.9
|
||||
```
|
||||
|
||||
You can tell two things from this:
|
||||
1. The Client Agent is likely able to intercept the DNS request, because the server is a local IPv6 address in the [ULA](https://en.wikipedia.org/wiki/Unique_local_address) range.
|
||||
Both an IPv4 CGNAT range or IPv6 ULA range IP address are indications of this.
|
||||
2. The Client Agent is able to identify `mytarget.boundary.dev` as an alias with a target that the requesting user is authorized to connect to, because it responded with a valid DNS response pointing to a local IPv4 address in the CGNAT range.
|
||||
Similarly to above, the IP address in the response may also be an IPv6 address in the ULA range.
|
||||
|
||||
If you do not see this kind of response, it may be that the alias you are trying to connect to doesn't exist, or your user is not authorized to connect to it.
|
||||
Double check that you are using the correct alias and that your user is authorized to connect to it.
|
||||
|
||||
## Flush OS DNS cache
|
||||
|
||||
If you still do not see the expected behavior, it can be useful to flush the operating system's DNS cache.
|
||||
The exact steps depend on the operating system you use:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
```shell-session
|
||||
$ sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
```shell-session
|
||||
ipconfig /flushdns
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
After you flush the DNS cache, try connecting to the alias again, or repeat the steps above.
|
||||
|
||||
If you are still not able to understand what is wrong, submit a support ticket. Include the `boundary client-agent status` output and the log file in the ticket.
|
||||
|
||||
## Common error messages
|
||||
|
||||
Refer to the following common error messages for more information about their possible causes and resolutions.
|
||||
|
||||
### nodename nor servname provided, or not known / No such host is known
|
||||
|
||||
This is a generic error for a failed DNS resolution.
|
||||
It can mean a number of different things:
|
||||
- The alias doesn't exist or is misspelled.
|
||||
- Your user isn't authenticated or doesn't have permission to connect to the target.
|
||||
- The Client Agent is not able to intercept DNS requests, it could shut down or paused.
|
||||
- The OS DNS cache is interfering with the operation of the Client Agent.
|
||||
- The Client Agent may not yet know about the alias.
|
||||
It takes around 2 minutes for the Client Agent to learn about new aliases.
|
||||
|
||||
Follow the troubleshooting steps above to resolve the issue.
|
||||
|
||||
### failed to listen for DNS on either IPv4 or IPv6
|
||||
|
||||
This error happens when some other application on the local machine occupies the ports used by the Boundary Client Agent.
|
||||
The Client Agent requires access to port 53 for IPv4 and IPv6, both UDP and TCP.
|
||||
Diagnosing what causes the error differs per operating system:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="MacOS" group="macos">
|
||||
|
||||
As a privileged user, you can use the `lsof` program to find what applications are occupying a port, for example:
|
||||
|
||||
```shell-session
|
||||
$ sudo lsof -nP | grep ":53"
|
||||
```
|
||||
|
||||
If anything is occupying port 53, you may need to terminate the application before the Client Agent is able to start.
|
||||
|
||||
Applications that make use of the Apple Virtualization Framework are known to sometimes occupy this port under
|
||||
the name `_mdnsresponder`. If you have any virtualization software, you may need to turn it off before using
|
||||
the Client Agent.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Windows" group="windows">
|
||||
|
||||
As a privileged user, you can open the **Resource Monitor** and inspect the **Network** > **Listening Ports** section to find any applications that use port 53.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Once you have identified which other software is using the port, you can stop it and try to start the Client Agent again.
|
||||
|
||||
### failed to refresh alias cache: error="fetching resolvable aliases: error performing client request during List call"
|
||||
|
||||
This usually implies that there is a problem reaching the internet or the Boundary controller.
|
||||
The error is related to the periodic updating of aliases used by the Client Agent to know whether a DNS request matches an alias or not.
|
||||
|
||||
HashiCorp recommends that you pause the Client Agent and examine the status and logs for further errors:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent pause
|
||||
```
|
||||
|
||||
Follow the troubleshooting steps to understand why the Client Agent is not able to reach the controller.
|
||||
|
||||
### sendmsg: broken pipe
|
||||
|
||||
On MacOS versions 15.1 and 15.2, the firewall may incorrectly block the Client Agent from sending DNS responses. To resolve this issue,
|
||||
upgrade to MacOS version 15.3 or later.
|
||||
|
||||
It may be neccessary to explicitly allow the `boundary-client-agent` process access to incoming network connections.
|
||||
|
||||
From the Firewall options in System Settings, toggle the `boundary-client-agent` to **Allow incoming connections**.
|
||||
|
||||
### WARNING! Remote host indentification has changed! It is possible that someone is doing something nasty!
|
||||
|
||||
This error arises when you use an alias to connect to an SSH target after the first successful connection using that alias. The issue occurs because Boundary workers generate a new host key on every new SSH connection. You can safely ignore the warning using the `StrictHostKeyChecking=no` command line option:
|
||||
|
||||
```shell-session
|
||||
$ ssh -o StrictHostKeyChecking=no targetalias.boundary.dev
|
||||
```
|
||||
|
||||
You can also remove the existing server host key from the `~/.ssh/known_hosts` file to avoid the error.
|
||||
|
||||
### This site can't be reached... DNS_PROBE_FINISHED_NXDOMAIN
|
||||
|
||||
This error occurs when you have authenticated to Boundary and have a target that is configured with an alias.
|
||||
When you copy the alias from the **Target** page and paste it in the browser, you receive the error.
|
||||
The Client Agent is not running, and if you attempt to resume it, you receive a message that says "bind address already in use."
|
||||
|
||||
A conflicting service may be preventing the Client Agent from receiving DNS requests.
|
||||
The service may be bound to port 53.
|
||||
Restarting your computer may resolve the conflict.
|
||||
|
||||
### error when attempting to resume... bind address already in use: invalid state transition
|
||||
|
||||
This error occurs when you have authenticated to Boundary and have a target that is configured with an alias.
|
||||
When you attempt to use the alias to connect to the target, you receive the error message in Boundary Desktop.
|
||||
The Client Agent is not running, and if you attempt to resume it, you receive a message that says "bind address already in use."
|
||||
|
||||
A conflicting service may be preventing the Client Agent from receiving DNS requests.
|
||||
The service may be bound to port 53.
|
||||
Restarting your computer may resolve the conflict.
|
||||
|
||||
## Transparent sessions known issues
|
||||
|
||||
Refer to the following table for known issues with the Client Agent that may affect transparent sessions:
|
||||
|
||||
| Issue | Description |
|
||||
| ----- | ----------- |
|
||||
| SSH connection fails with man-in-the-middle warning | On Linux systems, the initial transparent session may be successful, but any subsequent connections prompt a warning that you may be experiencing a man-in-the-middle attack. <br /><br /> For more information, refer to [WARNING! Remote host indentification has changed! It is possible that someone is doing something nasty!](/boundary/docs/client-agent/troubleshoot#warning-remote-host-indentification-has-changed-it-is-possible-that-someone-is-doing-something-nasty) in the **Common error messages** section.|
|
||||
| Boundary Client Agent authentication does not persist across restarts | When you reboot, you are required to re-authenticate to the Client Agent before you can use transparent sessions. |
|
||||
| Windows installer prompts for restart | When you install Boundary, the Windows installer occasionally prompts you to restart your computer, however it is not necessary. |
|
||||
| Boundary Client Agent resumes on reboot | If the Client Agent is paused and the machine is rebooted, the Client Agent will be resumed after the reboot. |
|
||||
| Single-word aliases do not work on Windows | If you create an alias consisting of a single word without a dot (`.`), the alias will not work on Windows. |
|
||||
| Windows installer does not support partial installations | The Windows installer fails to start the Client Agent if the Desktop client is not installed at the same time. |
|
||||
| Alias connection failures inside containers/VMs | Using transparent sessions rely on network access to the local network of the computer the Client Agent is running on. Network enclaves such as those created by Docker containers and VMs cannot reach this network. |
|
||||
| DNS lookup is broken on MacOS 15.1 and 15.2 | MacOS 15.1 and 15.2 may incorrectly block DNS lookups for the Client Agent. This issue is resolved in MacOS 15.3 and later. |
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Client cache overview
|
||||
description: >-
|
||||
Learn how the client cache enables Boundary to quickly retrieve local information about session and target resources. Manage startup and other cache functions.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Client cache
|
||||
|
||||
The Boundary client cache runs on end users' computers and locally caches session and target resource information from Boundary instances.
|
||||
The cache helps expedite searches.
|
||||
|
||||
## Boundary `list` vs. `search`
|
||||
|
||||
You can use the Boundary API or CLI to `list` resources like targets, sessions, hosts, and users.
|
||||
When you use the `list` command, Boundary searches the control plane to provide a current total of resources when it produces the list of results.
|
||||
Some Boundary resources can provide a significant number of items in the response.
|
||||
|
||||
Because large lists of results may overwhelm your system resources, the client cache caches the results of the `list` operation.
|
||||
You can search the local cache instead of the control plane to help protect your system resources.
|
||||
The Boundary `search` command also produces a list of Boundary resources.
|
||||
When you use the `search` command, however, Boundary searches the local cache to create the list.
|
||||
|
||||
For more information, refer to the [`search`](/boundary/docs/commands/search) command documentation.
|
||||
|
||||
<Note>
|
||||
|
||||
The `search` operation only displays the resources that you have read permissions to view.
|
||||
If you are logged in as a user who does not have the permissions to view a resource, it does not display in the list of results.
|
||||
|
||||
For more information, refer to [Identity and access management (IAM)](/boundary/docs/concepts/iam).
|
||||
|
||||
</Note>
|
||||
|
||||
## Client cache management
|
||||
|
||||
The Boundary client cache starts automatically in the background when a user runs a CLI command that interacts with a Boundary instance.
|
||||
If you do not want the cache to automatically start, you can include the `-skip-cache-daemon` flag or set the **BOUNDARY_SKIP_CACHE_DAEMON** environment variable when you use the Boundary CLI to interact with a Boundary instance.
|
||||
|
||||
### Startup and customization
|
||||
|
||||
You can start the cache manually using the `boundary cache start` command.
|
||||
By default, the cache starts in the foreground.
|
||||
You can start it in the background by adding the `-background` flag.
|
||||
|
||||
If you start the cache manually, you can customize the caching behavior.
|
||||
Include any of the following options to customize the behavior:
|
||||
|
||||
- `max-search-staleness` - The amount of time that can pass since the last refresh before calling `boundary search` results in a blocking refresh from the Boundary instance of the resources being searched.
|
||||
- `max-search-refresh-timeout` - The amount of time the `boundary search` blocking refresh can take before it times out.
|
||||
In the event of a timeout, Boundary uses the stale data that is currently in the cache.
|
||||
- `refresh-interval` - A duration that specifies how frequently the client cache should query Boundary for changes to sessions and targets.
|
||||
Note that Boundary only searches sessions and targets that the user who ran the command has access to.
|
||||
|
||||
For more information, refer to the [`cache start`](/boundary/docs/commands/cache/start) command documentation.
|
||||
|
||||
### Logging
|
||||
|
||||
The client cache stores a log file in the **~/.boundary** directory.
|
||||
Boundary automatically rotates the log once it reaches 5 MB.
|
||||
It compresses and keeps the last 3 rotated logs before deleting a log.
|
||||
|
||||
### Status
|
||||
|
||||
You can check the status of the cache using the `boundary cache status` command.
|
||||
The command returns information about the cache including the uptime, user count, user information, and which Boundary resources the cache is tracking.
|
||||
|
||||
For more information, refer to the [`cache status`](/boundary/docs/commands/cache/status) command documentation.
|
||||
|
||||
|
||||
### Auth tokens
|
||||
|
||||
By default, the Boundary CLI tries to use a keyring to store and receive auth tokens.
|
||||
Whenever you use an auth token to interact with Boundary, the client cache stores the auth token and syncs the data associated with it.
|
||||
If you authenticate to multiple Boundary instances, the client cache stores multiple auth tokens and syncs the data associated with each token.
|
||||
|
||||
To search the client cache for a specific Boundary instance, you can specify the appropriate auth token using the `boundary cache add-token` command.
|
||||
|
||||
For more information, refer to the [`cache add-token`](/boundary/docs/commands/cache/add-token) command documentation.
|
||||
@@ -1,87 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts change-password - Command
|
||||
description: >-
|
||||
The "accounts change-password" command resets the password on account resources.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts change-password
|
||||
|
||||
Command: `boundary accounts change-password`
|
||||
|
||||
The `accounts change-password` command resets the password on account resources, if the types match and the operation is allowed by the given account type.
|
||||
You must verify the current password to complete the password reset.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example changes the password on a password-type account. If you execute the command without the `-current-password` and ` -new-password` parameters, you are
|
||||
prompted to enter the password values.
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts change-password -id acctpw_1234567890
|
||||
Please enter the current password (it will be hidden):
|
||||
Please enter the new password (it will be hidden):
|
||||
Please enter it one more time for confirmation:
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Account information:
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Wed, 12 Jul 2023 12:20:54 PDT
|
||||
ID: acctpw_1234567890
|
||||
Type: password
|
||||
Updated Time: Wed, 12 Jul 2023 22:29:59 PDT
|
||||
Version: 5
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: admin
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts change-password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-current-password` `(string: "")` - The current password for the account. If
|
||||
you do not specify the current password, the command prompts you to enter the password in a non-echoing way.
|
||||
|
||||
- `-id` `(string: "")` - The ID of the account for which to change the password.
|
||||
|
||||
- `-new-password` `(string: "")` - The new account password. If you do not specify a new password, the command prompts you to enter the password in a non-echoing way.
|
||||
|
||||
- `-version` `(int: 0)` The version of the account against which to perform the password reset operation. If you do not specify a version, the command automatically performs a check-and-set.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,195 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts create - Command
|
||||
description: >-
|
||||
The "accounts create" command creates a new account resource and associates it with an auth method.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts create
|
||||
|
||||
Command: `boundary accounts create`
|
||||
|
||||
The `accounts create` command lets you create an account associated with one of the following auth methods:
|
||||
|
||||
- LDAP
|
||||
- OIDC
|
||||
- Password
|
||||
|
||||
## Example
|
||||
|
||||
The following example creates an account named `test_account`. In this example, you provide a password when prompted:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create password \
|
||||
-auth-method-id=ampw_1234567890 \
|
||||
-login-name="tester01" \
|
||||
-name=test_account \
|
||||
-description="Test password account"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Please enter the password (it will be hidden):
|
||||
|
||||
Account information:
|
||||
Auth Method ID: ampw_ZbB6UXpW3B
|
||||
Created Time: Fri, 27 May 2022 11:16:47 MDT
|
||||
Description: Test password account
|
||||
ID: acctpw_A8R1escktO
|
||||
Name: test_account
|
||||
Type: password
|
||||
Updated Time: Fri, 27 May 2022 11:16:47 MDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: o_u54jrD6ydN
|
||||
Name: IT_Support
|
||||
Parent Scope ID: global
|
||||
Type: org
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: tester01
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create [type] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-auth-method-id` `(string: "")` - The auth-method resource to use for the
|
||||
operation. You can also specify the auth-method using the **BOUNDARY_AUTH_METHOD_ID**
|
||||
environment variable.
|
||||
- `-description` `(string: "")` - The description to set for the account.
|
||||
- `-name` `(string: "")` - The name to set on the account.
|
||||
|
||||
|
||||
### Usages by type
|
||||
|
||||
You can create `ldap`, `oidc`, and `password` type accounts.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="LDAP">
|
||||
|
||||
The `boundary accounts create ldap` command creates an account of `ldap` type.
|
||||
|
||||
#### Example
|
||||
|
||||
The example below creates an LDAP account with the login name `prodops` and the description `ldap account for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create ldap -login-name prodops \
|
||||
-description "ldap account for ProdOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create ldap [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### LDAP account option
|
||||
|
||||
The following option is LDAP-specific, in addition to the command options:
|
||||
|
||||
- `-login-name` `(string: "")` - The login name for the account.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="OIDC">
|
||||
|
||||
The `boundary accounts create oidc` command creates an account of `oidc` type.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates an OIDC account with the subject `prodops` and the description `Oidc account for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create oidc -subject "prodops" \
|
||||
-description "Oidc account for ProdOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create oidc [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### OIDC account options
|
||||
|
||||
The following options are OIDC-specific, in addition to the command options:
|
||||
|
||||
- `-issuer` `(string: "")` - The issuer for the account.
|
||||
- `-subject` `(string: "")` - The subject for this account on the OIDC provider.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Password">
|
||||
|
||||
The `boundary accounts create password` command creates an account of `password` type.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a password-type account with the login name `prodops` and the description `Password account for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create password -login-name prodops \
|
||||
-description "Password account for ProdOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Password account options
|
||||
|
||||
The following options are password-specific, in addition to the command
|
||||
options:
|
||||
|
||||
- `-login-name` `(string: "")` - The login name for the account
|
||||
- `-password` `(string: "")` - The password for the account. If blank, the
|
||||
command prompts you to enter the password interactively in a
|
||||
non-echoing way. Otherwise, this value can refer to a file on disk (`file://`) or an environment variable (`env://`) from which the password is read.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts delete - Command
|
||||
description: >-
|
||||
The "accounts delete" command deletes an existing account resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts delete
|
||||
|
||||
Command: `boundary accounts delete`
|
||||
|
||||
The `accounts delete` command lets you delete an existing account.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example deletes an account with the ID `acctpw_0987654321`.
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts delete -id=acctpw_0987654321
|
||||
The delete operation completed successfully.
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the account you want to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts - Command
|
||||
description: >-
|
||||
The "accounts" command performs operations on account resources. You can associate users with accounts using auth methods.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts
|
||||
|
||||
Command: `boundary accounts`
|
||||
|
||||
The `accounts` command lets you create and manage accounts resources in Boundary.
|
||||
You can associate Boundary users with one or more account resources using auth methods.
|
||||
Accounts represent external notions of a particular entity.
|
||||
Among other use cases, accounts provide an easy way to switch users to new IdPs within the organization that deploys Boundary.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves account information for a given account ID, `acctpw_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts read -id acctpw_1234567890
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Account information:
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Wed, 12 Jul 2023 12:20:54 PDT
|
||||
ID: acctpw_1234567890
|
||||
Type: password
|
||||
Updated Time: Wed, 12 Jul 2023 12:20:54 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: admin
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary accounts [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
change-password Change the password on an account
|
||||
create Create an account
|
||||
delete Delete an account
|
||||
list List an account
|
||||
read Read an account
|
||||
set-password Directly set the password on an account
|
||||
update Update an account
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [create](/boundary/docs/commands/accounts/create)
|
||||
- [delete](/boundary/docs/commands/accounts/delete)
|
||||
- [read](/boundary/docs/commands/accounts/read)
|
||||
- [update](/boundary/docs/commands/accounts/update)
|
||||
- [list](/boundary/docs/commands/accounts/list)
|
||||
- [set-password](/boundary/docs/commands/accounts/set-password)
|
||||
- [change-password](/boundary/docs/commands/accounts/change-password)
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts list - Command
|
||||
description: >-
|
||||
The "accounts list" command lists the available accounts that were created for an auth method.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts list
|
||||
|
||||
Command: `boundary accounts list`
|
||||
|
||||
The `accounts list` command lists all accounts created for a given auth method.
|
||||
|
||||
## Example
|
||||
|
||||
The following example lists all accounts for an auth method with ID, `ampw_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts list -auth-method-id ampw_1234567890
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Account information:
|
||||
ID: acctpw_0987654321
|
||||
Version: 1
|
||||
Type: password
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
ID: acctpw_1234567890
|
||||
Version: 5
|
||||
Type: password
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-auth-method-id` `(string: "")` - The auth-method resource from which to list accounts. You can also specify the auth-method resource using the **BOUNDARY_AUTH_METHOD_ID**
|
||||
environment variable.
|
||||
- `-filter` `(string: "")` - If set, the list operation is filtered before
|
||||
being returned. The filter operates against each item in the list. We recommend using
|
||||
single quotes, because filters contain double quotes.
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not provide a value, or if you provide a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts read - Command
|
||||
description: >-
|
||||
The "accounts read" command retrieves the account details for an account.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts read
|
||||
|
||||
Command: `boundary accounts read`
|
||||
|
||||
The `accounts read` command retrieves the account details for a given account ID.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example reads any account information with the ID `acctpw_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts read -id acctpw_1234567890
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Account information:
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Wed, 12 Jul 2023 12:20:54 PDT
|
||||
ID: acctpw_1234567890
|
||||
Type: password
|
||||
Updated Time: Wed, 12 Jul 2023 22:29:59 PDT
|
||||
Version: 5
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: admin
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the account to read.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts set-password - Command
|
||||
description: >-
|
||||
The "accounts set-password" command sets the password for account resources.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts set-password
|
||||
|
||||
Command: `boundary accounts set-password`
|
||||
|
||||
The `accounts set-password` command lets you set the password on account-type
|
||||
resources, if the types match and the operation is allowed by the given account
|
||||
type.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example sets the password on a password-type account. If you execute the command
|
||||
without the `-password` parameter, you are prompted to enter the password
|
||||
value.
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts set-password -id acctpw_1234567890
|
||||
Please enter the password (it will be hidden):
|
||||
Please enter it one more time for confirmation:
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Account information:
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Wed, 12 Jul 2023 12:20:54 PDT
|
||||
ID: acctpw_1234567890
|
||||
Type: password
|
||||
Updated Time: Wed, 12 Jul 2023 22:08:12 PDT
|
||||
Version: 2
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: admin
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
The output displays the account information.
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts set-password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the account on which to set a password.
|
||||
- `-password` `(string: "")` - The password for the account. Use this value with `env://` or `file://` syntax. If you do not specify a password, the command prompts you to enter the password in a non-echoing way.
|
||||
- `-version` `(int: 0)` - The version of the account against which to perform an
|
||||
update operation. If you do no specify a version, the command performs a check-and-set
|
||||
automatically.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,193 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: accounts update - Command
|
||||
description: >-
|
||||
The "accounts update" command updates an existing account resource's LDAP, OIDC, or password authentication information.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# accounts update
|
||||
|
||||
Command: `boundary accounts update`
|
||||
|
||||
The `accounts update` command updates an existing account's information for
|
||||
the LDAP, OIDC, or password auth method.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example updates an existing password-type account with the ID `acctpw_w3N3PlV34D`:
|
||||
|
||||
```plaintext
|
||||
ID: acctpw_w3N3PlV34D
|
||||
Version: 1
|
||||
Type: password
|
||||
Name: test_account
|
||||
Description: Test password account
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: tester01
|
||||
```
|
||||
|
||||
This command updates the name, login name, and description:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update password -id=acctpw_w3N3PlV34D \
|
||||
-name="tester" \
|
||||
-login-name="test-engineer" \
|
||||
-description="Only to be used for testing"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard highlight="4,6,25">
|
||||
|
||||
```plaintext
|
||||
Account information:
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Thu, 13 Jul 2023 22:30:53 PDT
|
||||
Description: Only to be used for testing
|
||||
ID: acctpw_w3N3PlV34D
|
||||
Name: tester
|
||||
Type: password
|
||||
Updated Time: Thu, 13 Jul 2023 22:40:48 PDT
|
||||
Version: 3
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
set-password
|
||||
change-password
|
||||
|
||||
Attributes:
|
||||
Login Name: test-engineer
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update [type] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-description` `(string: "")` - The description to set on the account.
|
||||
- `-id` `(string: "")` - The ID of the account to update.
|
||||
- `-name` `(string: "")` - The name to set on the account.
|
||||
- `-version` `(string: "")` - The version of the account against which to
|
||||
perform an update operation. If you do not specify a version, the command performs a
|
||||
check-and-set automatically.
|
||||
|
||||
### Usages by type
|
||||
|
||||
The available types are: `ldap`, `oidc`, and `password`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="LDAP">
|
||||
|
||||
The `boundary accounts update ldap` command updates an LDAP account.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates an LDAP account with the ID `acctldap_1234567890` to add the name `devops` and the description `ldap account for DevOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update ldap -id acctldap_1234567890 \
|
||||
-name "devops" \
|
||||
-description "ldap account for DevOps"
|
||||
```
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update ldap [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
</Tab>
|
||||
<Tab heading="OIDC">
|
||||
|
||||
The `boundary accounts update oidc` command updates an OIDC account.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates an OIDC account with the ID `acctoidc_1234567890` to add the name `devops` and the description `Oidc account for DevOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update oidc -id acctoidc_1234567890 \
|
||||
-name "devops" \
|
||||
-description "Oidc account for DevOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update oidc [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Password">
|
||||
|
||||
The `boundary accounts update password` command updates a Password type account.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a password account with the ID `acctpw_1234567890` to add the name `devops` and the description `Password account for DevOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update password -id acctpw_1234567890 \
|
||||
-name "devops" \
|
||||
-description "Password account for DevOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts update password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Password account option
|
||||
|
||||
The following option is specific to password accounts, in addition to the command
|
||||
options:
|
||||
|
||||
- `-login-name` `(string: "")` - The login name for the account.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: aliases create - Command
|
||||
description: >-
|
||||
The "aliases create" command creates a new alias resource for a target.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# aliases create
|
||||
|
||||
Command: `aliases create`
|
||||
|
||||
The `aliases create` command lets you create a new alias.
|
||||
|
||||
## Example
|
||||
|
||||
This example creates an alias for the target `prod-ops.example` with the name `prodops` and the description `Target alias for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases create target -value prod-ops.example -name prodops
|
||||
-description "Target alias for ProdOps"
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases create [type] [sub command] [options] [args]
|
||||
|
||||
Please see the typed subcommand help for detailed usage information.
|
||||
|
||||
Subcommands:
|
||||
target Create a target type alias
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Usages by type
|
||||
|
||||
At this time, you can only create aliases for targets.
|
||||
|
||||
The `aliases create target` command lets you create aliases for targets.
|
||||
|
||||
#### Example
|
||||
|
||||
This example creates an alias for the target `-prod-ops.example` with the name `prodops` and the description `Target alias for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases create target -value prod-ops.example -name prodops
|
||||
-description "Target alias for ProdOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases create target [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Command options
|
||||
|
||||
- `-description=<string>` - Specifies the optional description you want to use to describe the alias for identification purposes.
|
||||
- `-destination-id=<string>` - Specifies the ID of the target that the alias points to.
|
||||
- `-name=<string>` - Specifies the optional name you want to use to describe the alias for identification purposes.
|
||||
- `-scope-id=<string>` - Scope in which to create the alias. The default is `global`.
|
||||
You can also specify the scope using the BOUNDARY_SCOPE_ID environment variable.
|
||||
At this time, aliases are only supported for the global scope.
|
||||
- `-value=<string>` - The string that you want to use as the alias to represent the target.
|
||||
The `value` must comply with DNS naming rules.
|
||||
|
||||
#### Target alias options
|
||||
|
||||
- `-authorize-session-host-id=<string>` - Indicates the host ID to use when you use the alias to authorize a session.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: aliases delete - Command
|
||||
description: >-
|
||||
The "aliases delete" command deletes an existing alias resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# aliases delete
|
||||
|
||||
Command: `aliases delete`
|
||||
|
||||
The `aliases delete` command lets you delete an alias.
|
||||
|
||||
## Example
|
||||
|
||||
This example deletes an alias with the ID `alt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases delete -id alt_1234567890
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id=<string>` - The ID of the alias you want to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: aliases - Command
|
||||
description: >-
|
||||
The "aliases" command performs operations on alias resources. An alias is a globally unique, DNS-like string that is associated with a destination resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# aliases
|
||||
|
||||
Command: `boundary aliases`
|
||||
|
||||
The `aliases` command lets you create and manage alias resources in Boundary.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves alias information for a given alias ID, `alt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases read -id alt_1234567890
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary aliases [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
create Create an alias
|
||||
delete Delete an alias
|
||||
list List an alias
|
||||
read Read an alias
|
||||
update Update an alias
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [create](/boundary/docs/commands/aliases/create)
|
||||
- [delete](/boundary/docs/commands/aliases/delete)
|
||||
- [list](/boundary/docs/commands/aliases/list)
|
||||
- [read](/boundary/docs/commands/aliases/read)
|
||||
- [update](/boundary/docs/commands/aliases/update)
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: aliases list - Command
|
||||
description: >-
|
||||
The "aliases list" command lists the available alias resources within a scope or resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# aliases list
|
||||
|
||||
Command: `aliases list`
|
||||
|
||||
The `aliases list` command lets you list the aliases within a given scope or resource.
|
||||
|
||||
## Example
|
||||
|
||||
This example lists all aliases within the global scope.
|
||||
At this time, you can only create aliases in the global scope.
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases list
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-filter=<string>` - If set, Boundary filters the list operation before the results are returned.
|
||||
The filter operates against each item in the list.
|
||||
We recommend that you use single quotes, because the filters contain double quotes.
|
||||
Refer to the [Filtering and listing resources documentation](/boundary/docs/filtering) for more details.
|
||||
- `recursive` - If set, runs the list operation recursively on any child scopes, if the type supports it.
|
||||
The default value is `false`.
|
||||
- `scope-id=<string>` - The scope from which to list the aliases.
|
||||
The default value is `global`.
|
||||
You can also specify this value using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: aliases read - Command
|
||||
description: >-
|
||||
The "aliases read" command retrieves the details of an alias resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# aliases read
|
||||
|
||||
Command: `aliases read`
|
||||
|
||||
The `aliases read` command lets you read the details of an alias with a given ID.
|
||||
|
||||
## Example
|
||||
|
||||
This example reads the details of an alias with the ID `alt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases read -id alt_1234567890
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id=<string>` - The ID of the alias you want to read.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: aliases update - Command
|
||||
description: >-
|
||||
The "aliases update" command updates an existing alias resource with new information.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# aliases update
|
||||
|
||||
Command: `aliases update`
|
||||
|
||||
The `aliases update` command lets you update an alias.
|
||||
|
||||
## Example
|
||||
|
||||
This example updates a target-type alias with the ID `alt_1234567890` to add the name `devops`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases update target -id alt_1234567890 -name devops
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases update [type] [sub command] [options] [args]
|
||||
|
||||
Please see the typed subcommand help for detailed usage information.
|
||||
|
||||
Subcommands:
|
||||
target Update a target type alias
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Usages by type
|
||||
|
||||
At this time, you can only create aliases for targets.
|
||||
|
||||
The `aliases update target` command lets you update aliases for targets.
|
||||
|
||||
#### Example
|
||||
|
||||
This example updates a target-type alias with the ID `alt_1234567890` to add the name `devops`:
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases update target -id alt_1234567890 -name devops
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary aliases update target [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Command options
|
||||
|
||||
- `-description=<string>` - Specifies the optional description you want to use to describe the alias for identification purposes.
|
||||
- `-destination-id=<string>` - Specifies the ID of the target that the alias points to.
|
||||
- `-name=<string>` - Specifies the optional name you want to use to describe the alias for identification purposes.
|
||||
- `-scope-id=<string>` - Scope in which the alias resides. The default is `global`.
|
||||
You can also specify the scope using the BOUNDARY_SCOPE_ID environment variable.
|
||||
At this time, aliases are only supported for the global scope.
|
||||
- `-value=<string>` - The string that you want to use as the alias to represent the target.
|
||||
The `value` must comply with DNS naming rules.
|
||||
|
||||
#### Target alias options
|
||||
|
||||
- `-authorize-session-host-id=<string>` - Indicates the host ID to use when you use the alias to authorize a session.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,138 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods change-state - Command
|
||||
description: >-
|
||||
The "auth-methods change-state" command changes the active and visibility state of an OIDC-type auth method resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods change-state
|
||||
|
||||
Command: `boundary auth-methods change-state`
|
||||
|
||||
The `auth-methods change-state` command changes the active and visibility state
|
||||
of an OIDC-type auth method given its ID.
|
||||
|
||||
An OIDC auth method can be in one of several different states: Inactive, Active
|
||||
Private, and Active Public. The current state of an OIDC auth method
|
||||
affects how endpoints respond to requests and, sometimes, whether access to
|
||||
an endpoint requires authentication.
|
||||
|
||||
- **MakeInactive** transitions an OIDC auth method from either the **Active Private**
|
||||
or the **Active Public** state into the **Inactive** state.
|
||||
- **MakePrivate** transitions an OIDC auth method from either the **Inactive** or the
|
||||
**Active Public** state into the **Active Private** state. If the transition is from the
|
||||
**Inactive** state, it will only succeed if the configuration is
|
||||
valid.
|
||||
- **MakePublic** transitions an OIDC auth method from either the **Inactive** or the
|
||||
**Active Private** state into the **Active Public** state. If the transition is from the
|
||||
**Inactive** state, it will only succeed if the configuration is
|
||||
valid.
|
||||
|
||||
Before you change the state of an auth-method, Boundary retrieves the provider’s discovery document for the auth method’s issuer and attempts to
|
||||
validate the auth-method’s configuration against this published information. If
|
||||
Boundary is unable to validate the configuration, an error is returned and the
|
||||
state change is not successful.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example changes the OIDC auth method's state to `active-public`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods change-state oidc -id amoidc_oHt4HQFCrN \
|
||||
-state active-public
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Method information:
|
||||
Created Time: Fri, 09 Sep 2022 11:11:55 MDT
|
||||
ID: amoidc_oHt4HQFCrN
|
||||
Name: auth0
|
||||
Type: oidc
|
||||
Updated Time: Fri, 09 Sep 2022 11:41:33 MDT
|
||||
Version: 3
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
change-state
|
||||
authenticate
|
||||
|
||||
Authorized Actions on Auth Method's Collections:
|
||||
accounts:
|
||||
create
|
||||
list
|
||||
managed-groups:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
api_url_prefix: https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud
|
||||
callback_url: https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud/v1/auth-methods/oidc:authenticate:callback
|
||||
client_id: zbaJLTZh3n14WqSV7qQ9onuIVRDaZdzx
|
||||
client_secret_hmac: Qc3i8NdnTP6rl4JANIg-a2GXgRW5rEKTp2ReIK_BOng
|
||||
issuer: https://dev-1vdl8c0q.us.auth0.com/
|
||||
max_age: 0
|
||||
signing_algorithms: [RS256]
|
||||
state: active-public
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods change-state oidc [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the oidc-type auth method on which to operate.
|
||||
|
||||
### OIDC auth method options
|
||||
|
||||
- `-disable-discovered-config-validation` - Disables validating
|
||||
the given auth method against configuration from the authorization server's
|
||||
discovery URL. You must specify this value every time an auth method that cannot be validated
|
||||
is updated or state changed. Not specifying a value is equivalent to setting the value to
|
||||
`false`. The default is `false`.
|
||||
|
||||
- `-state` `(string: "")` - The desired operational state of the auth method.
|
||||
Three different states exist for an authentication method:
|
||||
|
||||
- `inactive` users can not authenticate with inactive auth methods and the
|
||||
inactive auth methods are not listed for unauthenticated users.
|
||||
- `active-private` users can authenticate with active-private auth methods
|
||||
and active-private auth methods are not listed for unauthenticated users.
|
||||
- `active-public` users can authenticate with active-public auth methods and
|
||||
active-public auth methods are listed for unauthenticated users.
|
||||
|
||||
If you change an auth method from `active-public` or `active-private` to `inactive`, all
|
||||
in-flight authentications will succeed unless the auth method’s configuration is
|
||||
modified while the request is in-flight.
|
||||
|
||||
When you change an auth method's state using `boundary auth-methods change-state`,
|
||||
Boundary uses the `-disable-discovered-config-validation` flag to disable validation
|
||||
against the provider’s published discovery document. This allows for the very
|
||||
rare occurrence when the Provider has published an invalid discovery document.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,298 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods create - Command
|
||||
description: >-
|
||||
The "auth-methods create" command creates new auth method resources. You can create LDAP, OIDC, and password auth method types.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods create
|
||||
|
||||
Command: `boundary auth-methods create`
|
||||
|
||||
The `auth-methods create` command lets you create Boundary auth
|
||||
method resources. The available auth method types are: LDAP, OIDC, and password.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example creates an OIDC auth method by passing the OIDC provider's domain (`-issuer`), client ID, and client secret:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create oidc \
|
||||
-issuer "https://dev-1sdl8c0z.us.auth0.com" \
|
||||
-client-id "zaxJLTZh3n14WqSQ7qQ9onuIVRDaZdzz;" \
|
||||
-client-secret "t35c9NNw1aZ8haEKFJbJF0lauMOSp5UNPovUJXo8Ea2sPZAR1DszEowX-6-lg-Xr" \
|
||||
-signing-algorithm RS256 \
|
||||
-api-url-prefix "http://localhost:9200" \
|
||||
-name "auth0"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Method information:
|
||||
Created Time: Thu, 06 May 2021 16:39:33 MDT
|
||||
ID: amoidc_oHt4HQFCrN
|
||||
Name: auth0
|
||||
Type: oidc
|
||||
Updated Time: Thu, 06 May 2021 16:39:33 MDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
change-state
|
||||
authenticate
|
||||
|
||||
Authorized Actions on Auth Method's Collections:
|
||||
accounts:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
api_url_prefix: http://localhost:9200
|
||||
callback_url: http://localhost:9200/v1/auth-methods/oidc:authenticate:callback
|
||||
client_id: zbaJLTZh3n14WqSV7qQ9onuIVRDaZdzx
|
||||
client_secret_hmac: ayJRYSCphzxcHiKJvBrnDVtz1yiR958ejQuRGdQJMeM
|
||||
issuer: https://dev-1vdl8c0q.us.auth0.com
|
||||
signing_algorithms: [RS256]
|
||||
state: inactive
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create [type] [sub command] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options:
|
||||
|
||||
- `-description` `(string: "")` - The description to set on the auth method.
|
||||
- `-name` `(string: "")` - The name to set on the auth method.
|
||||
- `-scope-id` `(string: "")` - The scope in which to make the request. The default
|
||||
is `global`. You can also specify the scope using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
|
||||
### Usages by type
|
||||
|
||||
The available types are: `ldap`, `oidc`, and `password`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="LDAP">
|
||||
|
||||
The `boundary auth-methods create ldap` command creates an LDAP auth method.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates an LDAP auth method with the name `prodops` and the description `LDAP auth-method for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create ldap -name prodops \
|
||||
-description "LDAP auth-method for ProdOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create ldap [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### LDAP auth method options
|
||||
|
||||
The following are LDAP-specific options in addition to the command
|
||||
options:
|
||||
|
||||
- `-anon-group-search` - Uses anon bind when performing LDAP
|
||||
group searches (optional). The default is `false`.
|
||||
|
||||
- `-bind-dn` `(string: "")` - Uses the distinguished name of entry to bind when
|
||||
performing user and group searches (optional).
|
||||
|
||||
- `-bind-password` `(string: "")` - Indicates the password to use along with bind-dn
|
||||
performing user and group searches (optional).
|
||||
|
||||
- `-certificate` `(string: "")` - Specifies a PEM-encoded X.509 CA certificate in ASN.1 DER
|
||||
form that can be used as a trust anchor when connecting to an LDAP
|
||||
server(optional). You can specify this value multiple times.
|
||||
|
||||
- `-client-certificate` `(string: "")` - Specifies a PEM-encoded X.509 client certificate in
|
||||
ASN.1 DER form that can be used to authenticate against an LDAP server
|
||||
(optional).
|
||||
|
||||
- `-client-certificate-key` `(string: "")` - Specifies a PEM-encoded X.509 client
|
||||
certificate key in PKCS #8, ASN.1 DER form used with the client certificate
|
||||
(optional).
|
||||
|
||||
- `-discover-dn` - Uses anon bind to discover the bind DN of a
|
||||
user (optional). The default value is `false`.
|
||||
|
||||
- `-enable-groups` - Finds the authenticated user's groups during
|
||||
authentication (optional). The default is `false`.
|
||||
|
||||
- `-group-attr` `(string: "")` - Indicates the attribute that enumerates a user's group
|
||||
membership from entries returned by a group search (optional).
|
||||
|
||||
- `-group-dn` `(string: "")` - Specifies the base DN under which to perform group search.
|
||||
|
||||
- `-group-filter` `(string: "")` - Indicates a go template used to construct a LDAP group
|
||||
search filter (optional).
|
||||
|
||||
- `-insecure-tls` - Skips the LDAP server SSL certificate
|
||||
validation (optional). Use this option with caution; it is insecure. The default value is `false`.
|
||||
|
||||
- `-start-tls` - Issues the StartTLS command after connecting
|
||||
(optional). The default value is `false`.
|
||||
|
||||
- `-state` `(string: "")` - Indicates the desired operational state of the auth method.
|
||||
|
||||
- `-upn-domain` `(string: "")` - Specifies the userPrincipalDomain used to construct the
|
||||
UPN string for the authenticating user (optional).
|
||||
|
||||
- `-urls` `(string: "")` - Indicates the LDAP URLs that specify LDAP servers to connect to
|
||||
(required). You can specify this value multiple times.
|
||||
|
||||
- `-use-token-groups` - Uses the Active Directory tokenGroups
|
||||
constructed attribute of the user to find the group memberships (optional).
|
||||
The default value is `false`.
|
||||
|
||||
- `-user-attr` `(string: "")` - Specifies the attribute on user entry that matches the
|
||||
username that is passed during authentication (optional).
|
||||
|
||||
- `-user-dn` `(string: "")` - Indicates the base DN under which to perform user search
|
||||
(optional).
|
||||
|
||||
- `-user-filter` `(string: "")` - Specifies a go template used to construct a LDAP user
|
||||
search filter (optional).
|
||||
|
||||
</Tab>
|
||||
<Tab heading="OIDC">
|
||||
|
||||
The `boundary auth-methods create oidc` command creates an OIDC auth method.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates an OIDC auth method with the name `prodops` and the description `Oidc auth-method for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create oidc -name prodops \
|
||||
-description "Oidc auth-method for ProdOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create oidc [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### OIDC auth method options
|
||||
|
||||
The following are OIDC-specific options in addition to the command options:
|
||||
|
||||
- `-account-claim-maps` `(string: "")` - Specifies the optional account claim maps from
|
||||
custom claims to the standard claims of sub, name and email. These maps are
|
||||
represented as key=value where the key equals the Provider from-claim and the
|
||||
value equals the Boundary to-claim. For example "oid=sub". You may specify this value
|
||||
multiple times for different to-claims.
|
||||
|
||||
- `-allowed-audience` `(string: "")` - Indicates the acceptable audience ("aud") claim.
|
||||
You may specify this value multiple times.
|
||||
|
||||
- `-api-url-prefix` `(string: "")` - Specifies the URL prefix used by the OIDC provider in
|
||||
the authentication flow.
|
||||
|
||||
- `-claims-scopes` `(tring: "")` - Indicates the optional claims scope requested. You may specify this value multiple times.
|
||||
|
||||
- `-client-id` `(string: "")` - Specifies the OAuth 2.0 Client Identifier this auth method
|
||||
should use with the provider.
|
||||
|
||||
- `-client-secret` `(string: "")` - Indicates the corresponding client secret.
|
||||
|
||||
- `-idp-ca-cert` `(string: "")` - Specifies an optional PEM-encoded X.509 CA certificate that
|
||||
can be used as trust anchors when connecting to an OIDC provider. You may specify this value multiple times.
|
||||
|
||||
- `-issuer` `(string: "")` - Indicates the provider's issuer URL.
|
||||
|
||||
- `-max-age` `(string: "")` - Indicates the OIDC "max_age" parameter that is sent to the provider.
|
||||
|
||||
- `prompts` `(string: "")` - Indicates whether the OIDC authorization server should display reauthentication, account selection, or consent user interface prompts.
|
||||
You can optionally configure one or more of the following types of prompts to customize the behavior of the authentication process:
|
||||
- `none` - The authorization server does not display any authentication or consent prompts.
|
||||
- `login` - The authorization server prompts users for reauthentication before allowing them to log in.
|
||||
- `consent` - The authorization server prompts users for consent before returning any information to Boundary.
|
||||
- `select_account` - The authorization server prompts users to select a user account.
|
||||
The `select_account` option can be helpful if your users have multiple accounts.
|
||||
|
||||
<Note>
|
||||
|
||||
Cloud providers implement `prompts` in different ways.
|
||||
You may notice differences in behavior if you configure OIDC authentication on multiple cloud providers.
|
||||
|
||||
</Note>
|
||||
|
||||
- `-signing-algorithm` `(string: "")` - Indicates the allowed signing algorithm. You may specify this multiple times for multiple values.
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Password">
|
||||
|
||||
The `boundary auth-methods create password` command creates a Password type auth method.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a Password type auth method with the name `prodops` and the description `Password auth-method for ProdOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create password -name prodops \
|
||||
-description "Password auth-method for ProdOps"
|
||||
```
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary accounts create password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Password auth method options
|
||||
|
||||
The following are password auth method specific options in addition to the
|
||||
command options:
|
||||
|
||||
- `-min-login-name-length` `(string: "")` - The minimum length of login names.
|
||||
|
||||
- `-min-password-length` `(string: "")` - The minimum length of passwords.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods delete - Command
|
||||
description: >-
|
||||
The "auth-methods delete" command deletes an existing auth method resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods delete
|
||||
|
||||
Command: `boundary auth-methods delete`
|
||||
|
||||
The `auth-methods delete` command deletes an auth method given its ID.
|
||||
|
||||
## Example
|
||||
|
||||
The following example deletes an auth method with the ID, `moidc_oHt4HQFCrN`.
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods delete -id amoidc_oHt4HQFCrN
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the auth method to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,114 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods - Command
|
||||
description: >-
|
||||
The "auth-methods" command performs operations on Boundary authentication method resources. Auth methods let users authenticate to Boundary.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods
|
||||
|
||||
Command: `boundary auth-methods`
|
||||
|
||||
The `auth-methods` command lets you manage the auth method resource in Boundary. The auth
|
||||
method resource provides a mechanism for users to authenticate to
|
||||
Boundary. An auth method contains accounts which link an individual user to a
|
||||
set of credentials. They also contain managed groups which group accounts that satisfy
|
||||
specific criteria, and can be used as principals in roles.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example configures an OIDC auth method where the Boundary cluster
|
||||
address is stored in the `BOUNDARY_ADDR`, the OIDC provider's client ID is
|
||||
stored in the `CLIENT_ID`, and the client secret is stored in the
|
||||
`CLIENT_SECRET` environment variables.
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods create oidc \
|
||||
-issuer "https://dev-1sdl8c0z.us.auth0.com" \
|
||||
-client-id "$CLIENT_ID" \
|
||||
-client-secret "$CLIENT_SECRET" \
|
||||
-signing-algorithm RS256 \
|
||||
-api-url-prefix "$BOUNDARY_ADDR" \
|
||||
-name "auth0"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Method information:
|
||||
Created Time: Fri, 09 Sep 2022 11:11:55 MDT
|
||||
ID: amoidc_40fr5jkLpk
|
||||
Name: auth0
|
||||
Type: oidc
|
||||
Updated Time: Fri, 09 Sep 2022 11:11:55 MDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
change-state
|
||||
authenticate
|
||||
|
||||
Authorized Actions on Auth Method's Collections:
|
||||
accounts:
|
||||
create
|
||||
list
|
||||
managed-groups:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
api_url_prefix: https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud
|
||||
callback_url: https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud/v1/auth-methods/oidc:authenticate:callback
|
||||
client_id: zaxJLTZh3n14WqSQ7qQ9onuIVRDaZdzz
|
||||
client_secret_hmac: Qc3i8NdnTP6rl4JANIg-a2GXgRW5rEKTp2ReIK_BOng
|
||||
issuer: https://dev-1sdl8c0z.us.auth0.com
|
||||
signing_algorithms: [RS256]
|
||||
state: inactive
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary auth-methods [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
change-state
|
||||
create Create an auth method
|
||||
delete Delete an auth method
|
||||
list List an auth method
|
||||
read Read an auth method
|
||||
update Update an auth method
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [change-state](/boundary/docs/commands/auth-methods/change-state)
|
||||
- [create](/boundary/docs/commands/auth-methods/create)
|
||||
- [delete](/boundary/docs/commands/auth-methods/delete)
|
||||
- [list](/boundary/docs/commands/auth-methods/list)
|
||||
- [read](/boundary/docs/commands/auth-methods/read)
|
||||
- [update](/boundary/docs/commands/auth-methods/update)
|
||||
@@ -1,110 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods list - Command
|
||||
description: >-
|
||||
The "auth-methods list" command lists the available auth method resources within a scope or resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods list
|
||||
|
||||
Command: `boundary auth-methods list`
|
||||
|
||||
The `auth-methods list` command lists auth methods within an enclosing scope or
|
||||
resource.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example lists auth methods from the default `global` scope recursively from any child scopes, if applicable:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods list -recursive
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Method information:
|
||||
ID: amoidc_1234567890
|
||||
Scope ID: global
|
||||
Version: 1
|
||||
Type: oidc
|
||||
Name: Generated global scope initial oidc auth method
|
||||
Description: Provides initial administrative and unprivileged authentication into Boundary
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
change-state
|
||||
authenticate
|
||||
|
||||
ID: ampw_1234567890
|
||||
Scope ID: global
|
||||
Version: 1
|
||||
Type: password
|
||||
Name: Generated global scope initial password auth method
|
||||
Description: Provides initial administrative and unprivileged authentication into Boundary
|
||||
Is Primary For Scope: true
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
authenticate
|
||||
|
||||
ID: ampw_ZbB6UXpW3B
|
||||
Scope ID: o_u54jrD6ydN
|
||||
Version: 1
|
||||
Type: password
|
||||
Name: org_auth_method
|
||||
Description: Org auth method
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
authenticate
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-filter` `(string: "")` - If set, the list operation is filtered before
|
||||
being returned. The filter operates against each item in the list. We recommend using
|
||||
single quotes, because filters contain double quotes.
|
||||
|
||||
- `-recursive` - If set, the list operation is applied
|
||||
recursively into child scopes, if supported by the type. The default value is
|
||||
`false`.
|
||||
|
||||
- `-scope-id` `(string: "")` - The scope in which to make the request. The default
|
||||
scope is `global`. You can also specify a scope using the **BOUNDARY_SCOPE_ID** environment
|
||||
variable.
|
||||
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not provide a value, or if you provide a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods read - Command
|
||||
description: >-
|
||||
The "auth-methods read" command retrieves the details for an auth method resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods read
|
||||
|
||||
Command: `boundary auth-methods read`
|
||||
|
||||
The `auth-methods read` command reads an auth method given its ID.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example reads the auth method details for an auth method with the ID `amoidc_AliCbVihqv`.
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods read -id amoidc_AliCbVihqv
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Method information:
|
||||
Created Time: Thu, 13 May 2021 17:01:02 MDT
|
||||
Description: OIDC auth method for Auth0
|
||||
ID: amoidc_AliCbVihqv
|
||||
Name: Auth0
|
||||
Type: oidc
|
||||
Updated Time: Thu, 13 May 2021 17:01:02 MDT
|
||||
Version: 2
|
||||
|
||||
Scope:
|
||||
ID: o_1234567890
|
||||
Name: Generated org scope
|
||||
Parent Scope ID: global
|
||||
Type: org
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
change-state
|
||||
authenticate
|
||||
|
||||
Authorized Actions on Auth Method's Collections:
|
||||
accounts:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
api_url_prefix: http://localhost:9200
|
||||
callback_url: http://localhost:9200/v1/auth-methods/oidc:authenticate:callback
|
||||
client_id: zbaJLTZh3n14WqSV7qQ9onuIVRDaZdzx
|
||||
client_secret_hmac: AhyxTBqlZpnny78iA9M7QHKAKocI17bjwvS70B1ccg0
|
||||
issuer: https://dev-1vdl8c0q.us.auth0.com/
|
||||
signing_algorithms: [RS256]
|
||||
state: active-public
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the auth method to read.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,313 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-methods update - Command
|
||||
description: >-
|
||||
The "auth-methods update" command updates existing auth method resources. You can update LDAP, OIDC, and password auth method types.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-methods update
|
||||
|
||||
Command: `boundary auth-methods update`
|
||||
|
||||
The `auth-methods update` command lets you update Boundary auth method resources.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example updates an auth method to set the `-max-age` option to `0`.
|
||||
This update forces the user to reauthenticate, if they are already logged in with the current browser session:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update oidc -id amoidc_oHt4HQFCrN \
|
||||
-issuer "https://dev-1vdl8c0q.us.auth0.com/" \
|
||||
-max-age 0
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Method information:
|
||||
Created Time: Thu, 06 May 2021 16:39:33 MDT
|
||||
ID: amoidc_oHt4HQFCrN
|
||||
Name: auth0
|
||||
Type: oidc
|
||||
Updated Time: Thu, 06 May 2021 16:58:21 MDT
|
||||
Version: 2
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
change-state
|
||||
authenticate
|
||||
|
||||
Authorized Actions on Auth Method's Collections:
|
||||
accounts:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
api_url_prefix: https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud
|
||||
callback_url: https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud/v1/auth-methods/oidc:authenticate:callback
|
||||
client_id: zbaJLTZh3n14WqSV7qQ9onuIVRDaZdzx
|
||||
client_secret_hmac: ayJRYSCphzxcHiKJvBrnDVtz1yiR958ejQuRGdQJMeM
|
||||
issuer: https://dev-1vdl8c0q.us.auth0.com/
|
||||
max_age: 0
|
||||
signing_algorithms: [RS256]
|
||||
state: inactive
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update [type] [sub command] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options:
|
||||
|
||||
- `-description` `(string: "")` - The description to set on the auth method.
|
||||
- `-id` `(string: "")` - The ID of the auth method to update.
|
||||
- `-name` `(string: "")` - The name to set on the auth method.
|
||||
- `-version` `(int: 0)` - The version of the auth method to update.
|
||||
If you do not specify a version, the command performs a check-and-set automatically.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
|
||||
### Usages by type
|
||||
|
||||
The available types are: `ldap`, `oidc`, and `password`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="LDAP">
|
||||
|
||||
The `boundary auth-methods update ldap` command lets you update an LDAP auth method.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates an LDAP auth method with the ID `amldap_1234567890` to add the name `devops` and the description `LDAP auth-method for DevOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update ldap -id amldap_1234567890 \
|
||||
-name "devops" \
|
||||
-description "LDAP auth-method for DevOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update ldap [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### LDAP auth method options
|
||||
|
||||
The following are LDAP-specific options in addition to the command
|
||||
options.
|
||||
|
||||
- `-anon-group-search` - Uses anon bind when performing LDAP
|
||||
group searches (optional). The default value is `false`.
|
||||
|
||||
- `-bind-dn` `(string: "")` - Uses the distinguished name of entry to bind when
|
||||
performing user and group searches (optional).
|
||||
|
||||
- `-bind-password` `(string: "")` - Indicates the password to use along with bind-dn
|
||||
when performing user and group searches (optional).
|
||||
|
||||
- `-certificate` `(string: "")` - Specifies a PEM-encoded X.509 CA certificate in ASN.1 DER
|
||||
form that can be used as a trust anchor when connecting to an LDAP
|
||||
server(optional). You can specify this value multiple times.
|
||||
|
||||
- `-client-certificate` `(string: "")` - Specifies a PEM-encoded X.509 client certificate in
|
||||
ASN.1 DER form that can be used to authenticate against an LDAP server
|
||||
(optional).
|
||||
|
||||
- `-client-certificate-key` `(string: "")` - Specifies a PEM-encoded X.509 client
|
||||
certificate key in PKCS #8, ASN.1 DER form used with the client certificate
|
||||
(optional).
|
||||
|
||||
- `-discover-dn` - Uses anon bind to discover the bind DN of a
|
||||
user (optional). The default value is `false`.
|
||||
|
||||
- `-enable-groups` - Finds the authenticated user's groups during
|
||||
authentication (optional). The default is `false`.
|
||||
|
||||
- `-group-attr` `(string: "")` - Specifies the attribute that enumerates a user's group
|
||||
membership from entries returned by a group search (optional).
|
||||
|
||||
- `-group-dn` `(string: "")` - Specifies the base DN under which to perform group search.
|
||||
|
||||
- `-group-filter` `(string: "")` - Indicates a go template used to construct a LDAP group
|
||||
search filter (optional).
|
||||
|
||||
- `-insecure-tls` - Skips the LDAP server SSL certificate
|
||||
validation (optional). Use this option with caution, it is insecure. The default value is `false`.
|
||||
|
||||
- `-start-tls` - Issues the StartTLS command after connecting
|
||||
(optional). The default is `false`.
|
||||
|
||||
- `-state` `(string: "")` - Indicates the desired operational state of the auth method.
|
||||
|
||||
- `-upn-domain` `(string: "")` - Indicates the userPrincipalDomain used to construct the
|
||||
UPN string for the authenticating user (optional).
|
||||
|
||||
- `-urls` `(string: "")` - Indicates the LDAP URLs that specify LDAP servers to connect to
|
||||
(required). You may specify this value multiple times.
|
||||
|
||||
- `-use-token-groups` - Uses the Active Directory tokenGroups
|
||||
constructed attribute of the user to find the group memberships (optional).
|
||||
The default value is `false`.
|
||||
|
||||
- `-user-attr` `(string: "")` - Indicates the attribute on user entry matching the
|
||||
username that is passed during authentication (optional).
|
||||
|
||||
- `-user-dn` `(string: "")` - Specifies the base DN under which to perform user search
|
||||
(optional).
|
||||
|
||||
- `-user-filter` `(string: "")` - Specifies a go template used to construct a LDAP user
|
||||
search filter (optional).
|
||||
|
||||
</Tab>
|
||||
<Tab heading="OIDC">
|
||||
|
||||
The `boundary auth-methods update oidc` command lets you update OIDC auth methods.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates an OIDC auth method with the ID `amoidc_1234567890` to add the name `devops` and the description `Oidc auth-method for DevOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update oidc -id amoidc_1234567890 \
|
||||
-name "devops" \
|
||||
-description "Oidc auth-method for DevOps"
|
||||
```
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update oidc [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### OIDC auth method options
|
||||
|
||||
The following are options are specific to OIDC auth-methods in addition to the command options.
|
||||
|
||||
- `-account-claim-maps` `(string: "")` - Indicates the optional account claim maps from
|
||||
custom claims to the standard claims of sub, name and email. These maps are
|
||||
represented as key=value where the key equals the Provider from-claim and the
|
||||
value equals the Boundary to-claim. For example "oid=sub". You may specify this value
|
||||
multiple times for different to-claims.
|
||||
|
||||
- `-allowed-audience` `(string: "")` - Indicates the acceptable audience ("aud") claim.
|
||||
You may specify this value multiple times.
|
||||
|
||||
- `-api-url-prefix` `(string: "")` - Indicates the URL prefix used by the OIDC provider in
|
||||
the authentication flow.
|
||||
|
||||
- `-claims-scopes` `(tring: "")` - Specifies the optional claims scope requested. You may specify this value multiple times.
|
||||
|
||||
- `-client-id` `(string: "")` - Indicates the OAuth 2.0 Client Identifier this auth method
|
||||
should use with the provider.
|
||||
|
||||
- `-client-secret` `(string: "")` - Indicates the corresponding client secret.
|
||||
|
||||
- `-idp-ca-cert` `(string: "")` - Specifies an optional PEM-encoded X.509 CA certificate that
|
||||
can be used as trust anchors when connecting to an OIDC provider. May be
|
||||
specified multiple times.
|
||||
|
||||
- `-disable-discovered-config-validation` - Disables validating
|
||||
the given auth method against configuration from the authorization server's
|
||||
discovery URL. This must be specified every time an unvalidatable auth method
|
||||
is updated or state changed; not specifying it is equivalent to setting it to
|
||||
false. The default is false.
|
||||
|
||||
- `-dry-run` - Performs all completeness and validation checks
|
||||
with any newly-provided values without persisting the changes. The default is
|
||||
false.
|
||||
|
||||
- `-idp-ca-cert` `(tring: "")` - Indicates an optional PEM-encoded X.509 CA certificate that
|
||||
can be used as trust anchors when connecting to an OIDC provider. You may specify this value multiple times.
|
||||
|
||||
- `-issuer` `(string: "")` - Indicates the provider's Issuer URL.
|
||||
|
||||
- `-max-age` `(string: "")` - Indicates the OIDC "max_age" parameter sent to the provider.
|
||||
|
||||
- `prompts` `(string: "")` - Indicates whether the OIDC authorization server should display reauthentication, account selection, or consent user interface prompts.
|
||||
You can optionally configure one or more of the following types of prompts to customize the behavior of the authentication process:
|
||||
- `none` - The authorization server does not display any authentication or consent prompts.
|
||||
- `login` - The authorization server prompts users for reauthentication before allowing them to log in.
|
||||
- `consent` - The authorization server prompts users for consent before returning any information to Boundary.
|
||||
- `select_account` - The authorization server prompts users to select a user account.
|
||||
The `select_account` option can be helpful if your users have multiple accounts.
|
||||
|
||||
<Note>
|
||||
|
||||
Cloud providers implement `prompts` in different ways.
|
||||
You may notice differences in behavior if you configure OIDC authentication on multiple cloud providers.
|
||||
|
||||
</Note>
|
||||
|
||||
- `-signing-algorithm` `(string: "")` - Indicates the allowed signing algorithm. You may specify this value multiple times for multiple values.
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Password">
|
||||
|
||||
The `boundary auth-methods update password` command lets you update a Password-type auth method.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a Password-type auth method with the ID `ampw_1234567890` to add the name `devops` and the description `Password auth-method for DevOps`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update password -id ampw_1234567890 \
|
||||
-name "devops" \
|
||||
-description "Password auth-method for DevOps"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-methods update password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Password auth method options
|
||||
|
||||
The following options are specific to the Passwor-type auth method in addition to the
|
||||
command options.
|
||||
|
||||
- `-min-login-name-length` `(string: "")` - The minimum length of login names.
|
||||
|
||||
- `-min-password-length` `(string: "")` - The minimum length of passwords.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-tokens delete - Command
|
||||
description: >-
|
||||
The "auth-tokens delete" command deletes an existing auth token resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-tokens delete
|
||||
|
||||
Command: `boundary auth-tokens delete`
|
||||
|
||||
The `auth-tokens delete` command deletes an auth token given its ID.
|
||||
|
||||
## Example
|
||||
|
||||
The following command deletes an auth token with the ID `at_LvUqeYz80B`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens delete -id at_LvUqeYz80B
|
||||
The delete operation completed successfully.
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the auth token to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-tokens - Command
|
||||
description: >-
|
||||
The "auth-tokens" command peforms operations on auth token resources.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-tokens
|
||||
|
||||
Command: `boundary auth-tokens`
|
||||
|
||||
The `auth-tokens` command lets you manage auth token resources in Boundary.
|
||||
|
||||
## Example
|
||||
|
||||
The following example command lists existing auth tokens recursively:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens list -recursive
|
||||
|
||||
Auth Token information:
|
||||
ID: at_LvUqeYz80B
|
||||
Scope ID: global
|
||||
Approximate Last Used Time: Sun, 13 Aug 2023 17:22:59 PDT
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Sun, 13 Aug 2023 17:22:59 PDT
|
||||
Expiration Time: Sun, 20 Aug 2023 17:22:59 PDT
|
||||
Updated Time: Sun, 13 Aug 2023 17:22:59 PDT
|
||||
User ID: u_1234567890
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
read:self
|
||||
delete
|
||||
delete:self
|
||||
|
||||
ID: at_TXmYwSqnnO
|
||||
Scope ID: global
|
||||
Approximate Last Used Time: Sun, 13 Aug 2023 17:23:16 PDT
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Sun, 13 Aug 2023 17:23:16 PDT
|
||||
Expiration Time: Sun, 20 Aug 2023 17:23:16 PDT
|
||||
Updated Time: Sun, 13 Aug 2023 17:23:16 PDT
|
||||
User ID: u_1234567890
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
read:self
|
||||
delete
|
||||
delete:self
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary auth-tokens [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
delete Delete an auth tokn
|
||||
list List an auth token
|
||||
read Read an auth token
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [delete](/boundary/docs/commands/auth-tokens/delete)
|
||||
- [list](/boundary/docs/commands/auth-tokens/list)
|
||||
- [read](/boundary/docs/commands/auth-tokens/read)
|
||||
@@ -1,99 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-tokens list - Command
|
||||
description: >-
|
||||
The "auth-tokens list" command lists the available auth token resources within an enclosing scope or resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-tokens list
|
||||
|
||||
Command: `boundary auth-tokens list`
|
||||
|
||||
The `auth-tokens list` command lists all auth tokens within an enclosing scope or
|
||||
resource.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following command lists all auth tokens recursively from any child scopes, if applicable:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens list
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Token information:
|
||||
ID: at_TXmYwSqnnO
|
||||
Approximate Last Used Time: Sun, 13 Aug 2023 18:03:51 PDT
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Sun, 13 Aug 2023 17:23:16 PDT
|
||||
Expiration Time: Sun, 20 Aug 2023 17:23:16 PDT
|
||||
Updated Time: Sun, 13 Aug 2023 18:03:51 PDT
|
||||
User ID: u_1234567890
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
read:self
|
||||
delete
|
||||
delete:self
|
||||
|
||||
ID: at_Gvd3jsqSO2
|
||||
Approximate Last Used Time: Sun, 13 Aug 2023 18:04:34 PDT
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Sun, 13 Aug 2023 18:04:34 PDT
|
||||
Expiration Time: Sun, 20 Aug 2023 18:04:34 PDT
|
||||
Updated Time: Sun, 13 Aug 2023 18:04:34 PDT
|
||||
User ID: u_1234567890
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
read:self
|
||||
delete
|
||||
delete:self
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-filter` `(string: "")` - If set, the list operation is filtered before it is returned.
|
||||
The filter operates against each item in the list.
|
||||
We recommend that you use single quotes, as filters contain double quotes.
|
||||
Refer to the [Filtering and listing resources documentation](/boundary/docs/filtering) for more details.
|
||||
|
||||
- `-recursive` - If set, the list operation is applied recursively into child scopes, if the type supports it.
|
||||
The default value is `false`.
|
||||
|
||||
- `-scope-id` `(string: "")` - The scope from which to list the auth tokens.
|
||||
The default value is `global`.
|
||||
You can also specify this value using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not provide a value, or if you provide a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: auth-tokens read - Command
|
||||
description: >-
|
||||
The "auth-tokens read" command retrieves the details for an auth token resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# auth-tokens read
|
||||
|
||||
Command: `boundary auth-tokens read`
|
||||
|
||||
The `auth-tokens read` command reads an auth token given its ID.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example reads the auth token details for an auth token with the ID `at_Gvd3jsqSO2`:
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens read -id at_Gvd3jsqSO2
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Auth Token information:
|
||||
Approximate Last Used Time: Sun, 13 Aug 2023 18:04:34 PDT
|
||||
Auth Method ID: ampw_1234567890
|
||||
Created Time: Sun, 13 Aug 2023 18:04:34 PDT
|
||||
Expiration Time: Sun, 20 Aug 2023 18:04:34 PDT
|
||||
ID: at_Gvd3jsqSO2
|
||||
Updated Time: Sun, 13 Aug 2023 18:04:34 PDT
|
||||
User ID: u_1234567890
|
||||
|
||||
Scope:
|
||||
ID: global
|
||||
Name: global
|
||||
Type: global
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
read:self
|
||||
delete
|
||||
delete:self
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary auth-tokens read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the auth token to read.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: authenticate - Command
|
||||
description: >-
|
||||
The "authenticate" command authenticates the CLI client using the specified auth method.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# authenticate
|
||||
|
||||
Command: `boundary authenticate`
|
||||
|
||||
The `authenticate` command authenticates the Boundary command line client using the auth method that you specify.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example authenticates the Boundary CLI using a configured OIDC auth method where the auth method ID is `amoidc_q7jAdI1QgA`:
|
||||
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate oidc -auth-method-id amoidc_q7jAdI1QgA
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Opening returned authentication URL in your browser...
|
||||
|
||||
Authentication information:
|
||||
Account ID: acctoidc_oztPFBFesH
|
||||
Auth Method ID: amoidc_oHt4HQFCrN
|
||||
Expiration Time: Thu, 13 May 2021 17:01:11 MDT
|
||||
User ID: u_JCRQP3ID7l
|
||||
|
||||
The token was successfully stored in the chosen keyring and is not displayed here.
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary authenticate [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
ldap Invoke the ldap auth method to authenticate with Boundary
|
||||
oidc Invoke the OIDC auth method to authenticate with Boundary
|
||||
password Invoke the password auth method to authenticate with Boundary
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [ldap](/boundary/docs/commands/authenticate/ldap)
|
||||
- [oidc](/boundary/docs/commands/authenticate/oidc)
|
||||
- [password](/boundary/docs/commands/authenticate/password)
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: authenticate ldap - Command
|
||||
description: >-
|
||||
The "authenticate ldap" command invokes the LDAP auth method to authenticate the CLI client.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# authenticate ldap
|
||||
|
||||
Command: `boundary authenticate ldap`
|
||||
|
||||
The `authenticate ldap` command lets you invokes the LDAP auth method to authenticate the
|
||||
Boundary CLI.
|
||||
|
||||
## Example
|
||||
|
||||
The following example uses an LDAP auth method with the ID `amldap_1234567890` and the login name `foo` to authenticate the Boundary CLI:
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate ldap -auth-method-id amldap_1234567890 -login-name foo
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate ldap [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-auth-method-id` `(string: "")` - The auth-method resource you want to use for authentication.
|
||||
You can also specify the auth method resource using the **BOUNDARY_AUTH_METHOD_ID** environment variable.
|
||||
|
||||
- `-login-name` `(string: "")` - A login name that corresponds to an account within the given auth method.
|
||||
You can also specify a login name using the **BOUNDARY_AUTHENTICATE_PASSWORD_LOGIN_NAME** environment variable.
|
||||
|
||||
- `-password` `(string: "")` - The password that is associated with the login name.
|
||||
If this value is blank, the command prompts you to enter the password interactively in a non-echoing way.
|
||||
Otherwise, this value can refer to a file on disk (`file://`) from which a password is read or an environment variable (`env://`) from which the password is read. You can also specify the password using the **BOUNDARY_AUTHENTICATE_PASSWORD_PASSWORD** environment variable.
|
||||
|
||||
- `-scope-id` `(string: "")` - The scope ID to use for the operation.
|
||||
You can also specify the scope ID using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: authenticate oidc - Command
|
||||
description: >-
|
||||
The "authenticate oidc" command invokes the OIDC auth method to authenticate the CLI client.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# authenticate oidc
|
||||
|
||||
Command: `boundary authenticate oidc`
|
||||
|
||||
The `authenticate oidc` command lets you invoke the OIDC auth method to authenticate the
|
||||
Boundary CLI.
|
||||
|
||||
The OIDC authentication method lets Boundary users delegate authentication
|
||||
to an OIDC provider. OIDC authentication allows Boundary to integrate with widely
|
||||
adopted identity providers like Okta, cloud-hosted active directory services
|
||||
with an OIDC frontend, and cloud identity management systems such as AWS IAM.
|
||||
|
||||
## Examples
|
||||
|
||||
The following command authenticates the Boundary CLI using an OIDC auth method with the ID `amoidc_q7jAdI1QgA`:
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate oidc -auth-method-id amoidc_q7jAdI1QgA
|
||||
Opening returned authentication URL in your browser...
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Authentication information:
|
||||
Account ID: acctoidc_f0wWsno9jQ
|
||||
Auth Method ID: amoidc_q7jAdI1QgA
|
||||
Expiration Time: Wed, 21 Apr 2021 15:02:38 MDT
|
||||
User ID: u_zAfnbL9b7y
|
||||
|
||||
The token was successfully stored in the chosen keyring and is not displayed here.
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate oidc [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-auth-method-id` `(string: "")` - The auth method resource you want to use for the authentication.
|
||||
You can also specify the auth method resource using the **BOUNDARY_AUTH_METHOD_ID** environment variable.
|
||||
|
||||
- `-scope-id` `(string: "")` - The scope ID to use for the operation.
|
||||
You can also specify the scope ID using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: authenticate password - Command
|
||||
description: >-
|
||||
The "authenticate password" command invokes the password auth method to authenticate the CLI client.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# authenticate password
|
||||
|
||||
Command: `boundary authenticate password`
|
||||
|
||||
The `authenticate password` command lets you invoke the password auth method to
|
||||
authenticate the Boundary CLI.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example authenticates the Boundary CLI using the password auth method and specifying the username:
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate password -login-name user1
|
||||
Please enter the password (it will be hidden): <password>
|
||||
|
||||
Authentication information:
|
||||
Account ID: acctpw_JQXp0QHxQL
|
||||
Auth Method ID: ampw_xxF3EIBn4k
|
||||
Expiration Time: Thu, 26 May 2022 11:36:27 MDT
|
||||
User ID: u_RlkqMP6jUv
|
||||
|
||||
The token was successfully stored in the chosen keyring and is not displayed here.
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary authenticate password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-auth-method-id` `(string: "")` - The auth-method resource you want to use for the
|
||||
authentication.
|
||||
You can also specify the auth method resource using the **BOUNDARY_AUTH_METHOD_ID** environment variable.
|
||||
|
||||
- `-login-name` `(string: "")` - A login name that corresponds to an account
|
||||
within the given auth method.
|
||||
You can also specify a login name using the **BOUNDARY_AUTHENTICATE_PASSWORD_LOGIN_NAME** environment variable.
|
||||
|
||||
- `-password` `(string: "")` - The password that is associated with the login name.
|
||||
If this value is blank, the command prompts you to enter the password interactively
|
||||
in a non-echoing way. Otherwise, this value can refer to a file on disk (`file://`)
|
||||
from which a password is read or an environment variable (`env://`) from which the
|
||||
password is read. You can also specify the password using the
|
||||
**BOUNDARY_AUTHENTICATE_PASSWORD_PASSWORD** environment variable.
|
||||
|
||||
- `-scope-id` `(string: "")` - The scope ID to use for the operation. You can also specify the scope ID using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: billing - Command
|
||||
description: >-
|
||||
The "billing" command retrieves the number of active users to help you predict user-based pricing.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# billing
|
||||
|
||||
Command: `boundary billing`
|
||||
|
||||
The `billing` command retrieves the number of active Boundary users in your organization to help you predict billing information.
|
||||
|
||||
An active user is any unique Boundary user resource that has performed at least one authenticated action during the relevant billing period.
|
||||
Users perform authenticated actions when they call API endpoints that require a valid auth token.
|
||||
Boundary provides auth tokens to users when they authenticate using an auth method.
|
||||
|
||||
## Examples
|
||||
|
||||
The following command retrieves the number of monthly active users between September 2023 and February 2024:
|
||||
|
||||
```shell-session
|
||||
$ boundary billing monthly-active-users /
|
||||
-start-time="2023-09" /
|
||||
-end-time="2024-02"
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary billing [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommand:
|
||||
monthly-active-users Display the number of monthly active users
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name of the subcommand in the sidebar or the link below:
|
||||
|
||||
- [monthly-active-users](/boundary/docs/commands/billing/monthly-active-users)
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: billing monthly-active-users - Command
|
||||
description: >-
|
||||
The "billing monthly-active-users" command retrieves the number of monthly active users during a specified time period to help you predict user-based pricing.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# billing monthly-active-users
|
||||
|
||||
Command: `boundary billing monthly-active-users`
|
||||
|
||||
The `billing monthly-active-users` command retrieves the number of monthly active Boundary users in your organization during a specific time to help predict billing information.
|
||||
|
||||
## Example
|
||||
|
||||
The following command retrieves the number of monthly active users between September 2023 and February 2024:
|
||||
|
||||
```shell-session
|
||||
$ boundary billing monthly-active-users /
|
||||
-start-time="2023-09" /
|
||||
-end-time="2024-02"
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary billing monthly-active-users [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `end-time=<string>` - The end date for which you want to view monthly active users in YYYY-MM format.
|
||||
If you do not include an end time, the command retrieves active users from the start time through the current month.
|
||||
|
||||
The end time is exclusive, so the command returns monthly active users up to, but not including, the month you enter.
|
||||
If the end time is **2024-07**, for example, the results include all active users from June (2024-06), but they would not include any users from July (2024-07).
|
||||
- `start-time=<string>` - The start date for which you want to view monthly active users in YYYY-MM format.
|
||||
|
||||
The start time is inclusive, so any active users from the month you enter are included in the results.
|
||||
If the start time is **2024-06**, for example, the command returns all users from June (2024-06) through the specified end time.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: cache add-token - Command
|
||||
description: >-
|
||||
The "cache add-token" command adds an auth token resource to the Boundary cache.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# cache add-token
|
||||
|
||||
Command: `boundary cache add-token`
|
||||
|
||||
The `boundary cache add-token` command lets you add an auth token from your keyring to a Boundary cache that is running.
|
||||
|
||||
By default, the Boundary CLI tries to use a keyring to store and receive auth tokens.
|
||||
Whenever you use an auth token to interact with Boundary, the client cache stores the auth token and syncs the data associated with it.
|
||||
If you authenticate to multiple Boundary instances, the client cache stores multiple auth tokens and syncs the data associated with each token.
|
||||
|
||||
By adding auth tokens to your client cache, you can select which specific Boundary instance you want to search.
|
||||
|
||||
<Note>
|
||||
|
||||
The `search` operation only displays the resources that you have permissions to view.
|
||||
You must have the `read` or `read:self` grant on the auth token to successfully add it.
|
||||
If you are logged in as a user who does not have the permissions to view a resource, it does not display in the list of results.
|
||||
|
||||
For more information, refer to [Identity and access management (IAM)](/boundary/docs/concepts/iam).
|
||||
|
||||
</Note>
|
||||
|
||||
## Examples
|
||||
|
||||
The following command adds an auth token to the client cache from your keyring:
|
||||
|
||||
```shell-session
|
||||
$ boundary cache add-token
|
||||
```
|
||||
|
||||
The following command specifies the name of the keyring `development` from which you want to add the token:
|
||||
|
||||
```shell-session
|
||||
$ boundary cache add-token -token-name development
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary cache add-token [options]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `keyring-type=<string>` - Specifies the type of keyring to use.
|
||||
The default value is `auto` which uses the Windows credential manager, OS X keychain, or cross-platform password store, depending on your platform.
|
||||
Use the value `none` to disable keyring functionality.
|
||||
Depending on your platform, available values include:
|
||||
- `wincred`
|
||||
- `keychain`
|
||||
- `pass`
|
||||
- `secret-service`
|
||||
|
||||
You can also specify the keyring type using the **BOUNDARY_KEYRING_TYPE** environment variable.
|
||||
- `output-curl-string` - Specifies that Boundary should print an equivalent cURL command string and exit, instead of executing the request.
|
||||
The default value is `false`.
|
||||
- `token` = A URL that points to a file on disk (file://) from which Boundary reads a token or an environment variable (env://) from which the token will be read.
|
||||
If you set this parameter, it overrides the `token-name` parameter.
|
||||
- `token-name` - If specified, Boundary uses the value in this parameter as the name when it stores the token in the system credential store.
|
||||
You can use this value to switch user identities for different commands.
|
||||
You can also specify a token name using the **BOUNDARY_TOKEN_NAME** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
-48
@@ -1,48 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: cache - Command
|
||||
description: >-
|
||||
The "cache" command performs operations on a local cache that facilitates searches and protects your system resources from being overwhelmed.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# cache
|
||||
|
||||
Command: `boundary cache`
|
||||
|
||||
The `cache` command lets you manage the Boundary cache and perform operations on the local cache of information.
|
||||
|
||||
## Example
|
||||
|
||||
The following command starts the Boundary cache in the background:
|
||||
|
||||
```shell-session
|
||||
$ boundary cache start -background
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary cache <subcommand> [options] [args]
|
||||
# ...
|
||||
Subcommands:
|
||||
add-token Add an auth token to a Boundary cache that is currently running.
|
||||
start Starts the Boundary cache.
|
||||
status Gets the status information of a Boundary cache that is currently running.
|
||||
stop Stops the Boundary cache.
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [add-token](/boundary/docs/commands/cache/add-token)
|
||||
- [start](/boundary/docs/commands/cache/start)
|
||||
- [status](/boundary/docs/commands/cache/status)
|
||||
- [stop](/boundary/docs/commands/cache/stop)
|
||||
-54
@@ -1,54 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: cache start - Command
|
||||
description: >-
|
||||
The "cache start" command starts the Boundary cache and determines the behavior of the local cache. You can customize log, search, and refresh settings.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# cache start
|
||||
|
||||
Command: `boundary cache start`
|
||||
|
||||
The `boundary cache start` command lets you manually start the Boundary cache and customize the behavior of the local cache.
|
||||
|
||||
## Example
|
||||
|
||||
The following command starts the Boundary cache in the background:
|
||||
|
||||
```shell-session
|
||||
$ boundary cache start -background
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary cache start [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `background` - Starts the Boundary cache in the background.
|
||||
The default value is `false`.
|
||||
By default, the cache starts in the foreground.
|
||||
- `log-format=<string>` - Specifies the log format, mostly as a fallback for events.
|
||||
Supported values are `standard` and `json`.
|
||||
- `max-search-refresh-timeout=<duration>` - If a search request triggers a best effort refresh, this value specifies how long the refresh should run before time out.
|
||||
In the event of a timeout, Boundary uses the stale data that is currently in the cache.
|
||||
The default value is 7 seconds.
|
||||
- `max-search-staleness=<duration>` - The amount of time that can pass since the last refresh before the client cache causes a blocking refresh.
|
||||
The blocking refresh occurs when you perform the `boundary search` command.
|
||||
It requires Boundary to refresh the local cache using the control plane.
|
||||
The default value is 30 seconds.
|
||||
- `refresh-interval` - A duration that specifies how frequently the client cache should query Boundary for changes to sessions and targets.
|
||||
Note that Boundary only searches sessions and targets that the user who ran the command has access to.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
-57
@@ -1,57 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: cache status - Command
|
||||
description: >-
|
||||
The "cache status" command checks the status of the Boundary cache and reports on configuration, user, and resource information.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# cache status
|
||||
|
||||
Command: `boundary cache status`
|
||||
|
||||
The `boundary cache status` command lets you manually check the status of the Boundary cache.
|
||||
Boundary prints out a status report that includes configuration, user, and resource information.
|
||||
|
||||
## Example
|
||||
|
||||
The following command checks the status of the Boundary cache:
|
||||
|
||||
```shell-session
|
||||
$ boundary cache status
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Status:
|
||||
Domain Socket: /home/my_user/.boundary/socket/daemon.sock
|
||||
Log Location: /home/my_user/.boundary/cache.log
|
||||
Uptime: 15m22s
|
||||
User Count: 1
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary cache status [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `output-curl-string` - Specifies that Boundary should print an equivalent cURL command string and exit, instead of executing the request.
|
||||
The default value is `false`.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
-37
@@ -1,37 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: cache stop - Command
|
||||
description: >-
|
||||
The "cache stop" command stops the Boundary cache.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# cache stop
|
||||
|
||||
Command: `boundary cache stop`
|
||||
|
||||
The `boundary cache stop` command lets you manually stop the Boundary cache.
|
||||
|
||||
## Example
|
||||
|
||||
The following command stops the Boundary cache:
|
||||
|
||||
```shell-session
|
||||
$ boundary cache stop
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary cache stop [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: client-agent - Command
|
||||
description: >-
|
||||
The "client-agent" command lets you interact with the Boundary Client Agent.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# client-agent
|
||||
|
||||
Command: `boundary client-agent`
|
||||
|
||||
The `client-agent` command lets you interact with the Boundary Client Agent.
|
||||
You can check the Client Agent's status, pause it, resume it, or list the active transparent sessions the Client Agent is managing.
|
||||
|
||||
## Examples
|
||||
|
||||
The following command lets you check the status of the Client Agent to ensure it is running:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent status
|
||||
```
|
||||
|
||||
The following command retrieves information about any sessions that the Client Agent is managing:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent sessions
|
||||
```
|
||||
|
||||
You can temporarily disable the Client Agent by pausing it with the following command:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent pause
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary client-agent <subcommand> [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
pause Pauses the running boundary client agent
|
||||
resume Resumes the paused boundary client agent
|
||||
sessions List active transparent sessions managed by the client agent.
|
||||
status Get the status information of the running boundary client agent
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [pause](/boundary/docs/commands/client-agent/pause)
|
||||
- [resume](/boundary/docs/commands/client-agent/resume)
|
||||
- [sessions](/boundary/docs/commands/client-agent/sessions)
|
||||
- [status](/boundary/docs/commands/client-agent/status)
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: client-agent pause - Command
|
||||
description: >-
|
||||
The "client-agent pause" command pauses the Client Agent so that it does not intercept DNS requests.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# client-agent pause
|
||||
|
||||
Command: `boundary client-agent pause`
|
||||
|
||||
The `boundary client-agent pause` command lets you temporarily stop the Client Agent.
|
||||
When the Client Agent is paused, it does not intercept DNS requests and you cannot use transparent sessions.
|
||||
|
||||
## Example
|
||||
|
||||
The following command pauses the Client Agent:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent pause
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent pause [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `client-agent-port=<uint>` - Specifies the port on which the Client Agent listens.
|
||||
You can also specify the port using the **BOUNDARY_CLIENT_AGENT_LISTENING_PORT** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: client-agent resume - Command
|
||||
description: >-
|
||||
The "client-agent resume" command resumes running the Client Agent when it is paused.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# client-agent resume
|
||||
|
||||
Command: `boundary client-agent resume`
|
||||
|
||||
The `boundary client-agent resume` command lets you resume the Client Agent when it is paused.
|
||||
When the Client Agent is paused, it does not intercept DNS requests and you cannot use transparent sessions.
|
||||
You must resume the Client Agent to use transparent sessions again after you pause it.
|
||||
|
||||
## Example
|
||||
|
||||
The following command resumes the Client Agent:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent resume
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent resume [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `client-agent-port=<uint>` - Specifies the port on which the Client Agent listens.
|
||||
You can also specify the port using the **BOUNDARY_CLIENT_AGENT_LISTENING_PORT** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: client-agent sessions - Command
|
||||
description: >-
|
||||
The "client-agent sessions" command lists any active sessions that the Client Agent is managing. It also lists any associated brokered credentials.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# client-agent sessions
|
||||
|
||||
Command: `boundary client-agent sessions`
|
||||
|
||||
The `boundary client-agent sessions` command lists any sessions that the Client Agent is managing as well as any brokered credentials that are associated with those sessions.
|
||||
|
||||
## Example
|
||||
|
||||
The following command lists any sessions that the Client Agent is managing:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent sessions
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent sessions [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `client-agent-port=<uint>` - Specifies the port on which the Client Agent listens.
|
||||
You can also specify the port using the **BOUNDARY_CLIENT_AGENT_LISTENING_PORT** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: client-agent status - Command
|
||||
description: >-
|
||||
The "client-agent status" command provides the status of the Client Agent so you can ensure that it is running.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# client-agent status
|
||||
|
||||
Command: `boundary client-agent status`
|
||||
|
||||
You can use the `boundary client-agent status` command to ensure that the Client Agent is running.
|
||||
The command provides the runtime status and information about whether the current user is authenticated.
|
||||
It may also include a list of errors, if the Client Agent has encountered any.
|
||||
|
||||
## Example
|
||||
|
||||
The following command provides the current status of the Client Agent:
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent status
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary client-agent status [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `client-agent-port=<uint>` - Specifies the port on which the Client Agent listens.
|
||||
You can also specify the port using the **BOUNDARY_CLIENT_AGENT_LISTENING_PORT** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: config autocomplete - Command
|
||||
description: >-
|
||||
The "config autocomplete" command installs or uninstalls autocompletion support for Boundary's CLI.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# config autocomplete
|
||||
|
||||
Command: `boundary config autocomplete`
|
||||
|
||||
The `config autocomplete` command lets you install or uninstall autocompletion support
|
||||
for Boundary's CLI.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following command installs autocompletion support for Boundary's CLI:
|
||||
|
||||
```shell-session
|
||||
$ boundary config autocomplete install
|
||||
```
|
||||
|
||||
The following command uninstalls autocompletion support from Boundary's CLI:
|
||||
|
||||
```shell-session
|
||||
$ boundary config autocomplete uninstall
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
**Install:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary config autocomplete install [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
**Uninstall:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary config autocomplete uninstall [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: config decrypt - Command
|
||||
description: >-
|
||||
The "config decrypt" command decrypts sensitive values in configuration files. You must mark sensitive values with {{decrypt()}} as appropriate.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# config decrypt
|
||||
|
||||
Command: `boundary config decrypt`
|
||||
|
||||
The `config decrypt` command decrypts sensitive values in a Boundary
|
||||
configuration file. You must mark these values with `{{decrypt()}}` as
|
||||
appropriate, for example: `key = {{decrypt(encrypted_value)}}`.
|
||||
|
||||
## Examples
|
||||
|
||||
The following command overwrites the existing configuration file using the `-overwrite` flag:
|
||||
|
||||
```shell-session
|
||||
$ boundary config decrypt -overwrite config.hcl
|
||||
```
|
||||
|
||||
In order for this command to perform its task, you must define a "kms" block within the configuration file:
|
||||
|
||||
```hcl
|
||||
kms "aead" {
|
||||
purpose = "config"
|
||||
aead_type = "aes-gcm"
|
||||
key = "7xtkEoS5EXPbgynwd+dDLHopaCqK8cq0Rpep4eooaTs="
|
||||
}
|
||||
```
|
||||
|
||||
You can define the "kms" block in the configuration file or using the `-config`
|
||||
flag. If you define it in the configuration file, only string parameters are
|
||||
supported, and the markers must be inside the quotation marks that delimit the string.
|
||||
Additionally, if you define the block inline, do not use an "aead" block with
|
||||
the key defined in the configuration file, as it provides no protection.
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary config decrypt [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-config` `(string: "")` - The configuration file to decrypt.
|
||||
|
||||
- `-config-kms` `(string: "")` - If set, the given file is parsed for
|
||||
a "kms" block with purpose `config` to determine whether it should be used to perform the command.
|
||||
If you do not configure this value, the command expects a block to be defined inline with the configuration file, and will only be able to support quoted string parameters.
|
||||
|
||||
- `-overwrite` - If set, overwrites the existing file. The default value is
|
||||
`false`.
|
||||
|
||||
- `-strip` - If set, strips the declarations from the file afterwards.
|
||||
The default value is `false`.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: config encrypt - Command
|
||||
description: >-
|
||||
The "config encrypt" command encrypts sensitive values in configuration files. You must mark sensitive values with {{encrypt()}} as appropriate.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# config encrypt
|
||||
|
||||
Command: `boundary config encrypt`
|
||||
|
||||
The `config encrypt` command encrypts sensitive values in a Boundary
|
||||
configuration file. You must mark these values with `{{encrypt()}}` as
|
||||
appropriate, for example: `key = {{encrypt(key_value)}}`.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following command overwrites the existing configuration file use the `-overwrite` flag:
|
||||
|
||||
```shell-session
|
||||
$ boundary config encrypt -overwrite config.hcl
|
||||
```
|
||||
|
||||
In order for this command to perform its task, you must define a "kms" block within a configuration file:
|
||||
|
||||
```hcl
|
||||
kms "aead" {
|
||||
purpose = "config"
|
||||
aead_type = "aes-gcm"
|
||||
key = "7xtkEoS5EXPbgynwd+dDLHopaCqK8cq0Rpep4eooaTs="
|
||||
}
|
||||
```
|
||||
|
||||
You can define the "kms" block in the configuration file or using the `-config`
|
||||
flag. If you define it in the configuration file, only string parameters are
|
||||
supported, and the markers must be inside the quotation marks that delimit the string.
|
||||
Additionally, if you define the block inline, do not use an "aead" block with
|
||||
the key defined in the configuration file as it provides no protection.
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary config encrypt [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-config` `(string: "")` - The configuration file to encrypt.
|
||||
|
||||
- `-config-kms` `(string: "")` - If set, the given file is parsed for
|
||||
a "kms" block with purpose `config` to determine whether it should be used to perform the command.
|
||||
If you do not configure this value, the command expects a block to be defined inline with the configuration file, and will only be able to support quoted string parameters.
|
||||
|
||||
- `-overwrite` - If set, overwrites the existing file. The default value is
|
||||
`false`.
|
||||
|
||||
- `-strip` - If set, strips the declarations from the file afterwards.
|
||||
The default value is `false`.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,97 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: config get-token - Command
|
||||
description: >-
|
||||
The "config get-token" command fetches a token stored by the Boundary CLI.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# config get-token
|
||||
|
||||
Command: `boundary config get-token`
|
||||
|
||||
The `config get-token` command fetches a token stored by the Boundary CLI.
|
||||
|
||||
## Examples
|
||||
|
||||
The following command gets the token stored by the Boundary CLI:
|
||||
|
||||
```shell-session
|
||||
$ boundary config get-token
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
at_yczA5UPS7Y_s13B5PWh7KENvtKQKgDxaEvP682FMfq5eXrpzKNTpmaHgLS2ucRexrTQ7ueMhDFY5MdFvNuzuTWzUzYgacitnSBaPo75b3XZU4Zp6wmdsXqmkPNY3U
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
This command can be useful in various situations. For example, developers could share a line such as the following in a shell script, such that each
|
||||
developer on their own machine executes the script using their own
|
||||
Boundary token:
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ curl --header "Authorization: Bearer $(boundary config get-token)" \
|
||||
--header "Content-Type: application/json" \
|
||||
http://127.0.0.1:9200/v1/roles/r_1234567890
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
This command keeps parity with the behavior of other Boundary commands; if you set the
|
||||
`BOUNDARY_TOKEN` environment variable, it overrides the value loaded
|
||||
from the system store. Not only does this keep parity, but it also allows
|
||||
examples such as the one above to work even if there is no stored token, but you specified
|
||||
an environment variable.
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary config get-token [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-account-id` - Prints out the account ID
|
||||
associated with the token instead of the token itself, if specified. The default value is
|
||||
`false`.
|
||||
|
||||
- `-auth-method-id` - Prints out the auth method ID
|
||||
associated with the token instead of the token itself, if specified. The default value is `false`.
|
||||
|
||||
- `-keyring-type` `(string: "")` - Indicates the type of keyring to use. This value defaults to
|
||||
`auto` which uses the Windows credential manager, OSX keychain, or
|
||||
cross-platform password store depending on the platform. Set this value to `none` to disable
|
||||
keyring functionality. The following keyring types are available, depending on platform:
|
||||
|
||||
- `wincred`
|
||||
- `keychain`
|
||||
- `pass`
|
||||
- `secret-service`
|
||||
|
||||
You can also specify the keyring type using the **BOUNDARY_KEYRING_TYPE** environment
|
||||
variable.
|
||||
|
||||
- `-token-name` `(string: "")` - Indicates whether the given value should be used as
|
||||
the name when loading the token from the system credential store. This value must
|
||||
correspond to a name used when authenticating. You can also specify the token name using
|
||||
the **BOUNDARY_TOKEN_NAME** environment variable.
|
||||
|
||||
- `-user-id` - Prints out the user ID associated
|
||||
with the token instead of the token itself, if specified. The default value is `false`.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,65 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: config - Command
|
||||
description: >-
|
||||
The "config" command groups subcommands that interact with Boundary's configuration files.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# config
|
||||
|
||||
Command: `boundary config`
|
||||
|
||||
The `config` command groups subcommands for operators to interact with
|
||||
Boundary's configuration files.
|
||||
|
||||
## Examples
|
||||
|
||||
The following command encrypts sensitive values in a configuration file:
|
||||
|
||||
```shell-session
|
||||
$ boundary config encrypt config.hcl
|
||||
```
|
||||
|
||||
The following command decrypts sensitive values in a configuration file:
|
||||
|
||||
```shell-session
|
||||
$ boundary config decrypt config.hcl
|
||||
```
|
||||
|
||||
The following command reads a stored token's output.
|
||||
|
||||
```shell-session
|
||||
$ boundary config get-token
|
||||
```
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary config <subcommand> [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
autocomplete Install or uninstall autocompletion for Boundary's CLI
|
||||
decrypt Decrypt sensitive values in Boundary's configuration file
|
||||
encrypt Encrypt sensitive values in Boundary's configuration file
|
||||
get-token Get the stored token, or its properties
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [autocomplete](/boundary/docs/commands/config/autocomplete)
|
||||
- [decrypt](/boundary/docs/commands/config/decrypt)
|
||||
- [encrypt](/boundary/docs/commands/config/encrypt)
|
||||
- [get-token](/boundary/docs/commands/config/get-token)
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect cassandra - Command
|
||||
description: >-
|
||||
The "connect cassandra" command performs a target authorization or consumes an existing authorization token, and then launches a proxied Cassandra (CQL) connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect cassandra
|
||||
|
||||
Command: `boundary connect cassandra`
|
||||
The `connect cassandra` command authorizes a session against a target and invokes a Cassandra client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
> **Note:** Currently, only configurations using Cassandra's `PasswordAuthenticator` are supported.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example shows how to connect to a target with the ID `ttcp_eTcZMueUYv` using a Cassandra helper:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect cassandra -target-id=ttcp_eTcZMueUYv \
|
||||
-keyspace=mykeyspace \
|
||||
-username=superuser
|
||||
```
|
||||
|
||||
When prompted, you must enter the password for the user, "superuser":
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Password:
|
||||
Connected to example-cluster at localhost:9042
|
||||
[cqlsh 6.2.0 | Cassandra 5.0.4 | CQL spec 3.4.7 | Native protocol v5]
|
||||
Use HELP for help.
|
||||
superuser@cqlsh:mykeyspace>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect cassandra [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### Cassandra options:
|
||||
|
||||
- `-keyspace` `(string: "")` - The keyspace name you want to pass through to the client.
|
||||
You can also specify the keyspace name using the **BOUNDARY_CONNECT_KEYSPACE** environment variable.
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke a Cassandra client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `cqlsh`.
|
||||
You can also specify how the CLI attempts to invoke a Cassandra client using the **BOUNDARY_CONNECT_CASSANDRA_STYLE** environment variable.
|
||||
|
||||
- `-username` `(string: "")` - The username you want to pass through to the client.
|
||||
This value may be overridden by credentials sourced from a credential store.
|
||||
You can also specify a username using the **BOUNDARY_CONNECT_USERNAME** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect http - Command
|
||||
description: >-
|
||||
The "connect http" command command performs a target authorization or consumes an existing authorization token, and then launches a proxied http connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect http
|
||||
|
||||
Command: `boundary connect http`
|
||||
|
||||
The `connect http` command authorizes a session against a target and invokes an
|
||||
HTTP client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
## Example
|
||||
|
||||
The following example authorizes a session to a target with the ID `ttcp_1234567890` and invokes the default HTTP client, `curl`:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect http -target-id=ttcp_1234567890
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect http [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
This command performs a target authorization or consumes an existing authorization token, and launches a proxied HTTP connection.
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### HTTP options:
|
||||
|
||||
- `-host` `(string: "")` - The host value to use.
|
||||
This setting overrides the endpoint address from the session information.
|
||||
Boundary passes the specified host name through to the client for use in the host header and TLS SNI value, if supported.
|
||||
You can also specify the host value using the **BOUNDARY_CONNECT_HTTP_HOST** environment variable.
|
||||
|
||||
- `-method` `(string: "")` - The HTTP method to use.
|
||||
If you don't set a method, Boundary uses the client's default.
|
||||
You can also specify a method using a the **BOUNDARY_CONNECT_HTTP_METHOD** environment variable.
|
||||
|
||||
- `-path` `(string: "")` - The path that is appended to the
|
||||
generated URL.
|
||||
You can also specify a path using the **BOUNDARY_CONNECT_HTTP_PATH** environment variable.
|
||||
|
||||
- `-scheme` `(string: "")` - The scheme to use.
|
||||
The default scheme is `https`.
|
||||
You can also specify the scheme using the **BOUNDARY_CONNECT_HTTP_SCHEME** environment variable.
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke an HTTP client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `curl`.
|
||||
You can also specify how the CLI attempts to invoke the HTTP client using the **BOUNDARY_CONNECT_HTTP_STYLE** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,104 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect - Command
|
||||
description: >-
|
||||
The "connect" command authorizes a target resource and launches a proxied connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect
|
||||
|
||||
Command: `boundary connect`
|
||||
|
||||
Every command that results in an API call contains a set of flags that control connection options, which include TLS and other settings.
|
||||
Boundary provides connect helpers that can facilitate access to certain protocols like HTTP, RDP, and SSH.
|
||||
One example is the Boundary helper for SSH that automatically accepts host SSH key prompts for you.
|
||||
You run these connect helpers using the command `boundary connect <subcommand>`.
|
||||
You can run `boundary connect -h` to see the available helpers, options, and arguments.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example connects to a target `ttcP_INY0BCD2VF` and shows the use of the
|
||||
[`-listen-addr`](/boundary/docs/commands//connect#-listen-port) and
|
||||
[`-listen-port`](/boundary/docs/commands//connect#-listen-addr) flags
|
||||
to specify the listening address and port used that Boundary will attempt to use
|
||||
for every connection. This example uses the address `127.0.0.1` and
|
||||
the port `8872`:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect ssh \
|
||||
-listen-addr=127.0.0.1 \
|
||||
-listen-port=8872
|
||||
-target_id=ttcp_INY0BCD2VF
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```text
|
||||
Usage: boundary connect <subcommand> [options] [args]
|
||||
# ...
|
||||
Subcommands:
|
||||
http Authorize a session against a target and invoke an HTTP client to connect
|
||||
kube Authorize a session against a target and invoke a Kubernetes client to connect
|
||||
cassandra Authorize a session against a target and invoke a Cassandra client to connect
|
||||
mysql Authorize a session against a target and invoke a MySQL client to connect
|
||||
mongo Authorize a session against a target and invoke a MongoDB client to connect
|
||||
postgres Authorize a session against a target and invoke a Postgres client to connect
|
||||
rdp Authorize a session against a target and invoke an RDP client to connect
|
||||
redis Authorize a session against a target and invoke a redis client to connect
|
||||
ssh Authorize a session against a target and invoke an SSH client to connect
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [http](/boundary/docs/commands/connect/http)
|
||||
- [kube](/boundary/docs/commands/connect/kube)
|
||||
- [cassandra](/boundary/docs/commands/connect/cassandra)
|
||||
- [mysql](/boundary/docs/commands/connect/mysql)
|
||||
- [mongo](/boundary/docs/commands/connect/mongo)
|
||||
- [postgres](/boundary/docs/commands/connect/postgres)
|
||||
- [rdp](/boundary/docs/commands/connect/rdp)
|
||||
- [redis] (/boundary/docs/commands/connect/redis)
|
||||
- [ssh](/boundary/docs/commands/connect/ssh)
|
||||
|
||||
### Command options
|
||||
|
||||
- `-addr` `(string: "")` - The address of the Boundary controller as a complete URL, for example https://boundary.example.com:9200.
|
||||
Instead of passing the `-addr` argument with every command, you can configure the **BOUNDARY_ADDR** environment variable.
|
||||
In both cases, the value denotes the address of the Boundary environment you want to send CLI commands to.
|
||||
- `-ca-cert` `(string: "")` - The path on the local disk to a single PEM-encoded CA certificate that should be used to verify the controller or worker server's SSL certificate.
|
||||
This value takes precedence over `-ca-path`.
|
||||
You can also specify the path using the **BOUNDARY_CACERT** environment variable.
|
||||
- `-ca-path` `(string: "")` - The path on the local disk to a directory of PEM-encoded CA certificates that should be used to verify the controller's SSL certificate.
|
||||
You can also specify the path using the **BOUNDARY_CAPATH** environment variable.
|
||||
- `-client-cert` `(string: "")` - The path on the local disk to a single PEM-encoded CA certificate that should be used for TLS authentication to the Boundary controller.
|
||||
If you configure this flag, the `-client-key` value is also required.
|
||||
You can also specify the path using the **BOUNDARY_CLIENT_CERT** environment variable.
|
||||
- `-client-key` `(string: "")` - The path on the local disk to a single PEM-encoded private key that matches the client certificate you referenced with `-client-cert`.
|
||||
You can also specify the path using the **BOUNDARY_CLIENT_KEY** environment variable.
|
||||
- `-listen-addr` `(string: "")` - If set, the CLI attempts to bind its listening address to the given value, which must be an IP address.
|
||||
If it cannot bind the listening address, the command produces an error.
|
||||
If you do not set this value, Boundary defaults to the most common IPv4 loopback address, 127.0.0.1.
|
||||
You can also specify a listening address using the **BOUNDARY_CONNECT_LISTEN_ADDR** environment variable.
|
||||
- `-listen-port` `(string: "")` - If set, the CLI attempts to bind its listening port to the given value.
|
||||
If it cannot bind the listening port, the command produces error.
|
||||
You can also specify a listening address using the **BOUNDARY_CONNECT_LISTEN_PORT** environment variable.
|
||||
- `-tls-insecure` - If set, this option disables verification of TLS certificates.
|
||||
We highly discourage using this option as it decreases the security of data transmissions to
|
||||
and from the Boundary server.
|
||||
The default value is `false`.
|
||||
You can also disable TLS certificate validation using the **BOUNDARY_TLS_INSECURE** environment variable.
|
||||
- `-tls-server-name` `(string: "")` - A name to use as the SNI host when you connect to the Boundary server using TLS.
|
||||
You can also specify the SNI host using the **BOUNDARY_TLS_SERVER_NAME** environment variable.
|
||||
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect kube - Command
|
||||
description: >-
|
||||
The "connect kube" command command performs a target authorization or consumes an existing authorization token, and then launches a proxied kube connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect kube
|
||||
|
||||
Command: `boundary connect kube`
|
||||
|
||||
The `connect kube` command authorizes a session against a target and invokes a
|
||||
Kubernetes client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
## Examples
|
||||
|
||||
The following example authorizes a session to a target with the ID `ttcp_1234567890` and runs the `get nodes` command using the default `kubectl` client:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect kube \
|
||||
-target-id ttcp_t12345 \
|
||||
-- get nodes
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect kube [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
This command performs a target authorization or consumes an existing authorization token, and launches a proxied Kube connection.
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### Kubernetes options:
|
||||
|
||||
- `-host` `(string: "")` - The host value to use.
|
||||
If set, this value overrides the endpoint address from the session information.
|
||||
Boundary passes the specified host name through to the client for use in the TLS SNI value, if supported.
|
||||
You can also specify the host value using the **BOUNDARY_CONNECT_KUBE_HOST** environment variable.
|
||||
|
||||
- `-scheme` `(string: "")` - The scheme to use.
|
||||
The default value is `https`.
|
||||
You can also specify the scheme using the **BOUNDARY_CONNECT_KUBE_SCHEME** environment variable.
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke a Kubernetes client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `kubectl`.
|
||||
You can also specify how the CLI attempts to invoke a Kubernetes client using the `BOUNDARY_CONNECT_KUBE_STYLE` environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect mongo - Command
|
||||
description: >-
|
||||
The "connect mongo" command performs a target authorization or consumes an existing authorization token, and then launches a proxied MongoDB connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect mongo
|
||||
|
||||
Command: `boundary connect mongo`
|
||||
|
||||
The `connect mongo` command authorizes a session against a target and invokes a MongoDB client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example shows how to connect to a target with the ID `ttcp_eTcMueUYv` using a MongoDB helper:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect mongo -target-id=ttcp_eTcZMueUYv \
|
||||
-dbname=northwind \
|
||||
-username=superuser \
|
||||
-authentication-database=admin \
|
||||
-format=table
|
||||
```
|
||||
|
||||
When prompted, you must enter the password for the user, "superuser":
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Enter password:
|
||||
Current Mongosh Log ID: 64a1b2c3d4e5f6789012345
|
||||
Connecting to: mongodb://127.0.0.1:12345/northwind?authSource=admin
|
||||
Using MongoDB: 7.0.0
|
||||
Using Mongosh: 2.0.0
|
||||
|
||||
northwind> show collections
|
||||
orders
|
||||
products
|
||||
customers
|
||||
|
||||
northwind> db.products.count()
|
||||
77
|
||||
|
||||
northwind>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect mongo [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### MongoDB options:
|
||||
|
||||
- `-dbname` `(string: "")` - The database name you want to pass through to the client.
|
||||
You can also specify the database name using the **BOUNDARY_CONNECT_DBNAME** environment variable.
|
||||
|
||||
- `-style` `(string: "mongosh")` - How the CLI attempts to invoke a MongoDB client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `mongosh`.
|
||||
You can also specify how the CLI attempts to invoke a MongoDB client using the **BOUNDARY_CONNECT_MONGO_STYLE** environment variable.
|
||||
|
||||
- `-username` `(string: "")` - The username you want to pass through to the client.
|
||||
This value may be overridden by credentials sourced from a credential store.
|
||||
You can also specify a username using the **BOUNDARY_CONNECT_USERNAME** environment variable.
|
||||
|
||||
- `-authentication-database` `(string: "")` - The authentication database for MongoDB.
|
||||
If omitted, mongosh defaults `authSource` to the database name (`-dbname`). If no database is specified, it defaults to `admin`.
|
||||
You can also specify the authentication database using the **BOUNDARY_CONNECT_MONGO_AUTHENTICATION_DATABASE** environment variable.
|
||||
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect mysql - Command
|
||||
description: >-
|
||||
The "connect mysql" command performs a target authorization or consumes an existing authorization token, and then launches a proxied MySQL connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect mysql
|
||||
|
||||
Command: `boundary connect mysql`
|
||||
|
||||
The `connect mysql` command authorizes a session against a target and invokes a MySQL client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example shows how to connect to a target with the ID `ttcp_eTcMueUYv` using a MySQL helper:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect mysql -target-id=ttcp_eTcZMueUYv \
|
||||
-dbname=northwind \
|
||||
-username=superuser \
|
||||
-format=table
|
||||
```
|
||||
|
||||
When prompted, you must enter the password for the user, "superuser":
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Enter password:
|
||||
Welcome to the MySQL monitor. Commands end with ; or \g.
|
||||
Your MySQL connection id is 8
|
||||
Server version: 8.0.30 MySQL Community Server - GPL
|
||||
|
||||
Copyright (c) 2000, 2022, Oracle and/or its affiliates.
|
||||
|
||||
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
|
||||
|
||||
mysql>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect mysql [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### MySQL options:
|
||||
|
||||
- `-dbname` `(string: "")` - The database name you want to pass through to the client.
|
||||
You can also specify the database name using the **BOUNDARY_CONNECT_DBNAME** environment variable.
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke a MySQL client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `mysql`.
|
||||
You can also specify how the CLI attempts to invoke a MySQL client using the **BOUNDARY_CONNECT_MYSQL_STYLE** environment variable.
|
||||
|
||||
- `-username` `(string: "")` - The username you want to pass through to the client.
|
||||
This value may be overridden by credentials sourced from a credential store.
|
||||
You can also specfiy a username using the **BOUNDARY_CONNECT_USERNAME** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect postgres - Command
|
||||
description: >-
|
||||
The "connect postgres" command performs a target authorization or consumes an existing authorization token, and then launches a proxied PostgreSQL connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect postgres
|
||||
|
||||
Command: `boundary connect postgres`
|
||||
|
||||
The `connect postgres` command authorizes a session against a target and invokes a Postgres client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example shows how to connect to a target with the ID `ttcp_eTcMueUYv` using a Postgres helper:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect postgres -target-id=ttcp_eTcZMueUYv \
|
||||
-dbname=northwind \
|
||||
-username=superuser \
|
||||
-format=table
|
||||
```
|
||||
|
||||
When prompted, you must enter the password for the user, "superuser":
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Password for user superuser:
|
||||
psql (14.2, server 13.2 (Debian 13.2-1.pgdg100+1))
|
||||
Type "help" for help.
|
||||
|
||||
postgres=#
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect postgres [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### Postgres options:
|
||||
|
||||
- `-dbname` `(string: "")` - The database name you want to pass through to the client.
|
||||
You can also specify the database name using the **BOUNDARY_CONNECT_DBNAME** environment variable.
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke a Postgres client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `psql`.
|
||||
You can also specify how the CLI attempts to invoke a Postgres client using the **BOUNDARY_CONNECT_POSTGRES_STYLE** environment variable.
|
||||
|
||||
- `-username` `(string: "")` - The username you want to pass through to the client.
|
||||
This value may be overridden by credentials sourced from a credential store.
|
||||
You can also specfiy a username using the **BOUNDARY_CONNECT_USERNAME** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect rdp - Command
|
||||
description: >-
|
||||
The "connect rdp" command command performs a target authorization or consumes an existing authorization token, and then launches a proxied RDP connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect rdp
|
||||
|
||||
Command: `boundary connect rdp`
|
||||
|
||||
The `connect rdp` command authorizes a session against a target and invokes an RDP client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
## Examples
|
||||
|
||||
The following example authorizes a session to a target with the ID `ttcp_1234567890` and invokes an RDP session with the built-in Windows RDP client, `mstsc`:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect rdp \
|
||||
-target-id ttcp_1234567890
|
||||
```
|
||||
|
||||
The following example authorizes a session to a target with the ID `ttcp_123457890` and invokes a custom command for the RDP macOS client:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect rdp \
|
||||
-target-id ttcp_1234567890
|
||||
-exec bash \
|
||||
-- -c "open rdp://full%20address=s={{boundary.addr}} && sleep 600"
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect rdp [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
This command performs a target authorization or consumes an existing authorization token, and launches a proxied RDP connection.
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### RDP options:
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke an RDP client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The currently-understood value is `mstsc`, which is the default on Windows and launches the Windows client.
|
||||
It is also the default on Mac, and launches an rdp://URL.
|
||||
You can also specify how the CLI attempts to invoke an RDP client using the **BOUNDARY_CONNECT_RDP_STYLE** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect redis - Command
|
||||
description: >-
|
||||
The "connect redis" command performs a target authorization or consumes an existing authorization token, and then launches a proxied redis (redis-cli) connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect redis
|
||||
|
||||
Command: `boundary connect redis`
|
||||
The `connect redis` command authorizes a session against a target and invokes a Redis client for the connection.
|
||||
The command fills in the local address and port.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example shows how to connect to a target with the ID `ttcp_eTcZMueUYv` using a Redis helper:
|
||||
|
||||
```shell-session
|
||||
$ boundary connect redis -target-id=ttcp_eTcZMueUYv \
|
||||
-username=superuser
|
||||
```
|
||||
|
||||
When prompted, you must enter the password for the user, "superuser":
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
|
||||
```plaintext
|
||||
Please input password:
|
||||
127.0.0.1:60835>
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect redis [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### Redis options:
|
||||
|
||||
- `-style` `(string: "")` - How the CLI attempts to invoke a Redis client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
The default and currently-understood value is `redis-cli`.
|
||||
You can also specify how the CLI attempts to invoke a Redis client using the **BOUNDARY_CONNECT_REDIS_STYLE** environment variable.
|
||||
|
||||
- `-username` `(string: "")` - The username you want to pass through to the client.
|
||||
This value may be overridden by credentials sourced from a credential store.
|
||||
You can also specify a username using the **BOUNDARY_CONNECT_USERNAME** environment variable.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,99 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: connect ssh - Command
|
||||
description: >-
|
||||
The "connect ssh" command command performs a target authorization or consumes an existing authorization token, and then launches a proxied SSH connection.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# connect ssh
|
||||
|
||||
Command: `boundary connect ssh`
|
||||
|
||||
The `connect ssh` command authorizes a session against a target and invokes an SSH client for the connection.
|
||||
The command fills in the local address and port.
|
||||
You can specify your SSH client of choice using the `-style` option.
|
||||
|
||||
@include 'cmd-connect-env-vars.mdx'
|
||||
|
||||
The SSH helper command sets the host key `Alias`.
|
||||
When an `Alias` is set, SSH does not use `localhost:<port>` for host key validation, but instead uses one of the following:
|
||||
|
||||
- For connections to a target that has an attached host set, the SSH helper command sets the `HostID` as the alias.
|
||||
- For connections directly to a host, the SSH helper command sets the `HostID` as the alias.
|
||||
- For connections to a target that has an address field configured, the SSH helper command sets the `TargetID` as the alias.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example authorizes a session to a target with the ID `ttcp_eTcZMueUYv` and invokes the default SSH client without any additional options:
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect ssh -target-id ttcp_eTcZMueUYv
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
The following example authorizes a session to a target with the ID `ttcp_eTcZMueUYv`, and pipes arguments directly to the invoked SSH binary.
|
||||
Any SSH arguments after the double hyphen are sent directly to the binary:
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect ssh -target-id ttcp_eTcZMueUYv -- -A
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect ssh -target-scope-name Helpdesk -target-name ubuntu-server -- -A
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect ssh -target-id=ttcp_Gymo7Vcq7Y \
|
||||
-host-id=hst_FrdNPd9Zm9 -- -l ubuntu -i private_key.pem
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary connect ssh [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
This command performs a target authorization or consumes an existing authorization token, and launches a proxied SSH connection.
|
||||
|
||||
@include 'cmd-connect-command-options.mdx'
|
||||
|
||||
### SSH options:
|
||||
|
||||
- `style` `(string: "")` - How the CLI attempts to invoke an SSH
|
||||
client.
|
||||
This value also sets a suitable default for `-exec`, if you did not specify a value.
|
||||
Currently understood values are `ssh` and `putty`.
|
||||
The default is `ssh`.
|
||||
You can also specify how the CLI attempts to invoke the SSH client using the **BOUNDARY_CONNECT_SSH_STYLE** environment variable.
|
||||
|
||||
- `username` `(string: "")` - The username you want to pass through to the
|
||||
client.
|
||||
You can also specify a username using the **BOUNDARY_CONNECT_USERNAME** environment variable.
|
||||
|
||||
- `remote-command` `(string: "")` - A command that you want to run on the remote host.
|
||||
You can specify a complete command line, or you may include additional arguments.
|
||||
If you include additional arguments, you must append them to the command and separate them using spaces.
|
||||
@@ -1,202 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-libraries create - Command
|
||||
description: >-
|
||||
The "credential-libraries create" command creates new credential library resources. You can create a generic Vault or Vault SSH certificate credential library.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-libraries create
|
||||
|
||||
Command: `boundary credential-libraries create`
|
||||
|
||||
The `credential-libraries create` command lets you create a credential library resource in Boundary.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example creates a credential library for database credentials where Vault's database secrets engine provides dynamic credentials:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create vault-generic \
|
||||
-credential-store-id csvlt_5fvkRjCjou \
|
||||
-vault-path "database/creds/dba" \
|
||||
-name "northwind dba"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Library information:
|
||||
Created Time: Wed, 28 Sep 2022 08:50:32 MDT
|
||||
Credential Store ID: csvlt_Xqa6V6QwfM
|
||||
ID: clvlt_Ex17uiP7FO
|
||||
Name: northwind dba
|
||||
Type: vault
|
||||
Updated Time: Wed, 28 Sep 2022 08:50:32 MDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_EZaXO0OZPX
|
||||
Name: db-project
|
||||
Parent Scope ID: o_R1QFYcO743
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
HTTP Method: GET
|
||||
Path: database/creds/dba
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create [type] [sub command] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-credential-store-id` `(string: "")` - The credential store resource to use
|
||||
for the operation. You can also specify the credential store using the
|
||||
**BOUNDARY_CREDENTIAL_STORE_ID** environment variable.
|
||||
- `-description` `(string: "")` - A description of the credential library.
|
||||
- `-name` `(string: "")` - The name of the credential library.
|
||||
|
||||
|
||||
### Usages by type
|
||||
|
||||
The available types are `vault-generic` and `vault-ssh-certificate`.
|
||||
|
||||
<Note>
|
||||
|
||||
A credential library type, `vault` is deprecated, so use `vault-generic` type instead.
|
||||
|
||||
</Note>
|
||||
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Vault">
|
||||
|
||||
The `credential-libraries create vault-generic` command lets you create a generic Vault credential library.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a generic Vault credential library using a credential store with the ID `csvlt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create vault-generic \
|
||||
-credential-store-id csvlt_1234567890 \
|
||||
-vault-path "database/creds/dba"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create vault-generic [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Vault credential library options
|
||||
|
||||
The following are specific Vault credential library options in addition to the command options:
|
||||
|
||||
- `-credential-mapping-override` - An override for credential mapping.
|
||||
- `-credential-type` `(string: "")` - The type of credential this library issues.
|
||||
The default value is `Unspecified`.
|
||||
- `-vault-http-method` `(string: "")` - The HTTP method the library should use when it communicates with Vault.
|
||||
- `-vault-http-request-body` `(string: "")` - The HTTP request body the credential library uses to communicate with Vault.
|
||||
This value can be the HTTP request body value itself, it can refer to a file on disk (`file://`) from which the value is read, or it can refer to an environment variable (`env://`) from which the value is read.
|
||||
- `-vault-path` `(string: "")` - The path in Vault to request credentials from.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="Vault SSH certificate">
|
||||
|
||||
The `credential-libraries create vault-ssh-certificate` command lets you create a Vault SSH certificate credential library.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a Vault SSH certificate credential library with the ID `csvlt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create vault-ssh-certificate \
|
||||
-credential-store-id csvlt_1234567890 \
|
||||
-vault-path "/ssh/sign/role" \
|
||||
-username user
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create vault-ssh-certificate [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Vault SSH certificate credential library options
|
||||
|
||||
The following are options are specific to the Vault SSH certificate credential library, in addition to the command options:
|
||||
|
||||
- `-additional-valid-principal` - Any additional users or groups that you want to configure as valid principals.
|
||||
By default, Boundary only passes the username to Vault to sign as a valid principal.
|
||||
Use this option when you want to configure additional users or groups as valid principals that the certificate should be signed for in Vault.
|
||||
|
||||
For more information, refer to OpenSSH's definition of [valid principals](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L176-L181) and Vault's [SSH secrets engine](https://developer.hashicorp.com/vault/api-docs/secret/ssh#valid_principals) documentation.
|
||||
- `-critical-option` - A key=value pair to add to the request's
|
||||
critical-options map.
|
||||
It can also be a key value only which sets a JSON null as the value.
|
||||
If you provide a value, Boundary infers the type automatically.
|
||||
You can use `-string-critical-option`, `-bool-critical-option`, or `-num-critical-option` to override the type.
|
||||
You can specify values for this option multiple times.
|
||||
This option supports sourcing values from files using `file://` and environment variables using `env://`.
|
||||
- `-critical-options` `(string: "")` - A JSON map value to use as the entirety of the request's critical-options map.
|
||||
Usually this value is sourced from a file using the `file://` syntax.
|
||||
This value is exclusive with the other critical-option flags.
|
||||
- `-extension` - A key=value pair to add to the request's extensions map.
|
||||
It can also be a key value only which will set a JSON null as the value.
|
||||
If you provide a value, Boundary automatically infers the type.
|
||||
You can use `-string-extension`, `-bool-extension`, or `-num-extension` to override the type.
|
||||
You can specify values for this option multiple times.
|
||||
This option supports sourcing values from files using `file://` and environment variables using `env://`.
|
||||
- `-extensions` `(string: "")` - A JSON map value to use as the entirety of
|
||||
the request's extensions map.
|
||||
Usually this value is sourced from a file using the `file://` syntax.
|
||||
This option is exclusive with the other extension flags.
|
||||
- `-key-bits` `(string: "")` - The number of bits to use when the SSH private key is generated.
|
||||
The value depends on the `key_type`.
|
||||
If you use a `ed25519` key, you should not set a value or set the value to `0`.
|
||||
If you use a `ecdsa` key, you should set the value to `256`, `384`, or `521`.
|
||||
If you use an `rsa` key, you should set the value to `2048`, `3072`, or `4096`.
|
||||
- `-key-id` `(string: "")` - Specifies the created certificate's key id.
|
||||
- `-key-type` `(string: "")` - Specifies the key type for the generated ssh private key.
|
||||
Supported values include `ed25519`, `ecdsa`, and `rsa`.
|
||||
- `-ttl` `(string: "")` - The generated certificate's time-to-live.
|
||||
- `-username` `(string: "")` - The username to use with the SSH certificate.
|
||||
- `-vault-path` `(string: "")` - The path in Vault to request credentials from.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-libraries delete - Command
|
||||
description: >-
|
||||
The "credential-libraries delete" command deletes an existing credential library resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-libraries delete
|
||||
|
||||
Command: `boundary credential-libraries delete`
|
||||
|
||||
The `credential-libraries delete` command lets you delete an existing credential library resource.
|
||||
|
||||
## Example
|
||||
|
||||
The following example deletes a credential library with the ID `csvlt_5fvkRjCjou`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries delete -id csvlt_5fvkRjCjou
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the credential library to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-libraries - Command
|
||||
description: >-
|
||||
The "credential-libraries" command performs operations on credential library resources. Credential libraries provide credentials of the same type and access level.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-libraries
|
||||
|
||||
Command: `boundary credential-libraries`
|
||||
|
||||
The `credential-libraries` command lets you perform operations on Boundary credential library resources.
|
||||
A credential library provides credentials for sessions.
|
||||
All credentials returned by a library must be equivalent from an access control perspective.
|
||||
|
||||
A credential library is responsible for managing the lifecycle of the credentials it returns.
|
||||
For dynamic secrets, this includes creation, renewal, and revocation.
|
||||
For rotating credentials, this includes check-out, check-in, and rotation of secrets.
|
||||
The system retrieves credentials from a library for a session and notifies the library when the session has been terminated.
|
||||
A credential library belongs to a single credential store.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves information for a credential library with the ID, `clvlt_QYnQPAjA24`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries read -id clvlt_QYnQPAjA24
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Library information:
|
||||
Created Time: Fri, 18 Aug 2023 16:22:29 PDT
|
||||
Credential Store ID: csvlt_5fvkRjCjou
|
||||
ID: clvlt_QYnQPAjA24
|
||||
Name: northwind dba
|
||||
Type: vault-generic
|
||||
Updated Time: Fri, 18 Aug 2023 16:22:29 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_tnqESc86qE
|
||||
Name: db-project
|
||||
Parent Scope ID: o_4VUR6ZATqW
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
HTTP Method: GET
|
||||
Path: database/creds/dba
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary credential-libraries [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
create Create a credential library
|
||||
delete Delete a credential library
|
||||
list List a credential library
|
||||
read Read a credential library
|
||||
update Update a credential library
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [create](/boundary/docs/commands/credential-libraries/create)
|
||||
- [delete](/boundary/docs/commands/credential-libraries/delete)
|
||||
- [list](/boundary/docs/commands/credential-libraries/list)
|
||||
- [read](/boundary/docs/commands/credential-libraries/read)
|
||||
- [update](/boundary/docs/commands/credential-libraries/update)
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-libraries list - Command
|
||||
description: >-
|
||||
The "credential-libraries list" command lists the available credential library resources within an enclosing scope or resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-libraries list
|
||||
|
||||
Command: `boundary credential-libraries list`
|
||||
|
||||
The `credential-libraries list` command lists credential libraries within an enclosing scope or resource.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example lists all credential libraries for a credential store with the ID `clvlt_QYnQPAjA24`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries list \
|
||||
-credential-store-id
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Library information:
|
||||
ID: clvlt_QYnQPAjA24
|
||||
Version: 1
|
||||
Type: vault-generic
|
||||
Name: northwind dba
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-credential-store-id` `(string: "")` - The credential store resource to list credential libraries for.
|
||||
You can also specify the credential store using the **BOUNDARY_CREDENTIAL_STORE_ID** environment variable.
|
||||
- `-filter` `(string: "")` - If set, Boundary filters the list operation before the results are returned.
|
||||
The filter operates against each item in the list.
|
||||
We recommend that you use single quotes, because the filters contain double quotes.
|
||||
Refer to the [Filtering and listing resources documentation](/boundary/docs/filtering) for more details.
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not provide a value, or if you provide a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,76 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-libraries read - Command
|
||||
description: >-
|
||||
The "credential-libraries read" command retrieves the details of a credential library.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-libraries read
|
||||
|
||||
Command: `boundary credential-libraries read`
|
||||
|
||||
The `credential-libraries read` command reads the credential library information for a specific credential library ID.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves credential library information for a credential library with the ID `clvlt_QYnQPAjA24`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries read -id clvlt_QYnQPAjA24
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Library information:
|
||||
Created Time: Fri, 18 Aug 2023 16:22:29 PDT
|
||||
Credential Store ID: csvlt_5fvkRjCjou
|
||||
ID: clvlt_QYnQPAjA24
|
||||
Name: northwind dba
|
||||
Type: vault-generic
|
||||
Updated Time: Fri, 18 Aug 2023 16:22:29 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_tnqESc86qE
|
||||
Name: db-project
|
||||
Parent Scope ID: o_4VUR6ZATqW
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
HTTP Method: GET
|
||||
Path: database/creds/dba
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the credential library from which to read information.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,200 +0,0 @@
|
||||
---
|
||||
layout: doc
|
||||
page_title: credential-libraries update - Command
|
||||
description: >-
|
||||
The "credential-libraries update" command updates an existing credential library resource with new information.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-libraries update
|
||||
|
||||
Command: `boundary credential-libraries update`
|
||||
|
||||
The `credential-libraries update` command lets you update Boundary credential library resources.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example updates an existing Vault credential library with the ID `csvlt_5fvkRjCjou` to point to a new Vault secrets engine path:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries update vault-generic \
|
||||
-id csvlt_5fvkRjCjou \
|
||||
-vault-path "database/creds/db-mysql"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Library information:
|
||||
Created Time: Fri, 18 Aug 2023 16:22:29 PDT
|
||||
Credential Store ID: csvlt_5fvkRjCjou
|
||||
ID: clvlt_QYnQPAjA24
|
||||
Name: northwind dba
|
||||
Type: vault-generic
|
||||
Updated Time: Fri, 18 Aug 2023 20:04:27 PDT
|
||||
Version: 2
|
||||
|
||||
Scope:
|
||||
ID: p_tnqESc86qE
|
||||
Name: db-project
|
||||
Parent Scope ID: o_4VUR6ZATqW
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
HTTP Method: GET
|
||||
Path: database/creds/db-mysql
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries update vault [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-description` `(string: "")` - A description to set on the credential library.
|
||||
- `-id` `(string: "")` - The ID of the credential library to update.
|
||||
- `-name` `(string: "")` - A name to set on the credential library.
|
||||
- `-version` `(int: 0)` - The version of the credential library against which to perform the update operation.
|
||||
If you don't specify a version, the command performs a check-and-set automatically.
|
||||
|
||||
#### Usages by type
|
||||
|
||||
The available types are `vault-generic` and `vault-ssh-certificate`.
|
||||
|
||||
<Note>
|
||||
|
||||
A credential library type, `vault` is deprecated, so use `vault-generic` type
|
||||
instead.
|
||||
|
||||
</Note>
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Vault">
|
||||
|
||||
The `credential-libraries update vault-generic` command lets you update a generic Vault credential library.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a generic Vault credential library with the ID `clvlt_1234567890` to add the name `devops` and the description `For DevOps usage`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries update vault-generic \
|
||||
-id clvlt_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries create vault-generic [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Vault credential library options
|
||||
|
||||
The following are specific Vault credential library options in addition to the command options:
|
||||
|
||||
- `-credential-mapping-override` - An override for credential mapping.
|
||||
- `-vault-http-method` `(string: "")` - The HTTP method the library should use when it communicates with Vault.
|
||||
- `-vault-http-request-body` `(strinboundary credential-libraries update vault-ssh-certificate -id clvsclt_1234567890 -name devops -description "For DevOps usage": "")` - The HTTP request body the credential library uses to communicate with Vault.
|
||||
This value can be the HTTP request body itself, it can refer to a file on disk (`file://`) from which the value is read, or it can refer to an environment variable (`env://`) from which the value is read.
|
||||
- `-vault-path` `(string: "")` - The path in Vault to request credentials from.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="Vault SSH certificate">
|
||||
|
||||
The `credential-libraries update vault-ssh-certificate` command lets you update a Vault SSH certificate credential library.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a Vault SSH certificate credential library with the ID `clvsclt_1234567890` to add the name `devops` and the description `For DevOps usage`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries update vault-ssh-certificate \
|
||||
-id clvsclt_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-libraries update vault-ssh-certificate [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Vault SSH certificate credential library options
|
||||
|
||||
The following are options specific to the Vault SSH certificate credential library, in addition to the command options:
|
||||
|
||||
- `-additional-valid-principal` - Any additional users or groups that you want to configure as valid principals.
|
||||
By default, Boundary only passes the username to Vault as a valid principal.
|
||||
Use this option when you want to configure additional users or groups as valid principals that the certificate should be signed for in Vault.
|
||||
|
||||
For more information, refer to OpenSSH's definition of [valid principals](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L176-L181) and Vault's [SSH secrets engine](https://developer.hashicorp.com/vault/api-docs/secret/ssh#valid_principals) documentation.
|
||||
- `-critical-option` - A key=value pair to add to the request's
|
||||
critical-options map.
|
||||
It can also be a key value only which sets a JSON null as the value.
|
||||
If you provide a value, Boundary infers the type automatically.
|
||||
You can use `-string-critical-option`, `-bool-critical-option`, or `-num-critical-option` to override the type.
|
||||
You can specify values for this option multiple times.
|
||||
This option supports sourcing values from files using `file://` and environment variables using `env://`.
|
||||
- `-critical-options` `(string: "")` A JSON map value to use as the entirety of the request's critical-options map.
|
||||
Usually this value is sourced from a file using the `file://` syntax.
|
||||
This value is exclusive with the other critical-option flags.
|
||||
- `-extension` - A key=value pair to add to the request's extensions map.
|
||||
It can also be a key value only which will set a JSON null as the value.
|
||||
If you provide a value, Boundary automatically infers the type.
|
||||
You can use `-string-extension`, `-bool-extension`, or `-num-extension` to override the type.
|
||||
You can specify values for this option multiple times.
|
||||
This option supports sourcing values from files using `file://` and environment variables using `env://`.
|
||||
- `-extensions` `(string: "")` - A JSON map value to use as the entirety of
|
||||
the request's extensions map.
|
||||
Usually this value is sourced from a file using the `file://` syntax.
|
||||
This option is exclusive with the other extension flags.
|
||||
- `-key-bits` `(string: "")` - The number of bits to use when the SSH private key is generated.
|
||||
The value depends on the `key_type`.
|
||||
If you use a `ed25519` key, you should not set a value or set the value to `0`.
|
||||
If you use a `ecdsa` key, you should set the value to `256`, `384`, or `521`.
|
||||
If you use an `rsa` key, you should set the value to `2048`, `3072`, or `4096`.
|
||||
- `-key-id` `(string: "")` - Specifies the certificate's key id.
|
||||
- `-key-type` `(string: "")` - Specifies the key type for the ssh private key.
|
||||
Supported values include `ed25519`, `ecdsa`, and `rsa`.
|
||||
- `-ttl` `(string: "")` - The generated certificate's time-to-live.
|
||||
- `-username` `(string: "")` - The username to use with the SSH certificate.
|
||||
- `-vault-path` `(string: "")` - The path in Vault to request credentials from.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,161 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-stores create - Command
|
||||
description: >-
|
||||
The "credential-stores create" command creates new credential store resources. You can create static or Vault credential stores to manage credentials.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-stores create
|
||||
|
||||
Command: `boundary credential-stores create`
|
||||
|
||||
The `credential-stores create` command lets you create a Boundary credential store resource.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example creates a credential store resource in a project scope with the ID `p_tnqESc86qE`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores create vault -scope-id p_tnqESc86qE \
|
||||
-vault-address $VAULT_ADDR \
|
||||
-vault-token $VAULT_TOKEN \
|
||||
-vault-namespace $VAULT_NAMESPACE
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Store information:
|
||||
Created Time: Thu, 28 Jul 2022 15:08:12 MDT
|
||||
ID: csvlt_ytzGHsfp3r
|
||||
Type: vault
|
||||
Updated Time: Thu, 28 Jul 2022 15:08:12 MDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_jd7lspegXk
|
||||
Name: ssh-project
|
||||
Parent Scope ID: o_SN2K0DAGpi
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Authorized Actions on Credential Store's Collections:
|
||||
credential-libraries:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
Address: https://vault-cluster-boundary.vault.11eb3a47-8920-4714-ba99-0242ac11000e.aws.hashicorp.cloud:8200
|
||||
Token HMAC: NZJWT74Jyq09gLQfP4RiK5eDWfY7NWXYHoKL4nKQFDY
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores create [type] [sub command] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-description` `(string: "")` - The description to set on the credential store.
|
||||
- `-name` `(string: "")` - The name to set on the credential store.
|
||||
- `-scope-id` `(string: "")` - The scope in which to make the request.
|
||||
The default scope is `global`.
|
||||
You can also indicate the scope using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
|
||||
### Usages by type
|
||||
|
||||
The available types are `static` and `vault`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Static">
|
||||
|
||||
The `credential-stores create static` command lets you create a static-type credential store.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a static credential score in a scope with the ID `p_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores create static -scope-id p_1234567890
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores create static [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Vault">
|
||||
|
||||
The `credential-stores create vault` command lets you create a Vault credential store.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a Vault credential store:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores create vault \
|
||||
-vault-address "http://127.0.0.1:8200" \
|
||||
-vault-token "<new-token-value>"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores create vault [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Vault credential stores options
|
||||
|
||||
The following options are specific to Vault credential stores in addition to the command options:
|
||||
|
||||
- `-vault-address` `(string: "")` - The address of the Vault server.
|
||||
The address should be a complete URL such as https://127.0.0.1:8200.
|
||||
- `-vault-ca-cert` `(string: "")` - The CA certificate to use when you connect to Vault.
|
||||
This value can be the CA certificate itself, or it can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-vault-client-certificate` `(string: "")` - The client certificate to use when Boundary connects to Vault for this credential store.
|
||||
This value can be the client certificate itself, or it can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-vault-client-certificate-key` `(string: "")` - The private key the client certificate should use when Boundary connects to Vault for this store.
|
||||
This value can be the private key itself, or it can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-vault-namespace` `(string: "")` - The Vault namespace the credential store should use.
|
||||
- `-vault-tls-server-name` `(string: "")` - The name to use as the SNI host when you connect using TLS.
|
||||
- `-vault-tls-skip-verify` - If set, skips TLS verification.
|
||||
The default value is `false`.
|
||||
- `-vault-token` `(string: "")` - The Vault token to use when Boundary connects to Vault for this credential store.
|
||||
- `-worker-filter` `(string: "")` - A Boolean expression to filter which workers can process Vault commands for this credential store.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-stores delete - Command
|
||||
description: >-
|
||||
The "credential-stores delete" command deletes an existing credential store resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-stores delete
|
||||
|
||||
Command: `boundary credential-stores delete`
|
||||
|
||||
The `credential-stores delete` command deletes a credential store given its ID.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example deletes a credential store with the ID `csvlt_5fvkRjCjou`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores delete -id csvlt_5fvkRjCjou
|
||||
The delete operation completed successfully.
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the credential store to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-stores - Command
|
||||
description: >-
|
||||
The "credential-stores" command performs operations on credential store resources. Credential stores can manage credentials of differing types and access levels.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-stores
|
||||
|
||||
Command: `boundary credential-stores`
|
||||
|
||||
The `credential-stores` command lets you manage Boundary credential store resources.
|
||||
|
||||
A credential store is a resource that can retrieve, store, and potentially generate credentials of differing types and differing access levels.
|
||||
They belong to projects and support the principle of least privilege by limiting the credentials that can be accessed to the minimum necessary for the project.
|
||||
A credential store can also contain credential libraries.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example lists all credential stores for a scope with the ID `p_tnqESc86qE`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores list -scope-id p_tnqESc86qE
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Store information:
|
||||
ID: csvlt_5fvkRjCjou
|
||||
Version: 1
|
||||
Type: vault
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary credential-stores [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
create Create a credential store
|
||||
delete Delete a credential store
|
||||
list List a credential store
|
||||
read Read a credential store
|
||||
update Update a credential store
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [create](/boundary/docs/commands/credential-stores/create)
|
||||
- [delete](/boundary/docs/commands/credential-stores/delete)
|
||||
- [list](/boundary/docs/commands/credential-stores/list)
|
||||
- [read](/boundary/docs/commands/credential-stores/read)
|
||||
- [update](/boundary/docs/commands/credential-stores/update)
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-stores list - Command
|
||||
description: >-
|
||||
The "credential-stores list" command lists the available credential store resources within an enclosing scope or resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-stores list
|
||||
|
||||
Command: `boundary credential-stores list`
|
||||
|
||||
The `credential-stores list` command lists any credential stores within an enclosing scope or resource.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example lists all credential stores for a scope with the ID `p_tnqESc86qE`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores list -scope-id p_tnqESc86qE
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Store information:
|
||||
ID: csvlt_5fvkRjCjou
|
||||
Version: 1
|
||||
Type: vault
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-filter` `(string: "")` - If set, Boundary filters the list operation before the results are returned.
|
||||
The filter operates against each item in the list.
|
||||
We recommend that you use single quotes, because the filters contain double quotes.
|
||||
Refer to the [Filtering and listing resources documentation](/boundary/docs/filtering) for more details.
|
||||
- `-recursive` - If set, the list operation is applied recursively into child scopes, if supported by the type.
|
||||
The default value is `false`.
|
||||
- `-scope-id ``(string: "")` - The scope in which to make the request.
|
||||
The default value is `global`.
|
||||
You can also specify the scope using the **BOUNDARY_SCOPE_ID** environment variable.
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not provide a value, or if you provide a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credential-stores read - Command
|
||||
description: >-
|
||||
The "credential-stores read" command retrieves the details of a credential store resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-stores read
|
||||
|
||||
Command: `boundary credential-stores read`
|
||||
|
||||
The `credential-stores read` command reads credential store information for a credential store with a specific ID.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves credential store information for a credential store with the ID `csvlt_5fvkRjCjou`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores read -id csvlt_5fvkRjCjou
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Store information:
|
||||
Created Time: Fri, 18 Aug 2023 16:22:02 PDT
|
||||
ID: csvlt_5fvkRjCjou
|
||||
Type: vault
|
||||
Updated Time: Fri, 18 Aug 2023 16:22:02 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_tnqESc86qE
|
||||
Name: db-project
|
||||
Parent Scope ID: o_4VUR6ZATqW
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Authorized Actions on Credential Store's Collections:
|
||||
credential-libraries:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
Address: http://127.0.0.1:8200
|
||||
Token Status: expired
|
||||
Worker Filter: "worker" in "/tags/type"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the credential store for which to read information.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,164 +0,0 @@
|
||||
---
|
||||
layout: doc
|
||||
page_title: credential-stores update - Command
|
||||
description: >-
|
||||
The "credential-stores update" command updates an existing credential store resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credential-stores update
|
||||
|
||||
Command: `boundary credential-stores update`
|
||||
|
||||
The `credential-stores update` command lets you update Boundary credential store resources.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example updates an existing Vault credential store with the ID `csvlt_5fvkRjCjou` to add the description `For DevOps usage`, and the Vault namespace `devops`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores update vault -id csvlt_5fvkRjCjou \
|
||||
-description "For DevOps usage" \
|
||||
-vault-namespace "devops"
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential Store information:
|
||||
Created Time: Fri, 18 Aug 2023 16:22:02 PDT
|
||||
Description: For DevOps usage
|
||||
ID: csvlt_5fvkRjCjou
|
||||
Type: vault
|
||||
Updated Time: Sun, 20 Aug 2023 22:21:25 PDT
|
||||
Version: 2
|
||||
|
||||
Scope:
|
||||
ID: p_tnqESc86qE
|
||||
Name: db-project
|
||||
Parent Scope ID: o_4VUR6ZATqW
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Authorized Actions on Credential Store's Collections:
|
||||
credential-libraries:
|
||||
create
|
||||
list
|
||||
|
||||
Attributes:
|
||||
Address: http://127.0.0.1:8200
|
||||
Namespace: devops
|
||||
Token Status: current
|
||||
Worker Filter: "worker" in "/tags/type"
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores update vault [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-description` `(string: "")` - The description to set on the credential store.
|
||||
- `-id` `(string: "")` - The ID of the credential store to update.
|
||||
- `-name` `(string: "")` - The name to set on the credential store.
|
||||
- `-version` `(int: 0)` - The version of the credential store against which to perform an update operation.
|
||||
If you do not specify a version, the command performs a check-and-set automatically.
|
||||
|
||||
#### Usages by type
|
||||
|
||||
The available types are `static` and `vault`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Static">
|
||||
|
||||
The `credential-stores update static` command lets you update information for a static credential store.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a static credential store with the name `devops` and the description `For DevOps usage`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores update static \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores update static [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Vault">
|
||||
|
||||
The `credential-stores update vault` command lets you update a Vault credential store.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a Vault credential store with the ID `csvlt_1234567890` to add the name `devops` and the description `For DevOps usage`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores update vault \
|
||||
-id csvlt_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credential-stores update vault [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Vault credential store options
|
||||
|
||||
The following options are specific to Vault credential stores in addition to the command options:
|
||||
|
||||
- `-vault-address` `(string: "")` - The address of the Vault server.
|
||||
The address should be a complete URL such as https://127.0.0.1:8200.
|
||||
- `-vault-ca-cert` `(string: "")` - The CA certificate to use when you connect to Vault.
|
||||
This value can be the CA certificate itself, or it can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-vault-client-certificate` `(string: "")` - The client certificate to use when Boundary connects to Vault for this credential store.
|
||||
This value can be the client certificate itself, or it can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-vault-client-certificate-key` `(string: "")` - The private key the client certificate should use when Boundary connects to Vault for this store.
|
||||
This value can be the private key itself, or it can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-vault-namespace` `(string: "")` - The Vault namespace the credential store should use.
|
||||
- `-vault-tls-server-name` `(string: "")` - The name to use as the SNI host when you connect using TLS.
|
||||
- `-vault-tls-skip-verify` - If set, skips TLS verification.
|
||||
The default value is `false`.
|
||||
- `-vault-token` `(string: "")` - The Vault token to use when Boundary connects to Vault for this credential store.
|
||||
- `-worker-filter` `(string: "")` - A Boolean expression to filter which workers can process Vault commands for this credential store.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,252 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credentials create - Command
|
||||
description: >-
|
||||
The "credentials create" command creates new credential resources. Available types are json, ssh-private-key, username-password, and username-password-domain.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credentials create
|
||||
|
||||
Command: `boundary credentials create`
|
||||
|
||||
The `credentials create` command lets you create Boundary credential resources.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example defines a new username password credential within a static credential store with the ID `credup_J15mtU4qmy`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create username-password \
|
||||
-name ssh-user \
|
||||
-credential-store-id credup_J15mtU4qmy\
|
||||
-username ssh-user \
|
||||
-password env://SSH_USER_PASS
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential information:
|
||||
Created Time: Tue, 22 Aug 2023 15:56:07 PDT
|
||||
Credential Store ID: csst_5GGWwRngd7
|
||||
ID: credup_J15mtU4qmy
|
||||
Name: ssh-user
|
||||
Type: username_password
|
||||
Updated Time: Tue, 22 Aug 2023 15:56:07 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_1zMlAwGHtH
|
||||
Name: quick-start-project
|
||||
Parent Scope ID: o_R0wbo0H6Zl
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
Password HMAC: bXhHJHgaGz6fpolEpQPd0azcICSgmbVuSLfyhJhmqJY
|
||||
Username: ssh-user
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create [type] [sub command] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-credential-store-id` `(string: "")` - The credential-store resource in which to create the credential.
|
||||
You can also specify the credential store using the **BOUNDARY_CREDENTIAL_STORE_ID** environment variable.
|
||||
- `-description` `(string: "")` - A description to set on the credential.
|
||||
- `-name` `(string: "")` - A name to set on the credential.
|
||||
|
||||
#### Usages by type
|
||||
|
||||
The available types are `json`, `ssh-private-key`, `username-password`, and `username-password-domain`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
The `credentials create json` command lets you create a JSON type credential.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a JSON credential in a credential store with the ID `csst_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create json \
|
||||
-credential-store-id csst_1234567890 \
|
||||
-object file:///home/user/secret
|
||||
```
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create json [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### JSON object credential options
|
||||
|
||||
The following options are specific to JSON credentials in addition to the command options:
|
||||
|
||||
- `-bool-kv` `(map: {})` – A key=value Boolean value to add to the request's object map.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-kv` `(map: {})` – A key=value pair to add to the request's object map.
|
||||
This option can also be a key value only which will set a JSON null as the value.
|
||||
If you provide a value, Boundary automatically infers the type.
|
||||
Use `-string-kv`,`-bool-kv`, or `-num-kv` to override the type.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-num-kv` `(map: {})` – A key=value numeric value to add to the request's object map.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-object` `(string: "")` - A JSON map value to use as the entirety of the request's object map.
|
||||
Usually this is sourced from a file using `file://` syntax.
|
||||
This option is exclusive with the other kv flags.
|
||||
- `-string-kv` `(map: {})` – A key=value string value to add to the request's object map.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="SSH private key">
|
||||
|
||||
The `credentials create ssh-private-key` command lets you create an SSH private key credential type.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates an SSH private key credential in a credential store with the ID `csvlt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create ssh-private-key \
|
||||
-credential-store-id csvlt_1234567890 \
|
||||
-username user \
|
||||
-private-key file:///home/user/.ssh/id_ed25519
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create ssh-private-key [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### SSH private key credential options
|
||||
|
||||
The following options are specific to SSH private key credentials in addition to the command options:
|
||||
|
||||
- `-private-key` `(string: "")` - The SSH private key associated with the
|
||||
credential.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-private-key-passphrase` `(string: "")` - The passphrase associated with the
|
||||
SSH private key.
|
||||
Boundary ingores this value if the private key does not require a passphrase or if you do not supply a private key.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
If you leave this option empty, and the key requires a passphrase, you can enter it manually.
|
||||
- `-username` `(string: "")` - The username associated with the credential.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Username password">
|
||||
|
||||
The `credentials create username-password` command lets you create a username password type credential.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a username password credential in a credential store with the ID `csvlt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create username-password \
|
||||
-credential-store-id csvlt_1234567890 \
|
||||
-username user -password pass
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials create username-password -credential-store-id [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
#### Username password credential options
|
||||
|
||||
The following options are specific to username password credentials in addition to the command options:
|
||||
|
||||
- `-password` `(string: "")` - The password associated with the credential.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-username` `(string: "")` - The username associated with the credential.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Username password domain">
|
||||
|
||||
The `credentials create username-password-domain` command lets you create a username password domain credential type for Active Directory authentication.
|
||||
|
||||
Username password domain credentials are primarily used with RDP targets for credential injection.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example creates a username password domain credential in a credential store with the ID `csst_1234567890`:
|
||||
|
||||
```shell-session
|
||||
boundary credentials create username-password-domain \
|
||||
-credential-store-id csst_1234567890 \
|
||||
-username administrator \
|
||||
-password env://ADMIN_PASSWORD \
|
||||
-domain company.com
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
boundary credentials create username-password-domain [options] [args]
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
#### Username password domain credential options
|
||||
|
||||
The following options are specific to username password domain credentials in addition to the command options:
|
||||
|
||||
- `domain` `(string: "")` - The Active Directory domain name. If you include the domain in the `username` field, Boundary automatically fills in the domain information.
|
||||
|
||||
For example, if you enter `admin@mydomain` or `mydomain\admin` in the `username` field, Boundary automatically completes the `domain` field with `mydomain`.
|
||||
|
||||
- `password` `(string: "")` - The password associated with the credential. This value can be a reference to a file on disk (file://) or an environment variable (env://) from which Boundary reads the value.
|
||||
|
||||
- `username` `(string: "")` - The username associated with the credential. This value can include domain information in `username@domain` or `domain\username` format.
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credentials delete - Command
|
||||
description: >-
|
||||
The "credentials delete" command deletes an existing credential resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credentials delete
|
||||
|
||||
Command: `boundary credentials delete`
|
||||
|
||||
The `credentials delete` command lets you delete a credential given its ID.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example deletes a credential with the ID `credup_6zHHwQWvUS`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials delete -id credup_6zHHwQWvUS
|
||||
The delete operation completed successfully.
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials delete [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the credential to delete.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credentials - Command
|
||||
description: >-
|
||||
The "credentials" command performs operations on Boundary credential resources. Credentials contain secrets that bind an identity to a set of permissions.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credentials
|
||||
|
||||
Command: `boundary credentials`
|
||||
|
||||
The `credentials` command lets you create and manage Boundary credential resources in Boundary's static credential store.
|
||||
|
||||
<Note>
|
||||
|
||||
The `credentials` command does not support viewing, creating, or managing credentials that reside in the Vault credential store.
|
||||
|
||||
</Note>
|
||||
|
||||
A credential is a data structure containing one or more secrets that bind an identity to a set of permissions or capabilities on a host for a session.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves information about a credential with the ID `credup_J15mtU4qmy`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials read -id credup_J15mtU4qmy
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential information:
|
||||
Created Time: Tue, 22 Aug 2023 15:56:07 PDT
|
||||
Credential Store ID: csst_5GGWwRngd7
|
||||
ID: credup_J15mtU4qmy
|
||||
Name: ssh-user
|
||||
Type: username_password
|
||||
Updated Time: Tue, 22 Aug 2023 15:56:07 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_1zMlAwGHtH
|
||||
Name: quick-start-project
|
||||
Parent Scope ID: o_R0wbo0H6Zl
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
Password HMAC: bXhHJHgaGz6fpolEpQPd0azcICSgmbVuSLfyhJhmqJY
|
||||
Username: ssh-user
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary credentials [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
create Create a credential
|
||||
delete Delete a credential
|
||||
list List a credential
|
||||
read Read a credential
|
||||
update Update a credential
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [create](/boundary/docs/commands/credentials/create)
|
||||
- [delete](/boundary/docs/commands/credentials/delete)
|
||||
- [list](/boundary/docs/commands/credentials/list)
|
||||
- [read](/boundary/docs/commands/credentials/read)
|
||||
- [update](/boundary/docs/commands/credentials/update)
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credentials list - Command
|
||||
description: >-
|
||||
The "credentials list" command lists the available credential resources within an enclosing scope or resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credentials list
|
||||
|
||||
Command: `boundary credentials list`
|
||||
|
||||
The `credentials list` command lists credentials within an enclosing scope or resource.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example lists all credentials for a credential store with the ID `csst_5GGWwRngd7`:
|
||||
|
||||
```shell-session
|
||||
$ credentials list -credential-store-id csst_5GGWwRngd7
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential information:
|
||||
ID: credup_29IUJANN59
|
||||
Version: 1
|
||||
Type: username_password
|
||||
Name: tester
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
ID: credup_6zHHwQWvUS
|
||||
Version: 1
|
||||
Type: username_password
|
||||
Name: support-eng
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
ID: credup_J15mtU4qmy
|
||||
Version: 1
|
||||
Type: username_password
|
||||
Name: ssh-user
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials list [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-credential-store-id` `(string: "")` - The credential store resource that contains the credentials you want to list.
|
||||
You can also specify the credential store using the **BOUNDARY_CREDENTIAL_STORE_ID** environment variable.
|
||||
- `-filter` `(string: "")` - If set, Boundary filters the list operation before the results are returned.
|
||||
The filter operates against each item in the list.
|
||||
We recommend that you use single quotes, because the filters contain double quotes.
|
||||
Refer to the [Filtering and listing resources documentation](/boundary/docs/filtering) for more details.
|
||||
- `list_token` (optional) - An opaque token that is returned from the previous `list` response.
|
||||
If you do not supply a value, pagination starts from the beginning.
|
||||
- `page_size` (optional) - An unsigned integer that indicates the number of items that should be included on the page of search results.
|
||||
If you do not provide a value, or if you provide a value of `0`, Boundary uses the default page size of 1000 items.
|
||||
If you configure it, the `page_size` value overrides the default page size.
|
||||
Controller administrators can also configure a `max_page_size` option that constrains the maximum page size a user can request.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: credentials read - Command
|
||||
description: >-
|
||||
The "credentials read" command retrieves the details of an existing credential resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credentials read
|
||||
|
||||
Command: `boundary credentials read`
|
||||
|
||||
The `credentials read` command retrieves information about a credential with a specified ID.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example retrieves credential information for a credential with the ID `credup_29IUJANN59`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials read -id credup_29IUJANN59
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential information:
|
||||
Created Time: Tue, 22 Aug 2023 18:26:06 PDT
|
||||
Credential Store ID: csst_5GGWwRngd7
|
||||
ID: credup_29IUJANN59
|
||||
Name: tester
|
||||
Type: username_password
|
||||
Updated Time: Tue, 22 Aug 2023 18:26:06 PDT
|
||||
Version: 1
|
||||
|
||||
Scope:
|
||||
ID: p_1zMlAwGHtH
|
||||
Name: quick-start-project
|
||||
Parent Scope ID: o_R0wbo0H6Zl
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
Password HMAC: bXhHJHgaGz6fpolEpQPd0azcICSgmbVuSLfyhJhmqJY
|
||||
Username: tester
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials read [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
### Command options
|
||||
|
||||
- `-id` `(string: "")` - The ID of the credential for which you want to retrieve information.
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,252 +0,0 @@
|
||||
---
|
||||
layout: doc
|
||||
page_title: credentials update - Command
|
||||
description: >-
|
||||
The "credentials update" command updates an existing credential resource.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# credentials update
|
||||
|
||||
Command: `boundary credentials update`
|
||||
|
||||
The `credentials update` command lets you update Boundary credential resources.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example updates an existing user password credential with a new password:
|
||||
|
||||
```shell-session
|
||||
$ export NEW_SSH_USER_PASSWORD="my-new-long-password"
|
||||
|
||||
$ boundary credentials update username-password -id credup_J15mtU4qmy \
|
||||
-password env://NEW_SSH_USER_PASSWORD
|
||||
```
|
||||
|
||||
**Example output:**
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```plaintext
|
||||
Credential information:
|
||||
Created Time: Tue, 22 Aug 2023 15:56:07 PDT
|
||||
Credential Store ID: csst_5GGWwRngd7
|
||||
Description: Ops admin who needs to access the machine
|
||||
ID: credup_J15mtU4qmy
|
||||
Name: ssh-user
|
||||
Type: username_password
|
||||
Updated Time: Tue, 22 Aug 2023 21:26:34 PDT
|
||||
Version: 2
|
||||
|
||||
Scope:
|
||||
ID: p_1zMlAwGHtH
|
||||
Name: quick-start-project
|
||||
Parent Scope ID: o_R0wbo0H6Zl
|
||||
Type: project
|
||||
|
||||
Authorized Actions:
|
||||
no-op
|
||||
read
|
||||
update
|
||||
delete
|
||||
|
||||
Attributes:
|
||||
Password HMAC: JxqSB5DJ_dBlTCJAfkX6k-o-6CwjgEDmmnbrTxvQ7_g
|
||||
Username: ssh-user
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update [type] [sub command] [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
### Command options
|
||||
|
||||
- `-description` `(string: "")` - A description to set on the credential.
|
||||
- `-id` `(string: "")` - The ID of the credential to update.
|
||||
- `-name` `(string: "")` - A name to set on the credential.
|
||||
- `-version` `(int: 0)` - The version of the credential to update.
|
||||
If you don't specify a version, the command performs a check-and-set automatically.
|
||||
|
||||
#### Usages by type
|
||||
|
||||
The available types are `json`, `ssh-private-key`, `username-password`, and `username-password-domain`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
The `credentials update json` command lets you update a JSON credential.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a JSON credential with the ID `csst_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update json \
|
||||
-id csst_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update json [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### JSON object credential options
|
||||
|
||||
The following options are specific to JSON credentials in addition to the command options:
|
||||
|
||||
- `-bool-kv` `(map: {})` – A key=value Boolean value to add to the request's object map.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-kv` `(map: {})` – A key=value pair to add to the request's object map.
|
||||
This option can also be a key value only which will set a JSON null as the value.
|
||||
If you provide a value, Boundary automatically infers the type.
|
||||
Use `-string-kv`,`-bool-kv`, or `-num-kv` to override the type.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-num-kv` `(map: {})` – A key=value numeric value to add to the request's object map.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-object` `(string: "")` - A JSON map value to use as the entirety of the request's object map.
|
||||
Usually this is sourced from a file using `file://` syntax.
|
||||
This option is exclusive with the other kv flags.
|
||||
- `-string-kv` `(map: {})` – A key=value string value to add to the request's object map.
|
||||
You can specify this option multiple times.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="SSH private key">
|
||||
|
||||
The `credentials update ssh-private-key` lets you update an SSH private key credential.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates an SSH private key with the ID `clvlt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update ssh-private-key \
|
||||
-id clvlt_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update ssh-private-key [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### SSH private key credential options
|
||||
|
||||
The following options are specific to SSH private key credentials in addition to the command options:
|
||||
|
||||
- `-private-key` `(string: "")` - The SSH private key associated with the
|
||||
credential.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-private-key-passphrase` `(string: "")` - The passphrase associated with the
|
||||
SSH private key.
|
||||
Boundary ingores this value if the private key does not require a passphrase or if you do not supply a private key.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
If you leave this option empty, and the key requires a passphrase, you can enter it manually.
|
||||
- `-username` `(string: "")` - The username associated with the credential.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Username password">
|
||||
|
||||
The `credentials update username-password` command lets you update a username password type.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a username password credential with the ID `clvlt_1234567890`:
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update username-password \
|
||||
-id clvlt_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage"
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
$ boundary credentials update username-password [options] [args]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Username password credential options
|
||||
|
||||
The following options are specific to username password credentials in addition to the command options:
|
||||
|
||||
- `-password` `(string: "")` - The password associated with the credential.
|
||||
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
|
||||
- `-username` `(string: "")` - The username associated with the credential.
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Username password domain">
|
||||
|
||||
The `credentials update username-password-domain` command lets you update an existing username password domain credential type.
|
||||
|
||||
Username password domain credentials are primarily used with RDP targets for credential injection.
|
||||
|
||||
#### Example
|
||||
|
||||
The following example updates a username password domain credential with the ID `csst_1234567890`:
|
||||
|
||||
```shell-session
|
||||
boundary credentials update username-password-domain \
|
||||
-id csst_1234567890 \
|
||||
-name devops \
|
||||
-description "For DevOps usage" \
|
||||
```
|
||||
|
||||
#### Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
boundary credentials update username-password-domain [options] [args]
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
#### Username password domain credential options
|
||||
|
||||
The following options are specific to username password domain credentials in addition to the command options:
|
||||
|
||||
- `domain` `(string: "")` - The Active Directory domain name. If you include the domain in the `username` field, Boundary automatically fills in the domain information.
|
||||
|
||||
For example, if you enter `admin@mydomain` or `mydomain\admin` in the `username` field, Boundary automatically completes the `domain` field with `mydomain`.
|
||||
|
||||
- `password` `(string: "")` - The password associated with the credential. This value can be a reference to a file on disk (file://) or an environment variable (env://) from which Boundary reads the value.
|
||||
|
||||
- `username` `(string: "")` - The username associated with the credential. This value can include domain information in `username@domain` or `domain\username` format.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@include 'cmd-option-note.mdx'
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: database - Command
|
||||
description: >-
|
||||
The "database" command performs operations on Boundary's database. You can initialize or migrate the database.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# database
|
||||
|
||||
Command: `boundary database`
|
||||
|
||||
The `database` command lets you perform operations on Boundary's database.
|
||||
|
||||
Boundary manages its state and configuration in a relational database management system (RDBMS), namely PostgreSQL.
|
||||
You must create, set up, and make the PostgreSQL database accessible to the Boundary controller nodes before you configure the nodes themselves.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example initializes the Boundary database:
|
||||
|
||||
```shell-session
|
||||
$ boundary database init \
|
||||
-skip-auth-method-creation \
|
||||
-skip-host-resources-creation \
|
||||
-skip-scopes-creation \
|
||||
-skip-target-creation \
|
||||
-config /etc/boundary.d/controller.hcl
|
||||
```
|
||||
|
||||
Before you can start Boundary, you must initialize the database from one Boundary controller.
|
||||
This operation is only required once.
|
||||
It will execute the required database migrations for the Boundary cluster to operate.
|
||||
|
||||
## Usage
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```shell-session
|
||||
Usage: boundary database [sub command] [options] [args]
|
||||
|
||||
# ...
|
||||
|
||||
Subcommands:
|
||||
init Initialize Boundary's database
|
||||
migrate Migrate Boundary's database to the most recent schema supported by this binary.
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
For more information, examples, and usage, click on the name
|
||||
of the subcommand in the sidebar or one of the links below:
|
||||
|
||||
- [init](/boundary/docs/commands/database/init)
|
||||
- [migrate](/boundary/docs/commands/database/migrate)
|
||||
Loaded 100 of 553 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user