Vault AWS IAM auth configuration problem.
1,093 views
Skip to first unread message
Kamil Sebastian
Sep 24, 2019, 11:45:09 AM9/24/19
to Vault
I am trying to configure Vault with AWS IAM auth method, but with no luck.
and following policies applied to that role:
I have Vault deployed in AWS, with role:
arn:aws:iam::123456789012:role/vault-ec2-role
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::vault-resources", "arn:aws:s3:::vault-data" ] }, { "Sid": "", "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": "arn:aws:s3:::vault-resources/resources/*" }, { "Sid": "", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::vault-data/*" }, { "Sid": "", "Effect": "Allow", "Action": "dynamodb:*", "Resource": [ "arn:aws:dynamodb:eu-west-1:123456789012:table/vault-ha-coordination/*", "arn:aws:dynamodb:eu-west-1:123456789012:table/vault-ha-coordination" ] }, { "Sid": "", "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:DescribeKey", "kms:Decrypt" ], "Resource": "arn:aws:kms:eu-west-1:123456789012:key/xxxxx-yyyyy-abcd-1234-567890" } ]}{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "iam:GetRole", "sts:AssumeRole", "ec2:DescribeInstances", "iam:GetInstanceProfile", "iam:GetUser", "sts:GetCallerIdentity" ], "Resource": "*" } ]}{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::user-data-deploy" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::user-data-deploy/*" ] } ]}{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetReplicationConfiguration" ], "Resource": "arn:aws:s3:::vault-data" }, { "Sid": "", "Effect": "Allow", "Action": [ "s3:GetObjectVersionAcl", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::vault-data/*" }, { "Sid": "", "Effect": "Allow", "Action": [ "s3:ReplicateObject", "s3:ReplicateDelete" ], "Resource": "arn:aws:s3:::vault-data-dr/*" } ]}{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetReplicationConfiguration" ], "Resource": "arn:aws:s3:::vault-resources" }, { "Sid": "", "Effect": "Allow", "Action": [ "s3:GetObjectVersionAcl", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::vault-resources/resources/*" }, { "Sid": "", "Effect": "Allow", "Action": [ "s3:ReplicateObject", "s3:ReplicateDelete" ], "Resource": "arn:aws:s3:::vault-resources-dr/resources/*" } ]}Then, as described here: https://github.com/hashicorp/terraform-aws-vault/tree/master/examples/vault-iam-auth
I ran in my Vault server cli:
$ vault auth enable aws
Success! Enabled aws auth method at: aws/
$ vault write auth/aws/role/xy auth_type=iam policies=policy max_ttl=180h bound_iam_principal_arn=arn:aws:iam::123456789012:*
Success! Data written to: auth/aws/role/xy
Then in my client (on my laptop) I am trying to login:
$ vault login -method=aws header_value=https://vault.domain.net role=xy
Error authenticating: Error making API request.
URL: PUT https://domain.net/v1/auth/aws/login
Code: 400. Errors:
* error making upstream request: received error code 403 from STS: <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<Error>
<Type>Sender</Type>
<Code>SignatureDoesNotMatch</Code>
<Message>Credential should be scoped to a valid region, not 'eu-west-1'. </Message>
</Error>
<RequestId>x-y-z-a-bcde</RequestId>
</ErrorResponse>
Any idea what I am doing wrong and where?
Becca Petrin
Sep 24, 2019, 12:19:07 PM9/24/19
to Vault
Hi Kamil,
I think what's happening is that the server you're logging in from is in "eu-west-1" and the AWS SDK that Vault uses is seeing that there's no STS region for that one. It's ultimately looking here for a match for that region. The code in Vault that controls which region is picked up by that login call is located here. Based on that, you should be able to override which region it uses for logging in by doing `$ export AWS_REGION=foo` on the server from which you're logging in.
What happens if you set the region to one of the ones with a listed STS endpoint, then run the login command again?
Thanks,
Becca
Vasilev Vjacheslav
Sep 25, 2019, 1:07:06 AM9/25/19
to Vault
Alternatively you may add "region" parameter at the end of the "vault login" command
Kamil Sebastian
Sep 25, 2019, 4:28:45 AM9/25/19
to Vault
That doesn't make any difference:
$ printenv | grep AWSAWS_ACCESS_KEY=AKIAAWS_SECRET_KEY=xyzAWS_REGION=eu-west-1$ vault login -method=aws header_value=https://vault.domain.net role=vault-ec2-roleError authenticating: Error making API request.
Code: 400. Errors:
* error making upstream request: received error code 403 from STS: <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/"> <Error> <Type>Sender</Type> <Code>SignatureDoesNotMatch</Code> <Message>Credential should be scoped to a valid region, not 'eu-west-1'. </Message> </Error> <RequestId>1-2-3-4-5</RequestId></ErrorResponse>$ vault login -method=aws header_value=https://vault.domain.net role=vault-ec2-role region=eu-west-1Error authenticating: Error making API request.
Code: 400. Errors:
* error making upstream request: received error code 403 from STS: <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/"> <Error> <Type>Sender</Type> <Code>SignatureDoesNotMatch</Code> <Message>Credential should be scoped to a valid region, not 'eu-west-1'. </Message> </Error> <RequestId>1-2-3-4-5</RequestId></ErrorResponse>$ vault login -method=aws header_value=https://vault.domain.net role=vault-ec2-role -region=eu-west-1Error authenticating: Error making API request.
Code: 400. Errors:
* error making upstream request: received error code 403 from STS: <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/"> <Error> <Type>Sender</Type> <Code>SignatureDoesNotMatch</Code> <Message>Credential should be scoped to a valid region, not 'eu-west-1'. </Message> </Error> <RequestId>1-2-3-4-5</RequestId></ErrorResponse>Kamil Sebastian
Sep 25, 2019, 4:44:45 AM9/25/19
to Vault
Also, I am not logging in from the server/ec2 instance in AWS, I am trying to login from my laptop.
On Tuesday, 24 September 2019 17:19:07 UTC+1, Becca Petrin wrote:
Kamil Sebastian
Sep 25, 2019, 6:43:11 AM9/25/19
to Vault
ok, I have made some progress on that, but still have issues. So the main issue was misconfigured AWS endpoints in AWS method configuration (https://vault.domain.net/ui/vault/settings/auth/configure/aws/client). Now all of them point to the right URLs:
However, the error I have now is:
$ vault login -method=aws header_value=vault.domain.net role=vault-ec2-roleError authenticating: Error making API request.
Code: 400. Errors:
* error looking up full ARN of entity &{aws 123456789012 user kamil.x_y }: error creating IAM client: unable to fetch current caller: SignatureDoesNotMatch: Credential should be scoped to a valid region, not 'ap-southeast-1'. status code: 403, request id: 308529fe-df7d-11e9-a831-811e2cea1d70where the region name is changing randomly on each login attempt.
Ivan Varbanov
Sep 25, 2019, 11:31:59 AM9/25/19
to vault...@googlegroups.com
Try adding region=eu-west-1 in your vault login command. I have been struggling with this few releases ... before 1.2.3 version I had to specify the sts endpoint in the aws client .... however with 1.2.3 I run into different issues so what I ended up is remove any custom endpoints I added and leave everything to the default ... then on the vault clients I just provide region us-east-1 since thats the "default" sts region ... otherwise I would always run into that signature issue :(
--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/fea8f5c4-1853-429b-9449-31e454ff03ea%40googlegroups.com.
Kamil Sebastian
Sep 25, 2019, 11:53:25 AM9/25/19
to Vault
It doesn't make any difference if I specify region in my login command line or not. If I remove endpoints from the method configuration then I am again in the place from my first post.
If I change sts endpoint to sts.amazonaws.com (without region) then I am getting error (like without sts endpoint configured):
$ vault login -method=aws header_value=vault.domain.net role=x region=eu-west-1
Error authenticating: Error making API request.
URL: PUT https://vault.domain.net/v1/auth/aws/login
Code: 400. Errors:
* error making upstream request: received error code 403 from STS: <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<Error>
<Type>Sender</Type>
<Code>SignatureDoesNotMatch</Code>
<Message>Credential should be scoped to a valid region, not 'eu-west-1'. </Message>
</Error>
<RequestId>b7f1a7a2-dfab-11e9-a411-d5eb5055ab90</RequestId>
</ErrorResponse>
if sts endpoint is set to: https://sts.eu-west-1.amazonaws.com then the error message is:
$ vault login -method=aws header_value=vault.domain.net role=x region=eu-west-1
Error authenticating: Error making API request.
URL: PUT https://vault.domain.net/v1/auth/aws/login Code: 400.
Errors:
* error looking up full ARN of entity &{aws 123456789012 user kamil.x_y }: error creating IAM client: unable to fetch current caller: SignatureDoesNotMatch: Credential should be scoped to a valid region, not 'ap-southeast-1'.
status code: 403, request id: ce131761-dfab-11e9-a12d-d390132286d5
where the `ap-southeast-1` is changing to random region on each request.
brgds,
Ivan Varbanov
Sep 25, 2019, 11:55:40 AM9/25/19
to vault...@googlegroups.com
Is your vault client and vault server the same versions? Which version are they?
--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/23820256-6f8b-4961-9ade-bfdce72436b9%40googlegroups.com.
Kamil Sebastian
Sep 25, 2019, 11:57:24 AM9/25/19
to Vault
And here is my vault aws method role config:
$ vault read auth/aws/role/x
Key Value
--- -----
allow_instance_migration false
auth_type iam
bound_account_id [123456789012]
bound_ami_id []
bound_ec2_instance_id <nil>
bound_iam_instance_profile_arn []
bound_iam_principal_arn [arn:aws:iam::123456789012:role/*]
bound_iam_principal_id []
bound_iam_role_arn []
bound_region []
bound_subnet_id []
bound_vpc_id []
disallow_reauthentication false
inferred_aws_region eu-west-1
inferred_entity_type ec2_instance
max_ttl 180h
policies [x]
resolve_aws_unique_ids true
role_id 1-2-3-4-5
role_tag n/a
token_bound_cidrs []
token_explicit_max_ttl 0s
token_max_ttl 180h
token_no_default_policy false
token_num_uses 0
token_period 0s
token_policies [devops]
token_ttl 0s
token_type default
Kamil Sebastian
Sep 25, 2019, 12:04:38 PM9/25/19
to vault...@googlegroups.com
Yes, both are 1.2.1. Server is running in AWS while the client is on my laptop.
Sent from my mobile.
Tel. / Signal. +44 758 306 8467
Tel. / Signal. +44 758 306 8467
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CANOW0dV%2BjbAXDkNWWCYdj8AOCG27Vf8R2DxkzUN1Q8XJTP3fVw%40mail.gmail.com.
Becca Petrin
Sep 25, 2019, 12:21:56 PM9/25/19
to Vault
Hi,
In looking back, I notice that when you show your env like this:
$ printenv | grep AWS
AWS_ACCESS_KEY=AKIA
AWS_SECRET_KEY=xyz
AWS_REGION=eu-west-1
I see that the region still hasn't been updated to a valid one. "ap-southeast-1" is also not valid per here.
I can duplicate your error through the following steps.
$ vault auth enable aws
$ vault write auth/aws/config/client secret_key=redacted access_key=redacted
$ vault write auth/aws/role/dev-role-iam auth_type=iam \
bound_iam_principal_arn=redacted policies=prod,dev
$ export AWS_REGION=ap-southeast-1
$ vault login -method=aws header_value=vault.example.com role=dev-role-iam
Error authenticating: Error making API request.
Code: 400. Errors:
* error making upstream request: received error code 403 from STS: <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<Error>
<Type>Sender</Type>
<Code>SignatureDoesNotMatch</Code>
<Message>Credential should be scoped to a valid region, not 'ap-southeast-1'. </Message>
</Error>
<RequestId>a8bf97e4-dfaf-11e9-a293-dff97ec75868</RequestId>
</ErrorResponse>
But if I then update my region and try again, it resolves.
$ export AWS_REGION=us-east-1
$ vault login -method=aws header_value=vault.example.com role=dev-role-iam
WARNING! The VAULT_TOKEN environment variable is set! This takes precedence
over the value set by this command. To use the value set by this command,
unset the VAULT_TOKEN environment variable or set it to the token displayed
below.
Success! You are now authenticated......
Could you try simplifying your config and role as shown above, then exporting a different region, then logging in again?
Thanks,
Becca
On Wednesday, September 25, 2019 at 9:04:38 AM UTC-7, Kamil Sebastian wrote:
Yes, both are 1.2.1. Server is running in AWS while the client is on my laptop.Sent from my mobile.
Tel. / Signal. +44 758 306 8467
To unsubscribe from this group and stop receiving emails from it, send an email to vault...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/23820256-6f8b-4961-9ade-bfdce72436b9%40googlegroups.com.
--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault...@googlegroups.com.
Kamil Sebastian
Sep 26, 2019, 10:39:41 AM9/26/19
to Vault
Hi Becca,
I started from scratch:
$ printenv | grep AWSAWS_REGION=us-east-1
$ vault auth enable awsSuccess! Enabled aws auth method at: aws/
$ vault write auth/aws/config/client secret_key=xyz access_key=abcdSuccess! Data written to: auth/aws/config/client
$ vault write auth/aws/role/role_name_corresponding_to_the_one_in_aws auth_type=iam policies=policy max_ttl=180h bound_iam_principal_arn=arn:aws:iam::123456789012:role/*Success! Data written to: auth/aws/role/role_name_corresponding_to_the_one_in_awsNow from Vault server EC2 instance:
$ vault login -method=aws role=role_name_corresponding_to_the_one_in_aws header_value=vault.domain.netSuccess! You are now authenticated. The token information displayed belowis already stored in the token helper. You do NOT need to run "vault login"again. Future Vault requests will automatically use this token.
WARNING! The following warnings were returned from Vault:
* TTL of "192h0m0s" exceeded the effective max_ttl of "180h0m0s"; TTL value is capped accordingly
Key Value--- -----token s.dssdfsdftoken_accessor sdsdfdfgetoken_duration 180htoken_renewable truetoken_policies ["default" "policy"]identity_policies []policies ["default" "policy"]token_meta_client_arn arn:aws:sts::123456789012:assumed-role/role_name_corresponding_to_the_one_in_aws/i-0123sdsdftoken_meta_client_user_id AROXXXtoken_meta_inferred_entity_id n/atoken_meta_inferred_entity_type n/atoken_meta_role_id asdsadasd-asasd-asdasd-asdasd-asdasdtoken_meta_account_id 123456789012token_meta_auth_type iamtoken_meta_canonical_arn arn:aws:iam::123456789012:role/role_name_corresponding_to_the_one_in_awstoken_meta_inferred_aws_region n/aBut, from client on my laptop I am getting different error:
$ vault login -method=aws header_value=vault.domain.net role=role_name_corresponding_to_the_one_in_awsError authenticating: Error making API request.
Code: 400. Errors:
* IAM Principal "arn:aws:iam::123456789012:user/kamil.x_y" does not belong to the role "role_name_corresponding_to_the_one_in_aws"Any idea on that? My user has two AWS system policies attached: AdministratorAccess and IAMUserChangePassword. Also on the server for test purposes I am using my AWS credentials (vault write auth/aws/config/client secret_key=xyz access_key=abcd)
brgds,
Kamil
Becca Petrin
Sep 26, 2019, 12:19:50 PM9/26/19
to Vault
Hi Kamil,
This is actually great news! That means we've graduated from the region-related errors, we're talking to STS now, and we're on to the next thing.
That error happens when you've configured a role to assume (arn:aws:iam::123456789012:role/*) that you're not allowed to assume from the client that's logging in. I'm guessing you've configured your laptop with your own AWS key and secret. They could either be in your environment variables, or in a file if you've been using their command-line tool and you've run "$ aws configure". I'm on Linux and AWS stores my credentials at ~/.aws/credentials.
Anyways, the login method is picking up who you are from your laptop's environment, sending it to Vault, and Vault is sending that to STS to see if you're allowed to assume that role. It's finding you're not allowed.
To give yourself access, assuming that you should have it and that you're the user configured on your laptop, you'd need to add this IAM policy to yourself:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/*"
}
}
Or under "Resource" you'd list a specific role instead of a wildcard. I believe that's all you need, but it's been a few weeks since I tested it through. If you Google "AWS assume role" you'll find various resources that are more specific on configuring the IAM policies in the AWS console.
-B
Kamil Sebastian
Sep 27, 2019, 7:17:22 AM9/27/19
to Vault
Hi Becca,
It doesn't seems to be working either. I have re-created two roles in the Vault:
$ vault delete auth/aws/role/role_name_corresponding_to_the_one_in_awsSuccess! Data deleted (if it existed) at: auth/aws/role/role_name_corresponding_to_the_one_in_aws$ vault delete auth/aws/role/xyzSuccess! Data deleted (if it existed) at: auth/aws/role/xyz
$ vault read auth/aws/role/xyzKey Value--- -----allow_instance_migration falseauth_type iambound_account_id []bound_ami_id []bound_ec2_instance_id <nil>bound_iam_instance_profile_arn []bound_iam_principal_arn [arn:aws:iam::123456789012:role/*]bound_iam_principal_id []bound_iam_role_arn []bound_region []bound_subnet_id []bound_vpc_id []disallow_reauthentication falseinferred_aws_region n/ainferred_entity_type n/amax_ttl 180hpolicies [xyz]resolve_aws_unique_ids truerole_id 2a17f9b5-fb16-f783-36f6-3e74227c95fcrole_tag n/atoken_bound_cidrs []token_explicit_max_ttl 0stoken_max_ttl 180htoken_no_default_policy falsetoken_num_uses 0token_period 0stoken_policies [xyz]token_ttl 0stoken_type default
$ vault read auth/aws/role/role_name_corresponding_to_the_one_in_awsKey Value--- -----allow_instance_migration falseauth_type iambound_account_id []bound_ami_id []bound_ec2_instance_id <nil>bound_iam_instance_profile_arn []bound_iam_principal_arn [arn:aws:iam::123456789012:role/role_name_corresponding_to_the_one_in_aws]bound_iam_principal_id [AROXXX]bound_iam_role_arn []bound_region []bound_subnet_id []bound_vpc_id []disallow_reauthentication falseinferred_aws_region n/ainferred_entity_type n/amax_ttl 180hpolicies [xyz]resolve_aws_unique_ids truerole_id 344dca2a-3763-ac98-c318-7643dca8acadrole_tag n/atoken_bound_cidrs []token_explicit_max_ttl 0stoken_max_ttl 180htoken_no_default_policy falsetoken_num_uses 0token_period 0stoken_policies [xyz]token_ttl 0stoken_type defaultThen successfully logged in on server using the second one:
$ vault login -method=aws role=x-y-vault-ec2-role header_value=vault.domain.net
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
WARNING! The following warnings were returned from Vault:
* TTL of "192h0m0s" exceeded the effective max_ttl of "180h0m0s"; TTL value
is capped accordingly
Key Value
--- -----
token s.sdff
token_accessor sdfsdf
token_duration 180h
token_renewable true
token_policies ["default" "xyz"]
identity_policies []
policies ["default" "xyz"]
token_meta_inferred_entity_type n/a
token_meta_role_id 344dca2a-3763-ac98-c318-7643dca8acad
token_meta_auth_type iam
token_meta_canonical_arn arn:aws:iam::123456789012:role/role_name_corresponding_to_the_one_in_aws
token_meta_client_arn arn:aws:sts::123456789012:assumed-role/role_name_corresponding_to_the_one_in_aws/i-sdfdfds
token_meta_client_user_id AROXXXX
token_meta_inferred_entity_id n/a
token_meta_account_id 123456789012
token_meta_inferred_aws_region n/a
Then created new AWS policy as you mentioned and applied to my user but still got the same error on the client in my laptop:
$ vault login -method=aws header_value=vault.domain.net role=x-y-vault-ec2-roleError authenticating: Error making API request.
Code: 400. Errors:
* IAM Principal "arn:aws:iam::123456789012:user/kamil.x_y" does not belong to the role "x-y-vault-ec2-role"So I applied the same set of Policies I have on my Vault EC2 instances to my user:
$ aws iam list-attached-role-policies --role-name role_name_corresponding_to_the_one_in_aws{ "AttachedPolicies": [ { "PolicyName": "x-y-vault-ec2-policy", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-ec2-policy" }, { "PolicyName": "x-y-vault-aws-auth-policy", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-aws-auth-policy" }, { "PolicyName": "x-y-vault-user-data-policy", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-user-data-policy" }, { "PolicyName": "x-y-vault-aws-auth-policy-2", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-aws-auth-policy-2" } ]}
$ aws iam list-attached-user-policies --user-name kamil.x_y{ "AttachedPolicies": [ { "PolicyName": "AdministratorAccess", "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess" }, { "PolicyName": "IAMUserChangePassword", "PolicyArn": "arn:aws:iam::aws:policy/IAMUserChangePassword" }, { "PolicyName": "Vault-any-role-access", "PolicyArn": "arn:aws:iam::123456789012:policy/Vault-any-role-access" }, { "PolicyName": "x-y-vault-ec2-policy", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-ec2-policy" }, { "PolicyName": "x-y-vault-aws-auth-policy", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-aws-auth-policy" }, { "PolicyName": "x-y-vault-user-data-policy", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-user-data-policy" }, { "PolicyName": "x-y-vault-aws-auth-policy-2", "PolicyArn": "arn:aws:iam::123456789012:policy/x-y-vault-aws-auth-policy-2" } ]}where the Vault-any-role-access content is:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "*" } ]}x-y-vault-aws-auth-policy is:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetRole", "iam:GetUser" ], "Resource": [ "arn:aws:iam::*:user/*", "arn:aws:iam::*:role/*" ] } ]}x-y-vault-aws-auth-policy-2 is:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:GetCallerIdentity", "sts:AssumeRole" ], "Resource": "*" } ]}and the role_name_corresponding_to_the_one_in_aws:
{ "Role": { "Description": "allows the vault ec2 nodes to access resources", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ ] } } ] }, "MaxSessionDuration": 3600, "RoleId": "AROXXX", "CreateDate": "2019-09-05T14:41:26Z", "Tags": [ { "Value": "x-y", "Key": "Environment" }, { "Value": "domain.net", "Key": "Environment-FQDN" }, { "Value": "terraform", "Key": "Managed_by" }, { "Value": "services", "Key": "EnvironmentType" }, { "Value": "xyz", "Key": "Owner" } ], "RoleName": "x-y-vault-ec2-role", "Path": "/", "Arn": "arn:aws:iam::123456789012:role/x-y-vault-ec2-role" }}Is there anything I missed?
brgds,
Kamil.
Kamil Sebastian
Sep 27, 2019, 11:38:49 AM9/27/19
to Vault
Interesting. If I write a role on the server:
$ vault write auth/aws/role/x auth_type=iam policies=devops max_ttl=180h bound_iam_principal_arn=arn:aws:iam::123456789012:user/*
Success! Data written to: auth/aws/role/x
then, almost success! I am able to login from my laptop:
$ vault login -method=aws role=x header_value=vault.domain.net
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
WARNING! The following warnings were returned from Vault:
* TTL of "192h0m0s" exceeded the effective max_ttl of "180h0m0s"; TTL value
is capped accordingly
Key Value
--- -----
token s.asd
token_accessor asd
token_duration 180h
token_renewable true
token_policies ["default" "devops"]
identity_policies []
policies ["default" "devops"]
token_meta_inferred_entity_type n/a
token_meta_role_id be3cd697-f2bc-7dc8-6b31-4c5e8c44f4d5
token_meta_client_arn arn:aws:iam::123456789012:user/kamil.x_y
token_meta_inferred_entity_id n/a
token_meta_canonical_arn arn:aws:iam::123456789012:user/kamil.x_y
token_meta_client_user_id AIDAXXXX
token_meta_inferred_aws_region n/a
token_meta_account_id 123456789012
token_meta_auth_type iam
but that means that any user in this particular AWS account can login, which is not something I want. So ideally would be to write a role like:
$ vault write auth/aws/role/x auth_type=iam policies=devops max_ttl=180h bound_iam_principal_arn=arn:aws:iam::123456789012:user/kamil.x_y
but doesn't work as it is unable to resolve ARN.
So I am nearly there.
brgds,
Kamil
On Thursday, 26 September 2019 17:19:50 UTC+1, Becca Petrin wrote:
David Mattia
Feb 4, 2020, 7:04:46 PM2/4/20
to Vault
Sorry for the super late reply here, but I encountered almost the exact same set of issues as Kamil did and found a solution.
By setting `resolve_aws_unique_ids` to false on the role, I am able to consistently create the role.
I'm unsure where the code is that looks up the role id given the arn, but it seems to be hitting a random endpoint (and not the sts endpoint specified in my backend_client).
Seeing as we both hit this, maybe it's worth looking into if this is a bug
By setting `resolve_aws_unique_ids` to false on the role, I am able to consistently create the role.
I'm unsure where the code is that looks up the role id given the arn, but it seems to be hitting a random endpoint (and not the sts endpoint specified in my backend_client).
Seeing as we both hit this, maybe it's worth looking into if this is a bug
Reply all
Reply to author
Forward
0 new messages