kubeflow: User None is not authorized to list ... for namespace: anonymous
/kind bug
What steps did you take and what happened: Installed kubeflow 1.0. While trying to create notebook server I am getting errors like:
User None is not authorized to list kubeflow.org.v1beta1.notebooks for namespace: anonymous
and
User None is not authorized to list .v1.persistentvolumeclaims for namespace: anonymous
What did you expect to happen: Successfully create notebook servers
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
- Kubeflow version: (version number can be found at the bottom left corner of the Kubeflow dashboard): 1.0
- kfctl version: (use
kfctl version
): 1.0-rc3 - Kubernetes platform: (e.g.
minikube
) AWS kops - Kubernetes version: (use
kubectl version
): 1.15.1 - OS (e.g. from
/etc/os-release
): Ubuntu 18.04
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 10
- Comments: 50 (32 by maintainers)
Issue-Label Bot is automatically applying the labels:
Please mark this comment with 👍 or 👎 to give our bot feedback! Links: app homepage, dashboard and code for this bot.
@jlewi @swiftdiaries I believe that supporting the non auth use case by writing alternate paths in our apps is not a very scalable option long term.
I would propose hardcoding a user, like @jlewi proposes. This could be done with an Istio rule to add a userid header to every request coming from the istio gateway.
Thanks a lot
I reinstalled everything. It’s Ok now, Thank you
@hexiaoting if you have the profile in a file called
profile.yaml
, you can run it usingkubectl apply -f profile.yaml
. It’d then create a namespace calledkubeflow-anonymous
.@hexiaoting could you please look to install with: https://github.com/kubeflow/manifests/blob/v1.0-branch/kfdef/kfctl_k8s_istio.yaml
The v1.0.0 config: https://github.com/kubeflow/manifests/blob/v1.0-branch/kfdef/kfctl_k8s_istio.v1.0.0.yaml
Is not updated yet and I’m working to refresh all v1.0.0 configurations.
@swiftdiaries I believe that tracing the headers through each hop (with something like tcpdump) will reveal the underlying issue.