na_ontap_iscsi_security: task returns "ok" without applying auth_type change - get_initiator() is not scoped to the SVM

[matalve]

Summary

Summary

Setting auth_type: deny for initiator: default with
na_ontap_iscsi_security returned ok (changed: false), but no PATCH
was sent and the SVM's default authentication type remained unchanged.

Theory: The module fetches the current initiator record without filtering on the
target SVM and blindly uses the first record returned. Since every
iSCSI-enabled SVM has a credentials record named default, the module can
end up comparing the desired state against another SVM's record. If
that record happens to match the desired state, the module concludes there
is nothing to do and silently skips the PATCH.

Root cause

In plugins/modules/na_ontap_iscsi_security.py (verified in the 23.5.0
tag; identical on main as of July 2026), get_initiator() queries the
credentials collection filtered only by initiator name — no SVM filter —
and then takes records[0]:

def get_initiator(self):
    params = {'fields': '*', 'initiator': self.parameters['initiator']}
    api = 'protocols/san/iscsi/credentials'
    message, error = self.rest_api.get(api, params)
    ...
    if message['num_records'] > 0:
        record = message['records'][0]

The SVM UUID is fetched in get_svm_uuid() and used correctly in the
PATCH/DELETE URLs, but never in this lookup. With N iSCSI-enabled SVMs the
query returns N default records. When records[0] belongs to a
different SVM and already matches the requested state, the computed modify
dict is empty and the module exits without making any changes.

The same unscoped lookup could in principle also affect non-default
initiators if the same IQN has credentials records on multiple SVMs.

Suggested fix

Scope the GET to the target SVM:

params = {'fields': '*', 'initiator': self.parameters['initiator'], 'svm.uuid': self.uuid}

Workaround

Read the record SVM-scoped via na_ontap_rest_info
(parameters: {svm.name: ..., initiator: default}) and PATCH
/protocols/san/iscsi/credentials/{svm.uuid}/default via
na_ontap_restit, guarded by a when: condition on the current
authentication_type.

Component Name

pip

Ansible Version

$ ansible --version
ansible [core 2.16.3]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.12/site-packages/ansible
  ansible collection location = /usr/share/ansible/collections/ansible_collections
  executable location = /usr/bin/ansible
  python version = 3.12.13 (main, Apr 16 2026, 22:51:04) [GCC 8.5.0 20210514 (Red Hat 8.5.0-28)] (/usr/bin/python3.12)
  jinja version = 3.1.2
  libyaml = True

ONTAP Collection Version

$ ansible-galaxy collection list

# /usr/share/ansible/collections/ansible_collections
Collection         Version
------------------ ----------
ansible.utils      6.0.1
community.crypto   2.26.7
community.general  11.4.4
netapp.ontap       23.5.0
netapp.storagegrid 21.14.0

ONTAP Version

NetApp Release 9.17.1P7: Mon Apr 20 13:57:24 UTC 2026

Playbook

- name: Set default iSCSI authentication to deny
  netapp.ontap.na_ontap_iscsi_security:
    hostname: "{{ ontap_hostname }}"
    username: "{{ ontap_username }}"
    password: "{{ ontap_password }}"
    https: true
    validate_certs: true
    use_rest: always
    state: present
    vserver: "{{ svm_name }}"
    initiator: default
    auth_type: deny

Steps to Reproduce

On a cluster with more than one iSCSI-enabled SVM, run the following
against an SVM whose default authentication type is not deny:

- name: Set default iSCSI authentication to deny
  netapp.ontap.na_ontap_iscsi_security:
    hostname: "{{ ontap_hostname }}"
    username: "{{ ontap_username }}"
    password: "{{ ontap_password }}"
    https: true
    validate_certs: true
    use_rest: always
    state: present
    vserver: "{{ svm_name }}"
    initiator: default
    auth_type: deny

Expected Results

The default credentials record on the target SVM is patched to
authentication_type: deny and the task reports changed: true.

Actual Results

The task completes with status `ok` (`changed: false`). No PATCH request
is sent, and `vserver iscsi security show` confirms the default
authentication type on the target SVM is unchanged.

Note: which SVM's `default` record the module happens to read is
arbitrary (first record of an unfiltered GET), so whether the bug
triggers — and in which direction — depends on cluster contents and
record ordering.

[DhivyaBharathi215]

The Story DEVOPS-8519 created