Please post feedback and replies to this comment.
The Jira activity plan seems to include a bunch of documentation deliverables (maybe copied in from the defaults?) that I'm not sure are really needed for this. The reason I say that is because it also says the change should be transparent to users and shouldn't require any documentation changes. If that's the case, and it isn't an XSEDE project, it probably doesn't need the engineering docs, either? Unless they contain details about how CILogon on hosted that need to be updated?
I'm available to pass along any info to the Globus team regarding the CILogon change. Will the Globus team need to change anything in Globus's configuration as a result of this rehosting? Will there be any noticable downtime?
Hi Lee. Thanks for the review.
I'm confused by your comment about the documentation deliverables. We need an updated design doc as input to the design review. We need a test plan (maybe unchanged from the last CILogon update, I'm not sure yet...) as input to test readiness review, and we need an updated deployment plan prior to acceptance of this change by operations. There are no user docs in the list of deliverables.
The change will likely include downtime, for the migration of the CILogon user database to Amazon RDS. Globus will not need to change any configuration, though it would be helpful if Globus could migrate to CILogon's OAuth2/OIDC endpoint so we can retire CILogon's old OAuth1 endpoint prior to our migration to AWS. I'd also appreciate input from Globus during the design review regarding requirements for high availability, since moving CILogon servers from NCSA/NICS to AWS will change the availability profile for this service.
(1) Will this migration require updates to the CPSs and an operational review by TAGPMA for accredited CILogon CAs?
(2) Will the AWS security controls, service configurations and settings be documented and made available for review?
(1) Yes, the CILogon team will do that.
(2) Yes, I'll put that in the XCI-783 design doc for the review. I think it will be really valuable to get input on it.
Please add mention of AWS Security Controls to be applied and documented into the design doc - if you've done that already, please point me to the current edition of the design document.
Thanks - Derek
Hi Derek. Thanks for reviewing the design doc. I guess I misunderstood what you're looking for. I think I documented security controls (network ingress/egress controls using ELB, VPC, and NAT Gateway; MFA for administrative access; offsite security log analysis using Splunk) and service configurations (Docker containers deployed across EC2 instances in 3 availability zones; using Amazon Container Registry; configurations managed by Ansible in private GitHub repos). Are there additional security/configuration questions/topics you'd like me to address in the design doc?
What I'd like to see as a product of the effort is a document detailing the policies and controls that are implemented in AWS to protect the setup. How are the services hosted in AWS being monitored for vulnerabilities and security updates?
Ah yes, I'll update the design doc to document the Qualys vulnerability scanning and Docker Image Update Notifier (DIUN) that we use to monitor for vulnerabilities and security updates. Thanks!
I've updated https://software.xsede.org/svn/xci/activities/xci-783/trunk/Deliverables... (v1.1) to include the additional documentation in Section E.2.8.
© ACCESS All Rights Reserved.
ACCESS is an advanced computing and data resource supported by the
National Science Foundation
and made possible through these lead institutions and their partners –
Carnegie Mellon University
University of Colorado Boulder
University of Illinois at Urbana-Champaign
State University of New York at Buffalo