Aws auth #151
Aws auth #151
Conversation
|
Looks nice. I won't have a chance to try it on the google hubs in the next
few days though.
…On Mon, May 25, 2020 at 4:48 PM Scott Henderson ***@***.***> wrote:
This adds Auth0 authentication to staging.aws-uswest2-binder.pangeo.io.
Deployed locally and seems to be working well. @TomAugspurger
<https://github.com/TomAugspurger> @jhamman <https://github.com/jhamman>,
I plan on also adding this to the AWS prod binder ASAP. Note this does not
add persistent storage or disable culling, it just requires people to
register with their github sign-on. Give it a try!
One consequence is that you can now only have one binder session running
at any given time. I think this is fine. Users see this message trying to
launch a second session:
Launch attempt 3 failed, retrying...
User scottyhq already has a running server.
The main pros are better tracking of users (emails and public github
profile info), and potentially assigning per-user permissions and
persistent storage. Pods are now named by github username, and the
image/repo is in the pod spec (e.g. kubectl describe pod -n staging
jupyter-scottyhq | grep BINDER_REQUEST)
------------------------------
You can view, comment on, or merge this pull request online at:
#151
Commit Summary
- initial auth0 config
- updated jupyterhub login
File Changes
- *M* deploy-aws/staging.yaml
<https://github.com/pangeo-data/pangeo-binder/pull/151/files#diff-7d21b802e0ad9dd8a058971cfb4917c2>
(74)
- *M* secrets-aws/staging.yaml
<https://github.com/pangeo-data/pangeo-binder/pull/151/files#diff-1ded3b67f7e0540cd696fe34bebd5d25>
(0)
Patch Links:
- https://github.com/pangeo-data/pangeo-binder/pull/151.patch
- https://github.com/pangeo-data/pangeo-binder/pull/151.diff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#151>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKAOISNNTCSPHZCMAPGJETRTLRUPANCNFSM4NJZQYXA>
.
|
Are you using a separate Auth0 account from the one I set up? I couldn't find any record of this app under my account. I really think we should use a single Auth0 account. For one thing, we will save money if we want to use the paid features. Furthermore, we will have all Pangeo users in one place, rather than spread across multiple unconnected accounts. I am happy to give out whatever privileges are needed to make this happen. |
|
sounds @rabernat, yes I created a separate account. just wanted to kick the tires myself on a rainy holiday morning ;) I'll transfer to pangeo.auth0.com before merging. |
|
No opinion :)
…On Tue, May 26, 2020 at 11:09 AM Scott Henderson ***@***.***> wrote:
sounds @rabernat <https://github.com/rabernat>, yes I created a separate
account. just wanted to kick the tires myself on a rainy holiday morning ;)
I'll transfer to pangeo.auth0.com before merging.
@TomAugspurger <https://github.com/TomAugspurger> - Would you like me to
add GCP staging config to this PR, or save it for another day?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#151 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKAOISHHURDPJVHC4URKW3RTPSSBANCNFSM4NJZQYXA>
.
|
|
Ok cool. Let's discuss this at the Pangeo meeting tomorrow. It's great to know that we can use Auth0 for all these things. What's missing I think is a broader strategy for how we want to manage identities across our different resources. We need a plan. |
| @@ -33,7 +33,7 @@ jobs: | |||
| name: Install helm | |||
| when: always | |||
| command: | | |||
| curl https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz | \ | |||
| curl https://get.helm.sh/helm-v3.4.1-linux-amd64.tar.gz | \ | |||
There was a problem hiding this comment.
matches pangeo cloud fed version as of 2/2/2021
| # name: Revert to Original EKS IP Whitelist | ||
| # when: always | ||
| # command: | | ||
| # aws eks update-cluster-config --name pangeo-binder --resources-vpc-config publicAccessCidrs=${AWS_IP_WHITELIST} > /dev/null |
There was a problem hiding this comment.
commenting deployment via CI for now to not interfere with GCP
| @@ -1,14 +1,15 @@ | |||
| # requirements.yaml | |||
| # https://github.com/jupyterhub/mybinder.org-deploy/blob/a15bac97e26b8a085255e06b3c765b9fb2e982fd/mybinder/Chart.yaml | |||
| dependencies: | |||
| - name: binderhub | |||
| version: 0.2.0-n219.hbc17443 | |||
There was a problem hiding this comment.
this is pretty far behind mybinder.org, but i don't want to mess with it since things are working
| - name: nginx-ingress | ||
| version: 1.34.2 | ||
| repository: https://kubernetes-charts.storage.googleapis.com | ||
| - name: ingress-nginx | ||
| version: 2.13.0 | ||
| repository: https://kubernetes.github.io/ingress-nginx |
There was a problem hiding this comment.
matches mybinder.org (https://github.com/jupyterhub/mybinder.org-deploy/blob/master/mybinder/Chart.yaml)
|
@TomAugspurger @rabernat after a day's worth of work I started the AWS binder back up with Auth enabled. CI failed last commit with some Helm config issues https://app.circleci.com/pipelines/github/pangeo-data/pangeo-binder/181/workflows/f7cbb6fe-178f-46cb-a272-2c5c35cde266/jobs/188 I had to change the Users of the pangeo binder are now tracked in the pangeo auth0 account. There is no checking for github org membership, anyone with a github id can use this (including pangeo-bot!). pangeo-gallery might need some updates to run via pangeo-bot with this. i'd really like to merge this in so that the latest and current AWS config is there. Then I'm hoping to leave it for future maintainers of pangeo-binder ;) I think it would be good to use the same setup for GCP. |
|
I won't have a chance to look closely for a bit, but +1 getting the AWS back ASAP, so commenting out the GCP deployment for now seems fine. |
|
addresses #188 |
This adds Auth0 authentication to staging.aws-uswest2-binder.pangeo.io. Deployed locally and seems to be working well. @TomAugspurger @jhamman, I plan on also adding this to the AWS prod binder ASAP. Note this does not add persistent storage or disable culling, it just requires people to register with their github sign-on. Give it a try!
One consequence is that you can now only have one binder session running at any given time. I think this is fine. Users see this message trying to launch a second session:
The main pros are better tracking of users (emails and public github profile info), and potentially assigning per-user permissions and persistent storage. Pods are now named by github username, and the image/repo is in the pod spec (e.g.
kubectl describe pod -n staging jupyter-scottyhq | grep BINDER_REQUEST)