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
90 stars 55 forks source link

[falcon_configure] Add ability to prevent service falcon-sensor to start #482

Open dhoppe opened 3 months ago

dhoppe commented 3 months ago

It looks like the variable falcon_service_state has not been defined at defaults/main.yml and therefore the task only relies on the default('restarted').

https://github.com/CrowdStrike/ansible_collection_falcon/blob/ba37c6f2ffe1ba32576102686a5efc86982e25cc/roles/falcon_configure/tasks/configure.yml#L28 https://github.com/CrowdStrike/ansible_collection_falcon/blob/ba37c6f2ffe1ba32576102686a5efc86982e25cc/roles/falcon_configure/tasks/win_configure.yml#L6

carlosmmatos commented 3 months ago

@dhoppe - what do you mean by "prevent" the service from starting for these tasks? They are for configuring the sensor, so when a change is made, the state needs to be restarted for linux.

I suppose we can make an argument for Windows that we don't really care about service state if someone wants to remove AID.

IMO the falcon_service_state should no longer exist, which needs to be fixed.

dhoppe commented 3 months ago

@dhoppe - what do you mean by "prevent" the service from starting for these tasks? They are for configuring the sensor, so when a change is made, the state needs to be restarted for linux.

@carlosmmatos I took a second look at the code and finally understand why the service is restarted.

IMO the falcon_service_state should no longer exist, which needs to be fixed.

@carlosmmatos I actually wanted to create a pull request to start or stop the service based on this variable. A change via falconctl would then trigger the handler via notify to restart the service. 🤔

When creating a golden image, the service should be stopped to ensure that no .lock files or similar exist. This would otherwise prevent the service from being started when creating a new EC2 instance.

carlosmmatos commented 3 months ago

I hear you. But the workflow is generally like this (linux):

  1. Install the sensor. For some reason our sensor gets installed in started state 🤷🏼‍♂️ . For obvious reason the sensor doesn't start since no CID has been applied at this stage.
  2. Then generally most people will set the CID and maybe some tags. In order for those to take effect, a restart must take place. After this restart, the sensor should make a connection to the cloud, do it's necessary metadata updates and be running.
  3. For VM templates/Gold Images - then the AID is deleted (no restart needed).
  4. Shutdown VM template/Gold Image
  5. Drink beer/whiskey 😉
dhoppe commented 3 months ago

I hear you. But the workflow is generally like this (linux):

  1. Install the sensor. For some reason our sensor gets installed in started state 🤷🏼‍♂️ . For obvious reason the sensor doesn't start since no CID has been applied at this stage.

@carlosmmatos I think this is handled by the package itself. For example, Debian / Ubuntu installs the package with a default configuration and starts the service. RedHat installs the package, but does not start the service by default until the user decides his configuration fits his requirements.

  1. Drink beer/whiskey 😉

I am definitely in favor of whiskey. 😁

carlosmmatos commented 3 months ago

Yes, I'm well aware that the package itself does this, it was more of a "why did engineering" make it like so 🤦🏼‍♂️

And I think all the distros start on install. I just double-checked rhel8/9 and they both will be in a failed state do to attempting to start without a cid.