# IAM permissions for HealthOmics
You can use AWS Identity and Access Management (IAM) to manage access to the HealthOmics API and resources such as stores and workflows. For users and applications in your account that use HealthOmics, you manage permissions in a permissions policy that you can apply to IAM users, groups, or roles.
To manage permissions for users and applications in your accounts, [use the policies that HealthOmics provides](permissions-user.md), or write your own. The HealthOmics console uses multiple services to get information about your function's configuration and triggers. You can use the provided policies as-is, or as a starting point for more restrictive policies.
HealthOmics uses IAM [service roles](permissions-service.md) to access other services on your behalf. For example, you would create or choose a service role when you run a workflow that reads data from Amazon S3. For some features, you also need to [configure permissions on resources in other services](permissions-resource.md). Review these requirements before you start working with HealthOmics
For more information about IAM, see [What is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide*.
**Topics**
+ [Identity-based IAM policies for HealthOmics](permissions-user.md)
+ [Service roles for AWS HealthOmics](permissions-service.md)
+ [Amazon ECR permissions](permissions-ecr.md)
+ [HealthOmics Resource permissions](permissions-resource.md)
+ [Permissions for data access using Amazon S3 URIs](s3-sharing.md)
# Identity-based IAM policies for HealthOmics
To grant users in your account access to HealthOmics, you use identity-based policies in AWS Identity and Access Management (IAM). Identity-based policies can apply directly to IAM users, or to IAM groups and roles that are associated with a user. You can also grant users in another account permission to assume a role in your account and access your HealthOmics resources.
To grant permission for users to perform actions on a workflow version, you must add the workflow and the specific workflow version to the resource list.
The following IAM policy allows a user to access all HealthOmics API actions, and to pass [service roles](permissions-service.md) to HealthOmics.
**Example User policy**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "omics.amazonaws.com"
}
}
}
]
}
```
When you use HealthOmics, you also interact with other AWS services. To access these services, use the managed policies provided by each service. To restrict access to a subset of resources, you can use the managed policies as a starting point to create your own more restrictive policies.
****
+ [AmazonS3FullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) – Access to Amazon S3 buckets and objects used by jobs.
+ [AmazonEC2ContainerRegistryFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess) – Access to Amazon ECR registries and repositories for workflow container images.
+ [AWSLakeFormationDataAdmin](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) – Access to Lake Formation databases and tables created by analytics stores.
+ [ResourceGroupsandTagEditorFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ResourceGroupsandTagEditorFullAccess) – Tag HealthOmics resources with HealthOmics tagging API operations.
The preceding policies don't allow a user to create IAM roles. For a user with these permissions to run a job, an administrator must create the service role that grants HealthOmics permission to access data sources. For more information, see [Service roles for AWS HealthOmics](permissions-service.md).
## Define custom IAM permissions for runs
You can include any workflow, run, or run group referenced by the `StartRun` request in an authorization request. To do so, list the desired combination of workflows, runs, or run groups in the IAM policy. For example, you can limit the use of a workflow to a specific run or run group. You can also specify that a workflow only be used with a run group.
The following is an example IAM policy that allows a single workflow with a single run group.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:StartRun"
],
"Resource": [
"arn:aws:omics:us-west-2:123456789012:workflow/1234567",
"arn:aws:omics:us-west-2:123456789012:runGroup/2345678"
]
},
{
"Effect": "Allow",
"Action": [
"omics:StartRun"
],
"Resource": [
"arn:aws:omics:us-west-2:123456789012:run/*",
"arn:aws:omics:us-west-2:123456789012:runGroup/2345678"
]
},
{
"Effect": "Allow",
"Action": [
"omics:GetRun",
"omics:ListRunTasks",
"omics:GetRunTask",
"omics:CancelRun",
"omics:DeleteRun"
],
"Resource": [
"arn:aws:omics:us-west-2:123456789012:run/*"
]
}
]
}
```
------
# Service roles for AWS HealthOmics
A service role is an AWS Identity and Access Management (IAM) role that grants permissions for an AWS service to access resources in your account. You provide a service role to AWS HealthOmics when you start an import job or start a run.
The HealthOmics console can create the required role for you. If you use the HealthOmics API to manage resources, create the service role using the IAM console. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html).
Service roles must have the following trust policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
The trust policy allows the HealthOmics service to assume the role.
**Topics**
+ [Example IAM service policies](#permissions-service-samplepolicies)
+ [Example CloudFormation template](#permissions-service-sampletemplates)
## Example IAM service policies
In these examples, resource names and account IDs are placeholders for you to replace with actual values.
The following example shows the policy for a service role that you can use for starting a run. The policy grants permissions to access the Amazon S3 output location, the workflow log group, and the Amazon ECR container for the run.
**Note**
If you're using call caching for the run, add the run cache Amazon S3 location as a resource in the s3 permissions.
**Example Service role policy for starting a run**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1"
]
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogStreams",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-east-1:123456789012:log-group:/aws/omics/WorkflowLog:log-stream:*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup"
],
"Resource": [
"arn:aws:logs:us-east-1:123456789012:log-group:/aws/omics/WorkflowLog:*"
]
},
{
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability"
],
"Resource": [
"arn:aws:ecr:us-east-1:123456789012:repository/*"
]
}
]
}
```
The following example shows the policy for a service role that you can use for a store import job. The policy grants permissions to access the Amazon S3 input location .
**Example Service role for Reference store job**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
## Example CloudFormation template
The following sample CloudFormation template creates a service role that gives HealthOmics permission to access Amazon S3 buckets that have names prefixed with `omics-`, and to upload workflow logs.
**Example Reference store, Amazon S3 and CloudWatch Logs permissions**
```
Parameters:
bucketName:
Description: Bucket name
Type: String
Resources:
serviceRole:
Type: AWS::IAM::Role
Properties:
Policies:
- PolicyName: read-reference
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- omics:*
Resource: !Sub arn:${AWS::Partition}:omics:${AWS::Region}:${AWS::AccountId}:referenceStore/*
- PolicyName: read-s3
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- s3:ListBucket
Resource: !Sub arn:${AWS::Partition}:s3:::${bucketName}
- Effect: Allow
Action:
- s3:GetObject
- s3:PutObject
Resource: !Sub arn:${AWS::Partition}:s3:::${bucketName}/*
- PolicyName: upload-logs
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- logs:DescribeLogStreams
- logs:CreateLogStream
- logs:PutLogEvents
Resource: !Sub arn:${AWS::Partition}:logs:${AWS::Region}:${AWS::AccountId}:loggroup:/aws/omics/WorkflowLog:log-stream:*
- Effect: Allow
Action:
- logs:CreateLogGroup
Resource: !Sub arn:${AWS::Partition}:logs:${AWS::Region}:${AWS::AccountId}:loggroup:/aws/omics/WorkflowLog:*
AssumeRolePolicyDocument: |
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Effect": "Allow",
"Principal": {
"Service": [
"omics.amazonaws.com"
]
}
}
]
}
```
# Amazon ECR permissions
Before the HealthOmics service can run a workflow in a container from your private Amazon ECR repository, you create a resource policy for the repository. The policy grants permission for the HealthOmics service to use the container. You add this resource policy to each private repository referenced by the workflow.
**Note**
The private repository and the workflow must be in the same region.
If different AWS accounts own the workflow and the repository, you need to configure cross-account permissions.
You don't need to grant additional repository access for shared workflows. However, you can create policies that allow or deny specific workflows access to the container image.
To use the Amazon ECR pull through cache feature, you need to create a registry permission policy.
The following sections describe how to configure Amazon ECR resource permissions for these scenarios. For more information about permissions in Amazon ECR, see [ Private registry permissions in Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-permissions.html).
**Topics**
+ [Create a resource policy for the Amazon ECR repository](#permissions-resource-policy)
+ [Running workflows with cross-account containers](#permissions-cross-account-containers)
+ [Amazon ECR policies for shared workflows](#permissions-shared-workflows)
+ [Policies for Amazon ECR pull through cache](#permissions-ecr-ptc)
## Create a resource policy for the Amazon ECR repository
Create a resource policy to allow the HealthOmics service to run a workflow using a container in the repository. The policy grants permission for the HealthOmics service principal to access the required Amazon ECR actions.
Follow these steps to create the policy:
1. Open the [private repositories](https://console.aws.amazon.com/ecr/private-registry/repositories) page in the Amazon ECR console and select the repository you're granting access to.
1. From the side bar navigation, select **Permissions**.
1. Choose **Edit**.
1. Choose **Edit policy JSON**.
1. Add the following policy statement and then select **Save**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "omics workflow access",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*"
}
]
}
```
------
## Running workflows with cross-account containers
If different AWS accounts own the workflow and the container, you need to configure the following cross-account permissions:
1. Update the Amazon ECR policy for the repository to explicitly grant permission to the account that owns the workflow.
1. Update the service role for the account that owns the workflow to grant it access to the container image.
The following example demonstrates an Amazon ECR resource policy that grants access to the account that owns the workflow.
In this example:
+ Workflow account ID: 111122223333
+ Container repository account ID: 444455556666
+ Container name: samtools
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
},
{
"Sid": "AllowAccessToTheServiceRoleOfTheAccountThatOwnsTheWorkflow",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/DemoCustomer"
},
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
To complete the setup, add the following policy statement to the service role of the account that owns the workflow. The policy grants permission for the service role to access the “samtools” container image. Make sure to replace the account numbers, container name, and region with your own values.
```
{
"Sid": "CrossAccountEcrRepoPolicy",
"Effect": "Allow",
"Action": ["ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer"],
"Resource": "arn:aws:ecr:us-west-2:444455556666:repository/samtools"
}
```
## Amazon ECR policies for shared workflows
**Note**
HealthOmics automatically allows a shared workflow to access the Amazon ECR repository in the workflow owner's account, while the workflow is running in the subscriber's account. You don't need to grant additional repository access for shared workflows. For more information see [Sharing HealthOmics workflows](https://docs.aws.amazon.com/omics/latest/dev/sharing-workflows.html).
By default, subscriber don’t have access to the Amazon ECR repository to use the underlying containers. Optionally, you can customize access to the Amazon ECR repository by adding condition keys to the repository's resource policy. The following sections provide example policies.
### Restrict access to specific workflows
You can list individual workflows in a condition statement, so only these workflow can use containers in the repository. The **SourceArn** condition key specifies the ARN of the shared workflow. The following example grants permission for the specified workflow to use this repository.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OmicsAccessPrincipal",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:omics:us-east-1:111122223333:workflow/1234567"
}
}
}
]
}
```
------
### Restrict access to specific accounts
You can list subscriber accounts in a condition statement, so that only these accounts have permission to use containers in the repository. The **SourceAccount** condition key specifies the AWS account of the subscriber. The following example grants permission for the specified account to use this repository.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OmicsAccessPrincipal",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
You can also deny Amazon ECR permissions to specific subscribers, as shown in the following example policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OmicsAccessPrincipal",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
## Policies for Amazon ECR pull through cache
To use Amazon ECR pull through cache, you create a registry permission policy. You also create a repository creation template, which defines the permissions for the repositories created by Amazon ECR pull through cache.
The following sections include examples of these policies. For more information about pull through cache, see [ Sync an upstream registry with an Amazon ECR private registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-private.html) in the *Amazon Elastic Container Registry User Guide*.
### Registry permission policy
To use Amazon ECR pull through cache, create a registry permission policy. The registry permissions policy provides control over replication and pull through cache permissions.
For cross-account replication, you must explictly allow each AWS account that can replicate its repositories to your registry.
By default, when you create a pull through cache rule, any IAM principal that has permission to pull images from a private registry can also use the pull through cache rule. You can use registry permissions to further scope down these permissions to specific repositories.
Add a registry permission policy to the account that owns the container image.
In the following example, the policy allows the HealthOmics service to create repositories for each upstream registry and to initiate upstream pull requests from the created repositories.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPTCinRegPermissions",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:CreateRepository",
"ecr:BatchImportUpstreamImage"
],
"Resource": [
"arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/*",
"arn:aws:ecr:us-east-1:123456789012:repository/docker-hub/*"
]
}
]
}
```
------
### Repository creation template
To use pull through cache in HealthOmics, the Amazon ECR repository must have a repository creation template. The template defines configuration settings for the private repositories created for an upstream registry.
Each template contains a repository namespace prefix, which Amazon ECR uses to match new repositories to a specific template. Templates can specify the configuration for all repository settings including resource-based access policies, tag immutability, encryption, and lifecycle policies. For more information, see [Repository creation templates](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) in the *Amazon Elastic Container Registry User Guide*.
In the following example, the policy allows the HealthOmics service to initiate upstream pull requests from the upstream repositories.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
### Policies for cross-account Amazon ECR access
For cross-account access, the owner of the private repository updates the registry permission policy and the repository creation template to allow access for the other account and that account's run role.
In the registry permission policy, add a policy statement to allow the other account's run role to access the Amazon ECR actions:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountPTCinRegPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/RUN_ROLE"},
"Action": [
"ecr:CreateRepository",
"ecr:BatchGetImage",
"ecr:BatchImportUpstreamImage"
],
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/path/*"
}
]
}
```
------
In the repository creation template, add a policy statement to allow the other account's run role to access the new container images. Optionally, you can add condition statements to limit access to specific workflows:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountPTCinRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/RUN_ROLE"},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:omics:us-east-1:444455556666:workflow/WORKFLOW_ID",
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
Add permissions for two additional actions (CreateRepository and BatchImportUpstreamImage) in the run role and specify the resource that the run role can access.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CrossAccountPTCRunRolePolicy",
"Effect": "Allow",
"Action": [
"ecr:CreateRepository",
"ecr:BatchImportUpstreamImage",
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:us-east-1:123456789012::repository/{path}/*"
}
]
}
```
------
# HealthOmics Resource permissions
AWS HealthOmics creates and accesses resources in other services on your behalf when you run a job or create a store. In some cases, you need to configure permissions in other services to access resources or to allow HealthOmics to access them.
For resource permissions related to Amazon ECR, see [Amazon ECR permissions](permissions-ecr.md).
## Lake Formation permissions
Before you use analytics features in HealthOmics, configure default database settings in Lake Formation.
**To configure resource permissions in Lake Formation**
1. Open the [Data catalog settings](https://console.aws.amazon.com/lakeformation/home#default-permission-settings) page in the Lake Formation console.
1. Uncheck the IAM access control requirements for databases and tables under **Default permissions for newly created databases and tables**.
1. Choose **Save**.
HealthOmics Analytics auto accepts data if your service policy has the correct RAM permissions, such as the following example.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"omics:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ram:AcceptResourceShareInvitation",
"ram:GetResourceShareInvitations"
],
"Resource": "*"
}
]
}
```
------
# 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](permissions-service.md).
There are three ways to share the capability of reading objects using the Amazon S3 APIs:
1. Policy based sharing – This sharing requires enabling the IAM principal both in the S3 Access policy and writing an IAM policy and attaching it to the IAM principal. See the next topic for more details.
1. Presigned URLs – You can also generate a shareable pre-signed URL for a file in the sequence store. To learn more about creating presigned URLs using Amazon S3, see [Using presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) in the Amazon S3 documentation. The sequence store S3 access policy supports statements for [limiting presigned URL capabilities](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html#PresignedUrlUploadObject-LimitCapabilities).
1. Assumed roles – Create a role within the data owner's account that has an access policy that allows users to assume that role.
**Topics**
+ [Policy based sharing](#policy-based-sharing)
+ [Example Restriction](#example-restriction)
## Policy based sharing
If you access sequence store data using a direct S3 URI, HealthOmics provides enhanced security measures for the associated S3 bucket access policy.
The following rules apply to new S3 access policies. For existing policies, the rules apply when you next update the policy:
+ The S3 access policies support the following [ policy elements](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)
+ Version, Id, Statement, Sid, Effect, Principal, Action, Resource, Condition
+ The S3 access policies support the following [condition keys](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html#amazons3-policy-keys):
+ s3:ExistingObjectTag/, s3:prefix, s3:signatureversion, s3:TlsVersion
+ Policies also support aws:PrincipalArn with the following condition operators: ArnEquals and ArnLike
If you try to add or update a policy to include an unsupported element or condition, the system rejects the request.
**Topics**
+ [Default S3 access policy](#default-access-policy)
+ [Customizing the access policy](#customize-access-policy)
+ [IAM policy](#iam-policy)
+ [Tag-based access control](#tag-based-access)
### Default S3 access policy
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:
------
#### [ JSON ]
****
```
{
"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/*"
}
]
}
```
------
### Customizing the access policy
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.
To add restrictions on the sharing or to 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.
### IAM policy
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](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) 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.
------
#### [ JSON ]
****
```
{
"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/*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/omics:readSetStatus": "ACTIVE"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890",
"Condition": {
"StringLike": {
"s3:prefix": "111111111111/sequenceStore/1234567890/*"
}
}
}
]
}
```
------
### Tag-based access control
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:::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 \$1111111111111) managed a data store. This data owner shares the data with a broad range of third party users, including a researcher (account \$1999999999999). 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 propagated. 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:
+ Statement 1 (restrictedGetWithdrawal): Account 999999999999 can't retrieve objects that are withdrawn.
+ Statement 2 (ownerGetAll): Account 111111111111, the data owner, can retrieve all objects, including objects that are withdrawn.
+ Statement 3 (everyoneListAll): All shared accounts, 111111111111 and 999999999999, can run the **ListBucket** operation on the whole prefix.
------
#### [ JSON ]
****
```
{
"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/*"
}
}
}
]
}
```
------