Periodic lack of responses on approval requests for GPU accounts

[tatarsky]

The process to validate a requested account is slow. We can often turn around the accounts for a user in seconds, but we were asked to confirm an account being valid first with the PI. Often this takes awhile for some groups. I suspect the PI is busy or doesn't know what we are asking. CSLAB in this case. The recent request for a Patricia Wong has been an example.

What would you like us to do?

I am happy to follow a process but a two day wait the user in question is going to think we are ignoring them. Obviously, if they aren't a valid user, thats fine. But I doubt anyone is trying to sneak onto the cluster and also giving us their email and phone number.

[ratsch]

Thanks for pointing this out. I suggest that you respond that you are waiting for an authorization response by one or more people (list from who). Then the user knows and can act to "activate" the authorizing person. In addition it would be useful that all groups have a second (possibly third) person who can authorize accounts for users. That will generally speed up this process.

Cheers, Gunnar

Sent from my phone

On Jun 12, 2014, at 8:05, tatarsky notifications@github.com wrote:

The process to validate a requested account is slow. We can often turn around the accounts for a user in seconds, but we were asked to confirm an account being valid first with the PI. Often this takes awhile for some groups. I suspect the PI is busy or doesn't know what we are asking. CSLAB in this case. The recent request for a Patricia Wong has been an example.

What would you like us to do?

I am happy to follow a process but a two day wait the user in question is going to think we are ignoring them. Obviously, if they aren't a valid user, thats fine. But I doubt anyone is trying to sneak onto the cluster and also giving us their email and phone number.

— Reply to this email directly or view it on GitHub.

[tatarsky]

We did on the waiting item. I will contact the user. If you have suggestions for second and third users for CSLAB let me know. Note from a security point of view, asking the person you are trying to authorize to initiate their own authorization isn't good if I still don't know the person granting it. She lists a person as a PI that doesn't match my knowledge of that groups PIs. I'll detail that in an email rather than putting it here.

[jchodera]

Thanks for bringing this to our attention, @tatarsky, and agree we should work to refine this process.

I like Gunnar's idea of

1. Having multiple people in each xxlab group that can approve the account
2. Communicating to the user a form letter that we are waiting for authorization of the account, and listing the people who could be contacted to facilitate this.

If it would be easiest, we can add another page to the user account spreadsheet with information on people who could provide approval for each xxlab group.

But I doubt anyone is trying to sneak onto the cluster and also giving us their email and phone number.

Not necessarily true. I've had some very weird phishing attacks recently that I still don't quite understand. Because much of the info for the cluster is public, and because of the potential ramifications from unauthorized access, I do think we have to be a bit careful here.

[jchodera]

Note from a security point of view, asking the person you are trying to authorize to initiate their own authorization isn't good if I still don't know the person granting it. She lists a person as a PI that doesn't match my knowledge of that groups PIs. I'll detail that in an email rather than putting it here.

James Hsieh is a PI at MSKCC in a another department. This is fine.

The authorization would have to come from one of the valid account approvers in the sponsoring group. So someone trusted by Chris Sander would still need to approve her account, but she could at least bug them so you don't have to.

[jchodera]

Chris will have to designate additional approvers in CSLAB, but we can try to get Kadeem to collect this information.

Note that Chris is the department chair, so a swift email response is not to be expected. Having multiple approvers designated from each group will help speed the turnaround.

[tatarsky]

I think CSLAB just having a secondary source of approval solves this problem. I like the idea of the approving capable emails per lab tossed as a second sheet of the form spreadsheet. I'm just trying to follow account making reasonable policy given your class of data. Should I activate the account for Patricia? Or hold for that list of people....

[jchodera]

I haven't yet found evidence of employment of a "Patricia Wang" in the Hsiesh lab at MSKCC, so please wait for official approval from Chris or his designees.

[jchodera]

And your efforts to make the policies workable are very much appreciated!

[tatarsky]

Well, she lists being on the "7th floor", so if there isn't a 7th floor let me know ;) There is a phone number in the spreadsheet. Portland area code but that is likely a cell. Holding on request until confirmed.

[ratsch]

In this case I would indeed wait for approval from Chris et al. (We can’t know all the other PIs collaborators.)

Cheers, Gunnar

On Jun 12, 2014, at 8:51 AM, tatarsky notifications@github.com wrote:

Well, she lists being on the "7th floor", so if there isn't a 7th floor let me know ;) There is a phone number in the spreadsheet. Portland area code but that is likely a cell. Holding on request until confirmed.

— Reply to this email directly or view it on GitHub.

[jchodera]

Maybe we should add an optional "MSKCC employee ID" field for folks who work at MSK? That might help speed this process for those who we can easily verify.

[ratsch]

I consider that id somewhat security sensitive as its used to authenticate against other systems. Since this information will be stored in the cloud, I’d suggest not to collect this information this way.

Gunnar

On Jun 12, 2014, at 8:54 AM, John Chodera notifications@github.com wrote:

Maybe we should add an optional "MSKCC employee ID" field for folks who work at MSK? That might help speed this process for those who we can easily verify.

— Reply to this email directly or view it on GitHub.

[jchodera]

I consider that id somewhat security sensitive as its used to authenticate against other systems. Since this information will be stored in the cloud, I’d suggest not to collect this information this way.

The spreadsheet that would collect this ID isn't public, so unless you expect Google employees to be hacking us via social engineering, I'm not sure that's a big concern. It could be, however, that the employee ID is simply too public and a name and ID could simply be lifted from some other place on the web, so it could be insecure because of that.

[jchodera]

I'm going to mark this as resolved by our change in protocol of having secondary approvers for each group. We'll make sure to complete that list at the HPC Committee Meeting on Wednesday morning.