mikebaumann
commented
5 years ago For the MVP, the plan for allowing Terra/FireCloud access to the HCA Google data has changed from using a minimal HCA Bond provider to instead simply adding the Google Group GROUP_All_Users@firecloud.org will be added to the HCA Google checkout bucket ACL with the Storage Object Viewer role. Consequently, the changes described in this issue are no longer needed.
The following document has been updated to reflect this change: Terra/Cromwell Access to Files Identified by DRS URIs for the HCA/Terra MVP
For the HCA handoff to Terra MVP, Bond will return the same Google Service Account key for all users. This service account will be added to the HCA DSS Google checkout bucket ACLs. My understanding from a discussion with Albano and Alex, is that for security reasons, the Broad should create this service account and provide the service account name/email to HCA to add the checkout bucket ACLs. This is, I believe, the same pattern being used by the Broad Mint team to access HCA data for analysis purposes. Ideally, the name of the service account should identify that it is associated with Terra/FireCloud.
Examples of existing Broad service accounts already being added to the HCA DSS Google checkout buckets are:
A potential name for this service account may be something like:
There is an open question regarding whether to use a single service account for access to all HCA DSS deployment tiers (dev, integration, staging, prod) or if we should use a different service account for different tiers. Using a single service account for all the tiers seems simpler and would facilitate pre-production end-to-end system integration testing, yet there may be security-related reasons for having multiple service accounts(?) Broad/HCA devsec and compliance guidance should be sought here.
For more information, please see: Terra/Cromwell Access to Files Identified by DRS URIs for the HCA/Terra MVP
┆Issue is synchronized with this Jira Story ┆Project Name: azul ┆Issue Number: AZUL-672