ansible-collections / community.general

Ansible Community General Collection
https://galaxy.ansible.com/ui/repo/published/community/general/
GNU General Public License v3.0
840 stars 1.54k forks source link

NIOS (Infoblox) modules should use API authentication cookie #679

Closed badnetmask closed 3 years ago

badnetmask commented 4 years ago
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
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 }}"
felixfontein commented 4 years ago

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?

felixfontein commented 4 years ago

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.)

ansibullbot commented 4 years ago

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

seb54000 commented 3 years ago

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.

felixfontein commented 3 years ago

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.

badnetmask commented 3 years ago

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).

felixfontein commented 3 years ago

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.

russoz commented 3 years ago

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

Akasurde commented 3 years ago

Thank you very much for your interest in Ansible. This plugin/module is no longer maintained in this repository and has been migrated to https://github.com/infobloxopen/infoblox-ansible

Migrated this issue in the above repository - https://github.com/infobloxopen/infoblox-ansible/issues/64.

If you have further questions please stop by IRC or the mailing list: