Skip to content

Latest commit

 

History

History
231 lines (206 loc) · 8.73 KB

Onboarding.md

File metadata and controls

231 lines (206 loc) · 8.73 KB
Raw

Table of contents

General access to study data

See this Slack message pointing to a Google Drive folder, maintained by Robin, that describes access to Metabase, REDCap, etc.

Adding new database users

Minting credentials

Before adding a new study member to the production database, confirm that Robin has the right agreements and documentation for the user to allow database access. For external collaborators, this is a DTUA. For internal team members, this is a CDA and training documentation (GCP, Human Subjects).

Next, create a new user with the id3c user create command.

Once you've created new database credentials with the appropriate grants, send them in an encrypted email to the new study member. One way to do this is to add the word "secure" (unquoted) in the subject. You may choose to follow the template below:

secure Seattle Flu Study database credentials

I just created an account for your use only to directly access our production database (ID3C).

Your username is $USERNAME. Your access token/password is: $PASSWORD Please keep these confidential and secure.

There are many ways to connect, but you can use the command-line PostgreSQL client psql to test like this:

psql --host production.db.seattleflu.org production $USERNAME

This will prompt you for your token/password. If you're connecting frequently, you can also setup a password file that PostgreSQL can use to remember your password (https://www.postgresql.org/docs/10/libpq-pgpass.html).

Please remember the data usage policies associated with accessing the database, as outlined in the DTUA you signed. If you have any questions, the @dev-team can help answer them on the #id3c or #informatics channels in the Seattle Flu Study Slack.

Accessing the production database

The production database has firewall rules that allow only access to certain IP addresses or IP ranges. The list of allowed IP addresses is described elsewhere. Generally speaking, you'll need to be connected to your institution's network (either on campus or via a VPN) to get access to the database. The UW Medicine and Fred Hutch VPNs are allowed.

UW Medicine VPN (Preferred)

To use the UW Medicine VPN, you'll need to create an AMC account. AMC (Academic Medical Center) accounts are used inside UW Medicine to connect to various UW Med resources, including the UW Medicine VPN. Here is the info about getting an AMC account. Your manager/supervisor/department authority should complete the form for you. Don't submit it for yourself.

Once you get your AMC account, go to this link to get instructions for installing the VPN client. (You need an AMC account to access this page.)

Adding your home IP address

Sometimes, we'll add someone's home IP address to our firewall's allowlist. This is currenlty only used for legacy exceptions or rare circumstances where VPN access could not be maintained. Newly onboarding users should first attempt to gain access through one of the institution's VPNs. To retrieve your public IPv4 address, once connected to your home internet, go to https://www.whatismyip.com/.

Adding new REDCap users

Before adding a new study member to any REDCap project, confirm the DTUA is executed with Robin. Then, use this script to programmatically import a user to all REDCap with permissions equivalent to an existing REDCap user.

Providing Switchboard access

Add users in the form of netid@washington.edu to the authorized-users file. For Switchboard, you'll typically be adding new users to the bat-lab group. Then, sudo git pull your new commit into /etc/apache2 on backoffice.

Note: You'll need to forward your authentication agent by logging onto the backoffice server with ssh -A.

You may need to run sudo systemctl reload apache2 for apache2 to notice the updated authz users file.

Providing Lead Dawgs access

The steps for providing Lead Dawgs access are similar to those for providing Switchboard access. For Lead Dawgs, you'll typically be adding users to the uw-kiosk-team user group.

Providing Fred Hutch S3 access

Providing study members with access to the Fred Hutch-managed AWS S3 bucket requires sending an email to Fred Hutch Sci Comp (scicomp@fhcrc.org) like the one below:

External collaboration for Economy Cloud storage

Hi Sci Comp,

Could you grant an external collaborator of ours access to the Bedford lab's Economy Cloud S3 bucket (fh-pi-bedford-t)?

{Affiliation} — {Name} <{Email}>

I'd like to restrict access to specific read/write operations scoped to specific object prefixes. Attached is the respective IAM policy document for {Affiliation}.

Note: if you're granting permissions to a non-Fred Hutch, SFS software developer, consider modifying the above language to something like:

I'd like to grant them read/write access to all files within the fh-pi-bedford-t/seattleflu object prefix.

When sending an email, be sure to CC the Bedford Lab dev team as well as the study member requesting access. See the next section for example IAM policies to attach to the email.

Example IAM policies

UW / BBI lab members

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::fh-pi-bedford-t",
      "Condition": {
        "StringLike": {
          "s3:prefix": "seattleflu/*"
        }
      }
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::fh-pi-bedford-t/seattleflu/bbi/*"
    }
  ]
}

UW / BBI software developers

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::fh-pi-bedford-t",
      "Condition": {
        "StringLike": {
          "s3:prefix": "seattleflu/*"
        }
      }
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::fh-pi-bedford-t/seattleflu/*"
    }
  ]
}

SCH

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::fh-pi-bedford-t",
      "Condition": {
        "StringLike": {
          "s3:prefix": "seattleflu/*"
        }
      }
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::fh-pi-bedford-t/seattleflu/sch/*"
    }
  ]
}

Swedish

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::fh-pi-bedford-t",
      "Condition": {
        "StringLike": {
          "s3:prefix": "seattleflu/*"
        }
      }
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::fh-pi-bedford-t/seattleflu/swedish/*"
    }
  ]
}