search

operate-first / blueprint

This is the blueprint for the Operate First Initiative
GNU General Public License v3.0
16 stars 16 forks source link

Specify existing academic environment requirements for access control to operations data #79

Closed hpdempsey closed 2 years ago

hpdempsey commented 3 years ago

The MOC, NERC and MGHPCC have existing requirements for granting different types of users access to operations data. These are not fully specified in the blueprint or ADRs for the current open issues related to access control. Collect this information and decide how to add it to the design document and relevant open issues.

hpdempsey commented 3 years ago

related issue #76 #77 #30

hpdempsey commented 3 years ago
  1. SSO systems are already in use in universities and research centers. The two most common identity and access management systems are Globus for researchers (https://www.globus.org/ ) and InCommon for US students (https://www.incommon.org/solutions/). Requirement: Academic users will use the SSO system their university designates to access Operate First services and data.
  2. Academic environments have public policies about acceptable use of their facilities. This allows them to specify who has access to services and data, and under what conditions that access can be revoked. The AUP can also specify conditions of use (such as no expectation of privacy). CloudLab has an excellent policy that has been successfully used for academic operations for many years: https://www.cloudlab.us/aup.php Requirement: Operate First will use identities from requirement #1 to manage access to services and data in keeping with the facility AUP. Only users with an active Operate First account may access services and data. (Derived requirement: Operate First environment will publish an AUP. This will require academic review.)
  3. The onboarding process for an academic environment ensures that each user views the AUP. Using your account means you accept the AUP. (Academic environments almost never have license agreements for end users.) Requirement: Onboarding for Operate First includes showing users the AUP. (Derived requirement: Operate First users whose accounts predate the AUP must be contacted so they can view and accept the AUP.)
  4. Academic environments may further limit access to specific operations data to a subset of users for privacy or security reasons. This level of access restriction cannot be supported in Operate First. Another way to express this is that the AUP must specify that operations data is available to all users with active accounts. Requirement: Operate First will not collect or store operations data that requires restricting data access to a subset of all active Operate First users. (This will require academic reviewers. This requirement also negates the need for a privacy policy. See https://www.globus.org/legal/privacy for a privacy policy successfully used for many years in Globus.) NONE of items 1-4 are actually legal agreements or contracts, so it is relatively straightforward to create and publish them.
  5. If data is transferred into or out of an academic environment, the university requires an approved data use agreement. The university may also require approval from an Institutional Review Board for data that involves human subjects. Examples for BU: https://www.bu.edu/researchsupport/forms-policies/data-use-agreement-form/ ://www.bu.edu/researchsupport/profile/institutional-review-board-irb/ Although the examples for these agreements are complex, in practice many data centers already have DUAs and IRB approvals for environments like Operate First. Michael Daitzman is working to get DUA and (if necessary) IRB approval in advance of prodcution deployment for Operate First data. Requirement: Operate First data will not be transferred into or out of the Operate First environment until we have an approved DUA and (if necessary) IRB approval from BU.
hpdempsey commented 3 years ago

Asked Michael Daitzman to review requirements.

msdisme commented 3 years ago

Looks good. I'll use it as a basis for discussions with legal, etc. who may have some stuff to add in.

durandom commented 3 years ago

Thanks, those requirements are pretty extensive :) If one of those influences a design decision, we should pull them into the ADR.

Can we start with the SSO ADR? https://github.com/operate-first/blueprint/pull/74

@tumido made a point to aggregate SSO from multiple sources

billburnseh commented 3 years ago

Great info. So the AUP would negate the need for a EULA, but perhaps may need some language to cover the data and it's licensing.... (not a lawyer).

hpdempsey commented 3 years ago

Yes, nice summary @billburnseh

billburnseh commented 3 years ago

Based on your excellent explanations....credit where credit is due! Thanks!

tumido commented 3 years ago

Thank you @hpdempsey ! :+1:

I think we need to consider "mingling" and interaction of 2 kinds of users - those who have access to research institutions and can login via academic SSOs and those who can't - independent users, RH/IBM/other engineers, users accessing a demo or attending a workshop, which requires them to interact with the platform (e.g. ODH demos for deploying various components etc.).

Both these types of users want to access our platform. While the first can login via academic SSO, the later one can login via email or possibly github only (Those are the only credentials we can use to identify them and are least intrusive.) For these users we still have the need for an EULA in some form.

Mind that those non-academic users are also interested in taking data in/out of the platform.

Additionally to that Operate First will soon operate clusters outside of MOC, which doesn't have this DUAs and IRBs that are enforced MOC. I'm not sure how we want to implement that, since we would like to have unified experience for all of the users, while it doesn't make any sense for a user accessing non-MOC cluster to have to comply with MOC policies directly (like being presented with MOC AUP).

While I understand the need for privacy policy and EULAs and what not, I'm not versed in this topic at all. So feel free to tell me if I'm totally missing the point now. :slightly_smiling_face:

tumido commented 3 years ago

Aand I've just read the Data license choice for Operate First email thread. Some of my concerns are already voiced there or explained. Just don't mind me :smile:

hpdempsey commented 3 years ago

You're not missing anything (except maybe some sleep). I don't think we've clarified yet how many stand-alone environments we will have, and the extent to which we'll be mixing academic and non-academic users in each environment. There are ways to connect commercial or workshop users to an academic SSO systems by having a second compatible certificate authority. NCSA operates one that is compatible with InCommon, for example. But we probably won't want to go to that extra effort, so systems with mixed types of users will have to support both AUP with SSO and EULAs. It's also possible we separate the two environments, but I hope we don't. Also, the DUAs for an academic environment apply to any ops data, regardless of the type of user (academic or not) who the data is associated with.

Thanks for your comments.

On Wed, Apr 28, 2021 at 5:48 PM Tom Coufal @.***> wrote:

Aand I've just read the Data license choice for Operate First email thread. Some of my concerns are already voiced there or explained. Just don't mind me 😄

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/operate-first/blueprint/issues/79#issuecomment-828802142, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMGMIELZCURNFGWPGUDDRY3TLB7CNANCNFSM43TAHSUQ .

msdisme commented 3 years ago

I'd love to see the thread @tumido referenced above. Re. SSO and academic above - two of the major academic login options both route via cilogon.org which includes both google (many companies including redhat.com logins) and GitHub as oauth providers so that they support non-academic users. Not sure of the "rules of engagement" for them.

tumido commented 3 years ago

@msdisme forwarded :slightly_smiling_face:

durandom commented 3 years ago

2 examples for Acceptable Use Policy

https://www.osgconnect.net/aup https://www.chameleoncloud.org/terms/

sesheta commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

HumairAK commented 3 years ago

/remove-lifecycle stale

sesheta commented 2 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

sesheta commented 2 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

sesheta commented 2 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

sesheta commented 2 years ago

@sesheta: Closing this issue.

In response to [this](https://github.com/operate-first/blueprint/issues/79#issuecomment-1067070480): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.