User cannot list pods in the namespace #167
Comments
|
output of Does this mean that the system:serviceaccount:pangeo:default user does not exist? Any suggestions on how to create this account with the CLI if so? Thanks! |
|
I'm not currently able to reproduce. You might want to try with the newer dask_kubernetes library from dask_kubernetes import KubeCluster
cluster = KubeCluster()
cluster.scale(2)
cluster |
|
Thanks @mrocklin. I tried your suggestion and got the same result. One thing that may be related is that I cannot get to work, so I commented it out, and that may mean that I need a service account that is not there. Do you have system:serviceaccount:pangeo:default in your clusterrolebinding? If not, maybe I need to troubleshoot the rbac setting in jupyter-config.yaml. |
|
Ah, I see, you're on your own deployment. Having rbac enabled would
explain the issues you're having.
Another solution to this problem would be to just properly define roles,
which is something we need to do anyway, but not something about which I
have any particular expertise. If this is something you wanted to look
into it would be a helpful addition to upstream.
…On Sat, Mar 17, 2018 at 4:07 PM, Tim Crone ***@***.***> wrote:
Thanks @mrocklin <https://github.com/mrocklin>. I tried your suggestion
and got the same result. One thing that may be related is that I cannot get
rbac:
enabled: false
to work, so I commented it out, and that may mean that I need a service
account that is not there. Do you have system:serviceaccount:pangeo:default
in your clusterrolebinding? If not, maybe I need to troubleshoot the rbac
setting in jupyter-config.yaml.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#167 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASszJsTU092WgXLnSIvOvKRZZl1fbY0ks5tfWz-gaJpZM4Su2he>
.
|
|
I don't know why, but jupyterhub will not install without rbac enabled in my yaml file. Helm throws a strangely worded "timed out waiting for the condition" error. It's not clear that anyone else is having this problem, so I will keep working on the rbac issue and keep you posted. Please let me know if you think of any reason why this might not be working for me. I will also look into role definitions as a possible alternative fix. Thanks! |
|
I'm probably not the person to help solve that. @yuvipanda and
@jacobtomlinson have the most expertise here, though they may be busy.
…On Sat, Mar 17, 2018 at 5:23 PM, Tim Crone ***@***.***> wrote:
I don't know why, but jupyterhub will not install with rbac enabled in my
yaml file. Helm throws a strangely worded "timed out waiting for the
condition" error. It's not clear that anyone else is having this problem,
so I will keep working on the rbac issue and keep you posted. Please let me
know if you think of any reason why this might not be working for me. I
will also look into role definitions as a possible alternative fix. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#167 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASszBtQBrOUOVIWEInm4zETzzd25Fu5ks5tfX7agaJpZM4Su2he>
.
|
|
Issue solved. The latest version of gcloud now creates clusters with the --no-enable-legacy-authorization option set by default. To create a cluster that will allow legacy authorization and thus allow jupyterlab to be install with rbac.enabled=false, it is necessary to create the cluster with the --enable-legacy-authorization flag. As you noted, operating without RBAC is super insecure, so we will eventually need to create a single user service account with the appropriate access. Not my area of expertise but I'd be happy to look into how it might work. |
|
I strongly advise against disabling RBAC. It is rather tedious to get everything configured correctly but once you do you will be in a much more secure position. Here is the service account config we are using to get you started. I am actively tweaking it so it isn't perfect yet, for example I can't seem to get pod logs through dask-kubernetes-serviceaccount.yamlkind: ServiceAccount
apiVersion: v1
metadata:
name: daskkubernetes
namespace: jupyter
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: daskkubernetes
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "list", "watch", "create", "delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: daskkubernetes
subjects:
- kind: ServiceAccount
name: daskkubernetes
namespace: jupyter
roleRef:
kind: Role
name: daskkubernetes
apiGroup: rbac.authorization.k8s.ioZero to jupyterhub configsingleuser:
serviceAccountName: daskkubernetes |
|
@jacobtomlinson if you have any interest in contributing something like this to upstream that would be very welcome. |
|
Happy to do so. I'll put a PR into z2jh to allow easy configuration. In our instance we are talking about |
|
@jacobtomlinson, thanks this is great. I managed to get this working mostly as is, using: but I had to add the namespace into the metadata section of the role and rolebinding because otherwise these get added to the default namespace. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed because it had not seen recent activity. The issue can always be reopened at a later date. |
When trying to execute the following within my own GCP deployment:
I get the following error:
I'm guessing this is because of some permission issue or missing service account setting on GCP. Any ideas what might be going on?
The text was updated successfully, but these errors were encountered: