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

added palomar cc to config/cloudbank.cluster.yaml #395

Merged
merged 1 commit into from
May 11, 2021

Conversation

sean-morris
Copy link
Contributor

@2i2c-org/tech-team Hey folks here is a first attempt at a PR for the addition of Palomar Community College.

- [email protected]
- [email protected]
- [email protected]
username_pattern: '^(.+@palomar\.edu|yuvipanda@gmail\.com|choldgraf@gmail\.com|georgiana\.dolocan@gmail\.com|aculich@berkeley\.edu|sean.smorris@berkeley\.edu|deployment-service-check)$'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yuvipanda could you explain what username_pattern means here? This line looks correct comparing it to the previous lines, but it's a bit hard to understand what it is and I don't see it documented

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @GeorgianaElena added it in #208, that PR has some context. Any ideas if we can improve this, or where we can document it, @GeorgianaElena?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at it some more, I think it's a regular expression that permits everyone from @palomar.edu, but also these explicitly listed addresses otherwise.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When an admin should not be allowed? I mean... I was expecting the admins to be excluded from the username_pattern...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was expecting the admins to be excluded from the username_pattern

Me too 👀

This is coming from jupyterhub. All users need to comply with username_pattern, including admins. Some code references:

Other thing that I noticed and I think it's related, is about allowed_users. All the admins, apart from being listed in the admin_users list, need to be in this allowed list too otherwise they will be denied access.
In my mind, if the user it's an admin, then they should be allowed by default.

(These over-complicates a bit #311 too)

I'm thinking about opening a PR on jupyterhub's side about this, but I would like to know your opinion first, in case my intuition is not right and I'm trying to create an anti-pattern.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jumping in a bit late here.

I did look around at entries for the other hubs in the cloudbank.cluster.yaml file. The username_pattern element was in the mills definition but not in the others. I probably should have checked out whether or not to use what appeared to be the general pattern:

as opposed to the pattern mills is using:

           admin_users: &mills_admins
            - [email protected]
            - [email protected]
            - [email protected]
            - [email protected]
            - [email protected]
            - [email protected]
            - [email protected]
          username_pattern:'^(.+@mills\.edu|yuvipanda@gmail\.com|choldgraf@gmail\.com|georgiana\.dolocan@gmail\.com|aculich@berkeley\.edu|jpercy@berkeley\.edu|deployment-service-check)$'

Are we ok here? Or should this change?

@yuvipanda yuvipanda merged commit fc732f9 into 2i2c-org:master May 11, 2021
@yuvipanda
Copy link
Member

Am just watching https://github.com/2i2c-org/pilot-hubs/runs/2560650750?check_suite_focus=true now, should have the hub up shortly

@damianavila
Copy link
Contributor

damianavila commented May 13, 2021

Other thing that I noticed and I think it's related, is about allowed_users. All the admins, apart from being listed in the admin_users list, need to be in this allowed list too otherwise they will be denied access.
In my mind, if the user it's an admin, then they should be allowed by default.

But if you have the allowed_users list empty, admins should be able to log in, right? cc @GeorgianaElena

Return True if username is allowed, False otherwise.
No allowed_users set means any username is allowed.

I'm thinking about opening a PR on jupyterhub's side about this, but I would like to know your opinion first, in case my intuition is not right and I'm trying to create an anti-pattern.

I think it makes sense to have a discussion there about this 😉

@yuvipanda
Copy link
Member

If allowed_users is empty, than everyone is allowed to login. But what we want is to only allow people who are admins to log in as well, so they can add other users via the db. For things like mills, we want everyone with the mills id to be able to log in, and in addition to that we want the people who are admins to login - so maybe they don't need to be listed in username_pattern? Not sure!

We're mixing two sources of users - the config and the db. This gets quite confusing...

@damianavila
Copy link
Contributor

If allowed_users is empty, than everyone is allowed to login. But what we want is to only allow people who are admins to log in as well, so they can add other users via the db.

Yep, I got that from another comment you posted in another issue, thanks for the clarification.
Quick question, how frequently are we backing up the db? Because if we lose that "allowed users" content, it could be a nightmare for the admins to re-add people...

so maybe they don't need to be listed in username_pattern? Not sure!

Since you are defining username_pattern, I think you may need to explicitly add the admins there because it does not seem admins are "allowed" nor "patterned" by default... which I find weird at first, but I am maybe missing something else.

We're mixing two sources of users - the config and the db. This gets quite confusing...

Maybe some explicit note in the docs could help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants