Setting Up Amazon Elastic Kubernetes Service Replication

Enabling Amazon EKS replication with Arpio

Jump to:

Overview

Granting Access to Source Clusters

Additional Requirements for Private Clusters

Overview

Arpio uses AWS Lambda functions in your AWS accounts to back up and restore Amazon EKS clusters. To do this, the Lambda function's execution role must have access to the EKS cluster’s control plane.

This IAM role is created automatically when you deploy the CloudFormation stack during setup. Its name will resemble:

ArpioPrimaryK8sDel-<account_id>-us-east-1

Once you add an EKS cluster to your Arpio application, Arpio checks if the execution role has the necessary permissions. If not, it raises an issue in the app with the command needed to grant access.

There are two supported methods for granting access:

• EKS Access Entries

• ConfigMap-based Authentication

Once access is granted, Arpio can begin creating recovery points for your EKS workload. It will also detect related AWS resources, such as ECR repositories and IAM roles, linked to your cluster configuration.

For more details, see the EKS resource reference.

Granting Arpio Access to your EKS Clusters

EKS Access Entries

The EKS Access Entry methodology is the best way to grant Arpio access to the Kubernetes API. Arpio will dynamically generate a command for each new cluster that you onboard via a Recovery Point issue. You can also prepare your own command using the following example:

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/AmazonEKSAdminViewPolicy \

--access-scope type=cluster

AWS-Auth ConfigMap 

Arpio also supports the older aws-auth ConfigMap methodology, if that is what your source cluster uses. A ConfigMap command will also be included in each Recovery Point issue for new clusters. You can also 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.

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.