NIOS (Infoblox) modules should use API authentication cookie

[Akasurde]

From @badnetmask on Jul 22, 2020 14:13

SUMMARY

This is a copy/follow-up on a previously discussed issue: https://github.com/ansible/ansible/issues/51402

The current authentication implementation of the NIOS (Infoblox) modules makes use of statically defined variables for username and password, to be used in every single task. This breaks the use of dynamic authentication methods, like in environments that use time-based password (token/2FA).

The NIOS WAPI provides a cookie (ibapauth), which can be retrieved on the first authentication, and re-used on every subsequent call. Using this cookie would prevent the need to re-send the password for every task.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

nios_* nios_network nios_zone nios_a_record nios_cname_record

ADDITIONAL INFORMATION

The final usage of this feature would make the NIOS-related playbooks behave like any other playbook that uses the "ovirt_*" modules. On those modules, the first task of the playbook is the authentication, which then generates an internal Ansible variable, which contains the authentication token, and is-reused for ever subsequent calls to the oVirt API. (examples can be found on: https://www.ovirt.org/develop/release-management/features/infra/ansible_modules.html)

As previously discussed with @justjais, in order to implement this feature, this module needs to be migrated to httpapi first, so that it no longer depends on the underlying infoblox-client Python library, allowing it to properly implement cookie-based authentication.

Below is an example of how a NIOS playbook would look like, if this authentication token would be implemented:

- hosts: nios
  connection: local
  tasks:
    - name: authenticate to Infoblox
      nios_auth:
        host: 192.0.0.2
        username: admin
        password: ansible
    - name: create management reverse DNS zone
      nios_zone:
        provider: "{{ nios_auth }}"
        name: 192.168.0.0
        state: present
    - name: create user reverse DNS zone
      nios_zone:
        provider: "{{ nios_auth }}"
        name: 192.168.1.0
        state: present
    - name: revoke authentication token (sends /wapi/vX/logout API call)
      nios_auth:
        state: absent
        nios_auth: "{{ nios_auth }}"

Copied from original issue: ansible/ansible#679

[Akasurde]

From @felixfontein on Jul 22, 2020 20:52

I'm not sure what the future of the nios modules in community.general is. I've heard talk that they should be moved to their own collection, but that won't happen in the near future (since the deadline for that passed). @gundalow do you have more info on what will happen to the nios modules? Or who is looking after them right now?

[Akasurde]

From @felixfontein on Jul 22, 2020 20:54

Ah, the current state is probably summed up in this issue: https://github.com/infobloxopen/infoblox-ansible/issues/7 (Which is pretty much: no news.)

[Akasurde]

From @ansibullbot on Jul 22, 2020 20:58

cc @NilashishC @Qalthos @brampling @danielmellado @ganeshrn @nerzhul @privateip @sganesh-infoblox @trishnaguha click here for bot help

[Akasurde]

From @seb54000 on Apr 14, 2021 12:10

Hello, we are very interested in the API authentication feature. It seems that PR referenced by @felixfontein is now merged ? https://github.com/infobloxopen/infoblox-ansible/pull/12

I don't understand well if it was a prerequisite to start working on feature proposal by @badnetmask ?

Do anybody have a clue if this feature may be of interest to other people in the community (@Vaishnavi-infoblox) ? I'm not able to develop it but I sure will be available for test and review.

[Akasurde]

From @felixfontein on Apr 17, 2021 08:45

I guess it depends on what happens with the infoblox collection. If it gets included in Ansible, we should really remove the modules here and redirect them to that collection. If not, well, I'm not sure what to do... Maybe deprecate the modules here and tell users to explicitly install and use that collection, assuming that the collection has all fixes incorporated that were added here.

[Akasurde]

From @badnetmask on Apr 17, 2021 13:32

I believe either @Vaishnavi-infoblox or @anagha-infoblox should have a better answer than me. I have been pushing some contributions under the collection project, but since I was told by @justjais that there would be a different direction with this module, this issue kind of slipped my mind. I'm willing to work on it though, just need to know what direction the project is taking (or if someone is already working on it and I am unaware).

[Akasurde]

From @felixfontein on Apr 17, 2021 16:15

In any case, I don't think we will accept new features for the modules in this collection. So if you want to work on this, you need to do that in the infoblox.nios_modules repository.

[Akasurde]

From @russoz on Jun 21, 2021 08:01

hi @badnetmask tudo bom? :brazil:

As mentioned before, it will make more sense to work on this issue in the context of the infoblox.nios_modules repository. Given that, is there any particular reason for us to keep this issue open here? TIA