* Refactor `identity/mfa/method/*` endpoints to fix bad OpenAPI
There is a problem with how the `identity/mfa/method/*` endpoints are
defined, resulting in incorrect OpenAPI generation.
I raised hashicorp/vault-client-go#180 to track a consequence, and
opened #20873 which explains the problem and adds a log message to
detect it.
This PR is now the fix.
It's actually quite an interesting problem, that has come about through
some particular implementation choices, in Vault's first/only case where
REST API objects are created by writing to the collection URL, and have
their ID allocated by the server, instead of the client.
The triggering cause of the malfunction was trying to have a single
framework.Path struct instance which optionally includes or excludes the
method_id path parameter, and also another framework.Path struct
instance handling list operations.
The fix is to simplify the path regexes, and have one framework.Path
which handles the method_id being present, and one that handles it being
absent.
The diff is somewhat large, because the affected code had been
copy/pasted four times (TOTP, Okta, Duo, PingID) - so I took the
opportunity to fix the duplication, creating appropriate helper methods
so that the quadruplicated code could be re-unified.
* Revise documentation
This update refactors how the documentation presents these endpoints to
users, both for clarity, and to align with the new structure of the
code.
From a user perspective, it clears up some unclear presentation of when
the `method_id` parameter should and should not be present, adds
a missing description of the response to create requests, and changes
the `method_id` parameter name to be used consistently (rather than `id`
in some cases, unlike the actual code/OpenAPI).
* Fix incorrect acronym (review fix)
* Accept suggestion of tweaked grammar in documentation
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
* Add changelog
---------
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
These don't do anything but reject requests:
> The server will not issue certificates for the identifier:
> role (something) will not issue certificate for name
> xps15.local.cipherboy.com
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update docs for new 1.14 ACME health checks
* Remove wording about informational warning only
- The health check can report back warnings if permissions are an issue
or if the local cluster configuration is missing.
* [docs] Remove beta tag and update example code, add HCP as a supported platform.
* [docs] extend vault secrets operator secret CRD examples (#20913)
* [docs] update helm docs for vso GA (#21150)
* [docs] Add some initial telemetry documentation (#21144)
* [docs] update api reference for VSO (#21153)
---------
Co-authored-by: Thy Ton <maithytonn@gmail.com>
* S3 Auto-Snapshot IAM Roles EKS Incompatibility Footnote
This is a common source of confusion for customers when setting up S3 auto snapshots on EKS.
Currently internal feature request 0/1182317814772514/1200126608980599 is open for this.
By adding this footnote, we will save our customer's time spent attempting to configure an unsupported feature.
* Minor updates
---------
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* Add ACME TLS-ALPN-01 Challenge validator to PKI
This adds support for verifying the last missing challenge type,
TLS-ALPN-01 challenges, using Go's TLS library. We wish to add this as
many servers (such as Caddy) support transparently renewing certificates
via this protocol, without influencing the contents of sites served.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Enable suggesting, validating tls-alpn-01 in PKI
Notably, while RFC 8737 is somewhat vague about what identifier types
can be validated with this protocol, it does restrict SANs to be only
DNSSans; from this, we can infer that it is not applicable for IP
typed identifiers. Additionally, since this must resolve to a specific
domain name, we cannot provision it for wildcard identifiers either.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Fix test expectations to allow ALPN challenges
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add tls-alpn-01 as a supported challenge to docs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add test for tls-alpn-01 challenge verifier
This hacks the challenge engine to allow non-standard (non-443) ports,
letting us use a local server listener with custom implementation.
In addition to the standard test cases, we run:
- A test with a longer chain (bad),
- A test without a DNSSan (bad),
- A test with a bad DNSSan (bad),
- A test with some other SANs (bad),
- A test without a CN (good),
- A test without any leaf (bad), and
- A test without the extension (bad).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update builtin/logical/pki/acme_challenges.go
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Kit Haines <khaines@mit.edu>
* Generate ACME EAB tokens that do not start with -
- To avoid people having issues copying EAB tokens and using them on command lines when they start with - from the base64 encoded values, append a prefix.
- Remove the key_bits data from the eab api, not really useful and now technically wrong
- Fix up some issues with tests not running in parallel.
- Update docs to reflect new EAB apis.
* Add ACME directory to the various EAB output APIs
* Update EAB token prefix to be divisable by 3
- Our decoded prefix was not divisable by 3, which meant the last
character might be tweaked by the rest of the input
