Bug 1315157

Summary: f5 plugin hardcodes admin user name
Product: OpenShift Container Platform Reporter: Jaspreet Kaur <jkaur>
Component: NetworkingAssignee: Ram Ranganathan <ramr>
Networking sub component: router QA Contact: zhaozhanqi <zzhao>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: high CC: aos-bugs, bbennett, bleanhar, bmeng, cryan, jokerman, mmasters, mmccomas, tdawson, zzhao
Version: 3.1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-12 16:31:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jaspreet Kaur 2016-03-07 05:47:13 UTC
Description of problem: The admin user is hardcoded in the plugin:

https://github.com/openshift/origin/blob/master/pkg/router/f5/f5.go#L1517

For security reasons, it may be required to use another user (with restricted privileges) to configure the f5.
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-concepts-11-4-0/10.html

This may lead to errors that we do not handle in the current implementation.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Ben Bennett 2016-03-07 15:25:37 UTC
Ram, should this be configurable?

Comment 2 Ben Bennett 2016-03-07 15:26:43 UTC
I closed https://github.com/openshift/origin/issues/7821 as a duplicate of this bug.

Comment 3 Ram Ranganathan 2016-03-07 19:07:50 UTC
Ben, yeah the admin account is used to upload the certs and key for TLS configuration. I think that's a bug - it can be the username passed to the router via 
--external-host-username  (or in the context of this code f5.username). 

@Miciah that sound good or is it

Comment 4 Ram Ranganathan 2016-03-07 19:08:55 UTC
oops hit enter too soon. @Miciah does https://bugzilla.redhat.com/show_bug.cgi?id=1315157#c3 sound good or are there other implications?  Thx

Comment 5 Ram Ranganathan 2016-03-07 19:25:45 UTC
PR at: https://github.com/openshift/origin/pull/7842

Comment 6 Miciah Dashiel Butler Masters 2016-03-07 19:30:08 UTC
That is correct: We use f5.username for iControl REST API calls and "admin" for SSH sessions, but we should probably use f5.username for both.  (In the v2 routing-daemon, we use the configured username for both.)

Comment 8 zhaozhanqi 2016-03-09 07:59:36 UTC
@Ram

I saw the code is using the default auth method SetBasicAuth. 
When I using the wrong username to test this. the F5 pod has some errors as below, In my opinion, I don't think the following message is useful to find the reason (user name is wrong)

***********************************************

# oc logs router-1-av2naW0309 02:52:55.159149    2234 reflector.go:289] pkg/admission/limitranger/admission.go:146: watch of *api.LimitRange ended with: 401: The event in requested index is outdated and cleared (the requested history has been cleared [192/83]) [1191]

W0309 07:52:27.537094       1 f5.go:243] Strict certificate verification is *DISABLED*
E0309 07:52:30.075312       1 f5.go:700] partition path "/Common" error: Encountered an error on GET request to URL https://10.3.88.53/mgmt/tm/sys/folder/~Common: error: Decoder.Decode failed: invalid character '<' looking for beginning of value
error: Encountered an error on GET request to URL https://10.3.88.53/mgmt/tm/sys/folder/~Common: error: Decoder.Decode failed: invalid character '<' looking for beginning of value


************************************************

Comment 9 Miciah Dashiel Butler Masters 2016-03-09 14:05:11 UTC
The F5 iControl REST API sometimes returns HTML responses instead of JSON.  It does so (at least sometimes) for HTTP 404; looks like it also does so for HTTP 401.  For this reason, we special-case HTTP 404 in rest_request to avoid attempting to decode the response; looks like we need to do the same for HTTP 401.  I'll make a PR to do so.

Comment 10 Ram Ranganathan 2016-03-09 18:39:12 UTC
@miciah Thanks. 

@zhaozhanqi this is sort of a different issue than this bug fix (will fail even without this fix, if you use an invalid user name/credentials). The test for this specific bug fix would be to specify a valid user not named 'admin' and see that it works fine. 
So if you could please file another bug and assign it to Miciah, that would be great for tracking purposes. Thx

Comment 11 zhaozhanqi 2016-03-10 11:09:52 UTC
verified this on 
oc v3.2.0.1
kubernetes v1.2.0-alpha.7-703-gbc4550d

when using a invalid username, the router pod cannot be running.

Comment 13 zhaozhanqi 2016-04-22 09:03:27 UTC
yeah, have verified in oc v3.2.0.1

Comment 15 errata-xmlrpc 2016-05-12 16:31:25 UTC
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://access.redhat.com/errata/RHSA-2016:1064