* Clarify docs around using either Consul or Vault managed PKI paths
The current docs can be misread to indicate that you need both the
Consul and Vault managed PKI Paths policies. The [Learning Tutorial](https://learn.hashicorp.com/tutorials/consul/vault-pki-consul-connect-ca?in=consul/vault-secure#create-vault-policies)
is clearer. This tries to make the original docs as clear as the
learning tutorial
* Clarify that PKI secret engines are used to store certs
Co-authored-by: Blake Covarrubias <blake.covarrubias@gmail.com>
Port some changes that were made to the backport branch but not in the original PR.
Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
Signed-off-by: Mark Anderson <manderson@hashicorp.com>
* Support vault namespaces in connect CA
Follow on to some missed items from #12655
From an internal ticket "Support standard "Vault namespace in the
path" semantics for Connect Vault CA Provider"
Vault allows the namespace to be specified as a prefix in the path of
a PKI definition, but our usage of the Vault API includes calls that
don't support a namespaced key. In particular the sys.* family of
calls simply appends the key, instead of prefixing the namespace in
front of the path.
Unfortunately it is difficult to reliably parse a path with a
namespace; only vault knows what namespaces are present, and the '/'
separator can be inside a key name, as well as separating path
elements. This is in use in the wild; for example
'dc1/intermediate-key' is a relatively common naming schema.
Instead we add two new fields: RootPKINamespace and
IntermediatePKINamespace, which are the absolute namespace paths
'prefixed' in front of the respective PKI Paths.
Signed-off-by: Mark Anderson <manderson@hashicorp.com>
Use long form of CLI flags in all example commands.
Co-authored-by: mrspanishviking <kcardenas@hashicorp.com>
Co-authored-by: David Yu <dyu@hashicorp.com>
* add diagram and text to explain certificates in consul
* use bullet points instead of enumeration
* Apply suggestions from code review
Co-authored-by: mrspanishviking <kcardenas@hashicorp.com>
* remove non needed text and improve image
* fix cert naming
* move section to the right place
* rename DC
Co-authored-by: mrspanishviking <kcardenas@hashicorp.com>
* Support vault auth methods for the Vault connect CA provider
* Rotate the token (re-authenticate to vault using auth method) when the token can no longer be renewed
* Support Vault Namespaces explicitly in CA config
If there is a Namespace entry included in the Vault CA configuration,
set it as the Vault Namespace on the Vault client
Currently the only way to support Vault namespaces in the Consul CA
config is by doing one of the following:
1) Set the VAULT_NAMESPACE environment variable which will be picked up
by the Vault API client
2) Prefix all Vault paths with the namespace
Neither of these are super pleasant. The first requires direct access
and modification to the Consul runtime environment. It's possible and
expected, not super pleasant.
The second requires more indepth knowledge of Vault and how it uses
Namespaces and could be confusing for anyone without that context. It
also infers that it is not supported
* Add changelog
* Remove fmt.Fprint calls
* Make comment clearer
* Add next consul version to website docs
* Add new test for default configuration
* go mod tidy
* Add skip if vault not present
* Tweak changelog text
Add the list of common Connect CA configuration options to the
provider-specific CA docs.
Previously these options were only documented under the agent
configuration options. This change makes it so that all supported CA
provider configuration options are available from a single location.
Co-authored-by: Daniel Nephin <dnephin@hashicorp.com>
* website: migrate to new nav-data format
* website: clean up unused intro content
* website: remove deprecated sidebar_title from frontmatter
* website: add react-content to fix global style import issue
twunderlich-grapl