Bug 1309891

Summary:	[RFE] RHEV-M REST Needs API Keys in Addition to UID/PW Access
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Keith Robertson <kroberts>
Component:	ovirt-engine	Assignee:	Nobody <nobody>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	high	Docs Contact:
Priority:	low
Version:	unspecified	CC:	gklein, jmoran, kroberts, lsurette, oourfali, rbalakri, Rhev-m-bugs, sbonazzo, yeylon, ykaul, ylavi
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-22 15:34:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Sub-Eng	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Keith Robertson 2016-02-18 22:05:12 UTC

The Red Hat Insights team will be creating a monitoring solution for RHEV beginning in RHEV 4.0.  To monitor the entire RHEV ecosystem, we need the ability to discover all of the topological information that constitutes a RHEV deployment.  This information includes, but is not limited to...
- Data Centers
- Clusters
- Hosts (ie. hypervisors IP and hostname SPM).
- Attached storage domains
- Various other bits of information 

Currently, there are REST API is gated by a UID and PW that are typically controlled by an integrated LDAP or AD server.  Hence, it is difficult for an Insights client to use the REST API without and administrator creating a UID/PW specifically for the client.

We believe that this would be a blocker to adoption and we think that having the Insights client store a UID/PW is a bad idea anyway.  

A better approach would be to have API access granted to the local 'root' user and/or a key that a client application could use from a designated host.

Comment 1 Oved Ourfali 2016-02-19 07:45:38 UTC

This shouldn't be a blocker for adoptation in any way. 

In 3.6 we provide an internal extension that you can add more users to, so, the setup can be changed to ask for a password for this user, create it for you automatically, and also configure the monitor system itself. 

You, of course, need to sync that with the integration team. 

We aren't going to add another type of authentication, such as the one you suggested. 

I suggest you indeed sync with the integration team, and change the title,  component and ovirt team of this bug accordingly.

Comment 2 Yaniv Lavi 2016-02-24 12:29:42 UTC

How do we resolve this issue with CFME?

Comment 3 Oved Ourfali 2016-02-24 12:42:23 UTC

(In reply to Yaniv Dary from comment #2)
> How do we resolve this issue with CFME?

Please elaborate, as the question isn't clear.
CFME has the username and password as well.

Comment 4 Yaniv Lavi 2016-02-24 12:48:44 UTC

(In reply to Oved Ourfali from comment #3)
> (In reply to Yaniv Dary from comment #2)
> > How do we resolve this issue with CFME?
> 
> Please elaborate, as the question isn't clear.
> CFME has the username and password as well.

Is it automatically defined? Is is the manual step in their setup?

Comment 5 Oved Ourfali 2016-02-24 12:51:42 UTC

(In reply to Yaniv Dary from comment #4)
> (In reply to Oved Ourfali from comment #3)
> > (In reply to Yaniv Dary from comment #2)
> > > How do we resolve this issue with CFME?
> > 
> > Please elaborate, as the question isn't clear.
> > CFME has the username and password as well.
> 
> Is it automatically defined? Is is the manual step in their setup?

When you add a rhev provider, you need to provide details.
Just as if you add an external provider in rhev to openstack/foreman/anything else...

Comment 6 Oved Ourfali 2016-02-29 12:31:52 UTC

Moving to the integration team for consideration, as per comment #1.

Comment 7 Yaniv Lavi 2016-03-02 14:54:30 UTC

Any thoughts?

Comment 8 Yaniv Lavi 2016-03-03 09:23:27 UTC

Keith, why don't you ask the admin@internal password in the access insights setup (or a password for another user)?

Comment 9 Keith Robertson 2016-03-17 14:20:35 UTC

(In reply to Yaniv Dary from comment #8)
> Keith, why don't you ask the admin@internal password in the access insights
> setup (or a password for another user)?

Yaniv,
We ultimately decided to do this in lieu of a better option.  It would still be nice to have an API key so that we don't need to save UID/PW to disk but UID/PW is the best option available, today.  To be clear, this BZ is not impeding our ability to execute Insights for RHEV.

Our flow, today, is as follows...
1) A RHEV Admin user creates a specific user for Insights via the RHEV-M UI.
2) When the RHEV Insights coordinator is launched there will be an option configure/save the user created in 1 to a config file.  
3) When the cron job fires and launches the Insights coordinator, the Insights coordinator will read credentials saved in 2 to the gain access to the RHEV-M's REST API.


NOTE: We are exploring whether or not we can create an Insights user directly from the RHEV-M's REST API _whithout_ going through the RHEV-M's UI.  The flow for this, if it works, would look something like this...
1) redhat-insights-rhev --configure
2) Prompt user for a RHEV-M admin user with the ability to create other users.
3) Use the credentials from 2 to create a user for Insights via the REST API
4) Save user created in 3 to config file.

Comment 10 Sandro Bonazzola 2016-03-22 15:28:31 UTC

Looks like changes in engine-setup are not needed then.
From my understanding this bug can be either closed wontfix or moved to insights.
Moving to sub-eng team for now.

Comment 11 Keith Robertson 2016-03-22 15:34:29 UTC

Again, API key would be nice so that we don't need to save PWs to disk but this will not be the first application to save a PW to a file.  IOW, there is precedent.