cisco.nxos.nxos_snmp_server - password breaks idempotency
jorgenspange opened this issue · 4 comments
SUMMARY
Idemptoncy breaks when you apply password in clear text.
ISSUE TYPE
- Bug Report
COMPONENT NAME
cisco.nxos.nxos_snmp_server
ANSIBLE VERSION
ansible [core 2.16.1]
config file = /Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg
configured module search path = ['/Users/jorgenspange/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /opt/homebrew/Cellar/ansible/9.1.0/libexec/lib/python3.12/site-packages/ansible
ansible collection location = /Users/jorgenspange/.ansible/collections:/usr/share/ansible/collections
executable location = /opt/homebrew/bin/ansible
python version = 3.12.1 (main, Dec 7 2023, 20:45:44) [Clang 15.0.0 (clang-1500.0.40.1)] (/opt/homebrew/Cellar/ansible/9.1.0/libexec/bin/python)
jinja version = 3.1.3
libyaml = True
COLLECTION VERSION
[jorgenspange@Jorgens-MBP git/ansible-network-automation (main) ]$ ansible-galaxy collection list cisco.nxos
# /Users/jorgenspange/.ansible/collections/ansible_collections
Collection Version
---------- -------
cisco.nxos 6.0.0
CONFIGURATION
[jorgenspange@Jorgens-MBP git/ansible-network-automation (main) ]$ ansible-config dump --only-changed
ANSIBLE_COW_PATH(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = /opt/homebrew/bin/cowsay
ANSIBLE_COW_SELECTION(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = small
ANSIBLE_NOCOWS(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = False
ANSIBLE_PIPELINING(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = True
CONFIG_FILE() = /Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg
DEFAULT_FORKS(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = 10
DEFAULT_GATHERING(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = smart
DEFAULT_HOST_LIST(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = ['/Users/jorgenspange/Docum>
DEFAULT_ROLES_PATH(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = ['/Users/jorgenspange/Docu>
DEFAULT_STDOUT_CALLBACK(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = yaml
DEFAULT_TIMEOUT(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = 120
DEFAULT_VAULT_PASSWORD_FILE(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = /Users/jorgenspan>
DISPLAY_SKIPPED_HOSTS(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = False
HOST_KEY_CHECKING(/Users/jorgenspange/Documents/git/ansible-network-automation/ansible.cfg) = False
OS / ENVIRONMENT
Macbook Pro 2021 M1
STEPS TO REPRODUCE
- name: configure_cisco.nxos.nxos | Set snmpv3 configuration.
cisco.nxos.nxos_snmp_server:
config:
contact: {{ snmp_contact }}
location: {{ snmp_location }}
users:
auth:
- authentication:
algorithm: sha
localized_key: false
password: {{ authentication_password }}
priv:
aes_128: true
privacy_password: {{ encryption_password }}
group: network-admin
user: snmp_rw
use_acls:
- ipv4: SNMP
user: snmp_rw
state: merged
EXPECTED RESULTS
When you apply multiple times it should not have state changed.
ACTUAL RESULTS
When applying this it multiple times it does a change everytime because it's reapplying the password:
commands:
- snmp-server user snmp_rw network-admin auth sha password123 priv aes-128 password123
(yes the password meets the requirements and is applied, just washed it away here)
@jorgenspange I think this is behaving as expected. NX-OS converts password123
into it's localized hashed format (default SHA-1) likely using a salt and stores that in it's configuration. As a result, this is what appears in running-config:
nexus9300-10-3-1# show running-config | section "^snmp-server user snmp_rw"
snmp-server user snmp_rw network-admin auth sha 332915F749A959BFF31571F660808B5A3478E32CAEBD priv aes-128 056E47AE43EC67C6896416B32CC4D47E3828B03CABA0 localizedV2key
snmp-server user snmp_rw use-ipv4acl SNMP
The nxos_snmp_server
has no way of understanding if the password(s) passed through the task is what's actually configured on the box from this salted hash. As such, it considers this as a diff and keeps trying to push it every time the playbook is run.
The solution here is to run a task with state: gathered
and round-trip that information to the aforementioned task. Or, manually update your task to reflect the localized salted hashed version of the passwords, instead of the plain text ones.
Hope that helps!
@NilashishC Yes, that's for sure what is happening. But for instance cisco.ios.ios_snmp_server has the same challenge, but that does not apply the password as long as the users is provisioned, therefore the idempotency is still intact.
Would it be possible to do something similar here? Maybe you could have a force_update: boolean to deal with this somehow.
@jorgenspange The behavior in cisco.ios is wrong. We would push a patch to fix it.
The facts are not rendering user-> authentication -> password
information in snmp_server
Playbook -
- name: Apply the provided configuration
# check_mode: true
cisco.ios.ios_snmp_server:
config:
communities:
- acl_v4: testACL
name: mergedComm
rw: true
users:
- authentication:
algorithm: md5
password: Test
encryption:
priv: 3des
password: Test
group: dev
username: userPaul
version: v3
state: merged
Redacted output -
after:
communities:
- acl_v4: testACL
name: mergedComm
rw: true
users:
- authentication:
algorithm: md5
encryption:
priv: 3des
group: dev
username: userPaul
version: v3
before:
communities:
- acl_v4: testACL
name: mergedComm
rw: true
commands:
- snmp-server user userPaul dev v3 auth md5 ******** priv 3des ********
invocation:
I see this enhancement went in with the PR
As mentioned in previous comments passwords or any such information not present in the running configuration of the appliance is expected to break idempotence. And that would be the expected behavior of the module.
Given that we prohibit the way the patch was added to cisco.ios we would be unable to update configuration with the overridden and replaced state.
I hope this answers your question.
Regards.
CC @roverflow This would need fix in cisco.ios ^
Regards