How to enable Amazon EKS replication with Arpio
Arpio uses AWS Lambda functions that run in your AWS accounts to assist in backing up and restoring Amazon EKS clusters. In order to back up customer-created EKS clusters, Arpio's Kubernetes delegate function's execution role needs to be given access to the EKS cluster's control plane. The function's execution IAM role will be created automatically when the upon execution of the CloudFormation stack provided during application setup. That role name will look something like:
ArpioPrimaryK8sDel-<account_id>-us-east-1
After you add an Amazon EKS cluster to your Arpio application, Arpio will check that the execution role has the appropriate permissions to access the cluster. If it doesn't, Arpio will raise an issue in your application that contains the command you should run to grant it access.
It's easiest to use the command that Arpio generates for your cluster, but you can prepare your own command using the following example that adds an EKS access entry.
aws eks create-access-entry \
--region=<region-code> \
--cluster-name <my-cluster> \
--principal-arn arn:aws:iam::<accountID>:role/ArpioPrimaryK8sDel-<role-unique-string>-<region-code> \
--type STANDARD \
--user Arpio ; aws eks associate-access-policy \
--region=<recovery-region-code> \
--cluster-name <my-cluster> \
--principal-arn arn:aws:iam::<accountID>:role/ArpioPrimaryK8sDel-<role-unique-string>-<recovery-region-code> \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
Alternatively, if your Amazon EKS cluster is using ConfigMap, you can use the following example to create a command to add an IAM Identity Mapping to the aws-auth ConfigMap in the kube-system namespace:
eksctl create iamidentitymapping \
--cluster <my-cluster> \
--region=<region-code> \
--arn arn:aws:iam::<aws-account-id>:role/ArpioPrimaryK8sDel-... \
--group system:masters \
--no-duplicate-arns
This group (system:masters) is the same access the creator of the cluster is granted in AWS. For this reason, when the recovery cluster is brought up, this step doesn't have to be repeated, as Arpio will have created it.
A less privileged group on the cluster is permissible, but it must have read access to everything one wishes to replicate. (The default view role does not include reading secrets, for instance.)
After granting permissions to the above role, recovery point creation for your EKS workload will begin. In addition to being able to access the cluster's configuration to back it up, Arpio will then be able to find additional AWS resources your configuration depends upon such as ECR repositories and IAM roles.
Learn more about how Arpio replicates EKS cluster attributes in the EKS resource reference.
Additional requirements for private Amazon EKS Clusters
In order for Arpio to ensure network access to private clusters, Arpio installs an AWS Lambda function into the subnets and security group attached to the individual clusters. To authenticate to those clusters and retrieve the cluster configuration, Arpio’s Lambda delegate needs to communicate with the EKS STS and Amazon S3 APIs. If those subnets do not have access to the internet, VPC Endpoints are available to make those connections.
Those endpoints need to be available via DNS in the following format to allow for Arpio's Lambda delegate to find them:
<service name>.<region>.amazonaws.com
This is the default configuration for most endpoints, but Amazon S3 requires the ‘private DNS names’ option to be enabled as well.