Issues logging into Vault using AWS IAM auth

[Matt Scifo]

I'm having issues logging into Vault using AWS IAM auth.

I've done the following to setup (assume proper variable interpolation):

vault auth-enable -address=$VAULT_ADDR aws
vault write -address=$VAULT_ADDR auth/aws/config/client iam_server_id_header_value=$fqdn \
 access_key=$aws_access_key secret_key=$aws_secret_key region=$aws_region
vault write -address=$VAULT_ADDR auth/aws/role/$aws_devops_role auth_type=iam \    bound_iam_principal_arn=arn:aws:iam::$aws_account_id:role/$aws_devops_role policies=prod max_ttl=500h

I've also created the associated $aws_devops_role role in AWS with the following trust policy...

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$aws_account_id:user/$MYUSER"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

and added the following permission policy to the "$MYUSER" IAM user...

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1495739374000",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::$aws_account_id:role/$aws_devops_role"
            ]
        }
    ]
}

I then try to login to Vault on my workstation with AWS credentials already configured with the "$MYUSER" accesskey/secretkey and get the following error:

$ vault auth -method=aws -address=https://$fqdn header_value=$fqdn role=$aws_devops_role
Error making API request.


URL: PUT https://$fqdn/v1/auth/aws/login
Code: 400. Errors:


* IAM Principal "arn:aws:iam::$aws_account_id:user/$MYUSER" does not belong to the role "$aws_devops_role"

Am I missing something regarding permissions/policies?  

[Joel Thompson]

Hi Matt,

What you are describing is expected behavior. You've configured the role in Vault so that the IAM role $aws_devops_role can get a Vault token with permissions specified by the prod policy. But you're authenticating as $MYUSER, and hence the error you're seeing.

In configuring your user and role, you've set it up so that $MYUSER can call sts:AssumeRole and receive temporary credentials for $aws_devops_role. Where I think the confusion is that Vault won't do that for you (and in fact, by design, cannot as the necessary credentials are never sent over the wire).

If it's your intention to have $MYUSER be able to receive the Vault token, then you have a couple of options:

1. Set the bound_iam_principal_arn to arn:aws:iam::$aws_account_id:user/$MYUSER

2. From your workstation, call sts:AssumeRole, use that to retrieve temporary credentials from STS, and then use those credentials to authenticate to Vault.

I think the first is closer to what you are trying to achieve, and it would also let you remove the trust policy on $aws_devops_role and the sts:AssumeRole permission on $MYUSER if you have no other need to assume that role, so it's simpler. But there could be reasons why you'd want to do the second (e.g., you have EC2 instances in an instance profile in the $aws_devops_role that you also want to have access to the same Vault role and don't want to create separate roles for $aws_devops_role and $MYUSER).

Hope this helps!

--Joel

--
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/c563edde-81a0-4d8c-8149-fe7885de7eae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Scifo]

Hi Joel,

Thanks for the info.  It sounds like I just misunderstood the purpose of the AWS auth backend.  I was hoping that it would allow regular AWS users to login to Vault using their existing AWS credentials, and it does, not just easily.  As you indicated for option 1, I would have to create a new "auth/aws/role" in Vault for every single user and bind each to the user's IAM ARN.  That's not really scalable, to say the least.  And going with option 2 is placing the burden of quite a few extra steps on the user in order to get the STS temporary credentials first to then use to login to vault.

I'll try to find another way to make things simpler.

Thanks.

[Joel Thompson]

Hi Matt,

Agree, for that particular use case, it's a bit awkward, I'll try to think a bit more about how it might be better supported.

If it helps, here's a quick bash snippet using the awscli that can make #2 much easier. Distributing this around would be a little awkward, but should make the actual authentication workflow simpler for your users. (Of course, the same thing can be done in any other language of choice, but this is quick and simple.)

read -a CREDS <<< $(aws sts assume-role --role-arn arn:aws:iam::$aws_account_id:role/$aws_devops_role --role-session-name $MYUSER --output text) 

export AWS_ACCESS_KEY_ID="${CREDS[4]}" 
export AWS_SECRET_ACCESS_KEY="${CREDS[6]}" 
export AWS_SECURITY_TOKEN="${CREDS[7]}" 
export AWS_SESSION_TOKEN="${CREDS[7]}"

--Joel

p.s. FWIW, I'm personally a fan of AdRoll's Hologram, https://github.com/AdRoll/hologram, in which people have role credentials, and it fits much better with the IAM auth method, but I know setting this up is more work and effort.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/3df61922-72a1-4d18-bfbe-2538f28228d7%40googlegroups.com.

[Joel Thompson]

Hi Matt (and any others who might be interested),

Resurrecting this thread....

As I mentioned below, I've been thinking about the right way to solve this use case more comfortably. A feature request came up in the GitHub issue tracker yesterday that could potentially work really well for you (and it's simple enough, I'm a bit embarrassed I hadn't thought of it sooner...) -- support IAM groups.

The workflow I have in mind would be that you'd bind a Vault role to an AWS IAM group, say, arn:aws:iam::123456789012:group/VaultDevUsers. You'd then put your IAM users in this group, and when they authenticated to Vault, Vault would see that the role is bound to a group, look up the group members, and ensure that the IAM user is a member of the group. If so, it'd return a token. Group membership would only be checked at login time, not at token renewal time (same semantics as the LDAP backend).

Thoughts? Would this be something anybody in the community would want to use? Seems like a fun project to work on, but I'd only want to do this (and add the corresponding complexity to the codebase) if users would get actual value out of it.

See https://github.com/hashicorp/vault/issues/3179 for the original GitHub issue that sparked this thought as well as my 7:04 p.m. EDT comment about some implementation details (if you can make it through my long wall of text!).

--Joel

[Josh Smift]

I'm having what seems like it might be a similar issue, and haven't figured out the right combination of things to make things match up. I have AWS credentials with no privileges except to assume one of a couple of other roles, and assuming a more privileged role requires MFA authentication. When I do that, my ARN looks like this:

+$ aws sts get-caller-identity

{

    "UserId": "snip:jsmift",

    "Account": "snip",

    "Arn": "arn:aws:sts::snip:assumed-role/admin/jsmift"

}

I've added an auth path to Vault like this:

vault write /auth/aws/role/admin auth_type=iam policies=admin bound_iam_principal_arn="arn:aws:sts::snip:assumed-role/admin/*"

When I try to authenticate, I get this error:

+$ vault auth -method=aws role=admin

Error making API request.

URL: PUT https://snip:8200/v1/auth/aws/login

Code: 400. Errors:

* IAM Principal "arn:aws:sts::snip:assumed-role/admin/jsmift" does not belong to the role "admin"

What might be going wrong here?

[Joel Thompson]

Hi Josh,

Sorry for being a bit slow to get back to you on this (my excuse, though, is perhaps a bit appropriate as I was attending the AWS conference all of last week and fell behind on emails).

Anyway, welcome to the vagaries of AWS identity. The tl;dr: you'll want to set bound_iam_principal_arn to arn:aws:iam::<account_id>:role/admin (this has iam instead of sts, role instead of assumed-role, and there's no /* at the end of the ARN).

For a bit of a longer explanation, whenever you authenticate to AWS using credentials from an assumed role, AWS actually considers you to simultaneously be two different principals: arn:aws:iam::<account_id>:role/<role_name> AND arn;aws:sts::<account_id>:assumed-role/<role_name>/<role_session_name>. sts:GetCallerIdentity always returns the latter, but within the AWS context, you will get permissions assigned to both principals in a resource policy (e.g., in an S3 bucket policy). While AWS fully supports this duality, Vault does not; you have to set the bound_iam_principal_arn to the first form. The reason is mostly that I wanted to get a simpler Vault feature out to Vault users and I felt that the IAM ARN would be the more familiar form to users. A PR to improve the documentation or change the behavior would, I assume, be welcomed :)

Hope this helps!

--Joel

--

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/4af4e562-b1ce-4ed9-b32b-a62e81fee468%40googlegroups.com.

[Josh Smift]

That worked! I would've sworn I tried that, or something like it, but maybe I kept the '*' at the end or something. I'll take a look at the docs again and see if there's an obvious place to make that more obvious. Thanks!

Oh, one other note: It seemed to work for me with either 'sts' or 'iam' at that point in the ARN. Shrug.