kellyrowland / hpcsyspros19 Goto Github PK

I looked over the article and have the following feedback:

• I made a few edits in this PR: #5
• I find the following sentences to be awkward.
  • NERSC is not the first organization to implement multi-factor authentication (MFA) for its users, and we had seen multiple talks by other supercomputing facilities who had deployed MFA. The switch from present tense to the pluperfect feels awkward to me.
  • In addition, NERSC wanted to make it possible for users whose tokens were not immediately available to not be stuck and unable to work. The phrase not be stuck also feels awkward to me. I'm not sure how to re-word it, but I would try to remove the negatives, In addition, NERSC wanted to make it possible for users whose tokens were not immediately available to be able to work or something along those lines.
• Lastly, in Figure 2, the sshproxy architecture has a "revocation lists", which is a feature that doesn't exist.

Just to start off this was a great read. The topic is very much on point for our HPC community and honestly much of the IT community at large.

My reactions as I read this, as I'm from a site much smaller than NERSC and with far fewer resources, is that I'm unsure if we could approach this problem/need and create a freelance solution such as you all have done. To that end it would be great if there was some content/advice for those interested in looking down this general direction of where they might get started. Especially if they are smaller or emerging institution. The alternative may just be to look at a one of canned 3rd party solutions, but your solution's openness has some distinct appeal.

Let me jump to the latter part of 4.1.3 where you talk about the 'fail-open' setup. I wonder if you could include any info here about reactions of users when you have had to leverage this due to a planned or unplanned outage. Do you have users get surprised/spooked when MFA is not requested/needed? As part of your social aspects of the paper I'm wondering this.

Then maybe for section 4.3... Earlier you noted that your move to MFA was not mandated. Did you have significant resistance to the change? Where there any lessons learned that could be shared on how you presented MFA to users that were more successful in them getting on board with the change/direction?

---

This is a great paper, perfectly suited for the workshop. Only thing I'd recommend is an acknowledgement of the ssh controlmaster functionality, and how sshproxy improves on workflows otherwise enabled by it.

---

Was it an options to simply have MFA implemented at the gate? In a setup where users must access cluster resources through\over a VPN connection doing the multi-factor at the initial login seems simple. Was that a consideration since you had the flexibility to implement base on in-house requirements.

Sharing some of the information about how users were notified and including the actual memos, emails and articles that went out describing the change would be useful as supplements.

What types of automation were impacted by the MFA implementation and did it call for major re-tooling of scripts and code to integrate MFA?

Also the 100 users that needed "Hand holding" or personal help what types of help need was the most common?

---

I have no suggestions to make this paper stronger. In the second round of reviews, I'd put this work in the strongly accept category.

One thing I tried to find is where to review OTPproxy and sshproxy. I hope it was just my inability to Google harder and not that they aren't available for other HPC sites.

This is a great read and topic for the HPC community.

The one area I'm left asking myself after reading this is, could another site attempt to do something like this? This is where I'm not as clear on from the paper. Is the paper trying to demonstrate an approach that others should/could follow on, or is the nature of the implementation too custom to the characteristics of NERSC or maybe too advanced for some sites to attempt to roll their own? So what I'm left here is wishing there was a more clear message at the start or at the end of the paper that would indicate your opinion on where the papers intent is. This seems key as we, those reviewing the papers, are being asked to consider how easy the methods in the paper would be to replicate by others in the HPC community.

---

This is a great submission for the workshop.

---

The table on page six is ok but appears a bit pix-elated and jagged. It may not display nicely on some screens. It would be nice to clean or tighten it up or use a vector as opposed to bitmap image.

---

The inclusion of additional diagrams and sample user communications are great inclusions to the paper. The lessons learned will serve the community well as a roadmap on how to add MFA to infrastructures.