Bug 1289603 - oc login fails with Unauthorized error sometimes on HA etcd environment
oc login fails with Unauthorized error sometimes on HA etcd environment
Product: OpenShift Container Platform
Classification: Red Hat
Component: Auth (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Jordan Liggitt
weiwei jiang
Depends On: 1282718
Blocks: 1267746
  Show dependency treegraph
Reported: 2015-12-08 09:30 EST by Evgheni Dereveanchin
Modified: 2016-10-30 18:54 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1282718
Last Closed: 2016-01-26 14:19:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Evgheni Dereveanchin 2015-12-08 09:30:19 EST
+++ This bug was initially created as a clone of Bug #1282718 +++

Description of problem:

In an HA scenario logins may fail with a 401 Unauthorized error.
This seems to happen due to stale reads from etcd.

How reproducible:

Steps to Reproduce:
1) set up a 3.1 environment with HA etcd
2) log into the server multiple times
# sum=0;for i in {1..500}; do oc login https://<master-url>:8443 -u <username> -p <password>; if [[ $? == 0 ]]; then sum=$(($sum + 1)); fi ; done; echo $sum

Actual results:
Sometime can't login, run 500 times, about 230 login failed.

Expected results:
All the login opts should be successful

Additional info:
In non-HA setups the test plan always runs with 0 failed logins

--- Additional comment from Jordan Liggitt on 2015-11-18 19:06:22 CET ---

Pretty sure this is a stale read issue when using an etcd cluster. I see this in the master configs:

  ca: master.etcd-ca.crt
  certFile: master.etcd-client.crt
  keyFile: master.etcd-client.key
    - https://openshift-159.lab.eng.nay.redhat.com:2379
    - https://openshift-138.lab.eng.nay.redhat.com:2379
    - https://openshift-155.lab.eng.nay.redhat.com:2379

So there are at least three etcd servers in place, right?

1. The token is created, written to etcd, and returned to the client.
2. The client then uses the token against the users/~ API
3. The authentication layer attempts to verify the token exists in etcd. There is no guarantee the same etcd server is queried for the token.

In this case, I think a quorum read may be needed when the token is not found.
Comment 2 Jordan Liggitt 2015-12-09 14:36:36 EST
Recreated locally with single master and 3-node etcd cluster. A quorum read is needed. The current (deprecated) etcd client does not expose the quorum read option. Work upstream to switch to the current etcd client is tracked in https://github.com/kubernetes/kubernetes/issues/11962
Comment 3 Jordan Liggitt 2015-12-09 14:44:00 EST
For reference, I spun up an etcd cluster in three docker containers like this:


docker run -d -p 4001:4001 -p 7001:7001 --name etcd0 quay.io/coreos/etcd:v2.0.3 \
 -name etcd0 \
 -advertise-client-urls       http://$IP:4001 \
 -listen-client-urls \
 -initial-advertise-peer-urls http://$IP:7001 \
 -listen-peer-urls   \
 -initial-cluster-token       my-etcd-cluster \
 -initial-cluster etcd0=http://$IP:7001,etcd1=http://$IP:7002,etcd2=http://$IP:7003 \
 -initial-cluster-state new

docker run -d -p 4002:4002 -p 7002:7002 --name etcd1 quay.io/coreos/etcd:v2.0.3 \
 -name etcd1 \
 -advertise-client-urls       http://$IP:4002 \
 -listen-client-urls \
 -initial-advertise-peer-urls http://$IP:7002 \
 -listen-peer-urls   \
 -initial-cluster-token       my-etcd-cluster \
 -initial-cluster etcd0=http://$IP:7001,etcd1=http://$IP:7002,etcd2=http://$IP:7003 \
 -initial-cluster-state existing

docker run -d -p 4003:4003 -p 7003:7003 --name etcd2 quay.io/coreos/etcd:v2.0.3 \
 -name etcd2 \
 -advertise-client-urls       http://$IP:4003 \
 -listen-client-urls \
 -initial-advertise-peer-urls http://$IP:7003 \
 -listen-peer-urls   \
 -initial-cluster-token       my-etcd-cluster \
 -initial-cluster etcd0=http://$IP:7001,etcd1=http://$IP:7002,etcd2=http://$IP:7003 \
 -initial-cluster-state existing

Then started my master server from a config referencing an external etcd like this:

  ca: ""
  certFile: ""
  keyFile: ""
Comment 7 Jordan Liggitt 2016-01-13 13:13:40 EST
Fixed in puddle AtomicOpenShift/3.1/2016-01-13.1
Comment 8 DeShuai Ma 2016-01-14 00:49:39 EST
Verify on puddle AtomicOpenShift/3.1/2016-01-13.1, this bug is fixed.
Comment 10 errata-xmlrpc 2016-01-26 14:19:35 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.


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