In addition to the specific permissions that are already mentioned, the project also needs the `iam.googleapis.com` API enabled, otherwise authenticating will fail with an error similar to:
```
Error authenticating: Error making API request.
URL: PUT https://localhost:8200/v1/auth/gcp/login
Code: 400. Errors:
* could not find service account key or Google Oauth cert with given 'kid' id
```
* allow passing a path for options so that it can be extracted from the model
* add cred type selector for the aws generate form
* style hint text on generate creds form
* add tests for aws-credential adapter
* allow for the case where we might have zero ttl
* show error for TTL picker if a non-number is entered for the duration part of the TTL
* fix positioning of tooltips
* fix ttl rendering with invalid input for initialValue
* allow for enterprise init attributes
* allow moving from init to auth in the init flow on the tutorial machine
* show loading spinner while cluster is unsealing
* use seal-status type to determine the init attrs
* add init acceptance tests
* stored_shares should always be 1
* fix lint
* format template
* remove explicity model attr from init controller
Specifying the `allowed_organiztaional_units` parameter to a cert auth
backend role will require client certificates to contain at least one of
a list of one or more "organizational units" (OU).
Example use cases:
Certificates are issued to entities in an organization arrangement by
organizational unit (OU). The OU may be a department, team, or any other logical
grouping of resources with similar roles. The entities within the OU
should be granted the same policies.
```
$ vault write auth/cert/certs/ou-engineering \
certificate=@ca.pem \
policies=engineering \
allowed_organiztaional_units=engineering
$ vault write auth/cert/certs/ou-engineering \
certificate=@ca.pem \
policies=engineering \
allowed_organiztaional_units=engineering,support
```
* logical/aws: Harden WAL entry creation
If AWS IAM user creation failed in any way, the WAL corresponding to the
IAM user would get left around and Vault would try to roll it back.
However, because the user never existed, the rollback failed. Thus, the
WAL would essentially get "stuck" and Vault would continually attempt to
roll it back, failing every time. A similar situation could arise if the
IAM user that Vault created got deleted out of band, or if Vault deleted
it but was unable to write the lease revocation back to storage (e.g., a
storage failure).
This attempts to harden it in two ways. One is by deleting the WAL log
entry if the IAM user creation fails. However, the WAL deletion could
still fail, and this wouldn't help where the user is deleted out of
band, so second, consider the user rolled back if the user just doesn't
exist, under certain circumstances.
Fixes#5190
* Fix segfault in expiration unit tests
TestExpiration_Tidy was passing in a leaseEntry that had a nil Secret,
which then caused a segfault as the changes to revokeEntry didn't check
whether Secret was nil; this is probably unlikely to occur in real life,
but good to be extra cautious.
* Fix potential segfault
Missed the else...
* Respond to PR feedback
The addition of CheckMigration to the server startup process means
that physical backends in this test need to be able to respond to Get() without error.
* auth/aws: Make identity alias configurable
This is inspired by #4178, though not quite exactly what is requested
there. Rather than just use RoleSessionName as the Identity alias, the
full ARN is uses as the Alias. This mitigates against concerns that an
AWS role with an insufficiently secured trust policy could allow an
attacker to generate arbitrary RoleSessionNames in AssumeRole calls to
impersonate anybody in the Identity store that had an alias set up.
By using the full ARN, the owner of the identity store has to explicitly
trust specific AWS roles in specific AWS accounts to generate an
appropriate RoleSessionName to map back to an identity.
Fixes#4178
* Respond to PR feedback
* Remove CreateOperation
Response to PR feedback
* Add AWS Secret Engine Root Credential Rotation
This allows the AWS Secret Engine to rotate its credentials used to
access AWS. This will only work when the AWS Secret Engine has been
provided explicit IAM credentials via the config/root endpoint, and
further, when the IAM credentials provided are the only access key on
the IAM user associated wtih the access key (because AWS allows a
maximum of 2 access keys per user).
Fixes#4385
* Add test for AWS root credential rotation
Also fix a typo in the root credential rotation code
* Add docs for AWS root rotation
* Add locks around reading and writing config/root
And wire the backend up in a bunch of places so the config can get the
lock
* Respond to PR feedback
* Fix casing in error messages
* Fix merge errors
* Fix locking bugs
* Parallelize a couple AWS acceptance tests
Starting an effort to paralleize AWS secret engine acceptance tests.
Currently they take over a minute to run, and this parallelizes the two
that explicitly call a 10-second sleep, reulting in a 10-second speedup
in test time.
* Parameterize IAM user name
Probably not needed, but future-proofing the code
* Make remainder of tests parallel
AWS_ACCOUNT_ID environment variable is no longer being used; global
mutable state is a recipe for disaster when trying to run things in
parallel, and parallelizing the tests exposed a race condition in which
they were depending on the AWS_ACCOUNT_ID environment variable to be set
before they were run.
AWS_DEFAULT_REGION is still left as an environment variable because it
is required by AWS SDKs, but its configuration is now protected by a
sync.Once to ensure it only ever gets called a single time.
* Replace generateUnique*Name with testhelpers method
* Add test file for testing path_restore in Transit backend. Fails because 'force' is not implemented yet
* initial implementation of 'force', to force restore of existing transit key atomically
