Bug 1414300

Summary: Pod request OAuth provider information caused apisever to panic
Product: OpenShift Container Platform Reporter: Chuan Yu <chuyu>
Component: apiserver-authAssignee: Stefan Schimanski <sttts>
Status: CLOSED ERRATA QA Contact: Chuan Yu <chuyu>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.0CC: aos-bugs, jliggitt, tdawson
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-12 19:09:49 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 Chuan Yu 2017-01-18 09:28:54 UTC 
Description of problem:
This request caused apisever to panic when Oauth provider info consumed in a pod

Version-Release number of selected component (if applicable):
openshift v3.5.0.4+86a6117
kubernetes v1.5.0-beta.2+225eecc
etcd 3.1.0-rc.0

How reproducible:
always

Steps to Reproduce:
1.Create a test pod which contain a shell env
2.try to check the url in the pod, oc rsh <pod name>in the test pod:
  curl https://openshift.default.svc/.well-known/oauth-authorization-server -k
3.

Actual results:
Return some error hint 'This request caused apisever to panic. Look in log for details.'

Expected results:
Should return some Oauth provider info

Additional info:
/var/log/messages:
Jan 18 02:41:50 atomic-openshift-master: I0118 02:41:50.859507   92440 asm_amd64.s:479] GET /.well-known/oauth-authorization-server: (292.386µs) 0 [[curl/7.29.0] 192.168.2.150:46538]
Jan 18 02:41:50 atomic-openshift-master: E0118 02:41:50.859925   92440 runtime.go:64] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference)

Jan 18 02:41:50 atomic-openshift-master: E0118 02:41:50.860497   92440 panics.go:37] APIServer panic'd on GET /.well-known/oauth-authorization-server: runtime error: invalid memory address or nil pointer dereference
Jan 18 02:41:50 atomic-openshift-master: goroutine 38381 [running]:
Jan 18 02:41:50 atomic-openshift-master: runtime/debug.Stack(0x8d780e0, 0xc42cb3ae00, 0x4289743)
Jan 18 02:41:50 atomic-openshift-master: /usr/lib/golang/src/runtime/debug/stack.go:24 +0x79
Jan 18 02:41:50 atomic-openshift-master: github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/genericapiserver/filters.WithPanicRecovery.func1.1(0x3a88da0, 0xc420010040)
Jan 18 02:41:50 atomic-openshift-master: /builddir/build/BUILD/atomic-openshift-git-0.86a6117/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/genericapiserver/filters/panics.go:37 +0x74
Comment 1 Jordan Liggitt 2017-01-18 14:47:04 UTC 
fixed in https://github.com/openshift/origin/pull/12459
Comment 2 Jordan Liggitt 2017-01-18 14:48:24 UTC 
fixed in v3.5.0.5
Comment 3 Chuan Yu 2017-01-19 02:11:12 UTC 
Verified in v3.5.0.6, steps:
1.Create a test pod which contain a shell env
2.try to check the url in the pod, oc rsh <pod name>in the test pod:
  curl https://openshift.default.svc/.well-known/oauth-authorization-server -k
3.get the results as expected:

{
        "issuer": "https://master:8443",
        "authorization_endpoint": "https://master:8443/oauth/authorize",
        "token_endpoint": "https://master:8443/oauth/token",
        "scopes_supported": [
          "user:full",
          "user:info",
          "user:check-access",
          "user:list-scoped-projects",
          "user:list-projects"
        ],
        "response_types_supported": [
          "code",
          "token"
        ],
        "grant_types_supported": [
          "authorization_code",
          "implicit"
        ],
        "code_challenge_methods_supported": [
          "plain",
          "S256"
        ]
      }


# openshift version
openshift v3.5.0.6+87f6173
kubernetes v1.5.2+43a9be4
etcd 3.1.0-rc.0
Comment 5 errata-xmlrpc 2017-04-12 19:09:49 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/RHBA-2017:0884