-
Notifications
You must be signed in to change notification settings - Fork 23.8k
-
Notifications
You must be signed in to change notification settings - Fork 23.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minimum permissions required for use of Amazon cloud modules, and improve ansible error output #22552
Comments
I've been looking into this, and it would 1) take a long time 2) need to be updated regularly. Some modules will be more messy to document than others. As I am unable to focus solely on this, I'd welcome anyone interested to submit PRs. It is a documentation bug and I feel like fixing it would be very helpful (as I've tripped over this problem a few times myself). I will start requesting for new modules to document this. |
i did a quick and dirty scan with: output of which is below: but yeah, it would take some upkeep. I think beyond just the documentation that more helpful error messages from ansible would be good. I don't know if boto is the weak link there, but the errors messages some aws tools give where they contain the sts encoded error message would be great (the ones you can then decode with FILE: lib/ansible/modules/cloud/amazon/aws_kms.py |
It is very difficult to fully document the requirements of each module because those requirements will vary depending on how the module is used. For example, a module that is only used in "state: present" mode will need only create rights and should not have delete rights, whilst if you use the same module with "state: absent" you will need delete rights. My proposal is to
@robertpearce I've got an active pull request which is fixing the integration tests and improving the error messages as I go along (see #22499) could you please merge that into your ansible and see if it improves your error messages. Please, then list each case where you get a useless error message and we can try to fix it. When you find a case, please report the YAML for the task which caused the error and the detailed output of running ansible-playbook -vvv ; please @ me in the report (it can just be a comment in this ticket as far as I'm concerned. |
The newer boto3 modules provide better errors. For example, testing some newer modules you get the following:
So it's pretty clear what IAM permission i need to grant. |
@wimnat I can't confirm. I'm trying to do a simple task: start instance with ansible, and it's a big headache for me (even for AWS support). I assigned EC2 full access for IAM, simulated a policy, confirmed with AWS support, but ansible didn't work. And I don't see the detailed error. Only:
So yes, all essential modules should be served with the list of approximate permissions. PS. It's rediculous when u have ec2 full access role and you can't even start instance. |
Can you show me one of your AWS tasks? Have you tried using AWS cli on the same instance? Does that work? |
@wimnat Yes, I've just started the instance from aws cli:
From ansible - still no luck. Playbook:
I tried weeks ago with the same playbook - all worked fine. Now it doesn't work. boto==2.46.1 |
When you said in your previous post that you had 'assigned EC2 full access for IAM' what do you mean exactly? Have you assigned an iam role to the instance? If yes, then the aws credentials in your task are unnecessary. |
I assigned EC2 full access for the whole ec2 service within eu-central-1 region. Instance ID is asterisk.
Why do you think credentials are unnecessary? I didn't configure aws cli profile on my machine(only for tests). And ansible doesn't know my AWS creds. |
Ansible doesn't need to know your creds if you're using iam roles. Thats the whole point in them - to avoid having to use access keys on EC2 instances. However, iam service role are relatively new and I'm not sure on the boto3 or ansible support. If you just create an instance role and assign it to the ansible instance you should be fine. |
Also, I would seriously consider modifying that policy of only for testing. If any one got access to one of your instances they could perform absolutely any action |
@wimnat that's the point. I used 3 actions:StartInstances, StopInstances, DescribeInstances and succedded with instance start/stop. Now, even with EC2 full previliges I'm unable to start instance. You thought I'm using ansible on EC2 machine, but no, It's my local machine. That's why I have to specify aws creds in playbook :) |
Ok I'm confused. I thought your play wasn't working at all. So you ran it first time and it worked and then you rerun it and got an author error? Check the iam permissions of your user. As you're running from your local machine, iam service roles are not going to make any difference |
It worked a few weeks ago. Permissions are ok, because I used this creds in aws cli to run instance. That's why ansible+AWS IAM is very weeeeired. |
So what's the exact error? |
Error I mentioned in my first post: UnauthorizedOperationYou are not authorized to perform this operation. detailed: https://pastebin.com/nNmGbY6g |
Well then it must be your user permissions. What's your policy look like?
Try addingfull EC2 permissions or turn on CloudTrail and see what calls
are failing
The module could very well behaved differently on subsequent runs
…On 25 May 2017 12:27 am, "klausitto" ***@***.***> wrote:
Error I mentioned in my first post:
UnauthorizedOperationYou are not authorized to perform this operation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22552 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHFORhxoSTPlpG0fH_aiZ7pUpzG2aNSmks5r9D5ngaJpZM4Mazbe>
.
|
I pasted my policy a few messages above :) |
@klausitto Yeah, so you've hit upon the crux of the problem. Different runs will use different permissions (and determining what permissions you may require means you have to trace both the ansible code and boto code) and since the ec2 module uses boto2 as opposed to boto3 it doesn't provide helpful responses when it gets a 403 Forbidden (permissions) error. Your policy+playbook combination doesn't work for me either. It appears that resources beyond your policy are being used. I have a hunch it has to do with boto trying to do a DescribeInstances action and since you're only allowing actions to be done to a particular instance that is causing the issue. Changes resources to "*" works for me. It's just hard to determine what the issue is. This problem will hopefully be simpler to fix once things are ported to boto3. I'm sorry you're dealing with this. |
@s-hertel If you look at my policy, I'm not restricting access for particular instances. I've provided a full access to entire region. UPD: Hint regarding CloudTrail was very helpful. Thanks @wimnat. Final IAM policy to run Instance:
|
@klausitto Yes. :) |
Thank you very much for your interest in Ansible. Ansible has migrated much of the content into separate repositories to allow for more rapid, independent development. We are closing this issue/PR because this content has been moved to one or more collection repositories.
For further information, please see: |
COMPONENT NAME
aws modules (various)
ANSIBLE VERSION
2.2.1.0
Documentation for AWS specific modules (ec2_vol etc), should outline which IAM permissions are required for the module to work.
EXPECTED RESULTS
There should be a note on the AWS specific module outlining the list of IAM permissions that module uses to do it's job. Otherwise the end user is left with the prospect of pouring through ansible source code, and trying to guess what has been called. At the very least, the sts coded errors should be displayed to the user in the output together with the existing 'permission denied' error.
ACTUAL RESULTS
Currently the error message of 'permission denied' is pretty useless, as you don't know WHICH permission was denied, or which was being attempted, either.
The text was updated successfully, but these errors were encountered: