| 2017-08-15 09:50:50 |
Ilya Etingof |
bug |
|
|
added bug |
| 2017-08-21 16:31:32 |
Dmitry Tantsur |
tags |
rfe |
rfe snmp |
|
| 2017-08-21 16:31:37 |
Dmitry Tantsur |
ironic: status |
New |
Confirmed |
|
| 2017-08-21 16:31:40 |
Dmitry Tantsur |
ironic: importance |
Undecided |
Wishlist |
|
| 2017-08-21 16:54:21 |
Ilya Etingof |
description |
The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the control place network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters (crypto keys and protocol IDs) to utilize all the SNMPv3 security features.
On the flip side, that would introduce a dependency on the `pycryptodome` package which pysnmp uses for the low-level crypto operations. |
The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the control plane network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters (crypto keys and protocol IDs) to utilize all the SNMPv3 security features.
On the flip side, that would introduce a dependency on the `pycryptodome` package which pysnmp uses for the low-level crypto operations. |
|
| 2017-11-22 13:17:20 |
Ilya Etingof |
description |
The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the control plane network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters (crypto keys and protocol IDs) to utilize all the SNMPv3 security features.
On the flip side, that would introduce a dependency on the `pycryptodome` package which pysnmp uses for the low-level crypto operations. |
The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the control plane network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters to utilize all the SNMPv3 security features. Then the operator could configure SNMP driver to use either SNMP v1, v2c or v3 by way of setting the `snmp_version` option (which is already present).
SNMPv3-related options to be introduced would be:
* snmp_usm_user: user name (string)
* snmp_usm_auth_protocol: tokens like md5, sha
* snmp_usm_auth_key: ascii string
* snmp_usm_priv_protocol: tokens like des, aes
* snmp_usm_priv_key: ascii string
* snmp_context_name: SNMP context (string) to address possibly many instances of the same MIB behind a single SNMP agent
Implementation-wise, we would not need to fork Ironic SNMP driver or introduce new hardware type or migrate existing SNMPv1/v2c configuration by way of adding SNMPv3 support to the SNMP driver.
The same applies to the VirtualPDU tool -- we will need to teach it picking up the options above [1], no backward incompatible changes anticipated.
The proposed change would introduce the indirect dependency on the `pycryptodomex` package which pysnmp (4.4.1+) uses for the low-level crypto operations.
1. https://github.com/openstack/virtualpdu/blob/master/virtualpdu/main.py#L51 |
|
| 2017-11-22 20:23:42 |
Ruby Loo |
tags |
rfe snmp |
rfe-approved snmp |
|
| 2017-11-24 14:47:06 |
Ilya Etingof |
ironic: assignee |
|
Ilya Etingof (etingof) |
|
| 2018-02-16 09:46:12 |
Ilya Etingof |
description |
The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the control plane network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters to utilize all the SNMPv3 security features. Then the operator could configure SNMP driver to use either SNMP v1, v2c or v3 by way of setting the `snmp_version` option (which is already present).
SNMPv3-related options to be introduced would be:
* snmp_usm_user: user name (string)
* snmp_usm_auth_protocol: tokens like md5, sha
* snmp_usm_auth_key: ascii string
* snmp_usm_priv_protocol: tokens like des, aes
* snmp_usm_priv_key: ascii string
* snmp_context_name: SNMP context (string) to address possibly many instances of the same MIB behind a single SNMP agent
Implementation-wise, we would not need to fork Ironic SNMP driver or introduce new hardware type or migrate existing SNMPv1/v2c configuration by way of adding SNMPv3 support to the SNMP driver.
The same applies to the VirtualPDU tool -- we will need to teach it picking up the options above [1], no backward incompatible changes anticipated.
The proposed change would introduce the indirect dependency on the `pycryptodomex` package which pysnmp (4.4.1+) uses for the low-level crypto operations.
1. https://github.com/openstack/virtualpdu/blob/master/virtualpdu/main.py#L51 |
The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the management network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters to utilize all the SNMPv3 security features. Then the operator could configure SNMP driver to use either SNMP v1, v2c or v3 by way of setting the `snmp_version` option (which is already present).
SNMPv3-related options to be introduced would be:
* snmp_usm_user: user name (string)
* snmp_usm_auth_protocol: tokens like md5, sha
* snmp_usm_auth_key: ascii string
* snmp_usm_priv_protocol: tokens like des, aes
* snmp_usm_priv_key: ascii string
* snmp_context_name: SNMP context (string) to address possibly many instances of the same MIB behind a single SNMP agent
Implementation-wise, we would not need to fork Ironic SNMP driver or introduce new hardware type or migrate existing SNMPv1/v2c configuration by way of adding SNMPv3 support to the SNMP driver.
The same applies to the VirtualPDU tool -- we will need to teach it picking up the options above [1], no backward incompatible changes anticipated.
The proposed change would introduce the indirect dependency on the `pycryptodomex` package which pysnmp (4.4.1+) uses for the low-level crypto operations.
1. https://github.com/openstack/virtualpdu/blob/master/virtualpdu/main.py#L51 |
|
| 2018-02-26 11:40:20 |
OpenStack Infra |
ironic: status |
Confirmed |
In Progress |
|
| 2023-11-19 15:01:50 |
Dmitry Tantsur |
ironic: status |
In Progress |
Fix Released |
|
