How to connect AWS EKS to Razorops

Amazon Elastic Container Service for Kubernetes (EKS) is the managed Kubernetes service of AWS. This article explains how Razorops will authentication on EKS cluster for your deployments.


Amazon EKS was released to general availability in June 2018. It is in the same category of services as GKE from Google Cloud Platform or AKS from Microsoft Azure.

EKS does not create and run an entire cluster for you, unlike the latter two services, but it creates and runs the control plane of a cluster for you. The meaning of the control plane is generally the master nodes. In particular, EKS runs multiple master nodes in different availability zones in an AWS-managed account. You are responsible for provisioning and running the worker nodes in your own account as an EC2 instances.

We will follow some series of steps to achieve our goal to connect EKS running cluster to Razorops in order to allow Razorops to perform deployment operations for you on your behalf.


Connecting EKS cluster to Razorops is quite easy once we get few details of the EKS cluster in hand. Followings are the required things we need:

  1. Your EKS cluster is running. If it is not ready yet, then please follow the instructions on AWS EKS Docs here. We recommend to create EKS Cluster through AWS Management Console, because it makes sure that you have completed all the necessary creation steps e.g VPC, Security Groups, Amazon EKS IAM Roles, Subnets, Endpoint access.

  2. You have created a Managed Node Group or a worker Node. If you haven't created one, please read AWS EKS's Creating aManaged Node group here

  3. You have authenticated EKS locally so that you have access to EKS cluster for admin operations. It will become very easy if you have followed the 1st step through AWS Management Console. For more details please read our article Connect with AWS EKS.

  4. Test if you are connected with EKS Cluster. Please run the following command.

kubectl get nodes

Output should be something like below:

NAME                                             STATUS   ROLES    AGE     VERSION
ip-[some-ip-address].[region].compute.internal   Ready    <none>   3d12h   v1.14.7-eks-1861c5

If you see the output something like above, it means we are ready for the next step.

Ways to connect EKS with Razorops

The simplest way we can connect Razorops and EKS Cluster is through Cluster's ServiceAccount. As we know kubernetes enables access control for workloads by providing service accounts. A service account represents an identity for processes that run in a pod. When a process is authenticated through a service account, it can contact the API server and access cluster resources. If a pod doesn’t have an assigned service account, it gets the default service account.

For more details about ServiceAccount, please read Kubernetes Managing Service Accounts

ServiceAccount should have the right permissions to access the cluster resources and API server.

Creating a ServiceAccount.

To create a ServiceAccount, we need to create a resource of kind ServiceAccount. Run the following command.

kubectl apply -f

Content of the file is:

apiVersion: v1
kind: ServiceAccount
  name: razorops
  namespace: default

In the above file, resouce kind is ServiceAccount and our serviceaccount name is "razorops". You can change the name of the ServiceAccount as per your requirements. If you are using different namespace for your project then user that namespace throughout the tutorial. We are using default namespace in this document.

To make changes in the file, you can download it and then create the resource in kubernetes as follow.

curl -O

kubectl apply -f razorops-service-account.yaml

Now this serviceaccount "razorops" should have permissions to access resources and make request to cluster API server. To do so we need to create a resource of kind Role and bind this Role with our serviceaccount "razorops" that we just created above.

Creating a Role

In the RBAC(Role based access control) API, a role contains rules that represent a set of permissions. Permissions are purely additive (there are no “deny” rules). A role can be defined within a namespace with a Role, or cluster-wide with a ClusterRole. A Role can only be used to grant access to resources within a single namespace.

Run the following command:

kubectl apply -f

Content of the file is:

kind: Role
apiVersion: #RBAC mode is backed by the API
  name: razorops-role
  namespace: default
  - apiGroups: ["", "apps", "batch", "extensions"] # indicates the core API group
    resources: ["deployments", "services", "replicasets", "pods", "jobs", "cronjobs", "secrets", "serviceaccounts"]
      - create
      - delete
      - deletecollection
      - get
      - list
      - patch
      - update
      - watch

Our role name is "razorops-role". This role has permissions of all the resources mentioned in its yaml file. If you try to access resource other than mentioned above, it will not allow you.

You can modify resources and verbs in the above file accordingly. Again, we are using default namespace. If you are using your defined namespace then always make keep the same namespace across whole scenario.

Both Role named razorops-role and ServiceAccount named razorops are created. But, as of now, both the resources are independent, we need to tell our cluster API server to bind both so that our serviceaccount can take advantage of the rules we defined in the role.

Role Binding with Service Account.

Remember our role name is "razorops-role" and serviceaccount is "razorops". A resource of Kind "RoleBinding" is created. Run the following command to bind razorops-role to serviceaccount razorops as follow:

kubectl apply -f

Content of the file is:

kind: RoleBinding
  name: razorops-role-binding
  namespace: default
  - kind: ServiceAccount
    name: razorops
    namespace: default
  kind: Role
  name: razorope-role

This binding grants "razorops-role" role to serviceaccount "razorops" within the default namespace.

We have successfully created a service account which can access above mentioned resources. As of now, these resources are enough for us to do a proper deployment on worker nodes.

Create KubeConfig from ServiceAccount

Next step will generate the kubeconfig file in your current directory and also change the current context to use ServiceAccount "razorops".

First we need to download a scripting file as follow.

curl -O

./ default razorops

Here first we downloaded the file at your current directory. Then we ran the script with params namespace followed by serviceaccount.

As in our case, namespace is "default" and our service account which we created earlier is "razorops". You specify your own respective values.

Script will generate a kubeconfig file in your current directory and also it changed your current authentication to serviceaccount authentication.

If you view the kubeconfig file, it will look something like below:

apiVersion: v1
- cluster:
    certificate-authority-data: [certificate data string]
    server: [url]
  name: [url]
- context:
    cluster: [url]
    user: razorops
  name: registry
current-context: registry
kind: Config
preferences: {}
- name: razorops
    token: [token value string]

And we are done. All we need here is now "server" value under clusters and "token" value under users:

Lets call it "server endpoint" and "token".

Add server endpoint and token to Razorops website to authenticate

Now we will add our cluster to Razorops. Go to your dashboard, under kubernetes tab click Add New button


In the below form, Name: Give any name[Important because we will use this name in our .razorops.yaml file] CLUSTER API ENDPOINT= "server endpoint" which we got above in kubeconfig file at your local directory AUTHENTICATION METHOD *= Select "Cluster Api Token" API TOKEN="token" which we got above through in kubeconfig file at your local directory


Now click on "Create Cluster" button. It will register your cluster with your razorops account. These secrets are stored as kubernetes secrets and are incorporated when the need arrives.

Now we have success fully registered our cluster to razorops.