# Security in AWS Device Farm
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Device Farm, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using Device Farm. The following topics show you how to configure Device Farm to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Device Farm resources.
**Topics**
+ [Identity and access management in AWS Device Farm](security-iam.md)
+ [Compliance validation for AWS Device Farm](ATP-compliance.md)
+ [Data protection in AWS Device Farm](data-protection.md)
+ [Resilience in AWS Device Farm](disaster-recovery-resiliency.md)
+ [Infrastructure security in AWS Device Farm](infrastructure-security.md)
+ [Configuration vulnerability analysis and management in Device Farm](security-vulnerability-analysis-and-management.md)
+ [Incident response in Device Farm](security-incident-response.md)
+ [Logging and monitoring in Device Farm](security-logging-monitoring.md)
+ [Security best practices for Device Farm](security-best-practices.md)
# Identity and access management in AWS Device Farm
## Audience
How you use AWS Identity and Access Management (IAM) differs based on your role:
+ **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting AWS Device Farm identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How AWS Device Farm works with IAM](security_iam_service-with-iam.md))
+ **IAM administrator** - write policies to manage access (see [AWS Device Farm identity-based policy examples](security_iam_id-based-policy-examples.md))
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.
### AWS account root user
When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
### IAM Users and groups
An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.
### IAM roles
An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.
IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
# How AWS Device Farm works with IAM
Before you use IAM to manage access to Device Farm, you should understand which IAM features are available to use with Device Farm. To get a high-level view of how Device Farm and other AWS services work with IAM, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**Topics**
+ [Device Farm identity-based policies](#security_iam_service-with-iam-id-based-policies)
+ [Device Farm resource-based policies](#security_iam_service-with-iam-resource-based-policies)
+ [Access control lists](#security_iam_service-with-iam-acls)
+ [Authorization based on Device Farm tags](#security_iam_service-with-iam-tags)
+ [Device Farm IAM roles](#security_iam_service-with-iam-roles)
## Device Farm identity-based policies
With IAM identity-based policies, you can specify allowed or denied actions and resources and the conditions under which actions are allowed or denied. Device Farm supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see [IAM JSON Policy Elements Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Actions
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
Policy actions in Device Farm use the following prefix before the action: `devicefarm:`. For example, to grant someone permission to start Selenium sessions with the Device Farm desktop browser testing `CreateTestGridUrl` API operation, you include the `devicefarm:CreateTestGridUrl` action in the policy. Policy statements must include either an `Action` or `NotAction` element. Device Farm defines its own set of actions that describe tasks that you can perform with this service.
To specify multiple actions in a single statement, separate them with commas as follows:
```
"Action": [
"devicefarm:action1",
"devicefarm:action2"
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `List`, include the following action:
```
"Action": "devicefarm:List*"
```
To see a list of Device Farm actions, see [Actions defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) in the *IAM Service Authorization Reference*.
### Resources
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
The Amazon EC2 instance resource has the following ARN:
```
arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId}
```
For more information about the format of ARNs, see [Amazon Resource Names (ARNs) and AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
For example, to specify the `i-1234567890abcdef0` instance in your statement, use the following ARN:
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"
```
To specify all instances that belong to an account, use the wildcard (\$1):
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
```
Some Device Farm actions, such as those for creating resources, cannot be performed on a resource. In those cases, you must use the wildcard (\$1).
```
"Resource": "*"
```
Many Amazon EC2 API actions involve multiple resources. For example, `AttachVolume` attaches an Amazon EBS volume to an instance, so an IAM user must have permissions to use the volume and the instance. To specify multiple resources in a single statement, separate the ARNs with commas.
```
"Resource": [
"resource1",
"resource2"
```
To see a list of Device Farm resource types and their ARNs, see [Resource types defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-resources-for-iam-policies) in the *IAM Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) in the *IAM Service Authorization Reference*.
### Condition keys
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
Device Farm defines its own set of condition keys and also supports the use of some global condition keys. To see all AWS global condition keys, see [AWS Global Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To see a list of Device Farm condition keys, see [Condition keys for AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-policy-keys) in the *IAM Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by AWS Device Farm](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions) in the *IAM Service Authorization Reference*.
### Examples
To view examples of Device Farm identity-based policies, see [AWS Device Farm identity-based policy examples](security_iam_id-based-policy-examples.md).
## Device Farm resource-based policies
Device Farm does not support resource-based policies.
## Access control lists
Device Farm does not support access control lists (ACLs).
## Authorization based on Device Farm tags
You can attach tags to Device Farm resources or pass tags in a request to Device Farm. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. For more information about tagging Device Farm resources, see [Tagging AWS Device Farm resources](tagging.md).
To view an example identity-based policy for limiting access to a resource based on the tags on that resource, see [Viewing Device Farm desktop browser testing projects based on tags](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-project-tags).
## Device Farm IAM roles
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an entity in your AWS account that has specific permissions.
### Using temporary credentials with Device Farm
Device Farm supports the use of temporary credentials.
You can use temporary credentials to sign in with federation to assume an IAM role orcross-account role. You obtain temporary security credentials by calling AWS STS API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
### Service-linked roles
[Service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view, but cannot edit, the permissions for service-linked roles.
Device Farm uses service-linked roles in the Device Farm desktop browser testing feature. For information on these roles, see [ Using Service-Linked Roles in Device Farm desktop browser testing](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) in the developer guide.
### Service roles
Device Farm does not support service roles.
This feature allows a service to assume a [service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role) on your behalf. This role allows the service to access resources in other services to complete an action on your behalf. Service roles appear in your IAM account and are owned by the account. This means that an IAM administrator can change the permissions for this role. However, doing so might break the functionality of the service.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.
By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.
The following table outlines the Device Farm AWS managed policies.
| Change | Description | Date |
| --- | --- | --- |
| [AWSDeviceFarmFullAccess](https://console.aws.amazon.com/iam/home?region=us-east-1#/policies/arn:aws:iam::aws:policy/AWSDeviceFarmFullAccess$jsonEditor) | Provides full access to all AWS Device Farm operations. | July 15, 2015 |
| [AWSServiceRoleForDeviceFarmTestGrid](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) | Allows Device Farm to access AWS resources on your behalf. | May 20, 2021 |
### Other policy types
AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# AWS Device Farm identity-based policy examples
By default, IAM users and roles don't have permission to create or modify Device Farm resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating Policies on the JSON Tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices)
+ [Allow users to view their own permissions](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Accessing one Device Farm desktop browser testing project](#security_iam_id-based-policy-examples-access-one-project)
+ [Viewing Device Farm desktop browser testing projects based on tags](#security_iam_id-based-policy-examples-view-project-tags)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete Device Farm resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Accessing one Device Farm desktop browser testing project
In this example, you want to grant an IAM user in your AWS account access to one of your Device Farm destktop browser testing projects, `arn:aws:devicefarm:us-west-2:111122223333:testgrid-project:123e4567-e89b-12d3-a456-426655441111`. You want the account to be able to see items related to the project.
In addition to the `devicefarm:GetTestGridProject` endpoint, the account must have the `devicefarm:ListTestGridSessions`, `devicefarm:GetTestGridSession`, `devicefarm:ListTestGridSessionActions`, and `devicefarm:ListTestGridSessionArtifacts` endpoints.
If you are using CI systems, you should give each CI runner unique access credentials. For example, a CI system is unlikely to need more permissions than `devicefarm:ScheduleRun` or `devicefarm:CreateUpload`. The following IAM policy outlines a minimal policy to allow a CI runner to start a test of a new Device Farm native app test by creating an upload and using it to schedule a test run:
## Viewing Device Farm desktop browser testing projects based on tags
You can use conditions in your identity-based policy to control access to Device Farm resources based on tags. This example shows how you might create a policy that allows the viewing of projects and sessions. Permission is granted if the `Owner` tag of the requested resource matches the username of the requesting account.
You can attach this policy to the IAM users in your account. If a user named `richard-roe` attempts to view a Device Farm project or session, the project must be tagged `Owner=richard-roe` or `owner=richard-roe`. Otherwise, the user is denied access. The condition tag key `Owner` matches both `Owner` and `owner` because condition key names are not case sensitive. For more information, see [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
# Troubleshooting AWS Device Farm identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with Device Farm and IAM.
## I am not authorized to perform an action in Device Farm
If you receive an error in the AWS Management Console that says you're not authorized to perform an action, you must contact your administrator for assistance. Your administrator is the person who provided you with your user name and password.
The following example error occurs when the IAM user, `mateojackson`, tries to use the console to view details about a run, but does not have `devicefarm:GetRun` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: devicefarm:GetRun on resource: arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `devicefarm:GetRun` on resource `arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111` resource using the `devicefarm:GetRun` action.
## I am not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Device Farm.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Device Farm. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I want to view my access keys
After you create your IAM user access keys, you can view your access key ID at any time. However, you can't view your secret access key again. If you lose your secret key, you must create a new access key pair.
Access keys consist of two parts: an access key ID (for example, `AKIAIOSFODNN7EXAMPLE`) and a secret access key (for example, `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`). Like a user name and password, you must use both the access key ID and secret access key together to authenticate your requests. Manage your access keys as securely as you do your user name and password.
**Important**
Do not provide your access keys to a third party, even to help [find your canonical user ID](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId). By doing this, you might give someone permanent access to your AWS account.
When you create an access key pair, you are prompted to save the access key ID and secret access key in a secure location. The secret access key is available only at the time you create it. If you lose your secret access key, you must add new access keys to your IAM user. You can have a maximum of two access keys. If you already have two, you must delete one key pair before creating a new one. To view instructions, see [Managing access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) in the *IAM User Guide*.
## I'm an administrator and want to allow others to access Device Farm
To allow others to access Device Farm, you must grant permission to the people or applications that need access. If you are using AWS IAM Identity Center to manage people and applications, you assign permission sets to users or groups to define their level of access. Permission sets automatically create and assign IAM policies to IAM roles that are associated with the person or application. For more information, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center User Guide*.
If you are not using IAM Identity Center, you must create IAM entities (users or roles) for the people or applications that need access. You must then attach a policy to the entity that grants them the correct permissions in Device Farm. After the permissions are granted, provide the credentials to the user or application developer. They will use those credentials to access AWS. To learn more about creating IAM users, groups, policies, and permissions, see [IAM Identities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) and [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
## I want to allow people outside of my AWS account to access my Device Farm resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether Device Farm supports these features, see [How AWS Device Farm works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
# Compliance validation for AWS Device Farm
Third-party auditors assess the security and compliance of AWS Device Farm as part of multiple AWS compliance programs. These include SOC, PCI, FedRAMP, HIPAA, and others. AWS Device Farm is not in scope of any AWS compliance programs.
For a list of AWS services in scope of specific compliance programs, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using Device Farm is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:
+ [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS.
+ [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location.
+ [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) in the *AWS Config Developer Guide* – AWS Config assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices.
# Data protection in AWS Device Farm
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Device Farm (Device Farm). As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Device Farm or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
## Encryption in transit
The Device Farm endpoints only support signed HTTPS (SSL/TLS) requests except where otherwise noted. All content retrieved from or placed in Amazon S3 through upload URLs is encrypted using SSL/TLS. For more information on how HTTPS requests are signed in AWS, see [Signing AWS API requests](https://docs.aws.amazon.com//general/latest/gr/signing_aws_api_requests.html) in the AWS General Reference.
It is your responsibility to encrypt and secure any communications that your tested applications make and any applications installed in the process of running on-device tests.
## Encryption at rest
Device Farm's desktop browser testing feature supports encryption at rest for artifacts generated during tests.
Device Farm's physical mobile device testing data is not encrypted at rest.
## Data retention
Data in Device Farm is retained for a limited time. After the retention period expires, the data is removed from Device Farm's backing storage.
| Content type | Retention period (days) | Metadata Retention period (days) |
| --- | --- | --- |
| Uploaded applications | 30 | 30 |
| Uploaded test packages | 30 | 30 |
| Logs | 400 | 400 |
| Video recordings and other artifacts | 400 | 400 |
It is your responsibility to archive any content that you want to retain for longer periods.
## Data management
Data in Device Farm is managed differently depending on which features are used. This section explains how data is managed while and after you use Device Farm.
### Desktop browser testing
Instances used during Selenium sessions are not saved. All data generated as a result of browser interactions is discarded when the session ends.
This feature currently supports encryption at rest for artifacts generated during the test.
### Physical device testing
The following sections provide information about the steps AWS takes to clean up or destroy devices after you have used Device Farm.
Device Farm's physical mobile device testing data is not encrypted at rest.
#### Public device fleets
After test execution is complete, Device Farm performs a series of cleanup tasks on each device in the public device fleet, including uninstallation of your app. If we cannot verify uninstallation of your app or any of the other cleanup steps, the device receives a factory reset before it is put back into use.
**Note**
It is possible for data to persist between sessions in some cases, especially if you make use of the device system outside the context of your app. For this reason, and because Device Farm captures video and logs of activity taking place during your use of each device, we recommend that you do not enter sensitive information (for example, Google account or Apple ID), personal information, and other security-sensitive details during your automated test and remote access sessions.
#### Private devices
After expiration or termination of your private device contract, the device is removed from use and securely destroyed in accordance with AWS destruction policies. For more information, see [Private devices in AWS Device Farm](working-with-private-devices.md).
## Key management
Currently, Device Farm does not offer any external key management for encryption of data, at rest or in transit.
## Internetwork traffic privacy
Device Farm can be configured, for private devices only, to use Amazon VPC endpoints to connect to your resources in AWS. Access to any non-public AWS infrastructure associated with your account (for example, Amazon EC2 instances without a public IP address) must use an Amazon VPC endpoint. Regardless of VPC endpoint configuration, Device Farm isolates your traffic from other users throughout the Device Farm network.
Your connections outside the AWS network are not guaranteed to be secured or safe, and it is your responsibility to secure any internet connections your applications make.
# Resilience in AWS Device Farm
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
Because Device Farm is available in the `us-west-2` Region only, we strongly recommend that you implement backup and recovery processes. Device Farm should not be the only source of any uploaded content.
Device Farm makes no guarantees of the availability of public devices. These devices are taken in and out of the public device pool depending on a variety of factors, such as failure rate and quarantine status. We do not recommend that you depend on the availability of any one device in the public device pool.
# Infrastructure security in AWS Device Farm
As a managed service, AWS Device Farm is protected by the AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access Device Farm through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
## Infrastructure security for physical device testing
Devices are physically separated during physical device testing. Network isolation prevents cross-device communication over wireless networks.
Public devices are shared, and Device Farm makes a best-effort attempt at keeping devices safe over time. Certain actions, such as attempts to acquire complete administrator rights on a device (a practice referred to as *rooting* or *jailbreaking*), cause public devices to become quarantined. They are removed from the public pool automatically and placed into manual review.
Private devices are accessible only by AWS accounts explicitly authorized to do so. Device Farm physically isolates these devices from other devices and keeps them on a separate network.
On privately managed devices, tests can be configured to use an Amazon VPC endpoint to secure connections in and out of your AWS account.
## Infrastructure security for desktop browser testing
When you use the desktop browser testing feature, all test sessions are separated from one another. Selenium instances cannot cross-communicate without an intermediate third party, external to AWS.
All traffic to Selenium WebDriver controllers must be made through the HTTPS endpoint generated with `createTestGridUrl`.
You are responsible for making sure that each Device Farm test instance has secure access to resources it tests. By default, Device Farm's desktop browser testing instances have access to the public internet. When you attach your instance to a VPC, it behaves like any other EC2 instance, with access to resources determined by the VPC's configuration and its associated networking components. AWS provides [security groups](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-groups.html) and [network Access Control Lists (ACLs)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html) to increase security in your VPC. Security groups control inbound and outbound traffic for your resources, and network ACLs control inbound and outbound traffic for your subnets. Security groups provide enough access control for most subnets. You can use network ACLs if you want an additional layer of security for your VPC. For general guidelines on security best practices when using Amazon VPCs, see [security best practices ](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-best-practices.html) for your VPC in the *Amazon Virtual Private Cloud User Guide*.
# Configuration vulnerability analysis and management in Device Farm
Device Farm allows you to run software that is not actively maintained or patched by the vendor, such as the OS vendor, hardware vendor, or phone carrier. Device Farm makes a best-effort attempt to maintain up to date software, but makes no guarantees that any particular version of the software on a physical device is up to date, by design allowing potentially vulnerable software to be put into use.
For example, if a test is performed on a device running Android 4.4.2, Device Farm makes no guarantee that the device is patched against the [vulnerability in Android known as StageFright](https://en.wikipedia.org/wiki/Stagefright_(bug)). It is up to the vendor (and sometimes the carrier) of the device to provide security updates to devices. A malicious application that uses this vulnerability is not guaranteed to be caught by our automated quarantining.
Private devices are maintained as per your agreement with AWS.
Device Farm makes a best-faith effort to prevent customer applications from actions such as *rooting* or *jailbreaking*. Device Farm removes devices that are quarantined from the public pool until they have been manually reviewed.
You are responsible for keeping any libraries or versions of software that you use in your tests, such as Python wheels and Ruby gems, up to date. Device Farm recommends that you update your test libraries.
These resources can help keep your test dependencies up to date:
+ For information about how to secure Ruby gems, see [Security Practices](https://guides.rubygems.org/security/) on the RubyGems website.
+ For information about the safety package used by Pipenv and endorsed by the Python Packaging Authority to scan your dependency graph for known vulnerabilities, see the [Detection of Security Vulnerabilities](https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities) on GitHub.
+ For information about the Open Web Application Security Project (OWASP) Maven dependency checker, see [OWASP DependencyCheck](https://owasp.org/www-project-dependency-check/) on the OWASP website.
It is important to remember that even if an automated system does not believe there are any known security issues, it does not mean that there are no security issues. Always use due diligence when using libraries or tools from third parties and verify cryptographic signatures when possible or reasonable.
# Incident response in Device Farm
Device Farm continuously monitors devices for behaviors that might indicate security issues. If AWS is made aware of a case where customer data, such as test results or files written to a public device, is accessible by another customer, AWS contacts affected customers, according to the standard incident alerting and reporting policies used throughout AWS services.
# Logging and monitoring in Device Farm
This service supports AWS CloudTrail, which is a service that records AWS calls for your AWS account and delivers log files to an Amazon S3 bucket. By using information collected by CloudTrail, you can determine what requests were successfully made to AWS services, who made the request, when it was made, and so on. To learn more about CloudTrail, including how to turn it on and find your log files, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
For information about using CloudTrail with Device Farm, see [Logging AWS Device Farm API calls with AWS CloudTrail](logging-using-cloudtrail.md).
# Security best practices for Device Farm
Device Farm provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.
+ Grant any continuous integration (CI) system you use the least privilege possible under IAM. Consider using temporary credentials for each CI system test so that even if a CI system is compromised, it cannot make spurious requests. For more information about temporary credentials, see the [IAM User Guide](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole).
+ Use `adb` commands in a custom test environment to clean up any content created by your application. For more information about custom test environments, see [Custom test environments in AWS Device Farm](custom-test-environments.md).