* docs: update deploy-and-login getting started guide with new authenticate usage
* docs: update api-clients/cli.mdx to remove login-name flag when using authenticate
* docs: update common-workflows/manage-users-groups.mdx to remove login-name flag when using authenticate
* docs: update common-workflows/workflow-ssh-proxycommand.mdx with new short form usage of authenticate command when using the primary auth method in the global scope
* docs: update oss/installing/no-gen-resources.mdx to remove login-name usage in authenticate command
* docs: update oss/installing/run-and-login.mdx with short form usage of boundary authenticate
* docs: fix tabs
* docs: fix numbering
* Apply batch of suggestions from code review
Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com>
* docs: fix code blocks
* fixes code blocks
---------
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com>
Co-authored-by: stellarsquall <stellarsquall@protonmail.ch>
When using the json output of the cli (`-format=json`), a successful
call to the controller API would place the HTTP status code in the JSON
as `status_code`. However, if there was an error from the API the status
code would be placed in the JSON as `status`. In order to be consistent,
this adds a `status_code` field to the error response case. For
backwards compatibility it still populates `status` in the error case.
This inconsistency was missed partially due to a bug in the CLI tests.
The assertion on status code was not valid and would always be
successful. Thus this also fixes the assertions and tests.
This ensures that checks for features should work, and bails early if
that is not the case, since if this fails the binary is essentially
broken. This also simplifies code that performs these checks, ie instead
of:
binaryVersion, err := version.GetReleaseVersion()
if err != nil {
// handle error? panic?
}
if version.SupportsFeature(binaryVersion, version.FeatureA) {
// code for FeatureA
} else {
// without FeatureA
}
Implementations can do:
if version.SupportsFeature(version.Binary, version.FeatureA) {
// code for FeatureA
} else {
// without FeatureA
}
Add vault ssh certificate credential library
This adds a new credential library type, `vault-ssh-certificate`, which
can be used with vault's ssh secret engine to generate certificates to
use as credentials for ssh. This new credential library can be created
using:
boundary credential-libraries create vault-ssh-certificate
See the help output for a full list of the options supported.
This also renames the `vault` credential library subtype to
`vault-generic`. The previous subtype of `vault` will continue to work,
thus the following commands are equivalent:
boundary credential-libraries create vault-generic
boundary credential-libraries create vault
See: https://developer.hashicorp.com/vault/docs/secrets/ssh
When issuing credentials from vault credential libraries, only persist
the vault credential if it is revokable. A credential that is revokable
has a valid lease id that can be used to revoke the lease in vault. If
the credential is not revokable it is also not renewable since renewing
also requires a lease id.
See: https://developer.hashicorp.com/vault/docs/concepts/lease
This defines a new credential library type for ssh certificates.
It adds new repository methods to support CRUDL of the new ssh
certificate credential library.
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
Allows for new issuing credential library implementations in the future.
Moved db and decrypt logic to privateCredentialLibraryAllTypes from
issueCredentialLibrary.
This also removes sessionId from retrieveCredential, it was not needed
and removing allows retrieveCredential to be reused for credentials
issued outside current workflow.
* chore: remove duplicate import
* feat: Add job run cleaner
The new job cleans job runs older than a configured interval.
Configure the job to clean jobs older than 1 minute.
* feat: default to using primary auth method with authenticating
* Add ability to specify scope ID flag in authenticate method
---------
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* Fix target port handling
This fixes two issues that compounded on each other (see the Changelog
update for more information):
* The verification logic for hosts was not correct for update operations
(in multiple ways) which meant that a host could be updated after
creation to have a port. Targets had a previously fixed bug where they
did not require a default port, which meant that ports could be used
from hosts
* A recent (unreleased) change had prioritized any port coming from the
host over the default port, which would mean there was no way if a
host had a port specified to use it in multiple targets.
This fixes the update verification logic, and strikes a middle ground
between breaking things and not by allowing existing addresses with
ports to be used with targets but ignoring that port, instead requiring
targets to have default port set at authorize time (currently there is
backwards compat that does not require this due to the original optional
port bug).
* Update CHANGELOG.md
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Jeff Mitchell
Damian Debkowski
Timothy Messier
Cameron Perera
Johan Brandhorst-Satzkorn
Irena Rindos
Hugo
Haotian
Danielle
Bryce Kalow
Josh Brand
Todd
Michael Li