Security context
Medium· 4.3GHSA-gq98-53rq-qr5h CVE-2023-2121CWE-79Published Jun 9, 2023

Hashicorp Vault vulnerable to Cross-site Scripting

Research this vulnerability

Research is free — Hunters explains how the bug works, the root-cause code pattern, how the fix addresses it, and how to test whether a target is affected, in chat. Investigate & write exploit is a paid run — the engine reads the advisory and fix commits, then builds and validates a working proof-of-concept exploit with reproduction steps.

Affected versions

0 → fixed in 1.11.111.12.0 → fixed in 1.12.71.13.0 → fixed in 1.13.3

Details

Vault and Vault Enterprise's (Vault) key-value v2 (kv-v2) diff viewer allowed HTML injection into the Vault web UI through key values. This vulnerability, CVE-2023-2121, is fixed in Vault 1.14.0, 1.13.3, 1.12.7, and 1.11.11.

The fix

Release delta 1.12.0 → 1.12.7 (contains the fix)

· Oct 11, 2022, 06:47 PM+1507576compare
website/content/docs/secrets/kmip-profiles.mdx+262 0
@@ -0,0 +1,262 @@
+---
+layout: docs
+page_title: KMIP - Profiles Support
+description: |-
+ The KMIP profiles define the use of KMIP objects, attributes, operations, message elements
+ and authentication methods within specific contexts of KMIP server and client interaction.
+ These profiles define a set of normative constraints for employing KMIP within a particular
+ environment or context of use.
+---
+
+# KMIP Profiles Version 1.4
+
+This document specifies conformance clauses in accordance with the OASIS TC Process ([TC-PROC section 2.18 paragraph 8a][tc-proc-2.18] )
+for the KMIP Specification ([KMIP-SPEC 12.1 and 12.2][kmip-spec]) for a KMIP server or KMIP client through profiles that define the
+use of KMIP objects, attributes, operations, message elements and authentication methods within specific contexts of
+KMIP server and client interaction.
+
+Vault implements version 1.4 of the following Key Management Interoperability Protocol Profiles:
+
+## [Baseline Server][baseline-server]
+ 1. Supports the following objects:
+
+ | Object | Supported |
+ | ----------------------------------------------------------------------- | :-------: |
+ | Attribute [KMIP-SPEC 2.1.1][kmip-spec-2.1.1] | ✅ |
+ | Credential [KMIP-SPEC 2.1.2][kmip-spec-2.1.2] | ✅ |
+ | Key Block [KMIP-SPEC 2.1.3][kmip-spec-2.1.3] | ✅ |
+ | Key Value [KMIP-SPEC 2.1.4][kmip-spec-2.1.4] | ✅ |
+ | Template-Attribute Structure [KMIP-SPEC 2.1.8][kmip-spec-2.1.8] | ✅ |
+ | Extension Information [KMIP-SPEC 2.1.9][kmip-spec-2.1.9] | ✅ |
+ | Profile Information [KMIP-SPEC 2.1.19][kmip-spec-2.1.19] | ✅ |
+ | Validation Information [KMIP-SPEC 2.1.20][kmip-spec-2.1.20] | ✅ |
+ | Capability Information [KMIP-SPEC 2.1.21][kmip-spec-2.1.21] | ✅ |
+
+ 2. Supports the following subsets of attributes:
+
+ | Attribute | Supported | Notes |
+ | -----------------------------------------------------------------------| :-------: | :----: |
+ | Unique Identifier [KMIP-SPEC 3.1][kmip-spec-3.1] | ✅ | |
+ | Name [KMIP-SPEC 3.2][kmip-spec-3.2] | ✅ | |
+ | Object Type [KMIP-SPEC 3.3][kmip-spec-3.3] | ✅ | |
+ | Cryptographic Algorithm [KMIP-SPEC 3.4][kmip-spec-3.4] | ✅ | |
+ | Cryptographic Length [KMIP-SPEC 3.5][kmip-spec-3.5] | ✅ | |
+ | Cryptographic Parameters [KMIP-SPEC 3.6][kmip-spec-3.6] | ✅ | |
+ | Digest [KMIP-SPEC 3.17][kmip-spec-3.17] | ✅ | |
+ | Cryptographic Usage Mask [KMIP-SPEC 3.19][kmip-spec-3.19] | ✅ | |
+ | State [KMIP-SPEC 3.22][kmip-spec-3.22] | ✅ | |
+ | Initial Date [KMIP-SPEC 3.23][kmip-spec-3.23] | ✅ | |
+ | Process Start Date [KMIP-SPEC 3.25][kmip-spec-3.25] | ✅ | Vault 1.11 |
+ | Protect Stop Date [KMIP-SPEC 3.26][kmip-spec-3.26] | ✅ | Vault 1.11 |
+ | Activation Date [KMIP-SPEC 3.24][kmip-spec-3.24] | ✅ | |
+ | Deactivation Date [KMIP-SPEC 3.27][kmip-spec-3.27] | ✅ | |
+ | Compromise Occurrence Date [KMIP-SPEC 3.29][kmip-spec-3.29] | ✅ | |
+ | Compromise Date [KMIP-SPEC 3.30][kmip-spec-3.30] | ✅ | |
+ | Revocation Reason [KMIP-SPEC 3.31][kmip-spec-3.31] | ✅ | |
+ | Object Group [KMIP-SPEC 3.33][kmip-spec-3.33] | ✅ | |
+ | Fresh [KMIP-SPEC 3.34][kmip-spec-3.34] | ✅ | |
+ | Link [KMIP-SPEC 3.35][kmip-spec-3.35] | ✅ | |
+ | Last Change Date [KMIP-SPEC 3.38][kmip-spec-3.38] | ✅ | |
+ | Alternative Name [KMIP-SPEC 3.40][kmip-spec-3.40] | ✅ | Vault 1.12 |
+ | Key Value Present [KMIP-SPEC 3.41][kmip-spec-3.41] | ✅ | Vault 1.12 |
+ | Key Value Location [KMIP-SPEC 3.42][kmip-spec-3.42] | 🔴 | |
+ | Original Creation Date [KMIP-SPEC 3.43][kmip-spec-3.43] | ✅ | |
+ | Random Number Generator [KMIP-SPEC 3.44][kmip-spec-3.44] | ✅ | |
+ | Description [KMIP-SPEC 3.46][kmip-spec-3.46] | ✅ | |
+ | Comment [KMIP-SPEC 3.47][kmip-spec-3.47] | ✅ | |
+ | Sensitive [KMIP-SPEC 3.48][kmip-spec-3.48] | ✅ | |
+ | Always Sensitive [KMIP-SPEC 3.49][kmip-spec-3.49] | ✅ | |
+ | Extractable [KMIP-SPEC 3.50][kmip-spec-3.50] | ✅ | |
+ | Never Extractable [KMIP-SPEC 3.51][kmip-spec-3.51] | ✅ | |
+
+ 3. Supports the following client-to-server operations:
+
+ | Operation | Supported | Notes |
+ | ------------------------------------------------------| :--------:|:-----:|
+ | Locate [KMIP-SPEC 4.9][kmip-spec-4.9] | ✅ | Vault version 1.11 supports attributes Activation Date, Application Specific Information, Cryptographic Algorithm, Cryptographic Length, Name, Object Type, Original Creation Date, and State. <br/> Vault version 1.12 supports all profile attributes except for Key Value Location. |
+ | Check [KMIP-SPEC 4.10][kmip-spec-4.10] | 🔴 | |
+ | Get [KMIP-SPEC 4.11][kmip-spec-4.11] | ✅ | |
+ | Get Attributes [KMIP-SPEC 4.12][kmip-spec-4.12] | ✅ | |
+ | Get Attribute List [KMIP-SPEC 4.13][kmip-spec-4.13] | ✅ | |
+ | Add Attribute [KMIP-SPEC 4.14][kmip-spec-4.14] | ✅ | |
+ | Modify Attribute [KMIP-SPEC 4.15][kmip-spec-4.15] | ✅ | Vault 1.12 |
+ | Delete Attribute [KMIP-SPEC 4.16][kmip-spec-4.16] | ✅ | Vault 1.12 |
+ | Activate [KMIP-SPEC 4.19][kmip-spec-4.19] | ✅ | |
+ | Revoke [KMIP-SPEC 4.20][kmip-spec-4.20] | ✅ | |
+ | Destroy [KMIP-SPEC 4.21][kmip-spec-4.21] | ✅ | |
+ | Query [KMIP-SPEC 4.25][kmip-spec-4.25] | ✅ | Vault 1.11 |
+ | Discover Versions [KMIP-SPEC 4.26][kmip-spec-4.26] | ✅ | |
+
+ 4.Supports the following message contents:
+
+ | Message Content | Supported |
+ | -----------------------------------------------------------------| :--------:|
+ | Protocol Version [KMIP-SPEC 6.1][kmip-spec-6.1] | ✅ |
+ | Operation [KMIP-SPEC 6.2][kmip-spec-6.2] | ✅ |
+ | Maximum Response Size [KMIP-SPEC 6.3][kmip-spec-6.3] | ✅ |
+ | Unique Batch Item ID [KMIP-SPEC 6.4][kmip-spec-6.4] | ✅ |
+ | Time Stamp [KMIP-SPEC 6.5][kmip-spec-6.5] | ✅ |
+ | Asynchronous Indicator [KMIP-SPEC 6.7][kmip-spec-6.7] | ✅ |
+ | Result Status [KMIP-SPEC 6.9][kmip-spec-6.9] | ✅ |
+ | Result Reason [KMIP-SPEC 6.10][kmip-spec-6.10] | ✅ |
+ | Batch Order Option [KMIP-SPEC 6.12][kmip-spec-6.12] | ✅ |
+ | Batch Error Continuation Option [KMIP-SPEC 6.13][kmip-spec-6.13] | ✅ |
+ | Batch Count [KMIP-SPEC 6.14][kmip-spec-6.14] | ✅ |
+ | Batch Item [KMIP-SPEC 6.15][kmip-spec-6.15] | ✅ |
+ | Attestation Capable Indicator [KMIP-SPEC 6.17][kmip-spec-6.17] | ✅ |
+ | Client Correlation Value [KMIP-SPEC 6.18][kmip-spec-6.18] | ✅ |
+ | Server Correlation Value [KMIP-SPEC 6.19][kmip-spec-6.19] | ✅ |
+ | Message Extension [KMIP-SPEC 6.16][kmip-spec-6.16] | ✅ |
+
+ 5. Supports the ID Placeholder [KMIP-SPEC 4][kmip-spec-4]
+ 6. Supports Message Format [KMIP-SPEC 7][kmip-spec-7]
+ 7. Supports Authentication [KMIP-SPEC 8][kmip-spec-8]
+ 8. Supports the TTLV encoding [KMIP-SPEC 9.1][kmip-spec-9.1]
+ 9. Supports the transport requirements [KMIP-SPEC 10][kmip-spec-10]
+ 10. Supports Error Handling [KMIP-SPEC 11][kmip-spec-11] for any supported object, attribute, or operation
+ 11. Optionally supports any clause within [KMIP-SPEC][kmip-spec] that is not listed above
+ 12. Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements - We do not have any extensions
+
+## [Symmetric Key Lifecycle Server][lifecycle-server]
+
+ 1. SHALL conform to the [Baseline Server][baseline-server]
+ 2. Supports the following objects:
+
+ | Object | Supported |
+ | -----------------------------------------------------------------------| :----- --:|
+ | Symmetric Key [KMIP-SPEC 2.2.2][kmip-spec-2.2.2] | ✅ |
+ | Key Format Type [KMIP-SPEC 9.1.3.2.3][kmip-spec-9.1.3.2.3] | ✅ |
+
+ 3. Supports the following subsets of attributes:
+
+ | Attribute | Supported | Notes |
+ | -----------------------------------------------------------------------| :-------: | :---: |
+ | Cryptographic Algorithm [KMIP-SPEC 3.4][kmip-spec-3.4] | ✅ | |
+ | Object Type [KMIP-SPEC 3.3][kmip-spec-3.3] | ✅ | |
+ | Process Start Date [KMIP-SPEC 3.25][kmip-spec-3.25] | ✅ | Vault 1.11 |
+ | Protect Stop Date [KMIP-SPEC 3.26][kmip-spec-3.26] | ✅ | Vault 1.11 |
+
+ 4. Supports the following client-to-server operations:
+
+ | Operation | Supported |
+ | ------------------------------------------------------| :--------:|
+ | Create [KMIP-SPEC 4.1][kmip-spec-4.1] | ✅ |
+
+ 5. Supports the following message encoding:
+
+ | Message Encoding | Supported | Notes |
+ | -------------------------------------------------------------------------------------| :--------:|:-----:|
+ | Cryptographic Algorithm [KMIP-SPEC 9.1.3.2.13][kmip-spec-9.1.3.2.13] with values: | | |
+ | i. 3DES | ✅ | Vault 1.12 |
+ | ii. AES | ✅ | |
+ | Object Type [KMIP-SPEC 9.1.3.2.12][kmip-spec-9.1.3.2.12] with value: | | |
+ | i. Symmetric Key | ✅ | |
+ | Key Format Type [KMIP-SPEC 9.1.3.2.3][kmip-spec-9.1.3.2.3] with value: | | |
+ | i. Raw | ✅ | |
+ | ii. Transparent Symmetric Key | 🔴 | |
+
+ 6. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Symmetric Key Lifecycle Server][lifecycle-server]
+ 7. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements.
+
+## [Basic Cryptographic Server][basic-cryptographic-server]
+
+ 1. SHALL conform to the [Baseline Server][baseline-server]
+ 2. Supports the following client-to-server operations:
+
+ | Operation | Supported | Notes |
+ | ------------------------------------------------------| :--------:| --------|
+ | Encrypt [KMIP-SPEC 4.29][kmip-spec-4.29] | ✅ | Vault 1.11 <br/> Supported for AES, unsupported for 3DES: <br/><br/> Supported Block Cipher Modes: <br/> <ol> <li> GCM </li> <li> CBC </li> <li> CFB </li> <li> CTR </li> <li> ECB </li> <li> OFB </li> </ol> <br/> Stream operations are supported except for GCM block cipher mode. <br/><br/> Supported padding methods: <br/> <ol> <li> None </li> <li> PKCS5 </li> </ol> |
+ | Decypt [KMIP-SPEC 4.30][kmip-spec-4.30] | ✅ | Vault 1.11 <br/> Supported for AES, unsupported for 3DES: <br/><br/> Supported Block Cipher Modes: <br/> <ol> <li> GCM </li> <li> CBC </li> <li> CFB </li> <li> CTR </li> <li> ECB </li> <li> OFB </li> </ol> <br/> Stream operations are supported except for GCM block cipher mode. <br/><br/> Supported padding methods: <br/> <ol> <li> None </li> <li> PKCS5 </li> </ol> | |
+
+ 3. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Basic Cryptographic Server][basic-cryptographic-server]
+ 4. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements.
+
+
+ [kmip-spec-2.1.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660735
+ [kmip-spec-2.1.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660736
+ [kmip-spec-2.1.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660737
+ [kmip-spec-2.1.4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660738
+ [kmip-spec-2.1.8]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660757
+ [kmip-spec-2.1.9]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660758
+ [kmip-spec-2.1.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660768
+ [kmip-spec-2.1.20]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660769
+ [kmip-spec-2.1.21]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660770
+ [kmip-spec-3.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660784
+ [kmip-spec-3.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660785
+ [kmip-spec-3.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660786
+ [kmip-spec-3.4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660787
+ [kmip-spec-3.5]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660788
+ [kmip-spec-3.6]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660789
+ [kmip-spec-3.17]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660800
+ [kmip-spec-3.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660807
+ [kmip-spec-3.22]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660810
+ [kmip-spec-3.23]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660811
+ [kmip-spec-3.25]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660813
+ [kmip-spec-3.26]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660814
+ [kmip-spec-3.24]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660812
+ [kmip-spec-3.27]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660815
+ [kmip-spec-3.29]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660817
+ [kmip-spec-3.30]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660818
+ [kmip-spec-3.31]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660819
+ [kmip-spec-3.33]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660821
+ [kmip-spec-3.34]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660822
+ [kmip-spec-3.35]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660823
+ [kmip-spec-3.38]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660826
+ [kmip-spec-3.40]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660828
+ [kmip-spec-3.41]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660829
+ [kmip-spec-3.42]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660830
+ [kmip-spec-3.43]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660831
+ [kmip-spec-3.44]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660832
+ [kmip-spec-3.46]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660834
+ [kmip-spec-3.47]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660835
+ [kmip-spec-3.48]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660836
+ [kmip-spec-3.49]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660837
+ [kmip-spec-3.50]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660838
+ [kmip-spec-3.51]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660839
+ [kmip-spec-4.9]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660849
+ [kmip-spec-4.10]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660850
+ [kmip-spec-4.11]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660851
+ [kmip-spec-4.12]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660852
+ [kmip-spec-4.13]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660853
+ [kmip-spec-4.14]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660854
+ [kmip-spec-4.15]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660855
+ [kmip-spec-4.16]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660856
+ [kmip-spec-4.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660859
+ [kmip-spec-4.20]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660860
+ [kmip-spec-4.21]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660861
+ [kmip-spec-4.25]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660865
+ [kmip-spec-4.26]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660866
+ [kmip-spec-6.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660887
+ [kmip-spec-6.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660888
+ [kmip-spec-6.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660889
+ [kmip-spec-6.4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660890
+ [kmip-spec-6.5]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660891
+ [kmip-spec-6.7]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660893
+ [kmip-spec-6.9]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660895
+ [kmip-spec-6.10]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660896
+ [kmip-spec-6.12]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660898
+ [kmip-spec-6.13]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660899
+ [kmip-spec-6.14]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660900
+ [kmip-spec-6.15]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660901
+ [kmip-spec-6.17]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660903
+ [kmip-spec-6.18]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660904
+ [kmip-spec-6.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660905
+ [kmip-spec-6.16]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660902
+ [kmip-spec-4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660840
+ [kmip-spec-7]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660906
+ [kmip-spec-8]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660909
+ [kmip-spec-9.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660911
+ [kmip-spec-10]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660973
+ [kmip-spec-11]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660974
+ [kmip-spec]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html
+ [kmip-spec-2.2.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660775
+ [kmip-spec-9.1.3.2.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660923
+ [kmip-spec-4.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660841
+ [kmip-spec-9.1.3.2.13]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660933
+ [kmip-spec-9.1.3.2.12]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660932
+ [kmip-spec-4.29]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660869
+ [kmip-spec-4.30]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660870
+ [baseline-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431430
+ [lifecycle-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431487
+ [basic-cryptographic-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431527
+ [tc-proc-2.18]: https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26/technical-committee-tc-process-27-july-2011/#specQuality
website/content/docs/upgrading/plugins.mdx+127 151
@@ -6,58 +6,76 @@ description: These are general upgrade instructions for Vault plugins.
# Upgrading Vault Plugins
-## External Plugin Upgrade Procedure
+## Plugin Upgrade Procedure
-The following procedure details steps for upgrading an external plugin that has
-been registered to the catalog on a running server. This procedure is
-applicable to secret engines, auth methods, and database plugins.
+The following procedures detail steps for upgrading a plugin that has been mounted
+at a path on a running server. The steps are the same whether the plugin being
+upgraded is built-in or external.
-Vault executes plugin binaries when they are configured and roles are established
-around them. The binary cannot be modified or replaced while running, so
-upgrades cannot be performed by simply swapping the binary and updating the hash
-in the plugin catalog.
+~> Plugin versioning was introduced with Vault 1.12.0, so if your Vault server is
+ on 1.11.x or earlier, see the [1.11.x version of this page](/docs/v1.11.x/upgrading/plugins)
+ for plugin upgrade instructions.
-Instead, you can restart or reload a plugin with the
-`sys/plugins/reload/backend` [API][plugin_reload_api]. Follow these steps to
-replace or upgrade a Vault plugin binary:
+### Upgrading auth and secrets plugins
-1. [Register][plugin_registration] version 1 of `my-db-plugin` to the catalog.
- Skip this step if your plugin is already registered.
+The process is nearly identical for auth and secret plugins. If you are upgrading
+an auth plugin, just replace all usages of `secrets` or `secret` with `auth`.
+
+1. [Register][plugin_registration] the first version of your plugin to the catalog.
+ Skip this step if your initial plugin is built-in or already registered.
```shell-session
- $ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \
- database \ # type
- my-db-plugin
+ $ vault plugin register
+ -sha256=<SHA256 Hex value of the plugin binary> \
+ secret \
+ my-secret-plugin
```
-2. [Mount][plugin_management] the plugin backend. Skip this step if the backend
+1. [Mount][plugin_management] the plugin. Skip this step if your initial plugin
is already mounted.
```shell-session
- $ vault secrets enable database
+ $ vault secrets enable my-secret-plugin
```
-3. Register version 2 of `my-db-plugin` to the catalog under the same plugin
- name, but with updated command to run version 2 of `my-db-plugin` and updated
- sha256 of the new binary
+1. Register a second version of your plugin. You **must** use the same plugin
+ type and name (the last two arguments) as the plugin being upgraded. This is
+ true regardless of whether the plugin being upgraded is built-in or external.
```shell-session
- $ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \
- database \ # type
- my-db-plugin
+ $ vault plugin register \
+ -sha256=<SHA256 Hex value of the plugin binary> \
+ -command=my-secret-plugin-1.0.1 \
+ -version=v1.0.1 \
+ secret \
+ my-secret-plugin
```
-4. Trigger a [plugin reload](/docs/commands/plugin/reload) to reload all
+1. Tune the existing mount to configure it to use the newly registered version.
+
+ ```shell-session
+ $ vault secrets tune -plugin-version=v1.0.1 my-secret-plugin
+ ```
+
+1. If you wish, you can check the updated configuration. Notice the "Version" is
+ now different from the "Running Version".
+
+ ```shell-session
+ $ vault secrets list -detailed
+ ```
+
+1. Finally, trigger a [plugin reload](/docs/commands/plugin/reload) to reload all
mounted backends using that plugin or a subset of the mounts using that plugin
- with either the `plugin` or `mounts` parameter respectively.
+ with either the `plugin` or `mounts` flag respectively.
```shell-session
- $ vault plugin reload -plugin my-db-plugin
+ $ vault plugin reload -plugin my-secret-plugin
```
-Until step 4, the mount will still use version 1 of `my-db-plugin`, and when
-the reload is triggered, Vault will kill `my-db-plugin`’s process and start the
-new plugin process for `my-db-plugin` version 2.
+Until the last step, the mount will still run the first version of `my-secret-plugin`. When
+the reload is triggered, Vault will kill `my-secret-plugin`’s process and start the
+new plugin process for `my-secret-plugin` version 1.0.1. The "Running Version" should also
+now match the "Version" when you run `vault secrets list -detailed`.
-> **Important:** Plugin reload of a new plugin binary must be
performed on each Vault instance. Performing a plugin upgrade on a single
@@ -65,147 +83,101 @@ instance or through a load balancer can result in mismatched
plugin binaries within a cluster. On a replicated cluster this may be accomplished
by setting the 'scope' parameter of the reload to 'global'.
-## Overriding Built-in Plugins
-
-### Background
-
-Vault's auth methods and secrets engines are structured as plugins, but this
-design is not obvious since many of them are built into Vault.
-
-You can see them with the Vault plugin list command, for example, the list of
-Secrets engines:
-
-```shell-session
-$ vault plugin list secret
-Plugins
-ad
-alicloud
-aws
-azure
-cassandra
-consul
-gcp
-gcpkms
-kv
-ldap
-mongodb
-mongodbatlas
-mssql
-mysql
-nomad
-openldap
-pki
-postgresql
-rabbitmq
-ssh
-terraform
-totp
-transit
-```
-
-This will list all Secrets engines, internal (built-in) or external. To find
-out if a plugin is built-in, we can query its info:
-
-```shell-session
-$ vault plugin info secret azure
-Key Value
-args []
-builtin true
-command n/a
-name azure
-sha256 n/a
-```
-
-Because these built-in engines are plugins, they can be overridden. This can be
-a useful way to leverage features or bug fixes in plugins that are newer than
-the version of Vault you're using, without updating or even restarting Vault,
-and while retaining the data for your existing mount.
-
-Assume you have a new version of Azure Secrets and the binary is called
-"azure_new". The binary needs to be in the [plugin directory](/docs/plugins/plugin-architecture#plugin-directory)
-and can then be registered as either a distinct plugin, or overriding the
-current one.
-
-~> **Important:** do not disable (`vault secrets disable ...`) any mount that has
-data you're interested in; that would erase storage. For the in-place update,
-register a new plugin atop the built-in one and leave any mounts alone.
-
-### Procedure for Overriding Built-in Plugins
-
-The syntax is the same as an external plugin, with the difference being you
-name it the same as a built-in:
+### Upgrading database plugins
-```shell-session
-$ vault plugin register \
- -sha256=<SHA256 Hex value of the plugin binary> \
- -command=azure_new \
- secret \
- azure
-```
+1. [Register][plugin_registration] the first version of your plugin to the catalog.
+ Skip this step if your initial plugin is built-in or already registered.
-"-command=azure_new" is the name of the binary, "secret" is the plugin type,
-and "azure" is the name of the built-in plugin that we're overriding. We can
-verify that the override is in place:
-
-```shell-session
-$ vault plugin info secret azure
-Key Value
-args []
-builtin false
-command azure_new
-name azure
-sha256 f6f6ec45d37484c257aa9ff80444b9f244aaef1c650edf8a42a2a1d3f00db2c5
-```
+ ```shell-session
+ $ vault plugin register
+ -sha256=<SHA256 Hex value of the plugin binary> \
+ database \
+ my-db-plugin
+ ```
-At this point we've overridden the built-in, but it is not yet actively
-handling requests. For that we run:
+1. [Mount][plugin_management] the plugin. Skip this step if your initial plugin
+ is already mounted.
-```shell-session
-$ vault plugin reload -plugin=azure
-```
+ ```shell-session
+ $ vault secrets enable database
+ $ vault write database/config/my-db \
+ plugin_name=my-db-plugin \
+ # ...
+ ```
-### Procedure for Reverting After Overriding A Built-in Plugin
+1. Register a second version of your plugin. You **must** use the same plugin
+ type and name (the last two arguments) as the plugin being upgraded. This is
+ true regardless of whether the plugin being upgraded is built-in or external.
-To revert the override, first deregister the plugin:
+ ```shell-session
+ $ vault plugin register \
+ -sha256=<SHA256 Hex value of the plugin binary> \
+ -command=my-db-plugin-1.0.1 \
+ -version=v1.0.1 \
+ database \
+ my-db-plugin
+ ```
-```shell-session
-$ vault plugin deregister secret azure
-```
+1. Update the database config with the new version. The database secrets
+ engine will immediately reload the plugin, using the new version. Any omitted
+ config parameters will not be updated.
+
+ ```shell-session
+ $ vault write database/config/my-db \
+ plugin_version=v1.0.1
+ ```
-Next, verify the override has been reverted and we are now using the built-in
-plugin:
+Until the last step, the mount will still run the first version of `my-db-plugin`. When
+the reload is triggered, Vault will kill `my-db-plugin`’s process and start the
+new plugin process for `my-db-plugin` version 1.0.1.
-```shell-session
-$ vault plugin info secret azure
-Key Value
-args []
-builtin true
-command n/a
-name azure
-sha256 n/a
-```
+### Downgrading Plugins
-Finally, reload the plugin:
+Plugin downgrades follow the same procedure as upgrades. You can use the Vault
+plugin list command to check what plugin versions are available to downgrade to:
```shell-session
-$ vault plugin reload -plugin=azure
+$ vault plugin list secret
+Name Version
+---- -------
+ad v0.14.0+builtin
+alicloud v0.13.0+builtin
+aws v1.12.0+builtin.vault
+azure v0.14.0+builtin
+cassandra v1.12.0+builtin.vault
+consul v1.12.0+builtin.vault
+gcp v0.14.0+builtin
+gcpkms v0.13.0+builtin
+kv v0.13.3+builtin
+ldap v1.12.0+builtin.vault
+mongodb v1.12.0+builtin.vault
+mongodbatlas v0.8.0+builtin
+mssql v1.12.0+builtin.vault
+mysql v1.12.0+builtin.vault
+nomad v1.12.0+builtin.vault
+openldap v0.9.0+builtin
+pki v1.12.0+builtin.vault
+postgresql v1.12.0+builtin.vault
+rabbitmq v1.12.0+builtin.vault
+ssh v1.12.0+builtin.vault
+terraform v0.6.0+builtin
+totp v1.12.0+builtin.vault
+transit v1.12.0+builtin.vault
```
-### Caveats to Overriding Built-in Plugins
+### Additional Upgrade Notes
* As mentioned earlier, disabling existing mounts will wipe the existing data.
-* This type of upgrade affects all uses of the plugin. So if you have 5
- different Azure Secrets mounts, they'll all change after the replacement. If
- you don't want that, you'll need to register the plugin under a different name
- and start with a fresh mount.
-* In most cases, data upgrade and downgrade is not an issue. If the "new" version
- introduces new data and you downgrade, the "old" version will ignore the
- extraneous data. In some cases upgrading changes existing data in non-backwards
- compatible ways, so it is good to check whether this is an issue.
+* Overwriting an existing version in the catalog will affect all uses of that
+ plugin version. So if you have 5 different Azure Secrets mounts using v1.0.0,
+ they'll all start using the new binary if you overwrite it. We recommend
+ treating plugin versions in the catalog as immutable, much like version control
+ tags.
+* Each plugin has its own data within Vault storage. While it is rare for HashiCorp
+ maintained plugins to update their storage schema, it is up to plugin authors
+ to manage schema upgrades and downgrades. Check the plugin release notes for
+ any unsupported upgrade or downgrade transitions, especially before moving to
+ a new major version or downgrading.
[plugin_reload_api]: /api-docs/system/plugins-reload-backend
[plugin_registration]: /docs/plugins/plugin-architecture#plugin-registration
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
6cb818993eaf8537f65816daf7123645adc7d926 (#17505)
builtin/logical/pki/path_tidy.go | 11 -----------
changelog/17497.txt | 3 +++
2 files changed, 3 insertions(+), 11 deletions(-)
create mode 100644 changelog/17497.txt
website/content/api-docs/secret/transform.mdx+14 1
@@ -181,7 +181,9 @@ configuration endpoints, and will be removed in a future release.
A role using this transformation must exist in this list in order for
encode and decode operations to properly function.
--
+- `deletion_allowed` `(bool: false)` -
+ If true, this transform can be deleted. Otherwise deletion is blocked while
+ this value remains false.
### Sample Payload
@@ -233,6 +235,12 @@ transformation exists, it will be updated with the new attributes.
A role using this transformation must exist in this list in order for
encode and decode operations to properly function.
+- `deletion_allowed` `(bool: false)` -
+ If true, this transform can be deleted. Otherwise deletion is blocked while this
+ value remains false. Note that deleting the transform deletes the underlying
+ key making decoding of FPE encoded values impossible without restoring from a
+ backup.
+
### Sample Payload
```json
@@ -337,6 +345,11 @@ transformation exists, it will be updated with the new attributes.
The list of tokenization stores to use for tokenization state. Vault's
internal storage is used by default.
+- `deletion_allowed` `(bool: false)` -
+ If true, this transform can be deleted. Otherwise deletion is blocked while this
+ value remains false. Note that deleting the transform deletes the underlying key
+ making decoding of tokenized values impossible without restoring from a backup.
+
### Sample Payload
```json
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
ed203c4548332562f81447e714c863e8fffc0d64 (#17548)
vault/core.go | 5 +++++
vault/core_util.go | 5 -----
2 files changed, 5 insertions(+), 5 deletions(-)
website/content/docs/plugins/index.mdx+58 15
@@ -7,21 +7,24 @@ description: Learn about Vault's plugin system.
# Plugin System
-All Vault auth methods and secrets engines are considered plugins. This concept
-allows both built-in and external plugins to be treated like building blocks.
-Any plugin can exist at multiple different mount paths. Different versions of a
-plugin may be at each location, with each version differing from Vault's
-version.
+Vault supports 3 types of plugins; auth methods, secret engines, and database
+plugins. This concept allows both built-in and external plugins to be treated
+like building blocks. Any plugin can exist at multiple different mount paths.
+Different versions of a plugin may be at each location, with each version differing
+from Vault's version.
-## Built-In Plugins
+A plugin is uniquely identified by its type (one of `secret`, `auth`, or
+`database`), name (e.g. `aws`), and version (e.g `v1.0.0`). An empty version
+implies either the built-in plugin or the single unversioned plugin that can
+be registered.
+
+See [Plugin Upgrade Procedure](/docs/upgrading/plugins#plugin-upgrade-procedure)
+for details on how to upgrade a built-in plugin in-place.
-Built-in plugins are shipped with Vault, often for commonly used implementations,
-and require no additional operator intervention to run. Built-in plugins are
-just like any other backend code inside Vault.
+## Built-In Plugins
-To use a different or edited version of a built-in plugin, the plugin must be
-run as an external plugin. See [Overriding Built-in Plugins](/docs/upgrading/plugins#overriding-built-in-plugins)
-for details on how to override a built-in plugin in-place.
+Built-in plugins are shipped with Vault, often for commonly used integrations,
+and can be used without any prerequisite steps.
## External Plugins
@@ -33,8 +36,48 @@ binaries can be obtained from [releases.hashicorp.com](https://releases.hashicor
or they can be [built from source](/docs/plugins/plugin-development#building-a-plugin-from-source).
Vault's external plugins are completely separate, standalone applications that
-Vault executes and communicates with over RPC. Each time a Vault secret engine
-or auth method is mounted, a new process is spawned. However, plugins can be
-made to implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing)
+Vault executes and communicates with over RPC. Each time a Vault secret engine,
+auth method, or database plugin is mounted, a new process is spawned. However,
+plugins can be made to implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing)
to improve performance. Plugin multiplexing allows plugin processes to be
reused across all mounts of a given type.
+
+## Plugin Versioning
+
+Vault supports managing, running and upgrading plugins using semantic version
+information.
+
+The plugin catalog optionally supports specifying a semantic version when
+registering an external plugin. Multiple versions of a plugin can be registered
+in the catalog simultaneously, and a version can be selected when mounting a
+plugin or tuning an existing mount in-place.
+
+If no version is specified when creating a new mount, the following precedence is used
+for any available plugins whose type and name match:
+
+* The plugin registered with no version
+* The plugin with the most recent semantic version among any registered versions
+* The plugin built into Vault
+
+### Built-In Versions
+
+Vault will report a version for built-in plugins to indicate what version of the
+plugin code got built into Vault as a dependency. For example:
+
+```shell-session
+$ vault plugin list secret
+Name Version
+---- -------
+ad v0.14.0+builtin
+alicloud v0.13.0+builtin
+aws v1.12.0+builtin.vault
+# ...
+```
+
+Here, Vault has a dependency on `v0.14.0` of the [hashicorp/vault-plugin-secrets-ad](https://github.com/hashicorp/vault-plugin-secrets-ad)
+repo, and the `vault` metadata identifier for `aws` indicates that plugin's code was
+within the Vault repo. For plugins within the Vault repo, Vault's own major, minor,
+and patch versions are used to form the plugin version.
+
+The `builtin` metadata identifier is reserved and cannot be used when registering
+external plugins.
website/content/docs/interoperability-matrix.mdx+85 0
@@ -0,0 +1,85 @@
+---
+layout: docs
+page_title: Vault Interoperability Matrix
+description: Guide to viewing which partners Vault integrates with.
+---
+
+# Vault Interoperability Matrix
+
+Vault integrates with various appliances, platforms and applications for different use cases. Below are two tables indicating the partner’s product that has been verified to work with Vault for [Auto Unsealing](/docs/concepts/seal#auto-unseal) / [HSM Support](/docs/enterprise/hsm) and [External Key Management](/use-cases/key-management).
+
+Auto Unseal and HSM Support was developed to aid in reducing the operational complexity of keeping the unseal key secure. This feature delegates the responsibility of securing the unseal key from users to a trusted device or service. At startup Vault will connect to the device or service implementing the seal and ask it to decrypt the root key Vault read from storage.
+
+Vault centrally manages and automates encryption keys across environments allowing customers to control their own encryption keys used in third party services or products.
+
+## Vault Seal and HSM Interoperability
+
+The below table shows the partner product and if the partner’s technology works with each individual seal component.
+
+| Partner | Product | Auto Unseal <br/> (Vault 0.9+) | Entropy Augmentation <br/>(Vault 1.3+) | Seal Wrap <br/>(Vault 0.9+) | Managed Keys <br/> (Vault 1.10+) | Min. Vault Version Verified |
+| ----------------- | -------------------------------------- | ------------ | -------------------- | ------------ |-------------- | --------------------------- |
+| AliCloud | AliCloud KMS | Yes | No | Yes | No | 0.11.2 |
+| Atos | Trustway Proteccio HSM | Yes | Yes | Yes | No | 1.9 |
+| AWS | AWS KMS | Yes | No | Yes | Yes | 0.9 |
+| Crypto4a | QxEDGE™️ HSP | Yes | Yes | Yes | Yes | 1.9 |
+| Entrust | nShield HSM | Yes | Yes | Yes | Yes | 1.3 |
+| Fortanix | FX2200 Series | Yes | Yes | Yes | No | 0.10 |
+| FutureX | Vectera Plus, KMES Series 3 | Yes | Yes | Yes | Yes | 1.5 |
+| FutureX | VirtuCrypt cloud HSM | Yes | Yes | Yes | Yes | 1.5 |
+| Google | GCP Cloud KMS | Yes | No | Yes | Yes | 0.9 |
+| Microsoft | Azure Key Vault | Yes | No | Yes | Yes | 0.10.2 |
+| Oracle | OCI KMS | Yes | No | Yes | No | 1.2.3 |
+| PrimeKey | SignServer Hardware Appliance | Yes | Yes | Yes | No | 1.6 |
+| Qrypt | Quantum Entropy Service | No | Yes | No | No | 1.11 |
+| Quintessence Labs | TSF 400 | Yes | Yes | Yes | No | 1.4 |
+| Securosys SA | Primus HSM | Yes | Yes | Yes | Yes | 1.7 |
+| Thales | Luna HSM | Yes | Yes | Yes | Yes | 1.4 |
+| Thales | Luna TCT HSM | Yes | Yes | Yes | Yes | 1.4 |
+| Thales | CipherTrust Manager | Yes | Yes | Yes | No | 1.7 |
+| Utimaco | HSM | Yes | Yes | Yes | Yes | 1.4 |
+| Yubico | YubiHSM 2 | Yes | Yes | Yes | No | 1.5 |
+<span style={{display:'block', textAlign:'right', fontSize:'12px'}}><em>Last Updated September 29, 2022</em></span>
+
+## Vault as an External Key Management System (EKMS)
+
+Partners who integrate with Vault to have Vault store and/or manage encryption keys with their products
+
+~> Note: HCP Vault Verified means that the integration has been verified to work with HCP Vault. All integrations have been verified with Vaut self-managed.
+
+<span style={{fontSize:'12px'}}>
+Vault Secrets Engine Key: K/V = <a href="/docs/secrets/kv">K/V secrets engine</a>; KMSE = <a href="/docs/secrets/key-management">Key Management Secrets Engine</a>; KMIP = <a href="/docs/secrets/kmip">KMIP Secrets Engine</a>; Transit = <a href="/docs/secrets/transit">Transit Secrets Engine</a>
+</span>
+
+| Partner | Product | Vault Secrets Engine | Min. Vault Version Verified | HCP Vault Verified |
+| ----------------- | ---------------------- | -------------------- | --------------------------- | ------------------- |
+| AWS | AWS KMS | KMSE | 1.8 | Yes |
+| Baffle | Shield | K/V | 1.3 | No |
+| Bloombase | StoreSafe | KMIP | 1.9 | N/A |
+| Cockroach Labs | Cockroach Cloud DB | KMSE | 1.10 | N/A |
+| Cockroach Labs | Cockroach DB | Transit | 1.10 | Yes |
+| Commvault Systems | CommVault | KMIP | 1.9 | N/A |
+| Cribl | Cribl Stream | K/V | 1.8 | Yes |
+| DataStax | DataStax Enterprise | KMIP | 1.11 | Yes |
+| Garantir | GaraSign | Transit | 1.5 | Yes |
+| Google | Google KMS | KMSE | 1.9 | N/A |
+| HPE | Exmeral Data Fabric | KMIP | 1.2 | N/A |
+| Intel | Key Broker Service | KMIP | 1.11 | N/A |
+| Micro Focus | Connected Mx | Transit | 1.7 | No |
+| Microsoft | Azure Key Vault | KMSE | 1.6 | N/A |
+| MinIO | Key Encryption Service | K/V | 1.11 | No |
+| MongoDB | Atlas | KMSE | 1.6 | N/A |
+| MongoDB | MongoDB Enterprise | KMIP | 1.2 | N/A |
+| MongoDB | Client Libraries | KMIP | 1.9 | N/A |
+| NetApp | ONTAP | KMIP | 1.2 | N/A |
+| Ondat | Trousseau | Transit | 1.9 | Yes |
+| Percona | Server 8.0 | KMIP | 1.9 | N/A |
+| Percona | XtraBackup 8.0 | KMIP | 1.9 | N/A |
+| Snowflake | Snowflake | KMSE | 1.6 | N/A |
+| VMware | vSphere 7.0 | KMIP | 1.2 | N/A |
+| VMware | vSan | KMIP | 1.2 | N/A |
+| Yugabyte | Yugabyte Platform | Transit | 1.9 | No |
+<span style={{display:'block', textAlign:'right', fontSize:'12px'}}><em>Last Updated September 29, 2022</em></span>
+
+Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) if there are any questions on the above tables.
+
+Missing an integration? Join the [Vault Integration Program](/docs/partnerships) and get the integration listed.
website/content/docs/secrets/databases/redis.mdx+126 0
@@ -0,0 +1,126 @@
+---
+layout: docs
+page_title: Redis - Database - Secrets Engines
+description: |-
+ Redis is one of the supported plugins for the database secrets engine.
+ This plugin generates database credentials dynamically based on configured
+ roles for the Redis database, and also supports [Static Roles](https://developer.hashicorp.com/vault/docs/secrets/databases#static-roles).
+---
+
+# Redis Database Secrets Engine
+
+Redis is one of the supported plugins for the database secrets engine. This
+plugin generates database credentials dynamically based on configured roles for
+the Redis database.
+
+See the [database secrets engine](/docs/secrets/databases) docs for
+more information about setting up the database secrets engine.
+
+## Capabilities
+
+| Plugin Name | Root Credential Rotation | Dynamic Roles | Static Roles | Username Customization |
+| --------------------------- | ------------------------ | ------------- | ------------ | ---------------------- |
+| `redis-database-plugin` | Yes | Yes | Yes | No |
+
+## Setup
+
+1. Enable the database secrets engine if it is not already enabled:
+
+ ```shell-session
+ $ vault secrets enable database
+ Success! Enabled the database secrets engine at: database/
+ ```
+
+ By default, the secrets engine will enable at the name of the engine. To
+ enable the secrets engine at a different path, use the `-path` argument.
+
+1. Configure Vault with the proper plugin and connection configuration:
+
+ ```shell-session
+ $ vault write database/config/my-redis-database \
+ plugin_name="redis-database-plugin" \
+ host="localhost" \
+ port=6379 \
+ tls=true \
+ ca_cert="$CACERT"
+ username="user" \
+ password="pass" \
+ allowed_roles="my-*-role"
+ ```
+
+1. You should consider rotating the admin password. Note that if you do, the
+ new password will never be made available through Vault, so you should
+ create a Vault-specific database admin user for this.
+
+ ```shell-session
+ vault write -force database/rotate-root/my-redis-database
+ ```
+
+## Usage
+
+After the secrets engine is configured, write dynamic and static roles
+to Vault to enable generating credentials.
+
+### Dynamic roles
+
+1. Configure a dynamic role that maps a name in Vault to a JSON string
+ containing the Redis ACL rules, which are either documented [here](https://redis.io/commands/acl-cat) or in the output
+ of the `ACL CAT` Redis command.
+
+ ```shell-session
+ $ vault write database/roles/my-dynamic-role \
+ db_name="my-redis-database" \
+ creation_statements='["+@admin"]' \
+ default_ttl="5m" \
+ max_ttl="1h"
+ Success! Data written to: database/roles/my-dynamic-role
+ ```
+
+ Note that if a creation_statement is not provided the user account will
+ default to a read only user, `'["~*", "+@read"]'` that can read any key.
+
+1. Generate a new set of credentials by reading from the `/creds` endpoint with the name
+ of the role:
+
+ ```shell-session
+ $ vault read database/creds/my-dynamic-role
+ Key Value
+ --- -----
+ lease_id database/creds/my-dynamic-role/OxCTXJcxQ2F4lReWPjbezSnA
+ lease_duration 5m
+ lease_renewable true
+ password dACqHsav6-attdv1glGZ
+ username V_TOKEN_MY-DYNAMIC-ROLE_YASUQUF3GVVD0ZWTEMK4_1608481717
+ ```
+
+### Static roles
+
+1. Configure a static role that maps a name in Vault to an existing Redis
+ user.
+
+ ```shell-session
+ $ vault write database/static-roles/my-static-role \
+ db_name="my-redis-database" \
+ username="my-existing-redis-user" \
+ rotation_period=5m
+ Success! Data written to: database/static-roles/my-static-role
+ ```
+
+1. Retrieve the credentials from the `/static-creds` endpoint:
+
+ ```shell-session
+ $ vault read database/static-creds/my-static-role
+ Key Value
+ --- -----
+ last_vault_rotation 2020-12-20T10:39:49.647822-06:00
+ password ylKNgqa3NPVAioBf-0S5
+ rotation_period 5m
+ ttl 4m39s
+ username my-existing-redis-user
+ ```
+
+## API
+
+The full list of configurable options can be seen in the [Redis Database Plugin API](/api-docs/secret/databases/redis) page.
+
+For more information on the database secrets engine's HTTP API please see the [Database Secrets Engine API](/api-docs/secret/databases) page.
website/content/docs/commands/secrets/list.mdx+27 11
@@ -17,34 +17,48 @@ that the system default is in use.
## Deprecation Status Column
-As of 1.12, all builtin secrets engines will have an associated Deprecation
+As of 1.12, all built-in secrets engines will have an associated Deprecation
Status. This status will be reflected in the `Deprecation Status` column, seen
-below. All secrets engines which are not provided by builtin plugins will show a
+below. All secrets engines which are not provided by built-in plugins will show a
`Deprecation Status` of "n/a".
+## Version Columns
+
+The `-detailed` view displays some version information for each mount.
+
+The Version field indicates the configured version for the plugin. Empty, or "n/a",
+indicates the built-in or any matching unversioned plugin that may have been registered.
+
+Running Version indicates the actual plugin version running, which may differ from
+Version if the plugin hasn't been reloaded since the configured version was updated
+using the `secrets tune` command. Finally, the Running SHA256 field indicates the
+SHA256 sum of the running plugin's binary. This may be different from the SHA256
+registered in the catalog if the plugin hasn't been reloaded since the plugin
+version was overwritten in the catalog.
+
## Examples
List all enabled secrets engines:
```shell-session
$ vault secrets list
-Path Type Description
-cubbyhole/ cubbyhole per-token private secret storage
-secret/ kv key/value secret storage
-sys/ system system endpoints used for control, policy and debugging
+Path Type Accessor Description
+---- ---- -------- -----------
+cubbyhole/ cubbyhole cubbyhole_548b4dc5 per-token private secret storage
+secret/ kv identity_aa00c06d key/value secret storage
+sys/ system system_547412e3 system endpoints used for control, policy and debugging
```
List all enabled secrets engines with detailed output:
```shell-session
$ vault secrets list -detailed
-Path Plugin Accessor Default TTL Max TTL Force No Cache Replication Seal Wrap External Entropy Access Options Description UUID Deprecation Status
-cubbyhole/ cubbyhole cubbyhole_b16d1bc0 n/a n/a false local false false map[] per-token private secret storage 8c64d56b-9d46-d667-1155-a8c1a83a5d01 n/a
-identity/ identity identity_3d67c936 system system false replicated false false map[] identity store 5aa1e59c-33b5-9dec-05d6-c80c9a800557 n/a
-postgresql/ postgresql postgresql_f0a54308 system system false replicated false false map[] n/a 8cdc1d2d-0713-eaa6-17e3-49790a60650b deprecated
-sys/ system system_c86bd362 n/a n/a false replicated true false map[] system endpoints used for control, policy and debugging e3193999-0875-d38d-3458-21d9f2762c80 n/a
+Path Plugin Accessor Default TTL Max TTL Force No Cache Replication Seal Wrap External Entropy Access Options Description UUID Version Running Version Running SHA256 Deprecation Status
+---- ------ -------- ----------- ------- -------------- ----------- --------- ----------------------- ------- ----------- ---- ------- --------------- -------------- ------------------
+cubbyhole/ cubbyhole cubbyhole_b16d1bc0 n/a n/a false local false false map[] per-token private secret storage 8c64d56b-9d46-d667-1155-a8c1a83a5d01 n/a v1.12.0+builtin.vault n/a n/a
+identity/ identity identity_3d67c936 system system false replicated false false map[] identity store 5aa1e59c-33b5-9dec-05d6-c80c9a800557 n/a v1.12.0+builtin.vault n/a n/a
+postgresql/ postgresql postgresql_f0a54308 system system false replicated false false map[] n/a 8cdc1d2d-0713-eaa6-17e3-49790a60650b n/a v1.12.0+builtin.vault n/a deprecated
+sys/ system system_c86bd362 n/a n/a false replicated true false map[] system endpoints used for control, policy and debugging e3193999-0875-d38d-3458-21d9f2762c80 n/a v1.12.0+builtin.vault n/a n/a
```
## Usage
website/content/docs/partnerships.mdx+21 11
@@ -16,9 +16,11 @@ This program is intended to be largely a self-service process with links and gui
Vault is an Identity-based security solution that leverages trusted sources of identity to keep secrets and application data secured with one centralized, audited workflow for tightly controlling access to secrets across applications, systems, and infrastructure while encrypting data both in flight and at rest. For a full description of the current features please refer to the Vault [website](/).
-Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. This means the plugin process does not share the same memory space as Vault and therefore can only access the interfaces and arguments given to it.
+There are two main types of integrations with Vault. The first is Runtime Integrations which use Vault as part of a workflow. Many partners have integrations that use existing Vault deployments to retrieve various types of secrets for use in a partner’s application or platform. The use cases can range from Vault storing and providing secrets, issuing or managing PKI certificates or acting as an external key management system.
-Vault plugins can be built-in and bundled with the Vault binary, or be external that has to be manually mounted. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugin-portal).
+The second type is where a partner develops a custom plugin. Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC.
+
+Plugins can be broken into two categories, Secrets Engines and Auth Methods. They can be built-in and bundled with the Vault binary, or be external that has to be manually registered. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugins/plugin-portal).
The diagram below depicts the key Vault integration categories and types.
@@ -26,21 +28,29 @@ The diagram below depicts the key Vault integration categories and types.
Main Vault categories for partners to integrate with include:
-**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models to better support your business use case. You can find more information about Vault Auth Methods [here](/docs/auth/).
+**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models and partners can build a plugin that allows Vault to authenticate against the partners’ platform. You can find more information about Vault Auth Methods [here](/docs/auth/).
-**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing customer deployments of Vault and the partner’s solution.
+**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing deployments of Vault and the partner’s product as part of the customer's identity/security workflow.
-HSM (Hardware Security Module) are specific types of runtime integrations and provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol, thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault's HSM support [here](/docs/enterprise/hsm).
+Oftentimes these integrations involve modifying a partner’s product to become “Vault aware”. There are two main components that need to be considered for this type of integration:
+1. How is the application going to authenticate itself to Vault?
+1. Support of Namespaces
--> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
+There are many ways for an application to authenticate itself to Vault (see [Auth Methods](/docs/auth/)), but we recommend partners use one of the following methods: [AppRole](/docs/auth/approle), [JWT / OIDC](/docs/auth/jwt), [TLS Certificates](/docs/auth/cert) or [Username / Password](/docs/auth/userpass). For an integration to be verified as production ready by HashiCorp, there needs to be at least one other Auth method supported besides [Token](/docs/auth/token). Token is not recommended for use in production since it involves creating a manual long lived token (which is against best practice and poses a security risk). Using one of the above mentioned auth methods automatically creates short lived tokens and eliminates the need to manually generate a new token on a regular basis.
+
+As the number of customers using Vault Enterprise increases, partners are encouraged to support [Namespaces](https://learn.hashicorp.com/tutorials/vault/namespaces). By supporting Namespaces, there is an additional benefit that an integration should be able to work with HCP Vault.
+
+HSM (Hardware Security Module) are specific types of runtime integrations and can be configured to work with new or existing Vault deployments. They provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault’s HSM support [here](/docs/enterprise/hsm). A list of HSMs that have been verified to work with Vault is shown in our [interoperability matrix](/docs/interoperability-matrix).
**Audit/Monitoring & Compliance**: Audit/Monitoring and Compliance are components in Vault that keep a detailed log of all requests and responses to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors. Vault supports multiple audit devices to support your business use case. You can find more information about Vault Audit Devices [here](/docs/audit/).
-**Secrets Engines**: Secrets engines are plugin components which store, generate, or encrypt data. Secrets engines are provided with some set of data that perform actions on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, and secrets engines connect to other services. Examples of secrets engines include identity modules of Cloud providers like AWS, Azure IAM models, Cloud (LDAP), database or key management. You can find more information about Vault secrets engines [here](/docs/secrets/).
+**Secrets Engines**: Secrets engines are plugin components which store, generate, or encrypt data. Secrets engines are provided with some set of data, that take some action on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, other secrets engines connect to other services. Examples of Secrets Engines include identity modules of Cloud providers like AWS, Azure IAM models, Cloud (LDAP), database or certificate management. You can find more information about Vault Secrets Engines [here](/docs/secrets/).
+
+-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
### HCP Vault
-HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault.
+HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault Enterprise, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault.
Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](https://learn.hashicorp.com/collections/vault/cloud) learn guide for quickly getting started.
@@ -150,9 +160,9 @@ Once the integration has been verified, the partner is requested to sign the Has
At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration.
-For Auth or Secret Engine plugins specifically, once the plugin has been validated by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
+For Auth or Secret Engine plugins specifically, once the plugin has been verified by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugins/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
-For HCP Vault validations, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page.
+For HCP Vault verifications, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page.
### 6. Support
@@ -174,4 +184,4 @@ Below is a checklist of steps that should be followed during the Vault integrati
## Contact Us
-For any questions or feedback, please contact us at: [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com)
+For any questions or feedback, please contact us at: [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com)
website/content/docs/secrets/kmip.mdx+9 8
@@ -3,7 +3,7 @@ layout: docs
page_title: KMIP - Secrets Engines
description: |-
The KMIP secrets engine allows Vault to act as a KMIP server provider and
- handle the lifecycle of it KMIP managed objects.
+ handle the lifecycle of its KMIP managed objects.
---
# KMIP Secrets Engine
@@ -25,12 +25,9 @@ Vault's KMIP secrets engine listens on a separate port from the standard Vault l
Vault implements version 1.4 of the following Key Management Interoperability Protocol Profiles:
* [Baseline Server][baseline-server]
- * Supports all profile attributes except for *Alternative Name*, *Key Value Present* and
- *Key Value Location*.
- * Supports all profile operations except for *Check*, *Modify Attribute* and *Delete Attribute*.
- * Operation *Locate* only supports attributes *Activation Date*, *Application
- Specific Information*, *Cryptographic Algorithm*, *Cryptographic Length*,
- *Name*, *Object Type*, *Original Creation Date*, and *State*.
+ * Supports all profile attributes except for *Key Value Location*.
+ * Supports all profile operations except for *Check*.
+ * Operation *Locate* supports all profile attributes except for *Key Value Location*.
* [Symmetric Key Lifecycle Server][lifecycle-server]
* Supports cryptographic algorithm *AES* (*3DES* is not supported).
@@ -38,9 +35,11 @@ Vault implements version 1.4 of the following Key Management Interoperability Pr
* [Basic Cryptographic Server][basic-cryptographic-server]
* Supports block cipher modes *CBC*, *CFB*, *CTR*, *ECB*, *GCM*, and *OFB*.
- * On mulit-part (streaming) operations, block cipher mode *GCM* is not supported.
+ * On multi-part (streaming) operations, block cipher mode *GCM* is not supported.
* The supported padding methods are *None* and *PKCS5*.
+Refer to [KMIP - Profiles Support](/docs/secrets/kmip-profiles) page for more details.
+
[baseline-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431430
[lifecycle-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431487
[basic-cryptographic-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431527
@@ -102,6 +101,7 @@ operation_activate
operation_add_attribute
operation_create
operation_decrypt
+operation_delete_attribute
operation_destroy
operation_discover_versions
operation_encrypt
@@ -110,6 +110,7 @@ operation_get_attribute_list
operation_get_attributes
operation_import
operation_locate
+operation_modify_attribute
operation_query
operation_register
operation_rekey
website/content/docs/configuration/storage/index.mdx+1 1
@@ -79,7 +79,7 @@ Consul.
| Data location | Data is on disk. | All data is in memory. |
| System requirements | [System requirements](https://learn.hashicorp.com/tutorials/vault/raft-reference-architecture#system-requirements) | [System requirements](https://learn.hashicorp.com/tutorials/vault/reference-architecture#hardware-sizing-for-vault-servers) |
| Snapshots | Normal data backup strategy of your organization. | More frequent snapshots are necessary since data is in memory. |
-| Max message size | 1 MiB (Configurable using the [`max_entry_size`](/docs/configuration/storage/raft#max_entry_size) parameter) | 512 KiB (Configurable using the [`kv_max_value_size`](https://www.consul.io/docs/agent/options#kv_max_value_size) parameter) |
+| Max message size | 1 MiB (Configurable using the [`max_entry_size`](/docs/configuration/storage/raft#max_entry_size) parameter) | 512 KiB (Configurable using the [`kv_max_value_size`](https://www.consul.io/docs/agent/config/config-files#kv_max_value_size) parameter) |
If you have a Vault cluster using Consul as its storage backend and wish to
migrate to Integrated Storage, read the following tutorials:
website/content/docs/commands/auth/list.mdx+16 2
@@ -13,11 +13,25 @@ enabled auth methods and options for those methods.
## Deprecation Status Column
-As of 1.12, all builtin auth engines will have an associated Deprecation
+As of 1.12, all built-in auth engines will have an associated Deprecation
Status. This status will be reflected in the `Deprecation Status` column, seen
-below. All auth engines which are not provided by builtin plugins will show a
+below. All auth engines which are not provided by built-in plugins will show a
`Deprecation Status` of "n/a".
+## Version Columns
+
+The `-detailed` view displays some version information for each mount.
+
+The Version field indicates the configured version for the plugin. Empty, or "n/a",
+indicates the built-in or any matching unversioned plugin that may have been registered.
+
+Running Version indicates the actual plugin version running, which may differ from
+Version if the plugin hasn't been reloaded since the configured version was updated
+using the `secrets tune` command. Finally, the Running SHA256 field indicates the
+SHA256 sum of the running plugin's binary. This may be different from the SHA256
+registered in the catalog if the plugin hasn't been reloaded since the plugin
+version was overwritten in the catalog.
+
## Examples
List all auth methods:
website/content/docs/commands/plugin/index.mdx+25 17
@@ -13,35 +13,40 @@ the plugin catalog
## Examples
-List all available plugins in the catalog:
+List all available secret plugins in the catalog:
```shell-session
-$ vault plugin list
+$ vault plugin list secret
-Plugins
-my-custom-plugin
-# ...
+Name Version
+---- -------
+ad v0.14.0+builtin
+alicloud v0.13.0+builtin
+...
```
-Register a new plugin to the catalog:
+Register a new secret plugin to the catalog:
```shell-session
$ vault plugin register \
-sha256=d3f0a8be02f6c074cf38c9c99d4d04c9c6466249 \
- my-custom-plugin
+ secret my-custom-plugin
Success! Registered plugin: my-custom-plugin
```
Get information about a plugin in the catalog:
```shell-session
-$ vault plugin info my-custom-plugin
-Key Value
-command my-custom-plugin
-name my-custom-plugin
-sha256 d3f0a8be02f6c074cf38c9c99d4d04c9c6466249
+$ vault plugin info secret my-custom-plugin
+Key Value
+--- -----
+args []
+builtin false
+command my-custom-plugin
+deprecation_status n/a
+name my-custom-plugin
+sha256 33e72f3d30ff2acdbf3cf3c8fa1c8945b60dab876c4226ab25617a63c9f16cc5
+version n/a
```
## Usage
@@ -52,11 +57,12 @@ Usage: vault plugin <subcommand> [options] [args]
# ...
Subcommands:
- deregister Deregister an existing plugin in the catalog
- info Read information about a plugin in the catalog
- list Lists available plugins
- register Registers a new plugin in the catalog
- reload Reload mounted plugin backend
+ deregister Deregister an existing plugin in the catalog
+ info Read information about a plugin in the catalog
+ list Lists available plugins
+ register Registers a new plugin in the catalog
+ reload Reload mounted plugin backend
+ reload-status Get the status of an active or recently completed global plugin reload
```
For more information, examples, and usage about a subcommand, click on the name
website/content/partials/ent-supported-storage.mdx+3 0
@@ -0,0 +1,3 @@
+For enterprise customers, HashiCorp provides official support for Consul and Vault's Integrated Storage as storage backends. Vault Enterprise will
+no longer startup if configured to use a storage backend other than Consul or Integrated Storage. This is meant to protect against issues caused by using
+unsupported backends that do not support transactional storage.
website/content/docs/auth/jwt/index.mdx+46 40
@@ -140,15 +140,20 @@ EOF
```
- Monitor Vault's log output. Important information about OIDC validation failures will be emitted.
+
- Ensure Redirect URIs are correct in Vault and on the provider. They need to match exactly. Check:
http/https, 127.0.0.1/localhost, port numbers, whether trailing slashes are present.
+
- Start simple. The only claim configuration a role requires is `user_claim`. After authentication is
known to work, you can add additional claims bindings and metadata copying.
+
- `bound_audiences` is optional for OIDC roles and typically not required. OIDC providers will use
the client_id as the audience and OIDC validation expects this.
+
- Check your provider for what scopes are required in order to receive all
of the information you need. The scopes "profile" and "groups" often need to be
requested, and can be added by setting `oidc_scopes="profile,groups"` on the role.
+
- If you're seeing claim-related errors in logs, review the provider's docs very carefully to see
how they're naming and structuring their claims. Depending on the provider, you may be able to
construct a simple `curl` implicit grant request to obtain a JWT that you can inspect. An example
@@ -161,6 +166,7 @@ EOF
be helpful when debugging provider setup and verifying that the received claims are what you expect.
Since claims data is logged verbatim and may contain sensitive information, this option should not be
used in production.
+
- Azure requires some additional configuration when a user is a member of more
than 200 groups, described in [Azure-specific handling
configuration](/docs/auth/jwt/oidc-providers/azuread#optional-azure-specific-configuration)
@@ -231,46 +237,46 @@ Auth methods must be configured in advance before users or machines can
authenticate. These steps are usually completed by an operator or configuration
management tool.
-1. Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The
- backend will be mounted at the chosen name.
-
- ```text
- $ vault auth enable jwt
- or
- $ vault auth enable oidc
- ```
-
-1. Use the `/config` endpoint to configure Vault. To support JWT roles, either local keys, a JWKS URL, or an OIDC
- Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the
- list of available configuration options, please see the [API documentation](/api-docs/auth/jwt).
-
- ```text
- $ vault write auth/jwt/config \
- oidc_discovery_url="https://myco.auth0.com/" \
- oidc_client_id="m5i8bj3iofytj" \
- oidc_client_secret="f4ubv72nfiu23hnsj" \
- default_role="demo"
- ```
-
-1. Create a named role:
-
- ```text
- vault write auth/jwt/role/demo \
- allowed_redirect_uris="http://localhost:8250/oidc/callback" \
- bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
- bound_audiences="https://vault.plugin.auth.jwt.test" \
- user_claim="https://vault/user" \
- groups_claim="https://vault/groups" \
- policies=webapps \
- ttl=1h
- ```
-
- This role authorizes JWTs with the given subject and audience claims, gives
- it the `webapps` policy, and uses the given user/groups claims to set up
- Identity aliases.
-
- For the complete list of configuration options, please see the API
- documentation.
+1. Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The
+ backend will be mounted at the chosen name.
+
+ ```text
+ $ vault auth enable jwt
+ or
+ $ vault auth enable oidc
+ ```
+
+1. Use the `/config` endpoint to configure Vault. To support JWT roles, either local keys, a JWKS URL, or an OIDC
+ Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the
+ list of available configuration options, please see the [API documentation](/api-docs/auth/jwt).
+
+ ```text
+ $ vault write auth/jwt/config \
+ oidc_discovery_url="https://myco.auth0.com/" \
+ oidc_client_id="m5i8bj3iofytj" \
+ oidc_client_secret="f4ubv72nfiu23hnsj" \
+ default_role="demo"
+ ```
+
+1. Create a named role:
+
+ ```text
+ vault write auth/jwt/role/demo \
+ allowed_redirect_uris="http://localhost:8250/oidc/callback" \
+ bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
+ bound_audiences="https://vault.plugin.auth.jwt.test" \
+ user_claim="https://vault/user" \
+ groups_claim="https://vault/groups" \
+ policies=webapps \
+ ttl=1h
+ ```
+
+ This role authorizes JWTs with the given subject and audience claims, gives
+ it the `webapps` policy, and uses the given user/groups claims to set up
+ Identity aliases.
+
+ For the complete list of configuration options, please see the API
+ documentation.
### Bound Claims
website/content/docs/concepts/storage.mdx+2 2
@@ -80,7 +80,7 @@ components of that plan.
Backups and restores are ideally performed while Vault is offline. If offline
backups are not feasible, we recommend using a storage backend that supports
atomic snapshots (such as
-[Consul](https://www.consul.io/docs/commands/snapshot.html) or [Integrated
+[Consul](https://www.consul.io/commands/snapshot) or [Integrated
Storage](/docs/commands/operator/raft#snapshot)).
~> If your storage backend does not support atomic snapshots, we recommend only
@@ -92,7 +92,7 @@ other storage backends, follow the documentation of that backend for taking and
restoring backups.
- Integrated Storage [snapshots](/docs/commands/operator/raft#snapshot)
-- Consul [snapshots](https://www.consul.io/docs/commands/snapshot.html)
+- Consul [snapshots](https://www.consul.io/commands/snapshot)
#### Backing up Multiple Clusters
More files changed — see the full commit.

Release delta 1.13.0 → 1.13.3 (contains the fix)

· Mar 1, 2023, 08:22 PM+1753390compare
website/content/api-docs/secret/databases/postgresql.mdx+6 5
@@ -27,11 +27,12 @@ has a number of parameters to further configure a connection.
- `connection_url` `(string: <required>)` - Specifies the PostgreSQL DSN. This field
can be templated and supports passing the username and password
parameters in the following format `{{field_name}}`. Certificate authentication
- can be used by setting `?sslinline=true` and giving the SSL credentials in the
- `sslrootcert`, `sslcert` and `sslkey` credentials. A templated connection URL
- is required when using root credential rotation. This field supports both format
- string types, URI and keyword/value. Both formats support multiple host connection
- strings.
+ can be used by setting `?sslmode=` to be any of the applicable values as outlined in
+ the [Postgres SQL documentation](https://www.postgresql.org/docs/11/libpq-ssl.html#LIBPQ-SSL-PROTECTION)
+ and giving the SSL credentials in the `sslrootcert`, `sslcert` and `sslkey` credentials.
+ A templated connection URL is required when using root credential rotation. This field
+ supports both format string types, URI and keyword/value. Both formats support multiple
+ host connection strings.
- `max_open_connections` `(int: 4)` - Specifies the maximum number of open
connections to the database.
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
3dbe94678ffefe8295d196f0e8e633a2f9eeb1fd (#19675)
website/content/docs/enterprise/pkcs11-provider/index.mdx | 3 +++
1 file changed, 3 insertions(+)
website/content/docs/configuration/listener/tcp.mdx+7 0
@@ -133,6 +133,13 @@ default value in the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/co
`tls_min_version` and `tls_max_version` parameters) are widely considered
insecure.
+- `tls_max_version` `(string: "tls13")` – Specifies the maximum supported
+ version of TLS. Accepted values are "tls10", "tls11", "tls12" or "tls13".
+
+~> **Warning**: TLS 1.1 and lower (`tls10` and `tls11` values for the
+ `tls_min_version` and `tls_max_version` parameters) are widely considered
+ insecure.
+
- `tls_cipher_suites` `(string: "")` – Specifies the list of supported
ciphersuites as a comma-separated-list. The list of all available ciphersuites
is available in the [Golang TLS documentation][golang-tls].
version/version_base.go | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
website/content/partials/tokenization-rotation-persistence.mdx+14 0
@@ -0,0 +1,14 @@
+### Rotation configuration persistence issue could lose Transform Tokenization key versions
+
+A rotation performed manually or via automatic time based rotation after
+restarting or leader change of Vault, where configuration of rotation was
+changed since the initial configuration of the tokenization transform can
+result in the loss of intermediate key versions. Tokenized values from
+these versions would not be decodeable. It is recommended that customers
+who have enabled automatic rotation disable it, and other customers avoid
+key rotation until the upcoming fix.
+
+#### Affected Versions
+
+This issue affects Vault Enterprise with ADP versions 1.10.x and higher. A
+fix will be released in Vault 1.11.9, 1.12.5, and 1.13.1.
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
1fb765d61a9ac0081094d3ae92fda8e329cd0379 (#19559)
changelog/19545.txt | 3 +++
go.mod | 2 +-
go.sum | 4 ++--
3 files changed, 6 insertions(+), 3 deletions(-)
create mode 100644 changelog/19545.txt
ui/tests/acceptance/enterprise-oidc-namespace-test.js+91 0
@@ -0,0 +1,91 @@
+import { visit, currentURL } from '@ember/test-helpers';
+import { module, test } from 'qunit';
+import { setupApplicationTest } from 'ember-qunit';
+import { create } from 'ember-cli-page-object';
+import { setupMirage } from 'ember-cli-mirage/test-support';
+import parseURL from 'core/utils/parse-url';
+import consoleClass from 'vault/tests/pages/components/console/ui-panel';
+import authPage from 'vault/tests/pages/auth';
+
+const shell = create(consoleClass);
+
+const createNS = async (name) => {
+ await shell.runCommands(`write sys/namespaces/${name} -force`);
+};
+const SELECTORS = {
+ authTab: (path) => `[data-test-auth-method="${path}"] a`,
+};
+
+module('Acceptance | Enterprise | oidc auth namespace test', function (hooks) {
+ setupApplicationTest(hooks);
+ setupMirage(hooks);
+
+ hooks.beforeEach(async function () {
+ this.namespace = 'test-ns';
+ this.rootOidc = 'root-oidc';
+ this.nsOidc = 'ns-oidc';
+
+ this.server.post(`/auth/:path/config`, () => {});
+
+ this.enableOidc = (path, role = '') => {
+ return shell.runCommands([
+ `write sys/auth/${path} type=oidc`,
+ `write auth/${path}/config default_role="${role}" oidc_discovery_url="https://example.com"`,
+ // show method as tab
+ `write sys/auth/${path}/tune listing_visibility="unauth"`,
+ ]);
+ };
+
+ this.disableOidc = (path) => shell.runCommands([`delete /sys/auth/${path}`]);
+ });
+
+ test('oidc: request is made to auth_url when a namespace is inputted', async function (assert) {
+ assert.expect(5);
+
+ this.server.post(`/auth/${this.rootOidc}/oidc/auth_url`, (schema, req) => {
+ const { redirect_uri } = JSON.parse(req.requestBody);
+ const { pathname, search } = parseURL(redirect_uri);
+ assert.strictEqual(
+ pathname + search,
+ `/ui/vault/auth/${this.rootOidc}/oidc/callback`,
+ 'request made to auth_url when the login page is visited'
+ );
+ });
+ this.server.post(`/auth/${this.nsOidc}/oidc/auth_url`, (schema, req) => {
+ const { redirect_uri } = JSON.parse(req.requestBody);
+ const { pathname, search } = parseURL(redirect_uri);
+ assert.strictEqual(
+ pathname + search,
+ `/ui/vault/auth/${this.nsOidc}/oidc/callback?namespace=${this.namespace}`,
+ 'request made to correct auth_url when namespace is filled in'
+ );
+ });
+
+ await authPage.login();
+ // enable oidc in root namespace, without default role
+ await this.enableOidc(this.rootOidc);
+ // create child namespace to enable oidc
+ await createNS(this.namespace);
+ // enable oidc in child namespace with default role
+ await authPage.loginNs(this.namespace);
+ await this.enableOidc(this.nsOidc, `${this.nsOidc}-role`);
+ await authPage.logout();
+
+ await visit('/vault/auth');
+ assert.dom(SELECTORS.authTab(this.rootOidc)).exists('renders oidc method tab for root');
+ await authPage.namespaceInput(this.namespace);
+ assert.strictEqual(
+ currentURL(),
+ `/vault/auth?namespace=${this.namespace}&with=${this.nsOidc}%2F`,
+ 'url updates with namespace value'
+ );
+ assert.dom(SELECTORS.authTab(this.nsOidc)).exists('renders oidc method tab for child namespace');
+
+ // disable methods to cleanup test state for re-running
+ await authPage.login();
+ await this.disableOidc(this.rootOidc);
+ await this.disableOidc(this.nsOidc);
+ await shell.runCommands([`delete /sys/auth/${this.namespace}`]);
+ await authPage.logout();
+ });
+});
website/content/docs/internals/security.mdx+6 0
@@ -75,6 +75,12 @@ The following are not considered part of the Vault threat model:
credentials, they can access Vault with the level of privilege associated with this
client.
+- Protecting against Vault administrators supplying vulnerable or malicious configuration
+ data. Any data provided as configuration values to Vault's administrative endpoints
+ (e.g. [secret engines](/vault/docs/secrets) configurations), or Vault's
+ configuration files should be validated. If an attacker can write to Vault's
+ configuration, then the confidentiality or integrity of data can be compromised.
+
# External Threat Overview
Vault architecture compromises of three distinct systems:
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
6d8ed36032322caf95e619ab41e6fee77ec34548 (#19674)
.../content/api-docs/secret/databases/postgresql.mdx | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
builtin/logical/pki/backend_test.go+396 0
@@ -6399,6 +6399,433 @@ func TestStandby_Operations(t *testing.T) {
require.NotNil(t, resp, "got nil response from revoke request")
}
+type pathAuthCheckerFunc func(t *testing.T, client *api.Client, path string, token string)
+
+func isPermDenied(err error) bool {
+ return err != nil && strings.Contains(err.Error(), "permission denied")
+}
+
+func isUnsupportedPathOperation(err error) bool {
+ return err != nil && (strings.Contains(err.Error(), "unsupported path") || strings.Contains(err.Error(), "unsupported operation"))
+}
+
+func isDeniedOp(err error) bool {
+ return isPermDenied(err) || isUnsupportedPathOperation(err)
+}
+
+func pathShouldBeAuthed(t *testing.T, client *api.Client, path string, token string) {
+ client.SetToken("")
+ resp, err := client.Logical().ReadWithContext(ctx, path)
+ if err == nil || !isPermDenied(err) {
+ t.Fatalf("expected failure to read %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().ListWithContext(ctx, path)
+ if err == nil || !isPermDenied(err) {
+ t.Fatalf("expected failure to list %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().WriteWithContext(ctx, path, map[string]interface{}{})
+ if err == nil || !isPermDenied(err) {
+ t.Fatalf("expected failure to write %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().DeleteWithContext(ctx, path)
+ if err == nil || !isPermDenied(err) {
+ t.Fatalf("expected failure to delete %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().JSONMergePatch(ctx, path, map[string]interface{}{})
+ if err == nil || !isPermDenied(err) {
+ t.Fatalf("expected failure to patch %v while unauthed: %v / %v", path, err, resp)
+ }
+}
+
+func pathShouldBeUnauthedReadList(t *testing.T, client *api.Client, path string, token string) {
+ // Should be able to read both with and without a token.
+ client.SetToken("")
+ resp, err := client.Logical().ReadWithContext(ctx, path)
+ if err != nil && isPermDenied(err) {
+ // Read will sometimes return permission denied, when the handler
+ // does not support the given operation. Retry with the token.
+ client.SetToken(token)
+ resp2, err2 := client.Logical().ReadWithContext(ctx, path)
+ if err2 != nil && !isUnsupportedPathOperation(err2) {
+ t.Fatalf("unexpected failure to read %v while unauthed: %v / %v\nWhile authed: %v / %v", path, err, resp, err2, resp2)
+ }
+ client.SetToken("")
+ }
+ resp, err = client.Logical().ListWithContext(ctx, path)
+ if err != nil && isPermDenied(err) {
+ // List will sometimes return permission denied, when the handler
+ // does not support the given operation. Retry with the token.
+ client.SetToken(token)
+ resp2, err2 := client.Logical().ListWithContext(ctx, path)
+ if err2 != nil && !isUnsupportedPathOperation(err2) {
+ t.Fatalf("unexpected failure to list %v while unauthed: %v / %v\nWhile authed: %v / %v", path, err, resp, err2, resp2)
+ }
+ client.SetToken("")
+ }
+
+ // These should all be denied.
+ resp, err = client.Logical().WriteWithContext(ctx, path, map[string]interface{}{})
+ if err == nil || !isDeniedOp(err) {
+ if !strings.Contains(path, "ocsp") || !strings.Contains(err.Error(), "Code: 40") {
+ t.Fatalf("unexpected failure during write on read-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+ }
+ resp, err = client.Logical().DeleteWithContext(ctx, path)
+ if err == nil || !isDeniedOp(err) {
+ t.Fatalf("unexpected failure during delete on read-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().JSONMergePatch(ctx, path, map[string]interface{}{})
+ if err == nil || !isDeniedOp(err) {
+ t.Fatalf("unexpected failure during patch on read-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+
+ // Retrying with token should allow read/list, but not modification still.
+ client.SetToken(token)
+ resp, err = client.Logical().ReadWithContext(ctx, path)
+ if err != nil && isPermDenied(err) {
+ t.Fatalf("unexpected failure to read %v while authed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().ListWithContext(ctx, path)
+ if err != nil && isPermDenied(err) {
+ t.Fatalf("unexpected failure to list %v while authed: %v / %v", path, err, resp)
+ }
+
+ // Should all be denied.
+ resp, err = client.Logical().WriteWithContext(ctx, path, map[string]interface{}{})
+ if err == nil || !isDeniedOp(err) {
+ if !strings.Contains(path, "ocsp") || !strings.Contains(err.Error(), "Code: 40") {
+ t.Fatalf("unexpected failure during write on read-only path %v while authed: %v / %v", path, err, resp)
+ }
+ }
+ resp, err = client.Logical().DeleteWithContext(ctx, path)
+ if err == nil || !isDeniedOp(err) {
+ t.Fatalf("unexpected failure during delete on read-only path %v while authed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().JSONMergePatch(ctx, path, map[string]interface{}{})
+ if err == nil || !isDeniedOp(err) {
+ t.Fatalf("unexpected failure during patch on read-only path %v while authed: %v / %v", path, err, resp)
+ }
+}
+
+func pathShouldBeUnauthedWriteOnly(t *testing.T, client *api.Client, path string, token string) {
+ client.SetToken("")
+ resp, err := client.Logical().WriteWithContext(ctx, path, map[string]interface{}{})
+ if err != nil && isPermDenied(err) {
+ t.Fatalf("unexpected failure to write %v while unauthed: %v / %v", path, err, resp)
+ }
+
+ // These should all be denied. However, on OSS, we might end up with
+ // a regular 404, which looks like err == resp == nil; hence we only
+ // fail when there's a non-nil response and/or a non-nil err.
+ resp, err = client.Logical().ReadWithContext(ctx, path)
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during read on write-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().ListWithContext(ctx, path)
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during list on write-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().DeleteWithContext(ctx, path)
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during delete on write-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().JSONMergePatch(ctx, path, map[string]interface{}{})
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during patch on write-only path %v while unauthed: %v / %v", path, err, resp)
+ }
+
+ // Retrying with token should allow writing, but nothing else.
+ client.SetToken(token)
+ resp, err = client.Logical().WriteWithContext(ctx, path, map[string]interface{}{})
+ if err != nil && isPermDenied(err) {
+ t.Fatalf("unexpected failure to write %v while unauthed: %v / %v", path, err, resp)
+ }
+
+ // These should all be denied.
+ resp, err = client.Logical().ReadWithContext(ctx, path)
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during read on write-only path %v while authed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().ListWithContext(ctx, path)
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ if resp != nil || err != nil {
+ t.Fatalf("unexpected failure during list on write-only path %v while authed: %v / %v", path, err, resp)
+ }
+ }
+ resp, err = client.Logical().DeleteWithContext(ctx, path)
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during delete on write-only path %v while authed: %v / %v", path, err, resp)
+ }
+ resp, err = client.Logical().JSONMergePatch(ctx, path, map[string]interface{}{})
+ if (err == nil && resp != nil) || (err != nil && !isDeniedOp(err)) {
+ t.Fatalf("unexpected failure during patch on write-only path %v while authed: %v / %v", path, err, resp)
+ }
+}
+
+type pathAuthChecker int
+
+const (
+ shouldBeAuthed pathAuthChecker = iota
+ shouldBeUnauthedReadList
+ shouldBeUnauthedWriteOnly
+)
+
+var pathAuthChckerMap = map[pathAuthChecker]pathAuthCheckerFunc{
+ shouldBeAuthed: pathShouldBeAuthed,
+ shouldBeUnauthedReadList: pathShouldBeUnauthedReadList,
+ shouldBeUnauthedWriteOnly: pathShouldBeUnauthedWriteOnly,
+}
+
+func TestProperAuthing(t *testing.T) {
+ t.Parallel()
+ ctx := context.Background()
+ coreConfig := &vault.CoreConfig{
+ LogicalBackends: map[string]logical.Factory{
+ "pki": Factory,
+ },
+ }
+ cluster := vault.NewTestCluster(t, coreConfig, &vault.TestClusterOptions{
+ HandlerFunc: vaulthttp.Handler,
+ })
+ cluster.Start()
+ defer cluster.Cleanup()
+ client := cluster.Cores[0].Client
+ token := client.Token()
+
+ // Mount PKI.
+ err := client.Sys().MountWithContext(ctx, "pki", &api.MountInput{
+ Type: "pki",
+ Config: api.MountConfigInput{
+ DefaultLeaseTTL: "16h",
+ MaxLeaseTTL: "60h",
+ },
+ })
+ if err != nil {
+ t.Fatal(err)
+ }
+
+ // Setup basic configuration.
+ _, err = client.Logical().WriteWithContext(ctx, "pki/root/generate/internal", map[string]interface{}{
+ "ttl": "40h",
+ "common_name": "myvault.com",
+ })
+ if err != nil {
+ t.Fatal(err)
+ }
+
+ _, err = client.Logical().WriteWithContext(ctx, "pki/roles/test", map[string]interface{}{
+ "allow_localhost": true,
+ })
+ if err != nil {
+ t.Fatal(err)
+ }
+
+ resp, err := client.Logical().WriteWithContext(ctx, "pki/issue/test", map[string]interface{}{
+ "common_name": "localhost",
+ })
+ if err != nil || resp == nil {
+ t.Fatal(err)
+ }
+ serial := resp.Data["serial_number"].(string)
+
+ paths := map[string]pathAuthChecker{
+ "ca_chain": shouldBeUnauthedReadList,
+ "cert/ca_chain": shouldBeUnauthedReadList,
+ "ca": shouldBeUnauthedReadList,
+ "ca/pem": shouldBeUnauthedReadList,
+ "cert/" + serial: shouldBeUnauthedReadList,
+ "cert/" + serial + "/raw": shouldBeUnauthedReadList,
+ "cert/" + serial + "/raw/pem": shouldBeUnauthedReadList,
+ "cert/crl": shouldBeUnauthedReadList,
+ "cert/crl/raw": shouldBeUnauthedReadList,
+ "cert/crl/raw/pem": shouldBeUnauthedReadList,
+ "cert/delta-crl": shouldBeUnauthedReadList,
+ "cert/delta-crl/raw": shouldBeUnauthedReadList,
+ "cert/delta-crl/raw/pem": shouldBeUnauthedReadList,
+ "cert/unified-crl": shouldBeUnauthedReadList,
+ "cert/unified-crl/raw": shouldBeUnauthedReadList,
+ "cert/unified-crl/raw/pem": shouldBeUnauthedReadList,
+ "cert/unified-delta-crl": shouldBeUnauthedReadList,
+ "cert/unified-delta-crl/raw": shouldBeUnauthedReadList,
+ "cert/unified-delta-crl/raw/pem": shouldBeUnauthedReadList,
+ "certs": shouldBeAuthed,
+ "certs/revoked": shouldBeAuthed,
+ "certs/revocation-queue": shouldBeAuthed,
+ "certs/unified-revoked": shouldBeAuthed,
+ "config/auto-tidy": shouldBeAuthed,
+ "config/ca": shouldBeAuthed,
+ "config/cluster": shouldBeAuthed,
+ "config/crl": shouldBeAuthed,
+ "config/issuers": shouldBeAuthed,
+ "config/keys": shouldBeAuthed,
+ "config/urls": shouldBeAuthed,
+ "crl": shouldBeUnauthedReadList,
+ "crl/pem": shouldBeUnauthedReadList,
+ "crl/delta": shouldBeUnauthedReadList,
+ "crl/delta/pem": shouldBeUnauthedReadList,
+ "crl/rotate": shouldBeAuthed,
+ "crl/rotate-delta": shouldBeAuthed,
+ "intermediate/cross-sign": shouldBeAuthed,
+ "intermediate/generate/exported": shouldBeAuthed,
+ "intermediate/generate/internal": shouldBeAuthed,
+ "intermediate/generate/existing": shouldBeAuthed,
+ "intermediate/generate/kms": shouldBeAuthed,
+ "intermediate/set-signed": shouldBeAuthed,
+ "issue/test": shouldBeAuthed,
+ "issuer/default": shouldBeAuthed,
+ "issuer/default/der": shouldBeUnauthedReadList,
+ "issuer/default/json": shouldBeUnauthedReadList,
+ "issuer/default/pem": shouldBeUnauthedReadList,
+ "issuer/default/crl": shouldBeUnauthedReadList,
+ "issuer/default/crl/pem": shouldBeUnauthedReadList,
+ "issuer/default/crl/der": shouldBeUnauthedReadList,
+ "issuer/default/crl/delta": shouldBeUnauthedReadList,
+ "issuer/default/crl/delta/der": shouldBeUnauthedReadList,
+ "issuer/default/crl/delta/pem": shouldBeUnauthedReadList,
+ "issuer/default/unified-crl": shouldBeUnauthedReadList,
+ "issuer/default/unified-crl/pem": shouldBeUnauthedReadList,
+ "issuer/default/unified-crl/der": shouldBeUnauthedReadList,
+ "issuer/default/unified-crl/delta": shouldBeUnauthedReadList,
+ "issuer/default/unified-crl/delta/der": shouldBeUnauthedReadList,
+ "issuer/default/unified-crl/delta/pem": shouldBeUnauthedReadList,
+ "issuer/default/issue/test": shouldBeAuthed,
+ "issuer/default/resign-crls": shouldBeAuthed,
+ "issuer/default/revoke": shouldBeAuthed,
+ "issuer/default/sign-intermediate": shouldBeAuthed,
+ "issuer/default/sign-revocation-list": shouldBeAuthed,
+ "issuer/default/sign-self-issued": shouldBeAuthed,
+ "issuer/default/sign-verbatim": shouldBeAuthed,
+ "issuer/default/sign-verbatim/test": shouldBeAuthed,
+ "issuer/default/sign/test": shouldBeAuthed,
+ "issuers": shouldBeUnauthedReadList,
+ "issuers/generate/intermediate/exported": shouldBeAuthed,
+ "issuers/generate/intermediate/internal": shouldBeAuthed,
+ "issuers/generate/intermediate/existing": shouldBeAuthed,
+ "issuers/generate/intermediate/kms": shouldBeAuthed,
+ "issuers/generate/root/exported": shouldBeAuthed,
+ "issuers/generate/root/internal": shouldBeAuthed,
+ "issuers/generate/root/existing": shouldBeAuthed,
+ "issuers/generate/root/kms": shouldBeAuthed,
+ "issuers/import/cert": shouldBeAuthed,
+ "issuers/import/bundle": shouldBeAuthed,
+ "key/default": shouldBeAuthed,
+ "keys": shouldBeAuthed,
+ "keys/generate/internal": shouldBeAuthed,
+ "keys/generate/exported": shouldBeAuthed,
+ "keys/generate/kms": shouldBeAuthed,
+ "keys/import": shouldBeAuthed,
+ "ocsp": shouldBeUnauthedWriteOnly,
+ "ocsp/dGVzdAo=": shouldBeUnauthedReadList,
+ "revoke": shouldBeAuthed,
+ "revoke-with-key": shouldBeAuthed,
+ "roles/test": shouldBeAuthed,
+ "roles": shouldBeAuthed,
+ "root": shouldBeAuthed,
+ "root/generate/exported": shouldBeAuthed,
+ "root/generate/internal": shouldBeAuthed,
+ "root/generate/existing": shouldBeAuthed,
+ "root/generate/kms": shouldBeAuthed,
+ "root/replace": shouldBeAuthed,
+ "root/rotate/internal": shouldBeAuthed,
+ "root/rotate/exported": shouldBeAuthed,
+ "root/rotate/existing": shouldBeAuthed,
+ "root/rotate/kms": shouldBeAuthed,
+ "root/sign-intermediate": shouldBeAuthed,
+ "root/sign-self-issued": shouldBeAuthed,
+ "sign-verbatim": shouldBeAuthed,
+ "sign-verbatim/test": shouldBeAuthed,
+ "sign/test": shouldBeAuthed,
+ "tidy": shouldBeAuthed,
+ "tidy-cancel": shouldBeAuthed,
+ "tidy-status": shouldBeAuthed,
+ "unified-crl": shouldBeUnauthedReadList,
+ "unified-crl/pem": shouldBeUnauthedReadList,
+ "unified-crl/delta": shouldBeUnauthedReadList,
+ "unified-crl/delta/pem": shouldBeUnauthedReadList,
+ "unified-ocsp": shouldBeUnauthedWriteOnly,
+ "unified-ocsp/dGVzdAo=": shouldBeUnauthedReadList,
+ }
+ for path, checkerType := range paths {
+ checker := pathAuthChckerMap[checkerType]
+ checker(t, client, "pki/"+path, token)
+ }
+
+ client.SetToken(token)
+ openAPIResp, err := client.Logical().ReadWithContext(ctx, "sys/internal/specs/openapi")
+ if err != nil {
+ t.Fatalf("failed to get openapi data: %v", err)
+ }
+
+ validatedPath := false
+ for openapi_path, raw_data := range openAPIResp.Data["paths"].(map[string]interface{}) {
+ if !strings.HasPrefix(openapi_path, "/pki/") {
+ t.Logf("Skipping path: %v", openapi_path)
+ continue
+ }
+
+ t.Logf("Validating path: %v", openapi_path)
+ validatedPath = true
+ // Substitute values in from our testing map.
+ raw_path := openapi_path[5:]
+ if strings.Contains(raw_path, "roles/") && strings.Contains(raw_path, "{name}") {
+ raw_path = strings.ReplaceAll(raw_path, "{name}", "test")
+ }
+ if strings.Contains(raw_path, "{role}") {
+ raw_path = strings.ReplaceAll(raw_path, "{role}", "test")
+ }
+ if strings.Contains(raw_path, "ocsp/") && strings.Contains(raw_path, "{req}") {
+ raw_path = strings.ReplaceAll(raw_path, "{req}", "dGVzdAo=")
+ }
+ if strings.Contains(raw_path, "{issuer_ref}") {
+ raw_path = strings.ReplaceAll(raw_path, "{issuer_ref}", "default")
+ }
+ if strings.Contains(raw_path, "{key_ref}") {
+ raw_path = strings.ReplaceAll(raw_path, "{key_ref}", "default")
+ }
+ if strings.Contains(raw_path, "{exported}") {
+ raw_path = strings.ReplaceAll(raw_path, "{exported}", "internal")
+ }
+ if strings.Contains(raw_path, "{serial}") {
+ raw_path = strings.ReplaceAll(raw_path, "{serial}", serial)
+ }
+
+ handler, present := paths[raw_path]
+ if !present {
+ t.Fatalf("OpenAPI reports PKI mount contains %v->%v but was not tested to be authed or authed.", openapi_path, raw_path)
+ }
+
+ openapi_data := raw_data.(map[string]interface{})
… diff truncated
website/content/docs/platform/aws/lambda-extension.mdx+0 4
@@ -268,10 +268,6 @@ synchronously refresh its own token before proxying requests if the token is
expired (including a grace window), and it will attempt to renew its token if the
token is nearly expired but renewable.
-~> **Note**: The Vault Lambda Extension is currently incompatible with
-[AWS SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html).
-This is because AWS SnapStart does not support the Lambda Extensions API.
-
## Performance impact
AWS Lambda pricing is based on [number of invocations, time of execution and memory
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
94406d19179b7e5ba615fd4f10de06b9b620cfb5 (#19427)
website/content/docs/configuration/listener/tcp.mdx | 7 +++++++
1 file changed, 7 insertions(+)
shamir/shamir.go+24 15
@@ -86,31 +86,40 @@ func div(a, b uint8) uint8 {
panic("divide by zero")
}
- log_a := logTable[a]
- log_b := logTable[b]
- diff := ((int(log_a) - int(log_b)) + 255) % 255
-
- ret := int(expTable[diff])
+ ret := int(mult(a, inverse(b)))
// Ensure we return zero if a is zero but aren't subject to timing attacks
ret = subtle.ConstantTimeSelect(subtle.ConstantTimeByteEq(a, 0), 0, ret)
return uint8(ret)
}
+// inverse calculates the inverse of a number in GF(2^8)
+func inverse(a uint8) uint8 {
+ b := mult(a, a)
+ c := mult(a, b)
+ b = mult(c, c)
+ b = mult(b, b)
+ c = mult(b, c)
+ b = mult(b, b)
+ b = mult(b, b)
+ b = mult(b, c)
+ b = mult(b, b)
+ b = mult(a, b)
+
+ return mult(b, b)
+}
+
// mult multiplies two numbers in GF(2^8)
func mult(a, b uint8) (out uint8) {
- log_a := logTable[a]
- log_b := logTable[b]
- sum := (int(log_a) + int(log_b)) % 255
-
- ret := int(expTable[sum])
+ var r uint8 = 0
+ var i uint8 = 8
- // Ensure we return zero if either a or b are zero but aren't subject to
- // timing attacks
- ret = subtle.ConstantTimeSelect(subtle.ConstantTimeByteEq(a, 0), 0, ret)
- ret = subtle.ConstantTimeSelect(subtle.ConstantTimeByteEq(b, 0), 0, ret)
+ for i > 0 {
+ i--
+ r = (-(b >> i & 1) & a) ^ (-(r >> 7) & 0x1B) ^ (r + r)
+ }
- return uint8(ret)
+ return r
}
// add combines two numbers in GF(2^8)
shamir/tables.go+0 79
@@ -1,79 +0,0 @@
-package shamir
-
-// Tables taken from http://www.samiam.org/galois.html
-// They use 0xe5 (229) as the generator
-
-var (
- // logTable provides the log(X)/log(g) at each index X
- logTable = [256]uint8{
- 0x00, 0xff, 0xc8, 0x08, 0x91, 0x10, 0xd0, 0x36,
- 0x5a, 0x3e, 0xd8, 0x43, 0x99, 0x77, 0xfe, 0x18,
- 0x23, 0x20, 0x07, 0x70, 0xa1, 0x6c, 0x0c, 0x7f,
- 0x62, 0x8b, 0x40, 0x46, 0xc7, 0x4b, 0xe0, 0x0e,
- 0xeb, 0x16, 0xe8, 0xad, 0xcf, 0xcd, 0x39, 0x53,
- 0x6a, 0x27, 0x35, 0x93, 0xd4, 0x4e, 0x48, 0xc3,
- 0x2b, 0x79, 0x54, 0x28, 0x09, 0x78, 0x0f, 0x21,
- 0x90, 0x87, 0x14, 0x2a, 0xa9, 0x9c, 0xd6, 0x74,
- 0xb4, 0x7c, 0xde, 0xed, 0xb1, 0x86, 0x76, 0xa4,
- 0x98, 0xe2, 0x96, 0x8f, 0x02, 0x32, 0x1c, 0xc1,
- 0x33, 0xee, 0xef, 0x81, 0xfd, 0x30, 0x5c, 0x13,
- 0x9d, 0x29, 0x17, 0xc4, 0x11, 0x44, 0x8c, 0x80,
- 0xf3, 0x73, 0x42, 0x1e, 0x1d, 0xb5, 0xf0, 0x12,
- 0xd1, 0x5b, 0x41, 0xa2, 0xd7, 0x2c, 0xe9, 0xd5,
- 0x59, 0xcb, 0x50, 0xa8, 0xdc, 0xfc, 0xf2, 0x56,
- 0x72, 0xa6, 0x65, 0x2f, 0x9f, 0x9b, 0x3d, 0xba,
- 0x7d, 0xc2, 0x45, 0x82, 0xa7, 0x57, 0xb6, 0xa3,
- 0x7a, 0x75, 0x4f, 0xae, 0x3f, 0x37, 0x6d, 0x47,
- 0x61, 0xbe, 0xab, 0xd3, 0x5f, 0xb0, 0x58, 0xaf,
- 0xca, 0x5e, 0xfa, 0x85, 0xe4, 0x4d, 0x8a, 0x05,
- 0xfb, 0x60, 0xb7, 0x7b, 0xb8, 0x26, 0x4a, 0x67,
- 0xc6, 0x1a, 0xf8, 0x69, 0x25, 0xb3, 0xdb, 0xbd,
- 0x66, 0xdd, 0xf1, 0xd2, 0xdf, 0x03, 0x8d, 0x34,
- 0xd9, 0x92, 0x0d, 0x63, 0x55, 0xaa, 0x49, 0xec,
- 0xbc, 0x95, 0x3c, 0x84, 0x0b, 0xf5, 0xe6, 0xe7,
- 0xe5, 0xac, 0x7e, 0x6e, 0xb9, 0xf9, 0xda, 0x8e,
- 0x9a, 0xc9, 0x24, 0xe1, 0x0a, 0x15, 0x6b, 0x3a,
- 0xa0, 0x51, 0xf4, 0xea, 0xb2, 0x97, 0x9e, 0x5d,
- 0x22, 0x88, 0x94, 0xce, 0x19, 0x01, 0x71, 0x4c,
- 0xa5, 0xe3, 0xc5, 0x31, 0xbb, 0xcc, 0x1f, 0x2d,
- 0x3b, 0x52, 0x6f, 0xf6, 0x2e, 0x89, 0xf7, 0xc0,
- 0x68, 0x1b, 0x64, 0x04, 0x06, 0xbf, 0x83, 0x38,
- }
-
- // expTable provides the anti-log or exponentiation value
- // for the equivalent index
- expTable = [256]uint8{
- 0x01, 0xe5, 0x4c, 0xb5, 0xfb, 0x9f, 0xfc, 0x12,
- 0x03, 0x34, 0xd4, 0xc4, 0x16, 0xba, 0x1f, 0x36,
- 0x05, 0x5c, 0x67, 0x57, 0x3a, 0xd5, 0x21, 0x5a,
- 0x0f, 0xe4, 0xa9, 0xf9, 0x4e, 0x64, 0x63, 0xee,
- 0x11, 0x37, 0xe0, 0x10, 0xd2, 0xac, 0xa5, 0x29,
- 0x33, 0x59, 0x3b, 0x30, 0x6d, 0xef, 0xf4, 0x7b,
- 0x55, 0xeb, 0x4d, 0x50, 0xb7, 0x2a, 0x07, 0x8d,
- 0xff, 0x26, 0xd7, 0xf0, 0xc2, 0x7e, 0x09, 0x8c,
- 0x1a, 0x6a, 0x62, 0x0b, 0x5d, 0x82, 0x1b, 0x8f,
- 0x2e, 0xbe, 0xa6, 0x1d, 0xe7, 0x9d, 0x2d, 0x8a,
- 0x72, 0xd9, 0xf1, 0x27, 0x32, 0xbc, 0x77, 0x85,
- 0x96, 0x70, 0x08, 0x69, 0x56, 0xdf, 0x99, 0x94,
- 0xa1, 0x90, 0x18, 0xbb, 0xfa, 0x7a, 0xb0, 0xa7,
- 0xf8, 0xab, 0x28, 0xd6, 0x15, 0x8e, 0xcb, 0xf2,
- 0x13, 0xe6, 0x78, 0x61, 0x3f, 0x89, 0x46, 0x0d,
- 0x35, 0x31, 0x88, 0xa3, 0x41, 0x80, 0xca, 0x17,
- 0x5f, 0x53, 0x83, 0xfe, 0xc3, 0x9b, 0x45, 0x39,
- 0xe1, 0xf5, 0x9e, 0x19, 0x5e, 0xb6, 0xcf, 0x4b,
- 0x38, 0x04, 0xb9, 0x2b, 0xe2, 0xc1, 0x4a, 0xdd,
- 0x48, 0x0c, 0xd0, 0x7d, 0x3d, 0x58, 0xde, 0x7c,
- 0xd8, 0x14, 0x6b, 0x87, 0x47, 0xe8, 0x79, 0x84,
- 0x73, 0x3c, 0xbd, 0x92, 0xc9, 0x23, 0x8b, 0x97,
- 0x95, 0x44, 0xdc, 0xad, 0x40, 0x65, 0x86, 0xa2,
- 0xa4, 0xcc, 0x7f, 0xec, 0xc0, 0xaf, 0x91, 0xfd,
- 0xf7, 0x4f, 0x81, 0x2f, 0x5b, 0xea, 0xa8, 0x1c,
- 0x02, 0xd1, 0x98, 0x71, 0xed, 0x25, 0xe3, 0x24,
- 0x06, 0x68, 0xb3, 0x93, 0x2c, 0x6f, 0x3e, 0x6c,
- 0x0a, 0xb8, 0xce, 0xae, 0x74, 0xb1, 0x42, 0xb4,
- 0x1e, 0xd3, 0x49, 0xe9, 0x9c, 0xc8, 0xc6, 0xc7,
- 0x22, 0x6e, 0xdb, 0x20, 0xbf, 0x43, 0x51, 0x52,
- 0x66, 0xb2, 0x76, 0x60, 0xda, 0xc5, 0xf3, 0xf6,
- 0xaa, 0xcd, 0x9a, 0xa0, 0x75, 0x54, 0x0e, 0x01,
- }
-)
physical/mssql/mssql.go+25 5
@@ -4,6 +4,7 @@ import (
"context"
"database/sql"
"fmt"
+ "regexp"
"sort"
"strconv"
"strings"
@@ -18,6 +19,7 @@ import (
// Verify MSSQLBackend satisfies the correct interfaces
var _ physical.Backend = (*MSSQLBackend)(nil)
+var identifierRegex = regexp.MustCompile(`^[\p{L}_][\p{L}\p{Nd}@#$_]*$`)
type MSSQLBackend struct {
dbTable string
@@ -27,6 +29,13 @@ type MSSQLBackend struct {
permitPool *physical.PermitPool
}
+func isInvalidIdentifier(name string) bool {
+ if !identifierRegex.MatchString(name) {
+ return true
+ }
+ return false
+}
+
func NewMSSQLBackend(conf map[string]string, logger log.Logger) (physical.Backend, error) {
username, ok := conf["username"]
if !ok {
@@ -68,11 +77,19 @@ func NewMSSQLBackend(conf map[string]string, logger log.Logger) (physical.Backen
database = "Vault"
}
+ if isInvalidIdentifier(database) {
+ return nil, fmt.Errorf("invalid database name")
+ }
+
table, ok := conf["table"]
if !ok {
table = "Vault"
}
+ if isInvalidIdentifier(table) {
+ return nil, fmt.Errorf("invalid table name")
+ }
+
appname, ok := conf["appname"]
if !ok {
appname = "Vault"
@@ -93,6 +110,10 @@ func NewMSSQLBackend(conf map[string]string, logger log.Logger) (physical.Backen
schema = "dbo"
}
+ if isInvalidIdentifier(schema) {
+ return nil, fmt.Errorf("invalid schema name")
+ }
+
connectionString := fmt.Sprintf("server=%s;app name=%s;connection timeout=%s;log=%s", server, appname, connectionTimeout, logLevel)
if username != "" {
connectionString += ";user id=" + username
@@ -113,18 +134,17 @@ func NewMSSQLBackend(conf map[string]string, logger log.Logger) (physical.Backen
db.SetMaxOpenConns(maxParInt)
- if _, err := db.Exec("IF NOT EXISTS(SELECT * FROM sys.databases WHERE name = '" + database + "') CREATE DATABASE " + database); err != nil {
+ if _, err := db.Exec("IF NOT EXISTS(SELECT * FROM sys.databases WHERE name = ?) CREATE DATABASE "+database, database); err != nil {
return nil, fmt.Errorf("failed to create mssql database: %w", err)
}
dbTable := database + "." + schema + "." + table
- createQuery := "IF NOT EXISTS(SELECT 1 FROM " + database + ".INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME='" + table + "' AND TABLE_SCHEMA='" + schema +
- "') CREATE TABLE " + dbTable + " (Path VARCHAR(512) PRIMARY KEY, Value VARBINARY(MAX))"
+ createQuery := "IF NOT EXISTS(SELECT 1 FROM " + database + ".INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME=? AND TABLE_SCHEMA=?) CREATE TABLE " + dbTable + " (Path VARCHAR(512) PRIMARY KEY, Value VARBINARY(MAX))"
if schema != "dbo" {
var num int
- err = db.QueryRow("SELECT 1 FROM " + database + ".sys.schemas WHERE name = '" + schema + "'").Scan(&num)
+ err = db.QueryRow("SELECT 1 FROM "+database+".sys.schemas WHERE name = ?", schema).Scan(&num)
switch {
case err == sql.ErrNoRows:
@@ -137,7 +157,7 @@ func NewMSSQLBackend(conf map[string]string, logger log.Logger) (physical.Backen
}
}
- if _, err := db.Exec(createQuery); err != nil {
+ if _, err := db.Exec(createQuery, table, schema); err != nil {
return nil, fmt.Errorf("failed to create mssql table: %w", err)
}
vault/token_store.go+15 0
@@ -1557,6 +1557,10 @@ func (ts *TokenStore) lookupInternal(ctx context.Context, id string, salted, tai
return ts.lookupBatchToken(ctx, id)
}
+ // Before we check to see if this is an SSCT, keep the old value in case
+ // we need to check the full SSCT flow later.
+ originalToken := id
+
// lookupInternal is called internally with tokens that oftentimes come from request
// parameters that we cannot really guess. Most notably, these calls come from either
// validateWrappedToken and/or lookupTokenTainted, used in the wrapping token logic.
@@ -1700,6 +1704,17 @@ func (ts *TokenStore) lookupInternal(ctx context.Context, id string, salted, tai
// It's any kind of expiring token with no lease, immediately delete it
case le == nil:
if ts.core.perfStandby {
+ // If we're a perf standby with a token but without the lease entry, then
+ // we have the WALs for the token but not the lease entry. We should check
+ // the SSCToken again to validate our state. We will receive a 412 if we
+ // don't have the requisite state.
+ // We set unauth to 'false' here as we want to validate the full SSCT flow
+ // and if we're at this point in the method, we have reason to need the token.
+ _, err = ts.core.CheckSSCToken(ctx, originalToken, false, ts.core.perfStandby)
+ if err != nil {
+ return nil, err
+ }
+ // If we don't have a state error, and we're still here, return a 500.
return nil, fmt.Errorf("no lease entry found for token that ought to have one, possible eventual consistency issue")
}
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
e3c59773e969336bb4e85ddbf3a3700a6250f4c8 (#19629)
changelog/19625.txt | 4 ++++
vault/activity_log.go | 23 +++++++++++++++++++++++
vault/activity_log_util.go | 3 +++
vault/census.go | 6 ++++++
vault/core.go | 6 ++++++
vault/testing.go | 1 +
6 files changed, 43 insertions(+)
create mode 100644 changelog/19625.txt
create mode 100644 vault/census.go
website/content/partials/plugin-versioning.mdx+14 0
@@ -0,0 +1,14 @@
+Plugins can optionally self-report their own semantic version. For plugins that
+do so, Vault will automatically populate the plugin's version in the catalog
+without requiring the user to provide it. If users do provide a version during
+registration, Vault will error if the version provided does not match what the
+plugin reports. Plugins that report a non-empty version _must_ report a valid
+[Semantic Version](https://semver.org/) with a leading 'v' added or registration
+will fail, e.g. `v1.0.0` or `v2.3.2-beta`.
+
+Plugins that want to opt into this behavior can implement the version interface.
+However, it is not a prerequisite; users can still provide a version during
+registration if the plugin does not implement the version interface.
+
+To implement the version interface, plugins should first upgrade the Vault SDK
+package to at least v0.6.0.
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
29b1e5541a86b57e66b2f488097c29df4dcc9629 (#19655)
vault/hcp_link/capabilities/node_status/node_status.go | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
website/content/docs/enterprise/pkcs11-provider/index.mdx+3 0
@@ -29,6 +29,9 @@ with the KMIP Secrets Engine.
| Linux | x86-64 | RHEL 9 compatible | 2.34 |
| macOS | x86-64 | &mdash; | &mdash; |
+_Note:_ `vault-pkcs11-provider` runs on _any_ glibc-based Linux distribution. The versions above are given in RHEL-compatible GLIBC versions; for your
+distro's glibc version, choose the `vault-pkcs11-provider` built against the same or older version as what your distro provides.
+
The provider comes in the form of a shared C library, `libvault-pkcs11.so` (for Linux) or `libvault-pkcs11.dylib` (for macOS).
It can be downloaded from [releases.hashicorp.com](https://releases.hashicorp.com/vault-pkcs11-provider).
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
449482d9b37864c4408a5f904e67b7c9286d197c (#19692)
website/data/docs-nav-data.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
vault/token_store.go+0 15
@@ -1557,10 +1557,6 @@ func (ts *TokenStore) lookupInternal(ctx context.Context, id string, salted, tai
return ts.lookupBatchToken(ctx, id)
}
- // Before we check to see if this is an SSCT, keep the old value in case
- // we need to check the full SSCT flow later.
- originalToken := id
-
// lookupInternal is called internally with tokens that oftentimes come from request
// parameters that we cannot really guess. Most notably, these calls come from either
// validateWrappedToken and/or lookupTokenTainted, used in the wrapping token logic.
@@ -1704,17 +1700,6 @@ func (ts *TokenStore) lookupInternal(ctx context.Context, id string, salted, tai
// It's any kind of expiring token with no lease, immediately delete it
case le == nil:
if ts.core.perfStandby {
- // If we're a perf standby with a token but without the lease entry, then
- // we have the WALs for the token but not the lease entry. We should check
- // the SSCToken again to validate our state. We will receive a 412 if we
- // don't have the requisite state.
- // We set unauth to 'false' here as we want to validate the full SSCT flow
- // and if we're at this point in the method, we have reason to need the token.
- _, err = ts.core.CheckSSCToken(ctx, originalToken, false, ts.core.perfStandby)
- if err != nil {
- return nil, err
- }
- // If we don't have a state error, and we're still here, return a 500.
return nil, fmt.Errorf("no lease entry found for token that ought to have one, possible eventual consistency issue")
}
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
via OpenAPI into release/1.13.x (#19713)
builtin/logical/pki/backend.go | 7 +
builtin/logical/pki/backend_test.go | 427 ++++++++++++++++++++++
builtin/logical/pki/path_fetch_issuers.go | 29 +-
3 files changed, 461 insertions(+), 2 deletions(-)
website/content/api-docs/secret/identity/entity-alias.mdx+3 3
@@ -135,14 +135,14 @@ This endpoint is used to update an existing entity alias.
- `id` `(string: <required>)` – Identifier of the entity alias.
-- `name` `(string: <required>)` - Name of the alias. Name should be the identifier
+- `name` `(string: "")` - Name of the alias. Name should be the identifier
of the client in the authentication source. For example, if the alias belongs
to userpass backend, the name should be a valid username within userpass
backend. If alias belongs to GitHub, it should be the GitHub username.
-- `canonical_id` `(string: <required>)` - Entity ID to which this alias belongs to.
+- `canonical_id` `(string: "")` - Entity ID to which this alias belongs to.
-- `mount_accessor` `(string: <required>)` - Accessor of the mount to which the
+- `mount_accessor` `(string: "")` - Accessor of the mount to which the
alias should belong to.
- `custom_metadata` `(map<string|string>: <optional>)` - A map of arbitrary string to string valued
<82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
3e4262f57167444a41ddb0e2325c9e0d5a4d3700 (#19455)
website/content/docs/secrets/ldap.mdx | 2 ++
1 file changed, 2 insertions(+)
More files changed — see the full commit.

References