* Update aws auth docs with new semantics
Moving away from implicitly globbed bound_iam_role_arn and
bound_iam_instance_profile_arn variables to make them explicit
* Refactor tests to reduce duplication
auth/aws EC2 login tests had the same flow duplicated a few times, so
refactoring to reduce duplication
* Add tests for aws auth explicit wildcard constraints
* Remove implicit prefix matching from AWS auth backend
In the aws auth backend, bound_iam_role_arn and
bound_iam_instance_profile_arn were ALWAYS prefix matched, and there was
no way to opt out of this implicit prefix matching. This now makes the
implicit prefix matching an explicit opt-in feature by requiring users
to specify a * at the end of an ARN if they want the prefix matching.
* auth/aws: Allow binding by EC2 instance IDs
This allows specifying a list of EC2 instance IDs that are allowed to
bind to the role. To keep style formatting with the other bindings, this
is still called bound_ec2_instance_id rather than bound_ec2_instance_ids
as I intend to convert the other bindings to accept lists as well (where
it makes sense) and keeping them with singular names would be the
easiest for backwards compatibility.
Partially fixes#3797
* Accept temp creds in AWS secret backend acceptance tests
The AWS secret backend acceptance tests implicitly accepted long-lived
AWS credentials (i.e., AWS IAM user and/or root credentials) in two
ways:
1. It expected credentials to be passed in via the AWS_ACCESS_KEY_ID and
AWS_SECRET_ACCESS_KEY environment variables. By not accepting
AWS_SESSION_TOKEN or AWS_SECURITY_TOKEN, temporary credentials could
not be passed in. (This also forced all credentials to be passed in
via environment variables, which is a bit ugly).
2. The AWS sts:GetFederationToken call is only allowed from long-term
credentials. This is called by the Vault code which the acceptance
tests exercise.
1 is solved by deleting explicit references to credentials, which allows
the SDK to do one of the things it does best -- find credentials via the
default chain.
2 is a little more complicated. Rather than pass in whatever creds the
acceptance test was run under to the backend, the acceptance test now
creates a new IAM user and gets an access key from it, then passes the
IAM user's creds back to the backend so that it can call
sts:GetFederationToken (and then tries to clean up afterwards).
* Fix Travis build failure
The Travis build was failing because the user creation was happening
regardless of whether it was running in acceptance test mode or not.
This moves the user creation into the acceptance test precheck, which
requires lazily evaluating the credentials when configuring the backend
in the STS accetpance test, and so moving that to a PreFlight closure.
* Reduce blind sleeps in AWS secret backend acceptance tests
This removes a blind "sleep 10 seconds and then attempt to reuse the
credential" codepath and instead just keeps attemtping to reuse the
credential for 10 seconds and fails if there aren't any successful uses
after 10 seconds. This adds a few seconds speedup of acceptance test
runs from my experiments.
* auth/aws: Allow lists in binds
In the aws auth method, allow a number of binds to take in lists
instead of a single string value. The intended semantic is that, for
each bind type set, clients must match at least one of each of the bind
types set in order to authenticate.
Previously the functional test was only testing the PCKS7-signed identity
document, not the detached RSA signature, so adding a test for that in the
functional test suite.
* Verify DNS SANs if PermittedDNSDomains is set
* Use DNSNames check and not PermittedDNSDomains on leaf certificate
* Document the check
* Add RFC link
* Test for success case
* fix the parameter name
* rename the test
* remove unneeded commented code
* added a flag to make common name optional if desired
* Cover one more case where cn can be empty
* remove skipping when empty; instead check for emptiness before calling validateNames
* Add verification before adding to DNS names to also fix#3918
strings.HasPrefix is more correct; if a tag part value ended up
containing the expected prefix of another part, it could cause incorrect
parsing. I don't think that these values would be semantically legal
today, but it's probably better to be defensive.
* Differentiate between user/internal error in AppRole login.
This allows us to properly pass through internal errors back up into
core.
* Separate out error cases
