* Edit alias_name_source explanation
We wanted to clarify the difference between the two options and the implications.
* Add missing backticks
* Add comma
* Update website/content/api-docs/auth/kubernetes.mdx
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
---------
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Replace getNewModel with hydrateModel when model exists
* Update getNewModel to only handle nonexistant model types
* Update test
* clarify test
* Fix auth-config models which need hydration not generation
* rename file to match service name
* cleanup + tests
* Add comment about helpUrl method
* move files around
* move fetches to config to the configuration.index route
* working... for aws, lots of clean up left
* move error handling to parent route
* standarize configModel param
* add test coverage
* welp a miss for non configurable engines
* pr comments
* remove mirage interrupts and test actual api
* update configuration details test to test for template only things
* api error coverage
I wanted to make the list of API endpoints with restricted namespace access easier to find.
I considered adding the partial directly here, but thought the explanation in the link would have been helpful.
- Avoid this error for now
zlint_test.go:149: got unexpected error from test e_subj_orgunit_in_ca_cert: map[details:The OU attribute in the Subject is prohibited in Root and TLS CA certificates result:error]
Amazon Linux 2 uses an ancient version of Systemd/systemctl so instead
of using -P when determining the unit file we use the less convenient
-p.
Signed-off-by: Ryan Cragun <me@ryan.ec>
When verifying the Vault version, in addition to verifying the CLI
version we also check that the `/sys/version-history` contains the
expected version.
As part of this we also fix a bug where when doing an in-place upgrade
with a Debian or Redhat package we also remove the self-managed
`vault.service` systemd unit to ensure that correctly start up using the
new version of Vault.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Corrected Docs at: [vault/docs/auth/approle **Via the CLI**](https://developer.hashicorp.com/vault/docs/auth/approle#via-the-cli-1) which results in the error message below on versions near to Vault 1.17.x.
```
Error writing data to auth/approle/role/my-role: Error making API request.
URL: PUT https://.../v1/auth/approle/role/my-role
Code: 400. Errors:
* 'token_type' cannot be 'batch' or 'default_batch' when set to generate tokens with limited use count
```
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* router changes and appropriate file shuffling
* changelog
* fix test routes
* handle redirect... is this okay?
* test redirect coverage
* move configure-secret-backend test and cleanup
* coverage for non configurable secret engine:
* clean up
* remove redirect
* adds sslinline option to postgres conn string
* for database secrets type postgres, inspects the connection string for sslinline and generates a tlsconfig from the connection string.
* support fallback hosts
* remove broken multihost test
* bootstrap container with cert material
* overwrite pg config and set key file perms
* add feature flag check
* add tests
* add license and comments
* test all ssl modes
* add test cases for dsn (key/value) connection strings
* add fallback test cases
* fix error formatting
* add test for multi-host when using pgx native conn url parsing
---------
Co-authored-by: Branden Horiuchi <Branden.Horiuchi@blackline.com>
* init
* fix versions
* remove whitespace
* update version
* fix file name
* fix link
* fix links (included one from other known issue too
* Fix spacing
* remove destructureClientCounts
* Update type and mirage generator
* remove deprecated keys from hardcoded response samples
* Add back destructureClientCounts with updated description
* VAULT-28146: Add IPV6 support to enos scenarios
Add support for testing all raft storage scenarios and variants when
running Vault with IPV6 networking. We retain our previous support for
IPV4 and create a new variant `ip_version` which can be used to
configure the IP version that we wish to test with.
It's important to note that the VPC in IPV6 mode is technically mixed
and that target machines still associate public IPV6 addresses. That
allows us to execute our resources against them from IPV4 networks like
developer machines and CI runners. Despite that, we've taken care to
ensure that only IPV6 addresses are used in IPV6 mode.
Because we previously had assumed the IP Version, Vault address, and
listener ports in so many places, this PR is essentially a rewrite and
removal of those assumptions. There are also a few places where
improvements to scenarios have been included as I encountered them while
working on the IPV6 changes.
Signed-off-by: Ryan Cragun <me@ryan.ec>
