Permissions for data access using Amazon S3 URIs

You can access sequence store data using HealthOmics API operations or Amazon S3 API operations.

For HealthOmics API access, HealthOmics permissions are managed through an IAM policy. However, S3 Access requires two levels of configuration: explicit allow in the Store’s S3 Access Policy and an IAM policy. To learn more about using IAM policies with HealthOmics, see Service roles for HealthOmics.

There are three ways to share the capability of reading objects using the Amazon S3 APIs:

Policy based sharing

When you create a sequence store, HealthOmics creates a default S3 access policy granting the data store owner’s root account the following permissions for all accessible objects in the sequence store: S3:GetObject, S3GetObjectTagging, and S3:ListBucket. The default created policy is:

{
    "Version": "2012-10-17",
    "Statement":
    [
        {
            "Effect": "Allow",
            "Principal":
            {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action":
            [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*"
        },
        {
            "Effect": "Allow",
            "Principal":
            {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/111111111111/sequenceStore/1234567890/*"
        }
    ]
}   

If the S3 access policy is blank, no S3 access is allowed. If there is an existing policy and you need to remove s3 access, use deleteS3AccessPolicy to remove all access.

If a customer wants to add restrictions on the sharing or grant access to other accounts, you can update the policy using the PutS3AccessPolicy API. Updates to the policy can't go beyond the prefix for the sequence store or the actions specified.

To allow a user or IAM principal access using Amazon S3 APIs, in addition to permission in the S3 access policy, an IAM policy needs to be created and attached to the principal to grant access. A policy allowing Amazon S3 API access can be applied at the sequence store level or at a read set level. At the read set level, permission can be restricted either through the prefix or using resource tag filters for sample or subject ID patterns.

If the sequence store uses a customer managed key (CMK), the principal must also have rights to use the KMS key for decryption. For more information, see Cross-account KMS access in the AWS Key Management Service Developer Guide.

The following example gives a user access to a sequence store. You can fine-tune the access with additional conditions or resource-based filters.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3DirectAccess",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket",
                "s3:GetObjectTagging"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointArn": "arn:aws:s3:us-west-2:555555555555:accesspoint/592761533288-4891675750"
                }
            }
        }
    ]
}   

To use tag based access control, the sequence store must first be updated to propagate the tag keys that will be used. This configuration is set during sequence store creation or updating. Once the tags are propagated, tag conditions can be used to further add restrictions. The restrictions can be placed in the S3 Access policy or on the IAM policy. The following is an example of a tab based S3 access policy that would be set:

{
    "Sid": "tagRestrictedGets",
    "Effect": "Allow",
    "Principal":
    {
        "AWS": "arn:aws:iam::<target_restricted_account_id>:root"
    },
    "Action":
    [
        "s3:GetObject",
        "s3:GetObjectTagging"
    ],
    "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
    "Condition":
    {
        "StringEquals":
        {
            "s3:ExistingObjectTag/tagKey1": "tagValue1",
            "s3:ExistingObjectTag/tagKey2": "tagValue2"
        }
    }
}   

Example Restriction

Scenario: Creating a share where the data owner can restrict a user’s ability to download “withdrawn” data.

In this scenario, a data owner (account #111111111111) managed a data store. This data owner shares the data with a broad range of third party users, including a researcher (account #999999999999). As part of managing the data, the data owner periodically get requests to withdraw a participants data. To manage this withdrawal, the data owner first restricts direct download access on receiving the request and eventually deletes the data per their requirements.

To meet this need, the data owner sets up a sequence store and each read set receives a tag for “status” that will be set to “withdrawn” if the withdrawal request comes through. For data with the tag set to this value, they want to make sure no user can run “getObject” on this file. To do this setup, the data owner will need to ensure two steps are taken.

Step 1. For the sequence store, ensure that the status tag is updated to be propogated. This is done by adding the “status” key into the propogatedSetLevelTags when calling createSequenceStore or updateSequenceStore.

Step 2. Update the store’s s3 Access Policy to restrict getObject on objects with the status tag set to withdrawn. This is done by updating the stores access policy using the PutS3AccesPolicy API. The following policy would allow customers to still see the withdrawn files when listing objects but prevent them from accessing them:

{
    "Version": "2012-10-17",
    "Statement":
    [
        {
            "Sid": "restrictedGetWithdrawal",
            "Effect": "Allow",
            "Principal":
            {
                "AWS": "arn:aws:iam::999999999999:root"
            },
            "Action":
            [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
            "Condition":
            {
                "StringNotEquals":
                {
                    "s3:ExistingObjectTag/status": "withdrawn"
                }
            }
        },
        {
            "Sid": "ownerGetAll",
            "Effect": "Allow",
            "Principal":
            {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action":
            [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*",
            "Condition":
            {
                "StringEquals":
                {
                    "s3:ExistingObjectTag/omics:readSetStatus": "ACTIVE"
                }
            }
        },
        {
            "Sid": "everyoneListAll",
            "Effect": "Allow",
            "Principal":
            {
                "AWS": [
                    "arn:aws:iam::111111111111:root",
                    "arn:aws:iam::999999999999:root",
                ]
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890",
            "Condition":
            {
                "StringLike":
                {
                    "s3:prefix": "111111111111/sequenceStore/1234567890/*"
                }
            }
        }
    ]
}