api.yml behaves differently for falcon_install and falcon_configure when using non default URL

[mkurtis]

Because I am using the a non-default endpoint: "api.laggar.gcw.crowdstrike.com" rather than the default, "api.crowdstrike.com", the api.yml module of falcon_configure is not behaving the same way as falcon_install.

My Ansible playbook looks like this;

---

- hosts: all
  gather_facts: yes
  become: true
  roles:
    - role: crowdstrike.falcon.falcon_install
    - role: crowdstrike.falcon.falcon_configure
      falcon_cloud: api.laggar.gcw.crowdstrike.com

Note that the last line is a workaround, and solves my immediate problem. But should I need to do it this way since falcon_install does NOT need that variable to be set (its set in group_vars)?

I have the following variables set in my Ansible group_vars;

root@ae37a24ced7a:/tmp/tmp0wh9y45k# egrep '^falcon' ./group_vars/all/crowdstrike.yml
falcon_sensor_version_decrement: 2  
falcon_cloud: api.laggar.gcw.crowdstrike.com
falcon_cloud_autodiscover: False
falcon_client_id: !vault |
falcon_client_secret: !vault |
root@ae37a24ced7a:/tmp/tmp0wh9y45k#

I think the issue may be that falcon_install has some code that considers "x_cs_region" here, https://github.com/CrowdStrike/ansible_collection_falcon/blob/main/roles/falcon_install/tasks/api.yml#L17-L22

Whereas the api.yml in falcon_configure does not:
https://github.com/CrowdStrike/ansible_collection_falcon/blob/main/roles/falcon_configure/tasks/api.yml

It may be worth noting that once populated, the registered variable: "falcon_api_oauth2_token" DOES contain a key/value pair for "x_cs_region" when I authenticate against "api.crowdstrike.com" but not when I authenticate against api.laggar.gcw.crowdstrike.com.

Please let me know if this is a misunderstanding or configuration oversight on my part, or if it makes sense for you to make falcon_configure behave more like falcon_install does in this regard.

[carlosmmatos]

Hey @mkurtis - thanks for creating an issue. You are right that in theory, both roles should work the same, and it looks like this is something that should be easy enough to implement so expect a PR soon.

What you're running into here is a Ansible variable precedence issue where group_vars fall below that of role vars (defined in role/vars/main.yml). This particular variable should be in the role defaults, and not role vars so I will get that updated.