* revert STS lease changes, now create a lease for STS credentials but keep the ttl
Co-authored-by: Calvin Leung Huang <1883212+calvn@users.noreply.github.com>
* plugin/auth: enable multiplexing
- the plugin will be multiplexed when run as an external plugin
by vault versions that support secrets/auth plugin multiplexing (> 1.12)
- we continue to set the TLSProviderFunc to maintain backwards
compatibility with vault versions that don't support AutoMTLS (< 1.12)
* enable multiplexing for secrets engines
* add changelog
* revert call to ServeMultiplex for pki and transit
* Revert "revert call to ServeMultiplex for pki and transit"
This reverts commit 755be28d14b4c4c4d884d3cf4d2ec003dda579b9.
* Don't use a duplicate sync object for stepwise tests precheck
* Change STS test check to no longer look for a secret, add SetSourceIdentity policy to role
Basics of Cert-Count Telemetry, changelog, "best attempt" slice to capture (and test for) duplicates, Move sorting of possibleDoubleCountedRevokedSerials to after compare of entries. Add values to counter when still initializing.
Set lists to nil after use, Fix atomic2 import, Delay reporting metrics until after deduplication has completed,
The test works now, Move string slice to helper function; Add backendUUID to gauge name.
Update the AWS auth backend acceptance tests to account for the new
`iam_tags` field that comes back on responses.
* marked only tests requiring creds as acceptance
Renamed TestBackend_* to TestAcceptanceBackend_* if the test requires
AWS credentials. Otherwise left the name as TestBackend_* and set
`AcceptanceTest: false`.
* ensure generated names aren't too long
IAM roles and users have a 64 character limit, and adding Acceptance
to the test names was putting some over the length limit, so modified
generateUniqueName() to take a max length parameter and added
functions for each type of name generation (user, role, group).
* update genUsername to cap STS usernames at 64 chars
* add changelog
* refactor tests into t.Run block
* patch: remove warningExpected bool and include expected string
* patch: revert sts to cap at 32 chars and add assume_role case in genUsername
* update changelog
* update genUsername to return error if username generated exceeds length limits
* update changelog
* add conditional default username template to provide custom STS usernames
* update changelog
* include test for failing STS length case
* update comments for more clarity
Unlike the other libraries that were migrated, there are no usages of
this lib in any of our plugins, and the only other known usage was in
go-kms-wrapping, which has been updated. Aliasing it like the other libs
would still keep the aws-sdk-go dep in the sdk module because of the
function signatures. So I've simply removed it entirely here.
* add ability to customize IAM usernames based on templates
* add changelog
* remove unnecessary logs
* patch: add test for readConfig
* patch: add default STS Template
* patch: remove unnecessary if cases
* patch: add regex checks in username test
* patch: update genUsername to return an error instead of warnings
* patch: separate tests for default and custom templates
* patch: return truncate warning from genUsername and trigger a 400 response on errors
* patch: truncate midString to 42 chars in default template
* docs: add new username_template field to aws docs
* feat(aws): add ability to provide a sessionName to sts credentials
Co-authored-by: Brad Vernon <bvernon@nvidia.com>
Co-authored-by: Jim Kalafut <jim@kalafut.net>
Co-authored-by: Tom Proctor <tomhjp@users.noreply.github.com>
* Added support for iam_tags for AWS secret roles
This change allows iam_users generated by the secrets engine
to add custom tags in the form of key-value pairs to users
that are created.
Adds debug and warn logging around AWS credential chain generation,
specifically to help users debugging auto-unseal problems on AWS, by
logging which role is being used in the case of a webidentity token.
Adds a deferred call to flush the log output as well, to ensure logs
are output in the event of an initialization failure.
* add first stepwise test env, Docker, with example transit test
* update transit stepwise test
* add other tests that use stepwise
* cleanup test, make names different than just 'transit'
* return the stderr if compile fails with error
* minor cleanups
* minor cleanups
* go mod vendor
* cleanups
* remove some extra code, and un-export some fields/methods
* update vendor
* remove reference to vault.CoreConfig, which really wasn't used anyway
* update with go mod vendor
* restore Precheck method to test cases
* clean up some networking things; create networks with UUID, clean up during teardown
* vendor stepwise
* Update sdk/testing/stepwise/environments/docker/environment.go
haha thanks :D
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* Update sdk/testing/stepwise/environments/docker/environment.go
Great catch, thanks
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* fix redundant name
* update error message in test
* Update builtin/credential/userpass/stepwise_test.go
More explicit error checking and responding
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* Update builtin/logical/aws/stepwise_test.go
`test` -> `testFunc`
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* Update builtin/logical/transit/stepwise_test.go
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* fix typos
* update error messages to provide clarity
* Update sdk/testing/stepwise/environments/docker/environment.go
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* update error handling / collection in Teardown
* panic if GenerateUUID returns an error
* Update sdk/testing/stepwise/environments/docker/environment.go
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
* Update builtin/credential/userpass/stepwise_test.go
Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com>
* Update builtin/logical/aws/stepwise_test.go
Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com>
* Update builtin/logical/transit/stepwise_test.go
Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com>
* Update sdk/testing/stepwise/environments/docker/environment.go
Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com>
* import ordering
* standardize on dc from rc for cluster
* lowercase name
* CreateAPIClient -> NewAPIClient
* testWait -> ensure
* go mod cleanup
* cleanups
* move fields and method around
* make start and dockerclusternode private; use better random serial number
* use better random for SerialNumber
* add a timeout to the context used for terminating the docker container
* Use a constant for the Docker client version
* rearrange import statements
Co-authored-by: Michael Golowka <72365+pcman312@users.noreply.github.com>
Co-authored-by: Calvin Leung Huang <cleung2010@gmail.com>
Allows vault roles to be associated with IAM groups in the AWS
secrets engine, since IAM groups are a recommended way to manage
IAM user policies. IAM users generated against a vault role will
be added to the IAM Groups. For a credential type of
`assumed_role` or `federation_token`, the policies sent to the
corresponding AWS call (sts:AssumeRole or sts:GetFederation) will
be the policies from each group in `iam_groups` combined with the
`policy_document` and `policy_arns` parameters.
Co-authored-by: Jim Kalafut <jkalafut@hashicorp.com>
* secrets/aws: Support permissions boundaries on iam_user creds
This allows configuring Vault to attach a permissions boundary policy to
IAM users that it creates, configured on a per-Vault-role basis.
* Fix indentation of policy in docs
Use spaces instead of tabs
I probably left this cleanup commented out as part of debugging test
errors in #6789 and forgot to uncomment it, so actually cleaning up the
test user.
* secret/aws: Pass policy ARNs to AssumedRole and FederationToken roles
AWS now allows you to pass policy ARNs as well as, and in addition to,
policy documents for AssumeRole and GetFederationToken (see
https://aws.amazon.com/about-aws/whats-new/2019/05/session-permissions/).
Vault already collects policy ARNs for iam_user credential types; now it
will allow policy ARNs for assumed_role and federation_token credential
types and plumb them through to the appropriate AWS calls.
This brings along a minor breaking change. Vault roles of the
federation_token credential type are now required to have either a
policy_document or a policy_arns specified. This was implicit
previously; a missing policy_document would result in a validation error
from the AWS SDK when retrieving credentials. However, it would still
allow creating a role that didn't have a policy_document specified and
then later specifying it, after which retrieving the AWS credentials
would work. Similar workflows in which the Vault role didn't have a
policy_document specified for some period of time, such as deleting the
policy_document and then later adding it back, would also have worked
previously but will now be broken.
The reason for this breaking change is because a credential_type of
federation_token without either a policy_document or policy_arns
specified will return credentials that have equivalent permissions to
the credentials the Vault server itself is using. This is quite
dangerous (e.g., it could allow Vault clients access to retrieve
credentials that could modify Vault's underlying storage) and so should
be discouraged. This scenario is still possible when passing in an
appropriate policy_document or policy_arns parameter, but clients should
be explicitly aware of what they are doing and opt in to it by passing
in the appropriate role parameters.
* Error out on dangerous federation token retrieval
The AWS secrets role code now disallows creation of a dangerous role
configuration; however, pre-existing roles could have existed that would
trigger this now-dangerous code path, so also adding a check for this
configuration at credential retrieval time.
* Run makefmt
* Fix tests
* Fix comments/docs
This refactors role validation for the AWS secrets engine to be in a
separate method. Previously, all validation was interspersed with the
parsing of parameters when creating/updating a role, which led to a high
degree of complexity. Now, all validation is centralized which makes it
easier to understand and also easier to test (and so a number of test
cases have been added).
