# Security
<a name="security-1"></a>

When you build systems on AWS infrastructure, security responsibilities are shared between you and AWS. This [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) reduces your operational burden because AWS operates, manages, and controls the components including the host operating system, the virtualization layer, and the physical security of the facilities in which the services operate. For more information about AWS security, visit [AWS Cloud Security](http://aws.amazon.com/security/).

## IAM roles
<a name="iam-roles"></a>

AWS Identity and Access Management (IAM) roles allow customers to assign granular access policies and permissions to services and users on the AWS Cloud. This solution aims to create IAM roles with least privilege where resource access is required. The Amazon EKS deployment uses [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) to associate IAM roles with the Kubernetes service accounts used by the Migration Console pod (`migration-console-access-role`) and the Argo workflow executor pods (`argo-workflow-executor`). This means the Migration Console and the migration jobs can authenticate to Amazon OpenSearch Service, Amazon OpenSearch Serverless, Amazon S3, AWS Secrets Manager, and other AWS services without long-lived credentials.

## Security groups
<a name="security-groups"></a>

The solution creates security groups designed to control and isolate network traffic between Migration Assistant pods on Amazon EKS, as well as between certain Migration Assistant pods and associated services such as Amazon S3 (via VPC endpoints), Amazon OpenSearch Service, Amazon OpenSearch Serverless, and Amazon EFS. We recommend that you review the security groups and further restrict access as needed once the deployment is up and running. For source and target clusters, the source and target security groups must allow inbound traffic from the Amazon EKS cluster security group.

## AWS Secrets Manager
<a name="aws-secrets-manager"></a>

Migration Assistant for Amazon OpenSearch Service allows accessing stored secrets from AWS Secrets Manager from the Migration Console pod, the Argo workflow executor pods, and the Reindex-from-Snapshot, Capture Proxy, and Traffic Replayer workloads. Accessing these secrets allows for proper authentication when migrating data from source to target on Amazon OpenSearch Service or Amazon OpenSearch Serverless, and for observing migration status. Use `kubectl create secret generic` to create Kubernetes secrets in the `ma` namespace and reference them in `authConfig.basic.secretName` in your workflow configuration.

## Fine-grained access control
<a name="fine-grained-access-control"></a>

If your Amazon OpenSearch Service domain has fine-grained access control (FGAC) enabled, the Migration Assistant IAM role must be mapped to a security role on the domain (typically `all_access` during migration, then scoped down). Authentication gets you to the domain; FGAC authorizes what you can do once you are in. Both must be in place. The role mapping API path differs by engine: Elasticsearch 7.x uses `/_opendistro/_security/api/rolesmapping/role`, and OpenSearch 1.x and later uses `/_plugins/_security/api/rolesmapping/role`. See [Troubleshooting](troubleshooting.md) for details.