USGv6[0] requires implementing §4.1.1 of the NISTv6-r1 profile[1] for
IPv6-Only capabilities. This section requires that whenever Vault
displays IPv6 addresses (including CLI output, Web UI, logs, etc.) that
_all_ IPv6 addresses must conform to RFC-5952 §4 text representation
recommendations[2].
These recommendations do not prevent us from accepting RFC-4241[3] IPv6
addresses, however, whenever these same addresses are displayed they
must conform to the strict RFC-5952 §4 guidelines.
This PR implements handling of IPv6 address conformance in our
`vault server` routine. We handle conformance normalization for all
server, http_proxy, listener, seal, storage and telemetry
configuration where an input could contain an IPv6 address, whether
configured via an HCL file or via corresponding environment variables.
The approach I've taken is to handle conformance normalization at
parse time to ensure that all log output and subsequent usage
inside of Vaults various subsystems always reference a conformant
address, that way we don't need concern ourselves with conformance
later. This approach ought to be backwards compatible to prior loose
address configuration requirements, with the understanding that
going forward all IPv6 representation will be strict regardless of
what has been configured.
In many cases I've updated our various parser functions to call the
new `configutil.NormalizeAddr()` to apply conformance normalization.
Others required no changes because they rely on standard library URL
string output, which always displays IPv6 URLs in a conformant way.
Not included in this changes is any other vault exec mode other than
server. Client, operator commands, agent mode, proxy mode, etc. will
be included in subsequent changes if necessary.
[0]: https://www.nist.gov/publications/usgv6-profile
[1]: https://www.nist.gov/publications/nist-ipv6-profile
[2]: https://www.rfc-editor.org/rfc/rfc5952.html#section-4
[3]: https://www.rfc-editor.org/rfc/rfc4291
Signed-off-by: Ryan Cragun <me@ryan.ec>
* Fix "t.Fatal from a non-test goroutine" errors in cache_test.go
- t.Fatal(f) should not be called within a Go routine based on it's documentation and only from the main test's thread.
- In 1.24 this seems to cause build failures
* Address all "non-constant format string errors" from go vet
- Within 1.24 these now cause test builds to fail
…" from go vet
* database/mssql: set default root rotation stmt for contained db
* changelog
* add rotate root test
* fix test
* update passwords to make mssql happy
* create admin user
* update contained user create query
* remove test
* Adds an option to enable sAMAccountname logins when upndomain is set
* Adds an option to enable sAMAccountname logins when upndomain is set
* Updated changelog entry
* Update 29118.txt
* Updated cap/ldap version due to needed dependency
* Updated cap/ldap version due to needed dependency
* Restart CI
* Updated LDAP api-docs and docs describing the enable_samaccountname_login option
* Added missing comma in config_test.go
* Update enables_samaccountname
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Update enable_samaccountname_login feature documentation
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
---------
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* make one component and make one test file for that component. remove the two components and associated files the new component replaces
* make access type subtext dynamic based on model type
* clean up
* clean up
* remove model attr for display purposes
* split out lease to another second config model type and make is-wif-engine helper
* welp missed the old controller
* small removal of overkill comment
* pr feedback
* save lease config if only thing changed
* error handling in acceptance test
* test fix
* replace notOk with throw
* move back error message
* clean up focused largely on wif component test
* replace ok with true
* sdk/physical: use permitpool from go-secure-stdlib
* physical: use permitpool from go-secure-stdlib
* fixup! sdk/physical: use permitpool from go-secure-stdlib
* fixup! sdk/physical: use permitpool from go-secure-stdlib
* Updated the PostgreSQL database creation command to ensure the static role name is consistent.
The role name specified in allowed_roles="my-role" under the section "Rootless Configuration and Password Rotation for Static Roles" should align with the static role name in step #3. Previously, the command incorrectly used "my-static-role"; it should be "my-role" to match the earlier step.
The same role name should also be used when reading the static credentials in step #4
* Added the file changelog/29138.txt
* Delete changelog/29138.txt
---------
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
Co-authored-by: akshya96 <87045294+akshya96@users.noreply.github.com>
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
This PR introduces a new type of conflict resolution for duplicate
Entities and Groups. Renaming provides a way of preventing Vault from
entering case-sensitive mode, which is the current behavior for any kind
of duplicate.
Renames append the conflicting identity artifact's UUID to its name and
updates a metadata field to indicate the pre-existing artifact's UUID.
The feature is gated by the force-identity-deduplication activation flag.
In order to maintain consistent behavior between the reporting resolver
and the rename operation, we need to adjust the behavior of generated
reports. Previously, they intentionally preserved existing Group merge
determinism, wherein the last MemDB update would win and all others
would be renamed. This approach is more complicated for the rename
resolver, since we would need to update any duplicated entity in the
cache while inserting the new duplicate (resulting in two MemDB
operations). Though we can ensure atomic updates of the two identity
artifacts with transactions (which we could get for groups with a minor
adjustment, and we will get along with batching of Entity upserts on
load), it's far simpler to just rename all but the first insert as proposed
in the current PR.
Since the feature is gated by an activation flag with appropriate
warnings of potential changes via the reporting resolver, we opt
for simplicity over maintaining pre-existing behavior. We can revisit
this assumption later if we think alignment with existing behavior
outweighs any potential complexity in the rename operation.
Entity alias resolution is left alone as a destructive merge operation
to prevent a potentially high-impact change in existing behavior.
* initial things without helper changes
* adjust test for clean up of secret-engine-helper
* remove added line thats better in next pr
* remove extra check
* 🧹
* replace return with continue within loops
