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

[LEAP] GitHub sub-groups don't appear as part of parent groups for the purposes of Hub access #11

Open
rabernat opened this issue May 16, 2022 · 2 comments

Comments

@rabernat
Copy link

Context

In the following issues, we discussed the implementation of restricting access to resources based on github groups

This is an example of a profile-list configuration for LEAP

https://github.com/2i2c-org/infrastructure/blob/8ce956253bb1bbc4dd633630cb68b76d753bc569/config/clusters/leap/common.values.yaml#L87-L92

The group leap-stc:leap-pangeo-education is given access to this profile.

Problem

In the LEAP Manual I said the following

Anyone participating in a LEAP-sponsored research project is eligible to participate in the Research Category. A LEAP administrator will create a GitHub sub-team within the leap-pangeo-research team for each research project and add the project PIs as “maintainer”. It is the PIs’ responsibility to add and remove members from their team.

However, we have found that sub-teams do not automatically get added to the parent team. As a specific example, I created the momentum-fellows team as a sub-team of leap-pangeo-research and added @yuvipanda to it. As you can see, he does not automatically get added to leap-pangeo-research, and whatever logic the spawner is using does not recognize him as belonging to this group. So my instructions don't currently work.

Proposal

There are two potential solutions:

  • We work around this within LEAP by just adding all users explicitly to the leap-pangeo-research team AND their appropriate sub team. When removing them, we would then have to remember to manually remove them from both teams. This is not ideal from our point of view.
  • We resolve the issue upstream by modifying the access control rules to become aware of the concept of sub-teams and parent teams. I have no idea how complex this is technically. If it is easy, that would be my preferred solution

Updates and actions

No response

@yuvipanda
Copy link
Member

@rabernat i'd say let's temporarily codify solution (1) and we can prioritize and investigate (2) during our next sprint meeting

@damianavila
Copy link

damianavila commented Sep 20, 2023

Reviewed and we think we can close it by now after checking the source.

After re-reading I think this one is actually capturing the following request:

  • modifying the access control rules to become aware of the concept of sub-teams and parent teams

So re-opening with that updated interpretation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Needs Shaping / Refinement
Development

No branches or pull requests

3 participants