aws auth backend fail to verify signature

[jippi]

Environment:

• Vault Version: v0.9.4

auth backend: aws-ec2
auth role auth_type: ec2

Expected Behavior:

successful ec2 auth

Actual Behavior:

failed ec2 auth:

* failed to verify the signature

Steps to Reproduce:

vault write -address http://active.vault.service.consul:8200 -format json auth/aws/login role=$role pkcs7="$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/pkcs7 | tr -d '\n')" nonce=${nonce}

Important Factoids:

Worked on 0.9.3

[joelthompson]

Hey @jippi -- I dug into this a bit, and I think this is caused by fullsailor/pkcs7#29 (the PKCS7 library Vault uses internally) which is triggered by 0.9.4's upgrade to golang 1.10.

As a workaround, you can use the identity and signature parameters (as they don't use pkcs7), e.g.:

$ vault write auth/aws/login identity=$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | base64 -w 0) signature=$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/signature | tr -d '\n') role=<ROLE_NAME>

[jippi]

@joelthompson alright, I've just rolled back to 0.9.3 for now - didn't need anything from 0.9.4 anyway - is it possible to add a test to Vault to cover this case so it won't be a regression in the future?

[joelthompson]

There already is a test for this and it caught the regression, but that test is a manually run acceptance test because it makes real AWS API calls and so requires a valid EC2 instance identity document from an EC2 instance that is currently running, and it also requires valid AWS credentials in order to validate the instance. That's why it's not run as part of Travis builds for each PR, and I can only speculate that that's also probably why it wasn't run post-go1.10 upgrade but can't speak with any authority on that (I'm not a Vault team member, just a community member who works mostly on the AWS auth backend). I have been thinking a bit recently about how to improve overall testability so that these kinds of tests don't require valid EC2 instances, API creds, etc., and this is another great use case of why that would be valuable, but I don't have anything concrete (yet).

[jefferai]

@jippi We have some things in progress internally to get a test server up for exactly this kind of thing.