Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Mechanism to mount existing Kubernetes Secret for sensitive auth, e.g. `gateway.auth.kerberos.keytab`?
See original GitHub issueHey y’all!
I was scoping the possibility of using dask-gateway (via Kubernetes and the daskhub chart) with Google-manged Notebooks on GCP’s AI Platform (They’re Jupyter notebooks). My idea was to deploy dask-gateway to a GKE cluster on the same network/VPC, with dask-gateway configured for Kerebos authentication.
I noticed that gateway.auth.kerberos.keytab takes a path to an existing keytab on the machine. I would have thought that we’d want to mount an existing Kubernetes Secret to a path with the desired permissions…? I was wondering if this is a planned feature or maybe I’m simply going about this the wrong way…?
In general, it looks like a lot of sensitive material is passed in raw through the helm configs, rather than through Kubernetes Secrets?
Thanks so much for your time and consideration! I really appreciate the work on this project.
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I think this would be a good thing to implement and I’d be happy to take on the reviewing duties.
I don’t think you want the
daskhubchart for the use case you describe. Dask Hub is a meta chart which deploys Jupyter Hub and Dask gateway together. If you are using GCP AI Platform they are already providing Jupyter for you.I’m going to move this issue over to the
dask-gatewayrepo for further discussion about using secrets.