Bug 1315157 - f5 plugin hardcodes admin user name
Summary: f5 plugin hardcodes admin user name
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Routing
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Ram Ranganathan
QA Contact: zhaozhanqi
Depends On:
TreeView+ depends on / blocked
Reported: 2016-03-07 05:47 UTC by Jaspreet Kaur
Modified: 2016-08-24 03:54 UTC (History)
10 users (show)

Clone Of:
Last Closed: 2016-05-12 16:31:25 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:1064 normal SHIPPED_LIVE Important: Red Hat OpenShift Enterprise 3.2 security, bug fix, and enhancement update 2016-05-12 20:19:17 UTC

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


For security reasons, it may be required to use another user (with restricted privileges) to configure the f5.

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:

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

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 error: Decoder.Decode failed: invalid character '<' looking for beginning of value
error: Encountered an error on GET request to URL 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.


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