Skip to content

Create AWS EKS cluster from GitLab

Problem to solve

Users cannot currently create a cluster on AWS' EKS from GitLab. Creating a cluster on EKS is difficult for first time users.

Further details

https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html

It looks like eksctl create cluster takes care of everything, including adding nodes: https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html (edited)

Identity providers and federation https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html

Proposal

Provide a tight integration with EKS where users can create clusters from the GitLab GUI (similar to GKE)

Pre-requisites:

  1. User creates an IAM Policy that grants access to the required resources (read VPC, create cluster, nodes etc). GitLab will provide example JSON for this.
  2. User creates an IAM Cross Account Role, adding the GitLab AWS account ID as a trusted entity and the policy above for permissions.

User Flow

  1. User to enter the Role ARN and External ID generated in the pre-requisites step into the cluster form. These cannot be changed once set (for now).
  2. GitLab provisions a dedicated service account for this cluster in the GitLab AWS account, and grants permissions to assume the role above.
  3. GitLab (frontend) uses the service account to assume the role, and fills-in/validates the remaining fields in the cluster form.
  4. User completes the cluster form and submits it.
  • Cluster name
  • Kubernetes version (default to latest)
  • Region
  • Role Name (select existing)
  • VPC (select existing)
  • subnets (auto fill from VPC)
  • security group (auto fill from VPC)

  1. GitLab (backend) uses the service account to assume the role, and can provision the cluster. From here it is the same process as a GKE cluster (poll to check progress etc)

  2. Update cluster creation screen to provide two options

  • Create on cloud provider
  • Add existing cluster

  1. Once users select the new "Create on cloud provider" option, the flow for GKE will be the same as it is now.

  2. Cluster should have public access enabled by default so GitLab can interact with it.

User is able to select between EKS and GKE (alphabetical order):

Screen_Shot_2019-09-10_at_9.50.17_AM

SVGs:

The user would choose AWS from the first screen and we would keep them on that page but transition the content to be a form field that would allow them to input the necessary account details (instead of navigating away as we do with signing in to google). On that screen we can include a link to the docs that details how to get the necessary information (creating a service account) needed to provide credentials.

previous solution that involves logging in via AWS - this not a possible option. Clicking either would take the user to the screen to authorize application permissions:
Google Amazon
google-auth amazon-auth

This essentially removes the "login with google" button.

From there, the user sees the fields necessary to create the EKS cluster:

Kubernetes cluster name

[ ]

Environment scope

[ * ]

Choose which of your environments will use this cluster.

Kubernetes version

[ 1.13 ]

Select the Kubernetes version to install.

Role name

[ Select role name ˅ ]

Select the IAM Role to allow Amazon EKS and the Kubernetes control plane to manage AWS resources on your behalf. To use a new role name, first create one on Amazon Web Services ↗

Region

[ Select Region ˅ ]

Learn more about Regions ↗ .

Key pair name

[ Select region to choose key pair name ˅ ] (DISABLED IF REGION HAS NOT BEEN SELECTED)

[ Select key pair name ˅ ] (ENABLED IF REGION HAS BEEN SELECTED)

Select the key pair name that will be used to create EC2 nodes. To use a new key pair name, first create one on Amazon Web Services ↗

VPC

[ Select VPC ˅ ]

Select a VPC to use for your EKS Cluster resources. To use a new VPC, first create one on Amazon Web Services ↗

Subnets

[ subnet-4397a627 +6 more ˅ ]

Choose the subnets ↗ in your VPC where your worker nodes will run.

Security groups

[ None ˅ ]

Choose the security groups ↗ to apply to the EKS-managed Elastic Network Interfaces that are created in your worker node subnets.

[✓] GitLab-managed cluster

Allow GitLab to manage namespace and service accounts for this cluster. More information

  • Kubernetes version should be prefilled and have existing options in the dropdown
  • Role names and VPCs should be show existing options in the dropdown
  • Subnets and Security groups should be prefilled and are also multi-select. The options within the dropdown would look like:

Screen_Shot_2019-07-12_at_3.49.45_PM

Solution

Assets

What does success look like, and how can we measure that?

Add EKS as a platform in usage ping, similar to https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/usage_data.rb#L67

Links / references

Ruby Gem API method for creating cluster https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/EKS/Client.html#create_cluster-instance_method

https://aws.amazon.com/blogs/startups/from-zero-to-eks-with-terraform-and-helm/

Edited by Taurie Davis