Installing Conjur in an EKS Kubernetes Cluster with Helm

Conjur Open Source is a robust secrets management tool to manage, audit, and control access across multiple platforms. Let’s explore how to set up Conjur Open Source in the popular cloud provider, Amazon Web Services (AWS).

We’ll start by creating a new AWS Identity and Access Management (IAM) role and attaching the required permissions for creating an Amazon Elastic Kubernetes Service (EKS) cluster. Then, to simplify the process, we’ll configure AWS CLI and eksctl (Amazon’s official command-line interface (CLI) for creating and managing Amazon EKS efficiently).

Then, we’ll spin up the clusters and install Conjur using Helm Charts. We’ll also explore how Conjur, policies, and the IAM authenticator work after installation.

Let’s get started by jumping right into the AWS console.

Creating an AWS IAM Role

First, ensure you’re logged into your root AWS Account. The best security practice is to follow the principle of least permissions.

After logging into AWS Console, we search for IAM. Then click Users in the IAM dashboard.

On the next screen, we click Add User and fill in a relevant username. In the following selection, we choose an AWS access type according to our needs. Programmatic access is enough for this tutorial. We then click on the next section, where we can attach the relevant permissions.

Here we skip the optional Tags step and click Create User on the Review screen.

We save the Access key ID and Secret access key on the next screen and keep them safe. We need those keys to configure AWS CLI to create the EKS cluster.

Our next step is to install and set up AWS CLI in our local environment.

Installing AWS CLI

To install AWS CLI, we go to the AWS Command Line Interface User Guide and follow the instructions. We select our device operating system (OS) and install the relevant CLI.

To verify successful installation, we open the terminal and type:

aws -- version

If that command returns the version, that means we successfully installed it.

Now, we configure AWS CLI with our Access key ID and Secret access key. To do this, we execute:

aws -- configure

We add the Access key ID and Secret access key, then specify the default region and output format.

Now, the next step is to install eksctl.

Installing eksctl

eksctl is the official CLI tool to create and manage AWS EKS clusters, which use AWS CloudFormation under the hood. The CLI simplifies cluster creation and provides a convenient way to create clusters at scale. So, we’ll use eksctl to spin up the cluster for us.

If you have not yet installed eksctl, follow Amazon’s instructions. You can execute eksctl -– version to verify the installation.

Our next step is to create an EKS cluster comprising the required resources.

Creating the AWS EKS Cluster

Before continuing this tutorial, note that the resources we are creating are not a part of the AWS Free Tier. Also, the resources require at least 4GB of RAM and two vCPUs. There’s a significant chance that your pod will go into the evicted stage while waiting for the resources. Also, apart from using Amazon Elastic Compute Cloud (EC2) instances as nodes, AWS EKS charges (currently) $0.10 per hour. For this tutorial, we spin up a single node EKS cluster using t4g.medium, which has two vCPUs and 4GB of RAM.

First, ensure you have configured the previous steps and granted the necessary permissions or roles. Then, we open our terminal and execute the command below to start our EKS cluster:

eksctl create cluster --name conjur-eks --nodegroup-name linux-nodes --node-type t4g.medium --nodes 1

The above command creates an EKS server named conjur-eks using the Linux t4g.medium EC2 instance. It might take around 10 to 30 minutes until this Kubernetes cluster is available to use.

After the cluster deploys, it saves the kubeconfig file for kubectl to access. If you see the following message in your terminal, it means the cluster is up and running:

Now, we’ll use kubectl and Helm to install Conjur in our cluster.

Installing Conjur

The easiest way to install Conjur on AWS EKS is using a Helm Chart. If you don’t have Helm installed on your local machine, follow these instructions.

Then, we’ll store some variables to make the next process easier.

First, let’s generate a data key to encrypt secrets in the database, as shown below. You can check all the released versions on the Conjur OSS Helm Chart GitHub page.

DATA_KEY="$(docker run --rm cyberark/conjur data-key generate)"

HELM_RELEASE=conjur-oss

CONJUR_NAMESPACE=conjur

VERSION=2.0.3

It’s best practice to keep everything separated using the namespace. So, run this command:

kubectl create namespace "$CONJUR_NAMESPACE"

Now, our next step is to install the Helm Chart using the above-created variables. However, let’s create a custom values.yaml file for the Helm Chart.

Nano values.yaml

We then copy and paste the content below into values.yaml. You can also customize it.

account:

  name: "default"

  create: true

Authenticators:"authn-k8s/namespace,authn-k8s/deployment,authn-k8s/service_account,authn-k8s/demo,authn"

dataKey: $DATA_KEY

service:

  external:

       enabled: false

replicaCount: 1

After saving the custom values.yaml file, we now install Conjur on the EKS cluster using the following command:

helm install -n $CONJUR_NAMESPACE  $HELM_RELEASE -f values.yaml https://github.com/cyberark/conjur-oss-helm-chart/releases/download/v$VERSION/conjur-oss-$VERSION.tgz

It will take a minute or so to spin up the pods, but we are good to go when the pods are ready.

kubectl get pods -A

That’s all it takes! We have successfully installed Conjur in an AWS EKS cluster.

Conjur works by creating policies, and those policies define role-based access control (RBAC). Conjur’sdocumentation explains more about policies and best practices.

After creating the policies, we make the config map to generate the mTLS certificate and key. Then, after making the config map containing the policy and mTLS key, we create a deployment to install the Conjur client:

apiVersion: v1

kind: Pod

metadata:

  labels:

       run: conjur-client

  name: conjur-client

  namespace: conjur

spec:

  containers:

  - command:

       - sleep

       - "4800"

       image: cyberark/conjur-cli:5

       name: conjur-client

       volumeMounts:

       - name: policy

       mountPath: /policy

       - name: conjur-ca

       mountPath: /conjur-ca

   dnsPolicy: ClusterFirst

   restartPolicy: Always

   volumes:

   - name: policy

       configMap:

       name: policies

   - name: conjur-ca

       configMap:

       name: conjur-ca

The Conjur client comes with conjur-cli, which we use to load the policies. We run conjur-client using the command below:

kubectl exec -it -n $CONJUR_NAMESPACE conjur-client -- sh

After opening conjur-cli, we connect to the Conjur server and authenticate as an admin user. To authenticate as an admin user, we first need to generate the API key from the initial Helm Chart installation. We do this by executing this series of commands:

POD_NAME=$(kubectl get pods --namespace $CONJUR_NAMESPACE -l "app=$HELM_RELEASE,release=$HELM_RELEASE" -o jsonpath="{.items[0].metadata.name}")

The above command gives us the name of the pod where we need to extract the API key. Then, we get the API key using the following command:

kubectl exec --namespace $CONJUR_NAMESPACE  $POD_NAME --container=$HELM_RELEASE -- conjurctl role retrieve-key default:user:admin | tail -1

We can use the key we got using the previous command to connect to the Conjur server:

conjur init -u https://conjur-oss -a default

conjur authn login -u admin -p OBTAINED_API_KEY

After connecting to the Conjur server, we can load our policies, certificate, key, and, most importantly, secrets. Then, we use Conjur’s Kubernetes Authenticator Client for the authentication. Finally, we run Conjur Summon as the primary process and inject secrets to any application securely.

Setting Up the Conjur IAM Authenticator

We can store isolated secrets, but it requires pre-configuration. A better way is to use the assigned AWS Role to authenticate with Conjur to retrieve the secrets. We do this using the Conjur IAM Authenticator.

By default, Conjur comes with IAM Authenticator. Our first step is to set the following variable when we start Conjur:

CONJUR_AUTHENTICATORS=authn-iam/dev

Here, dev is the name of the service ID used to implement zoning in authentication..

Next, we create a policy to enable the IAM Authenticator. The only point to keep in mind is that id must match the naming convention of conjur/authn-iam/serviceID.

!policy

  id: conjur/authn-iam/prod

  body:

       !webservice

       !group clients

       !permit

       role: !group clients

       privilege: [ read, authenticate ]

       resource: !webservice

Then, we can create an application-level policy to grant permissions to fetch our database username and password to an AWS service. When that’s complete, we can use Conjur’s IAM Authenticator to authenticate our EC2 instances and AWS Lambda functions.

Conclusion

In this article, we started by creating a separate AWS Account with the necessary roles and permissions for us to create an AWS EKS cluster. Then, we installed two utilities, eksctl and AWS CLI, to make creating the EKS cluster easier. We then installed Conjur using Helm Charts, discussed Conjur security policies using the RBAC concept to control access, and installed a Conjur client to load policies and secrets.

Now you can set up Conjur to manage all your Kubernetes secrets and keep your resources secure. Conjur’s secrets management tool secures and manages your secrets across any cloud or on-prem environment, making it a platform secrets management tool for managing nonhuman access and machine identities centrally.

Secrets Management as a Service

Don’t want to setup and maintain your own secrets management solution? Be sure to check out Conjur Cloud, our SaaS secrets management solution here.

Staff Writer