Totally agree.
IMHO, there should be complete separation of what you collect(items) and what do you need to know to properly access those items(interfaces). Currently, User Macros work well as a solution to this problem.

So other conection details like SNMP community should be in interface as well.
Or in case of SSH/Telnet items: login/pass should be in interface.

Rephrasing self:
Currently three versions of same templates must be provided for SNMP: SNMPv1,SNMPv2, and SNMPv3.
But SNMP version is only a matter device configuration. Items provided by the device are the same.
Please consider to move all SNMP related settings(community, or user/password for v3, AES etc) from item page (making it also cleaner) to host interfaces where it belongs like so:

As a bonus, that would simplify things by far for Template management. Telnet/SSH should go to Host interface as well.

I agree, badly needed as encryption requirements from auditors push more and more people into SNMPv3, and just makes sense. I'm not sure "minor" is correct, but going in this direction seems straightforward at least. The biggest deal is how to handle migration seamlessly. My GUESS is the best idea is to deprecate agent-version agent templates but leave them in place, and create a 4th item type for "snmp Agent" that uses the interface, then people can migrate templates over time. Forcing a replacement in one version would be a breaking change, I think, as people may have hard coded community strings in both templates and host-items.

That could also be considered as a security feature:

better separation between 'what to collect'(items) and 'how to connect'(host interfaces) would allow to easier hide sensitive passwords in the future:

Then, some sort of 'Power user' in Zabbix could possibly create new items and modify them without actually having access to any passwords that Zabbix server uses to connect to hosts.

To the security comment above, the issue is a bit larger but could also benefit from some thought (and this change may help my localizing it). External checks now (usually) pass in credentials from macros like a community string, which are visible then in many places in zabbix, essentially exposing credentials incidentally (admittedly mostly, but not always, to people who already are admins). With SNMPv3 there are a lot more pieces to this, and in the current setup a likelihood of passing these into checks as parameters, making it worse. Isolating them somewhere, and perhaps providing an EASY callback of some sort to get an authenticated SNMP poll from an external check, without the check getting the actual credentials, might make a lot of sense. I am not quite sure what that may look like; one reason for external checks is you want to do something that's difficult to do in a simple snmp GET, but just adding it for people's thoughts in case this ever gets action, maybe it is worth considering external checks and how they may interact as well.

Another more general approach of securing sensitive information could be support of content encryption for user macros.

Linwood

To the security comment above, the issue is a bit larger but could also benefit from some thought (and this change may help my localizing it).

I already wrote about this on https://www.zabbix.com/forum/showpost.php?p=206719&postcount=4
okkuv9xh

Another more general approach of securing sensitive information could be support of content encryption for user macros.

All macros should be part of the host interfaces and if access to the host interface will be under internal ACLs protection this will fulfill all needs. Adding mechanism to pass only macros would be waste of effort.

I agree completely. This is especially painful with modular approach to templates and SNMPv3. Now you need to have separate template module for SHA+AES/SHA+DES/MD5+DES etc., because many devices still do not support AES/SHA (like Cisco SMB switches/Dell Powerconnect) and you cannot use macros for security level, auth protocol and privacy protocol. Only user, auth password and privacy password macros are supported.

Per item SNMP settings just do not make sense to me.

I'm agree too.

For example, I've datacenter with network devices and new security requirements from a customer - switch to snmpv3 where it's possible. Ok, some device support snmpv3 up to authPriv, some device support up to authNoPriv and some device support snmpv2 only. And, I'm not discuss about supported encryption algorithms... So, I should have, for example, three "snmp interface templates": one for authPriv, second for authNoPriv and third for snmpv2. Is it right?

@romale, I think the mechanics deserve some thought, but abstracting the protocol from the regular template is the real issue. If I want to access ifDescr, I shouldn't have to code the OID request for that a dozen times, for all the various combinations of access (nor even three times for SNMP V1, V2c and V3).  The current approach is just fundamentally inadequate.  I just did a client's setup, and decided to use V2c because I had all the templates in place and working, and it was just not worth the effort to change – that's sad, we should all be moving toward more, not less security.

It would be nice if the topic would at least attract some attention.

The placement of SNMP security features in the item is really annoying. Why is this separation between authentication and data gathering only available for IPMI? Because of this I have to maintain multiple duplicates of templates.

Definitely in favor of this feature. Let's say you have to manage 1000 identical routers and due to reality, not all of them are setup exactly the same concerning SNMP. You'd have to maintain at least 3 different templates (SNMPv1, v2, v3c) monitoring the same stuff, only because the SNMP version or settings are different. This seems a protocol specific configuration which should take place at host level.

I've raised a support ticket to recieve a quote for this feature. Anybody else that would add a possible part of sponsoring?

BTW potential changes in interface.

IMO it would be good if it will be possible to reshape that to add additional functionalities:

• possibility to access from agent code to host interface description (agent items API extension to allow access to that data will be necessary)
  By define custom interface properties and allow access to that data by agent it would be possible to pass necessary credentials on accessing to new items in form of loadable module like for example pass in in interface user/password to access to MySQL account used by loadable module with items allowing access to MySQL metrics.
  Generally here is possible to add some kind of generalisation in which any type of the item types if would be able access to interface data will be able to reduce to only two types: agent and not agent items.
  With that even SNMP, telnet or ssh items support could be provided as loadable module and will allow to add easily extend for new types of the monitoring without change core of the zabbix by simple load agent or proxy/server module.
• allow use macros in host interface
  Now is possible to use SNMP community as macro so on move SNMP version to the interface that needs to be preserved.
• hide host interface for non super admin users and/or allow to use ACLs to access to that data. Definitely on first iteration interface details should be accessible only for super admins.

I fully agree with all comments here. It is highly likely it will be implemented in Zabbix 5.0, some initial work is already in progress. Note that combined with https://support.zabbix.com/browse/ZBXNEXT-2957] it will help to manage SNMP credentials in a secure way.

Available in:

• 5.0.0beta1(master) 9c4604596fa

Updated general documentation:

• What's new
• Configuring SNMP monitoring
• Configuring a host
• Host export
• Template export

API documentation changes:

• Item object
• Host interface object
• Item prototype object
• LLD rule object
• item.create
• hostinterface.get
• discoveryrule.get
• itemprototype.get
• item.get
• configuration.import
• configuration.export
• Appendix 2. Changes from 4.4 to 5.0