Bug 624673 - Rework fence_vmware fence agent to use SOAP API to connect to Virtual Center instead of VMware Perl API
Rework fence_vmware fence agent to use SOAP API to connect to Virtual Center ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fence-agents (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: Marek Grac
Dean Jansa
:
: 486207 590696 (view as bug list)
Depends On: 668522 681835 755034
Blocks: GSS_6_2_PROPOSED 688370 688372 688374 688375
  Show dependency treegraph
 
Reported: 2010-08-17 09:11 EDT by Perry Myers
Modified: 2013-03-06 16:01 EST (History)
11 users (show)

See Also:
Fixed In Version: fence-agents-3.1.5-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 634567 668522 (view as bug list)
Environment:
Last Closed: 2011-12-06 07:22:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 17342 None None None Never
Red Hat Knowledge Base (Legacy) 29440 None None None Never

  None (edit)
Description Perry Myers 2010-08-17 09:11:14 EDT
Description of problem:
Existing fence_vmware uses 3rd party RPM dependency from VMware (VMware Perl API).  libvirt VMware/ESX driver implemented a SOAP method to connect to Virtual Center.

libvirt usage is fairly different than what we want for a general fence agent, so it's been recommended by libvirt team that we lift their SOAP code (just the parts of it that we need for the fence agent) and use it to rework the fence_vmware agent.
Comment 1 Ryan O'Hara 2010-08-30 14:13:27 EDT
Doing this will allow us to remove fence_vmware_helper.pl and fence_vware can be exclusively Python code. This will likely create a dependency on a SOAP module to be pulled into Pyton, such as SOAPy.

The vmware web site has a "VMware Infrastructure SDK Programming Guide" that seems helpful, too. Basic power on/off operations are PowerOnVM_Task and PowerOffVM_Task. Also look at libvirt, which uses a C API but has some python code to generate the SOAP code. This is more than we need for fence_vmware, but might be a handy reference.
Comment 2 Perry Myers 2010-09-16 07:53:33 EDT
*** Bug 486207 has been marked as a duplicate of this bug. ***
Comment 4 Perry Myers 2010-11-27 08:33:09 EST
*** Bug 590696 has been marked as a duplicate of this bug. ***
Comment 6 Brian Likosar 2011-02-07 15:45:39 EST
One thing to consider is that having a username/password combination with this level of access can be dangerous.  In documentation we ought to recommend that access levels be leveraged to provide a user with specific privileges.  Further, usernames and passwords can expire - using some authentication method (similar to ssh keys as in ESX connectivity previously) would be the ideal solution/option.
Comment 7 Perry Myers 2011-02-07 15:50:22 EST
liko also mentioned that there may be a way to use some sort of vCenter auth token in place of traditional user/pass.  If this auth method exists in vCenter we should investigate and incorporate it into the design of the new fence agent.
Comment 8 Perry Myers 2011-02-27 21:06:52 EST
Talked to marx about this, and he is not aware of any auth mechanism exposed via the SOAP interface aside from standard user/password.  There may be other auth mechanisms available to vCenter in general, but if they're not exposed via SOAP we can't take advantage of them.

As liko mentions above, we should document the following as best practice:

In vCenter create a new user that has limited permissions (i.e. user foo can only control guest 1 & 2 lifecycle functions).  Then the fence_vmware agent can be configured only with user foo credentials, limiting exposure of that user/pass.

liko: is pw timeout a hardcoded thing in vCenter or maybe does it only apply to the top level Administrator user?
Comment 9 Marek Grac 2011-02-28 03:50:32 EST
I have found out that even it is not mentioned in manual, method LoginBySSPI is documented in API. So we can try to implement it.
Comment 10 Marek Grac 2011-02-28 08:47:34 EST
LoginBySSPI in VMWare SOAP API:

http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html#loginBySSPI

@dpal: Can we use IPA for that instead of Windows AD?
Comment 11 Dmitri Pal 2011-02-28 09:48:03 EST
(In reply to comment #10)
> LoginBySSPI in VMWare SOAP API:
> 
> http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html#loginBySSPI
> 
> @dpal: Can we use IPA for that instead of Windows AD?

SSPI is a native Windows interface.
I am not sure but it actually might work.
Please see the following link 
http://msdn.microsoft.com/en-us/library/ms995352.aspx
I think you would have to implement service and client in a special way as described in the article.

Simo, can you add more?
Comment 12 Brian Likosar 2011-02-28 15:34:33 EST
@pmyers, regarding https://bugzilla.redhat.com/show_bug.cgi?id=624673#c8, I was incorrect.  There is no session timeout, so this might no longer be an issue.  From the documentation I've seen - there is fine granularity in permissions, such that the fence user can be locked down quite a bit.  I agree that we should document that as a best practice.
Comment 26 errata-xmlrpc 2011-12-06 07:22:34 EST
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.

http://rhn.redhat.com/errata/RHBA-2011-1599.html

Note You need to log in before you can comment on or make changes to this bug.