Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loss of API status on Forbidden #16731

Closed
enj opened this issue Oct 6, 2017 · 10 comments
Closed

Loss of API status on Forbidden #16731

enj opened this issue Oct 6, 2017 · 10 comments
Assignees
Labels
area/security component/auth help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. priority/P2 sig/security

Comments

@enj
Copy link
Contributor

enj commented Oct 6, 2017

Now:

$ curl -k https://$(openshift start --print-ip):8443/api/v1/namespaces/myproject/pods/podX1:8080/proxy/appEndPoint
User "system:anonymous" cannot get pods/unsafeproxy in the namespace "myproject": User "system:anonymous" cannot get pods/unsafeproxy in project "myproject"

In the past:

$ curl -k https://$(openshift start --print-ip):8443/api/v1/namespaces/myproject/pods/podX1:8080/proxy/appEndPoint
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "User \"system:anonymous\" cannot get pods/unsafeproxy in project \"myproject\"",
  "reason": "Forbidden",
  "details": {
    "name": "podX1:8080",
    "kind": "pods"
  },
  "code": 403
}

Are we OK with losing our nice machine parseable error? We lost this by moving to the upstream handlers. We should probably fix upstream to do something more useful.

@openshift/sig-security

@smarterclayton
Copy link
Contributor

smarterclayton commented Oct 6, 2017 via email

@simo5 simo5 added the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Oct 11, 2017
@liggitt
Copy link
Contributor

liggitt commented Oct 16, 2017

similar issue reported upstream, I verified we get full status objects back in 1.8, hadn't tracked down where it was fixed

kubernetes/kubernetes#52754 (comment)

@surajssd
Copy link
Contributor

This seems to be fixed in upstream:

on k8s

$ curl -k https://localhost:6443/api/v1/namespaces/default/pods/
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "pods is forbidden: User \"system:anonymous\" cannot list pods in the namespace \"default\"",
  "reason": "Forbidden",
  "details": {
    "kind": "pods"
  },
  "code": 403
}

on openshift

# curl -k https://localhost:8443/api/v1/namespaces/myproject/pods/
User "system:anonymous" cannot list pods in the namespace "myproject": User "system:anonymous" cannot list pods in project "myproject"

by upstream do you mean Kubernetes or something else?

@liggitt
Copy link
Contributor

liggitt commented Oct 16, 2017

yes, kubernetes. fixed in the 1.8 timeframe, which means openshift would pick up the fix in 3.8

@surajssd
Copy link
Contributor

Is this a beginner friendly issue? If yes, what particular areas I should look at to solve this problem?

I have been trying to solve this issue for quiet sometime now!

  • First I tried to find where this string is built? But it seems like the code is very modular and simple grep won't help.
  • When I tried the same on k8s, I found that the server throws the error in a rbac.go, about the denial of the request
  • Later I have inferred that I am being authenticated as system:anonymous but authorization step fails (please correct me if I am wrong here), the request is not going to the Admission Controllers
  • Doing more grepping on the source, found this one particular function Forbidden, thought this might be called but it is not being called so, also found a similar function here which is also not being called.
  • Now I resorted to see what kubectl has to offer, so ran the command kubectl get nodes --v 10, which listed bunch of functions, but not sure if those are server side or only called client side. The output has following line:
I1016 18:08:20.723527    8790 round_trippers.go:436] GET https://localhost:8443/api/v1/nodes 403 Forbidden in 0 milliseconds

which comes from here

  • This also led me nowhere?

Is there some specific place I should look at to fix this issue?

@surajssd
Copy link
Contributor

surajssd commented Oct 16, 2017

@liggitt thanks for that reply, did not see your early comment, but I think this will help me understand how this was solved 👍 :-)

Can you point me to the piece of code that fixed this one issue?

@enj
Copy link
Contributor Author

enj commented Oct 16, 2017

This was fixed in kubernetes/kubernetes#47384

@smarterclayton @liggitt are we OK with 3.7 not having status errors on forbidden? 3.6- work as expected, and so will 3.8+ Seems strange to have 3.7 be the only release with this in a broken state.

@xiaods
Copy link
Contributor

xiaods commented Oct 23, 2017

any update?

@simo5
Copy link
Contributor

simo5 commented Oct 25, 2017

Seem like it will be automatically fixed in 3.8, I am going to close this issue as we are not going to deal with this in 3.7 timeframe.

@simo5 simo5 closed this as completed Oct 25, 2017
@openshift openshift deleted a comment from smarterclayton Oct 25, 2017
@smarterclayton
Copy link
Contributor

Please make sure this is documented in the release notes for API changes and that it will be resolved in 3.8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security component/auth help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. priority/P2 sig/security
Projects
None yet
Development

No branches or pull requests

7 participants