CrowdStrike / ansible_collection_falcon

Comprehensive toolkit for streamlining your interactions with the CrowdStrike Falcon platform.
https://galaxy.ansible.com/ui/repo/published/crowdstrike/falcon/
GNU General Public License v3.0
95 stars 57 forks source link

Auth tasks fails due to sudo on localhost #467

Closed FriedCircuits closed 6 months ago

FriedCircuits commented 6 months ago

We recently migrated to running Jenkins in Kubernetes which runs our AMI builds. This job runs packer from a non root container and then spins up the target instance to install our baseline config which includes Crowdstrike. It's failing to run sudo since it's a non root container.

It looks like this task has delegate_to: localhost but without dropping sudo so it requires the localhost environment to have sudo for generating auth config. From looking at prior commits it seems it would be better to drop sudo rather than remove delegate_to.

https://github.com/CrowdStrike/ansible_collection_falcon/blob/main/roles/falcon_install/tasks/auth.yml

Thanks

carlosmmatos commented 6 months ago

@FriedCircuits thanks for opening up the issue. All modules are ran on localhost as non root user. There should be no need for root to execute the API calls as this is going to be handled by the localhost that should have all the python requirements installed. You can look at the main.yml task file and see that we only use become for tasks that will execute on your target host (aka installing the package). If you are passing in become somewhere else in your playbook, I would opt out of using that for our roles.

FriedCircuits commented 6 months ago

@carlosmmatos thanks for catching that. Totally missed it and assumed the role was running as root. 😁

carlosmmatos commented 6 months ago

No worries.. the old version 3 of our collection it was okay to do so. But since all the logic for talking to our API with our new modules is delegated to localhost and doesn't need root to talk with the API, it became easier to allow users to run our roles without having to worry about where to use become, since we are doing this in "hopefully" all the right places ;).

If you have any other questions or ideas for future features, don't hesitate to reach out here!