Bug 996926
Summary: | [RFE] Additional fields for fence_apc_snmp in the RHEV UI | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Marko Karg <mkarg> |
Component: | RFEs | Assignee: | Alexander Wels <awels> |
Status: | CLOSED ERRATA | QA Contact: | Antonin Pagac <apagac> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.2.0 | CC: | adahms, apagac, awels, bazulay, emesika, iheim, lpeer, mgrac, nbarcet, oourfali, pstehlik, rbalakri, sherold, yeylon, ykaul, ylavi |
Target Milestone: | ovirt-3.6.0-rc | Keywords: | FutureFeature, Improvement |
Target Release: | 3.6.0 | Flags: | sherold:
Triaged+
|
Hardware: | All | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: |
With this update, it is now possible to specify whether encryption is set for fence agent fields in the Power Management tab of the New Host and Edit Host windows. This enhancement addresses cases where certain fence agents require the ability to set whether a field is encrypted.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2016-03-09 20:31:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marko Karg
2013-08-14 09:49:24 UTC
(In reply to Marko Karg from comment #0) > Description of problem: > > We're missing a field for the parameter snmp_priv_passwd in the RHEV UI > window for the host powermanagement. Thus they are forced to enter it in > cleartext in the options field, which for them is a security concern and in > general is error prone. > > Version-Release number of selected component (if applicable): > > RHEV 3.2 > > How reproducible: > > always > > Steps to Reproduce: > 1. go to the power management settings > 2. set the type to fence_apc_snmp > 3. check the fields - there is none for the snmp_priv_passwd > > Actual results: > > The fields missing and has to be set up via the options > > Expected results: > > Fields for all possible parameters for the fence_apc_snmp type (for all > fence devices we support would of course be best). > Fields that contain passwords should be non-cleartext fields and contents > should be displayed as asterisks. This is fully supported by putting in the options field "P=<value>" The agent list handles 3 special parameters that are common to all PM agents 1) Secure flag 2) Port 3) Slot All other parameters should be issued in the options field with the following format <key1>=<val1>, ...... <keyN>=<valN> I think that this RFE should be closed I'm not sure it merits closing - seems like a UI nit pick. However I don't understand the more secure part? Marek, Can you please explain the what is the difference between the user/pass (that we can configure in apc_snmp) to the snmp_priv_passwd field the customer wants to add. @Barak, In SNMPv3 there are 3 levels of security: * noAuthnoPriv - only community name is used * AuthNoPriv - authentication (normal password) * AuthPriv - authentication & encryption of SNMP password (snmp_priv_password) Eli there is an option to add a simple checkbox whether to encrypt the options, This will solve the unencryped password in the DB, but the vdsm will still log it. This will not make it into 3.4 , hence moving to rhevm-future Eli please add the full description of this option in terms of building blocks. (In reply to Barak from comment #5) > Eli please add the full description of this option in terms of building > blocks. DB : Add a field (boolean) indicating if to encrypt options or not - default false (so no need to handle upgrade of the options field content) ENGINE : Adding handling in VDSDbFacadeImpl for encrypt/decrypt the options field according to the flag API : Adding support for the additional flag in POST/PUT/GET As stated in comment 5 , options will stay plain-text in teh VDSM level Arthur ? (In reply to Eli Mesika from comment #6) > (In reply to Barak from comment #5) > > > Eli please add the full description of this option in terms of building > > blocks. > > DB : > Add a field (boolean) indicating if to encrypt options or not - default > false (so no need to handle upgrade of the options field content) > > ENGINE : > Adding handling in VDSDbFacadeImpl for encrypt/decrypt the options > field according to the flag > > API : > Adding support for the additional flag in POST/PUT/GET > > As stated in comment 5 , options will stay plain-text in teh VDSM level > > Arthur ? This option sound good to me. Moving to consider to 3.6.0. Alexander: details on Comment #6, please contact Eli before starting the implementation to verify that what you intend to do is what actually needed. thanks. Alexander - should be in POST (since there is a patch)? Yes, hadn't gotten around to the book keeping yet. Build ID: 3.6.0-1 Verified. DB: Table 'fence_agents' contains 'encrypt_options', and if set, the options are encrypted. ENGINE: There is a 'Encrypt options' checkbox when 'apc_snmp' power management type is chosen. API: In /ovirt-engine/api/hosts/<HOST_ID>/fenceagents/<FENCEAGENT_ID> is '<encrypt_options>' flag. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html |