DEV Community: Binaya Sharma

Managing Secrets in Terraform with BitWarden

Binaya Sharma — Tue, 22 Jul 2025 06:03:44 +0000

Bitwarden has a Secrets Manager that has been specifically designed for storing secrets that can be used for machine-to-machine interaction.

In this demo, we will be integrating Terraform with Bitwarden. For this there are some pre-requisites:

bws command line utility
BitWarden Account

bws command line utility can simply be installed using the bash script. Also, we would need a account, and need to activate the Secrets Manager. We would also need to create a machine account. This will be used to authenticate with bitwarden.

Keep in mind that tokens are not saved, you will need to save it somewhere. Now we will be using configuring the providers:

providers.tf

terraform {
  required_providers {
    bitwarden-secrets = {
      source  = "sebastiaan-dev/bitwarden-secrets"
      version = "0.1.2"
    }
    random = {
      source  = "hashicorp/random"
      version = "3.6.3"
    }
  }
}

provider "random" {}

provider "bitwarden-secrets" {
  access_token = "#Acces_Token_From_the_Machine_Accounts"
}

I addition to bitwarden-secrets, i have also included random, as we will be creating a radom strong password and store it in the bitwarden.

Now we can go ahead and create project and secret within that.

# Create a project managed by Terraform
resource "bitwarden-secrets_project" "project" {
  name = "MyAwesomeProject"
}

# Create Random Password 
resource "random_password" "password" {
  length           = 16
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

# Create a secret in project managed by Terraform
resource "bitwarden-secrets_secret" "password" {
  key        = "password"
  value      = random_password.password.result
  project_id = bitwarden-secrets_project.project.id
}

Screenshot from the UI:

This way we can leverage the awesome BitWarden to store secrets and share with the team.

Basic Authentication in Nginx with docker-compose

Binaya Sharma — Sun, 22 Jun 2025 10:59:47 +0000

In this tutorial we are going to secure a deployment in which we are exposing application using reverse proxy. We will be using nginx in-front of nextjs application, and authenticating using simple auth. There could be multiple reason we would like it to do such as limiting access to the certain environment (may be development before big release to whole world)

Let us take a trivial docker-compose. I am taking example from the article.

docker-compose.yaml

version: '3.8'
services:
  nextjs:
    build:
      context: .
      dockerfile: Dockerfile.multistage
    container_name: nextjs_app
    ports:
      - "3000:3000"
    restart: unless-stopped

Now we would like to introduce nginx in front of nexjs application. And this will have basic auth mechanism within it.

Now let us generate password (This will be md5 hash). We can use temporary docker to generate htpasswd which later will be used to mount.

$ docker run --rm httpd htpasswd -nb myuser mypassword > htpasswd

Also, let us create a nginx.conf.

user nginx;
worker_processes auto;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    sendfile on;
    keepalive_timeout 65;

    server {
        listen 80;
        server_name localhost;

        location / {
            auth_basic "Restricted Access";
            auth_basic_user_file /etc/nginx/.htpasswd;

            proxy_pass http://nextjs:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root /usr/share/nginx/html;
        }
    }
}

Dockerfile for nginx

FROM nginx:latest

# Remove the default Nginx configuration file
RUN rm /etc/nginx/conf.d/default.conf

# Copy the custom Nginx configuration file
COPY nginx.conf /etc/nginx/nginx.conf

# Copy the htpasswd file
COPY htpasswd /etc/nginx/.htpasswd

# Expose port 80
EXPOSE 80

# Start Nginx when the container launches
CMD ["nginx", "-g", "daemon off;"]

Now the docker-compose will look like

version: '3.8'
services:
  apache:
    build:
      context: . 
      dockerfile: Dockerfile.nginx
    container_name: nginx
    ports:
      - "8181:80"

  nextjs:
    build:
      context: .
      dockerfile: Dockerfile.multistage
    container_name: nextjs_app
    restart: unless-stopped

Now we should be able to see a dialogue box before accessing nextjs application.

How to add additional Users ?

You can simply run the command for creating a new user.

$ docker run --rm httpd htpasswd -nb user2 password >> htpasswd

And re-run docker-compose.

This will append new user.

Migrate Self-Managed add-on to EKS Managed

Binaya Sharma — Wed, 18 Jun 2025 16:32:33 +0000

AWS introduced the concepts of Amazon EKS add-ons to ease the management of cluster add-on with the release of k8s 1.19.

In this particular use-case we had a cluster where add-ons were self managed, meaning installed using helm. There for each cluster upgrades, and new release of add-ons also needs to be upgraded. We were required to go through change-logs, and other pre-requisite so that there are no any breaking changes, and if there were we would need to make sure cluster works fine after the upgrade.

This management overhead could have been easily mitigated if we migrated to the EKS Managed add-ons. In this tutorial we will be migrating add-ons

Amazon VPC CNI
CoreDNS
Kube-Proxy

Verify add-ons status

Firstly we would need to verify which add-ons are configured using managed add-ons. For this use the command

$ aws eks list-addons --cluster-name $CLUSTER_NAME

Output may be different in your case. But in my case aws-efs-csi-driver and aws-guardduty-agent were managed using add-ons. So output was something like

$ aws eks list-addons --cluster-name demo-eks

{
    "addons": [
        "aws-efs-csi-driver",
        "aws-guardduty-agent"
    ]
}

Migrating Amazon VPC CNI Plugin

Amazon VPC CNI is responsible for creating Elastic Network Interface (ENI) and attach them to your worker nodes.

More about VPC CNI

Let’s first see the version configured in cluster and also create a backup of configuration. Backup is required, if in case something goes wrong, we can easily restore.

Version of VPC CNI Plugin

$ kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3

v1.19.5

Verify VPC CNI Plugin is managed manually

$ aws eks describe-addon --cluster-name demo-eks --addon-name vpc-cni --query addon.addonVersion --output text

An error occurred (ResourceNotFoundException) when calling the DescribeAddon operation: No addon: vpc-cni found in cluster: demo-eks

Create a Backup of Configuration

$ kubectl get daemonset aws-node -n kube-system -o yaml > aws-k8s-cni-backup.yaml

Now we have backup, also configured the correct version. Now lets create a IAM role with AmazonEKS_CNI_Policy.

#!/bin/bash

set -euo pipefail

# ==== CONFIGURATION ====
CLUSTER_NAME="your-cluster-name"   # Replace with your EKS cluster name
REGION="your-region"               # Replace with your AWS region (e.g., ap-south-1)
ENV="demo"                          # Environment or suffix
SERVICE_ACCOUNT_NAME="aws-node"
NAMESPACE="kube-system"
ROLE_NAME="AmazonEKSVPCCNIRole-${ENV}"
POLICY_ARN="arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"

# ==== DERIVED VALUES ====
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
OIDC_URL=$(aws eks describe-cluster \
  --name "$CLUSTER_NAME" \
  --region "$REGION" \
  --query "cluster.identity.oidc.issuer" \
  --output text)

OIDC_PROVIDER=$(echo "$OIDC_URL" | sed 's|https://||')
OIDC_PROVIDER_ARN="arn:aws:iam::$ACCOUNT_ID:oidc-provider/$OIDC_PROVIDER"

echo "Creating IAM role for $SERVICE_ACCOUNT_NAME in $NAMESPACE..."
echo "OIDC URL: $OIDC_URL"
echo "OIDC Provider ARN: $OIDC_PROVIDER_ARN"

# ==== CREATE TRUST POLICY JSON ====
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "${OIDC_PROVIDER_ARN}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${OIDC_PROVIDER}:sub": "system:serviceaccount:${NAMESPACE}:${SERVICE_ACCOUNT_NAME}"
        }
      }
    }
  ]
}
EOF

# ==== CREATE IAM ROLE ====
aws iam create-role \
  --role-name "$ROLE_NAME" \
  --assume-role-policy-document file://trust-policy.json

# ==== ATTACH POLICY ====
aws iam attach-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-arn "$POLICY_ARN"

echo "IAM role '$ROLE_NAME' created and policy attached."

# ==== CLEANUP ====
rm trust-policy.json

This also can be done using terraform. Sample terraform code

variable "env" {
  default = "demo"
}

variable "cluster_oidc_provider_arn" {}
variable "cluster_oidc_provider_url" {}

resource "aws_iam_role" "eks_cni_role" {
  name = "AmazonEKSVPCCNIRole-${var.env}"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          Federated = var.cluster_oidc_provider_arn
        },
        Action = "sts:AssumeRoleWithWebIdentity",
        Condition = {
          StringEquals = {
            "${replace(var.cluster_oidc_provider_url, "https://", "")}:sub" = "system:serviceaccount:kube-system:aws-node"
          }
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "cni_policy_attach" {
  role       = aws_iam_role.eks_cni_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
}

Set the cluster_oidc_provider_arn and cluster_oidc_provider_url from your EKS cluster or call from the resource/module block for EKS.

aws eks describe-cluster --name <CLUSTER> --query "cluster.identity.oidc.issuer" --output text
Use the URL as cluster_oidc_provider_url, and the full ARN as cluster_oidc_provider_arn.

Now we would need to create a ServiceAccount with appropriate roles attachments.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: aws-node
  namespace: kube-system
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/AmazonEKSVPCCNIRole-<ENV>

Finally we would need to migrate self-managed addons to EKS managed. Keep in mind keyword here is OVERWRITE.

$ aws eks create-addon \
  --cluster-name $CLUSTER \
  --addon-name vpc-cni \
  --service-account-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/AmazonEKSVPCCNIRole-${ENV} \
  --resolve-conflicts OVERWRITE

Migrating CoreDNS

CoreDNS is a flexible, extensible DNS server that can serve as the Kubernetes cluster DNS.

More about CoreDNS

Let’s first see the version configured in cluster and also create a backup of configuration. Backup is required, if in case something goes wrong, we can easily restore.

$ kubectl describe deployment coredns --namespace kube-system | grep coredns: | cut -d : -f 3

v1.11.4-eksbuild.2

$ kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-backup.yaml

Finally we would need to migrate self-managed addons to EKS managed. Again Keep in mind keyword here is OVERWRITE.

$ aws eks create-addon --cluster-name $CLUSTER --addon-name coredns --resolve-conflicts OVERWRITE

Migrating kube-proxy

The kube-proxy add-on is deployed on each Amazon EC2 node in your Amazon EKS cluster. It maintains network rules on your nodes and enables network communication to your Pods.

More about kube-proxy

Let’s first see the version configured in cluster and also create a backup of configuration. Backup is required, if in case something goes wrong, we can easily restore.

$ kubectl describe daemonset kube-proxy -n kube-system | grep Image
602401143452.dkr.ecr.eu-west-2.amazonaws.com/eks/kube-proxy:v1.32.0-eksbuild.2

$ kubectl get daemonset kube-proxy -n kube-system -o yaml > aws-k8s-kube-proxy-backup.yaml

Finally we would need to migrate self-managed addons to EKS managed. Again Keep in mind keyword here is OVERWRITE.

$ aws eks create-addon --cluster-name $CLUSTER --addon-name kube-proxy --resolve-conflicts OVERWRITE

Verification

Finally you can verify the installation of all addons using the command

$ aws eks list-addons --cluster-name demo-eks

{
    "addons": [
        "coredns",
        "kube-proxy",
        "vpc-cni",
        "aws-efs-csi-driver",
        "aws-guardduty-agent"
    ]
}

Happy Migration ! ! !