auth/aws: support all principal types #3179
Comments
|
What version of Vault is this? I believe 0.8.0 doesn't accept these but also shouldn't panic. |
|
@joelthompson I got the |
|
I was testing on 0.7.3 but looked at 0.8.0 and master to make sure it wasn't already fixed (and the code looked unchanged). Thanks for the quick fix on the panic! For adding the other principal types, they'll need to be added to this switch statement: https://github.com/hashicorp/vault/blob/v0.8.0/builtin/credential/aws/backend.go#L221
|
|
@bmoylan -- can you elaborate a bit more on your specific use case? I'm a bit confused about what you're trying to achieve, and it might be because I've confused you with the documentation. If you're inferring an EC2 instance type with the IAM auth, then you should be able to just do essentially a "list-and-shift" of your roles. Just specify Alternatively, is your use case that you want to NOT infer the EC2 instance entity type but allow any IAM principal in a given account the ability to login to a Vault role? That's currently not possible (and won't be fixed by @jeffrai's change). @jefferai -- sorry for taking a while to get back, things have been a bit hectic recently. I actually made a conscious decision to not support the First, some background about the subtleties of AWS IAM entities. It's important to understand the distinction between principal policies and resource policies. Principal policies are applied to a principal (e.g., an IAM user or a role) and specify which actions (e.g., s3:GetObject) on which resources (e.g., arn:aws:s3:::JoelsMagicBucket) that principal is permitted to take. Resource policies are applied to a resource (e.g., JoelsMagicBucket) and specify which principals (e.g., a particular IAM user or role) are permitted to take which actions (e.g., s3:GetObject) on the resource they're applied to. Now, Groups are also a bit weird. Groups can only contain users, not roles. Users get all the policies that apply to them individually and that apply to all the groups they are a member of, which is what you'd expect. However, the frustrating thing is that you cannot specify an IAM group as the principal in a resource policy. That is, let's say I have a group, VaultContributors, that contains Joel and Jeff. You cannot put, in an S3 bucket policy, that VaultDevelopers is allowed read access. You would have to individually permissions both the Joel and Jeff. Now, how this applies to Vault: I think the most natural interpretation for the bound IAM principal ARN is to consider it like you would a principal in a resource policy. You're applying a policy to a resource (i.e., a Vault role) specifying which IAM principals are allowed to access it. In that interpretation, specifying a As far as groups, if we're to follow the parallel to AWS resource policies, then we'd just simply disallow groups. If we wanted to support groups, it would basically require a new IAM permission to list group memberships on each login call, and basically follow similar semantics to LDAP (e.g., group memberships are only checked on initial login and not on subsequent token renews). I'd actually be open to doing so as it could solve one of the use cases that came up on the mailing list (and I'm a bit annoyed at myself for not thinking of supporting groups at that time). Federated users is something I don't have a lot of experience with, and architecturally, it also gets weird. The federated-user identities, as best I can tell, really come from an OpenID Connect identity provider, and supporting them in Vault would essentially be (mis?)using AWS as sort of an OIDC-aware identity proxy between an external OIDC provider and Vault, and it'd be much better to just have a direct OIDC auth backend in Vault (e.g., #2525). Thoughts on this? |
|
I see you just announced the release while I was typing that up. I'll need to test later tonight what happens when you use actual root credentials to authenticate to Vault, my suspicion is that there will be some issues with it. And sorry the previous post was so long, but it's a really subtle topic! |
|
I just did a quick test using root creds (which I generated just for the purposes of the test and then deleted them immediately afterwards!), and found out that they work as expected with Fixing this -- either by actually supporting root user creds even when unique ID resolution is turned on, or by changing the meaning of binding to the root user (which at this point would be a breaking change -- will require a little bit of effort. I'm happy to contribute the code for it, @jefferai let me know which direction you think is right or if you want to chat a bit more once you've recovered from the 0.8.1 release :) FWIW, I think I've made my opinion clear already on which option is better, but I'll defer to you, and I'll also add that I manually run the acceptance tests using both an IAM user and an EC2 instance in an instance profile before submitting PRs to the AWS auth backend. Since root users are unique enough in the AWS ecosystem, to properly support them, I'd need to also do the same for root users, which would involve generating and revoking root creds (I'm too paranoid to have root credentials laying around in any sort of long-term fashion). |
|
Hey @joelthompson -- thanks for the long write up and investigation! The background is really helpful. You're right that I'm hoping to create a role that authorizes any user/principal from a given account number without using EC2 inference. I have several clients (ec2 instance profiles, lambdas, devs on their laptops) from a particular account that i want to authorize. Totally in sync that root creds are bad and should never be used for day-to-day interactions. If we can't figure out how to support this via role declarations, my (lame) workaround would be to have a |
|
I mentioned federated users for completeness because they're in the IAM docs, but I don't have experience with them either and don't really intend to use them. |
|
Thinking some more about this, and given that Vault has shipped with Jeff's changes, I don't think it would be wise at this point to change the meaning of the As for your issue, something I've been thinking about is allowing specifying wildcards in Thoughts on this @bmoylan? Would this work for you? |
|
Yep, a wildcard would absolutely fulfill my immediate needs. |
|
Cool, I've started writing the code for wildcards, should hopefully have a PR ready in the next couple days :) |
This allows specifying a trailing wildcard in the bound_iam_principal_id in a semantically similar way to AWS. If a user specifies a bound_iam_principal_arn with a trailing wildcard, then Vault will NOT resolve the unqiue ID (analogous to the way AWS handles wildcards) and instead will just store the ARN. At login time, if a wildcard is specified in the bound ARN, Vault will first resolve the full ARN of the authenticating principal because the path component of roles is not visible from the GetCallerIdentity response. A cache has been included to speed up performance of these lookups and should be append only. To prevent unbounded growth of the cache, old entries are cleaned up if not used within a period of time. Also, as the complexity of scenarios of when Vault might make AWS API calls increases, including a recommended IAM policy to give the Vault server that can be more simply referenced in the future. Fixes hashicorp#3179
This is partially bug-report and partially feature-request:
Bug: The
awscredential backend currently panics when given an IAM principal ending inroot(e.g.arn:aws:iam::111111111111:root), despite it being a valid IAM principal. It should return an error if this is unsupported.FR: support this and all other principal types (currently missing
root,federated-user, andgroup).The text was updated successfully, but these errors were encountered: