DEV Community: Ashutosh Singh

GitHub Actions + AWS Role Chaining: A Security Upgrade Worth Making

Ashutosh Singh — Mon, 22 Dec 2025 23:41:17 +0000

As the year is coming to an end, I’ve been spending some time reflecting and intentionally improving my security knowledge.

Since joining Muzz, I’ve been exposed to systems that operate at scale, multiple AWS accounts, production-critical pipelines, and infrastructure that really cannot afford loose security practices. One of the most valuable things I learned during this journey is AWS role chaining in GitHub Actions.

It’s one of those setups that looks complex at first, but once it clicks, you realise:

“Yeah… this is how CI/CD should work.”

So I thought I’d share what we did, why we did it, and why you should probably do it too.

The Problem with “Simple” AWS Credentials in CI/CD

Traditionally, CI/CD pipelines access AWS by storing credentials like:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

as GitHub Secrets.

This works but it comes with problems:

Long-lived credentials sitting in GitHub
Hard to rotate safely
Over-permissioned “just in case”
No clear trust boundaries between environments
Risk increases as the organisation scales

As teams grow and environments multiply (shared, dev, staging, prod), this approach doesn’t scale securely.

The Modern Answer: GitHub OIDC + IAM Roles

Instead of static secrets, we moved to:

GitHub Actions OpenID Connect (OIDC) (I have already discussed that in my other blog)
IAM Roles with trust policies
Short-lived AWS credentials
Role chaining for environment isolation

This means:

No AWS secrets stored in GitHub
Credentials are issued only when a job runs
Access is tightly scoped and time-limited

What Is AWS Role Chaining?

Role chaining means:

GitHub Actions first assumes a base role (usually in a shared AWS account)
From there, it assumes a target role in another account (dev/prod).
Each hop has explicit trust and permissions.

Think of it like airport security:

GitHub gets through the main gate (shared role)
Then gets escorted to the correct terminal (dev/prod role)
No free roaming, no shortcuts

High Level Diagram

NOTE

Make sure you’re using the official AWS configure-aws-credentials GitHub Action with role chaining enabled (role-chaining: true).

If that approach doesn’t work for your setup, you can always fall back to the good old aws sts assume-role command as a manual alternative.

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT_ID:role/target-role
    role-chaining: true
    aws-region: eu-west-2

aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT_ID:role/target-role \
  --role-session-name github-actions-session

Final Thoughts

Security isn’t something you “add later,” it’s something you design into your workflows from day one.

Working with GitHub Actions and AWS role chaining this year changed how I think about CI/CD security. It showed me that you don’t need to slow teams down to be secure you need better defaults.

As the year wraps up, I’ve been consciously investing more time in understanding why certain security patterns exist, not just how to implement them. AWS role chaining is one of those patterns that quietly improves everything around it, from auditability to confidence in production deployments.

If you’re still using long-lived AWS keys in CI/CD, this is one of the cleanest upgrades you can make.

Hopefully, this helps a few fellow builders ship with a bit more confidence and a lot less risk, and if you have any issues, please comment.

Happy building

AWS Vault Integration

Ashutosh Singh — Fri, 19 Dec 2025 15:05:56 +0000

Securing AWS Access on My Laptop with AWS Vault

Since I joined Muzz, things have been moving fast. Between onboarding, understanding the platform, CI/CD pipelines, Kubernetes, and AWS infrastructure, my days have been pretty packed.

But with that pace, I’ve also picked up a few really nice practices, and one of them is AWS Vault.

Before this, like many others, I had AWS credentials sitting locally in ~/.aws/credentials. It works, but let’s be honest, it’s not ideal from a security point of view.

That’s where AWS Vault comes in.

What Is AWS Vault?

AWS Vault is an open-source tool that helps you securely store and access AWS credentials on your laptop.

Instead of keeping long-lived AWS access keys in plain text files, AWS Vault:

Stores credentials securely in your OS keychain

macOS → Keychain
Windows → Credential Manager
Linux → Secret Service

Generates temporary credentials using AWS STS

Prompts you for a password / OS unlock whenever you want to access AWS

Works seamlessly with AWS CLI, SDKs, and even the AWS Console

In simple terms:

You no longer store secrets locally instead, you unlock access only when needed.

Why This Matters (And Why We Use It)

At Muzz, security is taken seriously, and AWS Vault fits perfectly into that mindset.

Here’s why it’s a big improvement over traditional setups:

No plain-text access keys lying around

The OS encrypts credentials
Uses short-lived credentials instead of permanent ones
Works nicely with IAM roles and MFA
Forces a conscious “unlock” step before AWS access

Every time I want to access AWS resources, AWS Vault asks for my password, which is a great trade-off for better security.

Installing AWS Vault

macOS
brew install --cask aws-vault
Windows
choco install aws-vault
Linux
Download the binary from GitHub or install via Homebrew for Linux.

Verify installation:

aws-vault --version

Adding AWS Credentials Securely

To add credentials:

aws-vault add

You’ll be asked for:

AWS Access Key ID
AWS Secret Access Key

Once added:

They are encrypted
They are not stored in plain text
They’re only used to generate temporary session credentials

Using AWS Vault Day-to-Day
Run a Single AWS Command
aws-vault exec muzz -- aws s3 ls
OR

Just try to connect to EKS, or any AWS resources, and it will prompt you for the password

CONCLUSION

AWS Vault handles all of this quietly in the background, which makes it great for both security and developer experience.

What I Like Most About AWS Vault

Honestly, the best part is the mental shift it enforces:

“You don’t own AWS credentials, you borrow them temporarily.”

If you’re working with AWS regularly, especially on a laptop, AWS Vault is a must-have tool.

Real Monitoring Metrics

Ashutosh Singh — Wed, 04 Dec 2024 21:36:04 +0000

Monitoring

If you're starting in DevOps or have some experience but haven't had any actions in Monitoring, Logging or Alerts. This will help you with Monitoring( alerts a little bit) at least.

Without Monitoring, any application crumbles under its sheer vastness. Any application needs constant care, otherwise, things go haywire or just stop working altogether. Monitoring helps us detect incidents, events and evaluate system metrics. Actually, by monitoring system metrics, we detect incidents, events, etc. Monitoring can be done for various purposes like making sure the site is always healthy and servicing customers and bringing in revenue, or it can be done to detect any intrusion or threat whatever the reason, monitoring is important with the end goal of keeping the application/site always healthy.

Since I'm a DevOps Guy, I'm not going into security but rather monitoring to keep the application healthy, so let's start.

Prerequisite: AWS account, Helm

Google

suggest these 4 Major Signals or Golden Signals that we need to monitor all the time as they give critical data about the application.

1. Latency

The Duration required by the packet to reach the server and get back to us.

2. Traffic

Simply speaking the number of requests per second received by the server.

3. Errors

As the name suggests, the number of errors can be 4xx/5xx or timeout request, any request that took longer time to respond (more than set in SLOs)

4. Saturation

In layman's terms how full the system is. Any resource which is close to 100% utilization. Used to monitor the most constraints or limited resources in a system like CPU, Disk Space, Bandwidth etc.

Again these are very short explanations if you wanna read more about them click here.

Now let's talk about Tooling. I've been using Prometheus and Grafana as my go-to tools for monitoring.

So let's start with the hands-on.

STEP I

I'm doing this on AWS, specifically speaking EKS. Create the cluster using eksctl, I like eksctl as it creates everything from VPC to node group, with minimal inputs, you can find you're suitable setting here.

But here's mine:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: eu-west-2 # Replace with your preferred AWS region
  version: "1.30" # Replace with your desired Kubernetes version

managedNodeGroups:
  - name: ng-t2-medium
    instanceType: t3a.medium
    desiredCapacity: 2
    minSize: 2
    maxSize: 2
    volumeSize: 20 # Size in GiB
    privateNetworking: true # If you want nodes to use private subnets only
    ssh:
      enableSsm: true # Allows access via AWS Systems Manager Session Manager

Nothing complicated just 2 instances and that's all, remember to update the add-ons installed by eksctl.

STEP II

Now that we have our eksctl get remember to get the kubeconfig file in you're workstation by using the command:

aws eks update-kubeconfig --region <region-code> --name <cluster-name>

Now Let's use helm charts for kube-Prometheus stack install it and wait for the startup

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install <Name> prometheus-community/kube-prometheus-stack -n <namespace>

STEP III

Now that we have installed Prometheus and Grafana, Let's create an application that we gonna monitor.

I'm using a very simple nodejs application

const express = require("express");
const client = require("prom-client");
const winston = require("winston");
const os = require("os");

const app = express();
const PORT = 3000;

// Initialize Prometheus metrics
const httpRequestDuration = new client.Histogram({
  name: "http_request_duration_seconds",
  help: "Duration of HTTP requests in seconds",
  labelNames: ["method", "route", "status_code"],
  buckets: [0.1, 0.5, 1, 2, 5], // Buckets for latency
});

const httpRequestCount = new client.Counter({
  name: "http_requests_total",
  help: "Total number of HTTP requests",
  labelNames: ["method", "route"],
});

const httpErrorCount = new client.Counter({
  name: "http_errors_total",
  help: "Total number of HTTP errors",
  labelNames: ["method", "status_code"],
});

const systemMetrics = new client.Gauge({
  name: "system_resource_usage",
  help: "System CPU and memory usage",
  labelNames: ["resource"],
});

// Logger setup
const logger = winston.createLogger({
  level: "info",
  format: winston.format.json(),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: "app.log" }),
  ],
});

// Middleware to track request duration and traffic
app.use((req, res, next) => {
  const start = Date.now();
  httpRequestCount.inc({ method: req.method, route: req.path });
  res.on("finish", () => {
    const duration = (Date.now() - start) / 1000; // Convert to seconds
    httpRequestDuration.observe(
      { method: req.method, route: req.path, status_code: res.statusCode },
      duration
    );

    if (res.statusCode >= 400) {
      httpErrorCount.inc({ method: req.method, status_code: res.statusCode });
    }
  });
  next();
});

// Simple endpoints
app.get("/", (req, res) => {
  res.send("Welcome to the Golden Signals App!");
});

app.get("/hello", (req, res) => {
  setTimeout(() => {
    res.send("Hello, World!");
  }, Math.random() * 1000); // Random delay to simulate latency
});

app.get("/error", (req, res) => {
  res.status(500).send("Simulated error!");
});

// Expose metrics at /metrics
app.get("/metrics", async (req, res) => {
  res.set("Content-Type", client.register.contentType);
  res.end(await client.register.metrics());
});

// Monitor system resources every 5 seconds
setInterval(() => {
  const memoryUsage = process.memoryUsage().heapUsed / 1024 / 1024; // Convert to MB
  const cpuLoad = os.loadavg()[0]; // 1-minute average
  systemMetrics.set({ resource: "memory" }, memoryUsage);
  systemMetrics.set({ resource: "cpu" }, cpuLoad);

  logger.info({
    memoryUsage: `${memoryUsage.toFixed(2)} MB`,
    cpuLoad: cpuLoad.toFixed(2),
  });
}, 5000);

// Start server
app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

Dockerfile for the same

# Use the official Node.js image from the Docker Hub
FROM node:21-alpine

# Create and change to the app directory
WORKDIR /usr/src/app

# Copy application dependency manifests to the container image.
# A wildcard is used to ensure both package.json AND package-lock.json are copied.
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the local code to the container image
COPY . .

# Expose the port the app runs on
EXPOSE 3000

# Run the application
CMD ["node", "app.js"]

Now deployment, service and service monitor file for K8s

apiVersion: apps/v1
kind: Deployment
metadata:
  name: golden-signals-app
  labels:
    app: golden-signals-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: golden-signals-app
  template:
    metadata:
      labels:
        app: golden-signals-app
    spec:
      containers:
        - name: golden-signals-app
          image: ashutosh5786/golden-signal-app:v1
          ports:
            - containerPort: 3000
          resources:
            limits:
              memory: "256Mi"
              cpu: "500m"
            requests:
              memory: "128Mi"
              cpu: "250m"
          env:
            - name: NODE_ENV
              value: "production"
---
apiVersion: v1
kind: Service
metadata:
  name: golden-signals-service
  labels:
    app: golden-signals-app
spec:
  ports:
    - name: metrics-port             # Port name, used in ServiceMonitor
      port: 3000                     # Exposed port
      targetPort: 3000               # Port on the container
  selector:
    app: golden-signals-app
  type: ClusterIP
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: golden-signals-app-monitor
  labels:
    release: kubeprometheus <Name of the release used when installing using helm chart>
spec:
  selector:
    matchLabels:
      app: golden-signals-app
  endpoints:
    - port: metrics-port # Use the port name from the Service
      path: /metrics
      interval: 15s
  namespaceSelector:
    matchNames:
      - default <Namespace in which app is deployed>

At this point, I take that you understand what deployment and service are but you might have noticed the Service Monitor well it's a way for us to configure the Prometheus to monitor the pods we are creating.

STEP IV

After STEP III, we can head to Prometheus-ui, to check if the application is monitored or not. Go to Status > Target
If you see the application good otherwise go back and recheck everything.

It should look something like this:

After confirming that Prometheus is scrapping the data, let's move to Grafana. And create the Dashboard which is my favourite part.

STEP V

Let's start creating those dashboards.

Side Panel > Dashboard > Add Visualization
Select Prometheus as Data Source

Once You've done this Select the CODE Option instead of the Builder

As you can observe in the above screen.

Starting with Saturation for my case I have used the CPU as my constraint so I'm using below query to visualize it.

rate(container_cpu_usage_seconds_total{container="golden-signals-app"}[1m])

Now I'm gonna give all the query I used to build my dashboard for the Golden Signals

Latency (P95)
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
For more grain visualization we can have different queries but for the ease of this practical, I'm going with the easier option.

Error Rate
sum(rate(http_errors_total[1m])) by (status_code)

Traffic (RPS)
sum(rate(http_requests_total[1m]))

After Adding all those queries it should look like this

Now we are all ready to monitor those Golden Signals to make sure our applications are always healthy and 100% running.

CONCLUSION

Monitoring is essential to keeping your applications healthy and reliable. By tracking Golden Signals with Prometheus and Grafana, you can catch issues early and ensure smooth operations. This guide gives you a starting point to build a monitoring setup that grows with your application’s needs.

Thank you for Reading, I'd love to know what you have set up for monitoring in your system, If I missed anything please mention it in the comments.

Building Secure CI/CD with Terraform on AWS

Ashutosh Singh — Fri, 22 Nov 2024 13:46:00 +0000

Recently, I was interviewed for a DevOps role, and I was asked, "Do you use Terraform in CI/CD?" I said yes. How do you use Terraform in CI/CD? Put the AWS credentials in the GitHub secret and use it with the aws-cli tool to provision the infrastructure. Sadly, I didn't get the job, but I was compelled to explore a new way, so here I am sharing what I found.

Prerequisite: AWS & GitHub Account, Terraform

Let me tell you more about the question, he wanted to know how I handle the permission as this is the most important thing in DevOps, the answer I gave was alright, but it turns out we have more security in doing the same task, by letting the GitHub action or any other CI/CD tool to assume the role from AWS directly without us storing the aws secret or access key in the vault of our CI/CD tools. Instead, we can provision the dynamic credentials by using the AWS sts assume role & OIDC.

STEP I
To tackle this challenge securely and efficiently, the first step is to establish trust between AWS and GitHub Actions by setting up an OIDC provider. Let’s dive into how to do that. If you want to read more about OIDC click here.

Click on the Add Provider

Enter these details

OIDC provider: https://token.actions.githubusercontent.com
Audience: sts.amazonaws.com

Now that we have established the OIDC trust between AWS and GitHub, the next step is to create an IAM role with a custom trust policy. This role will allow GitHub Actions to assume the required permissions dynamically.

STEP II

Let's Create the IAM role using a custom trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:your-username/your-repo:ref:refs/heads/branch-name"
        }
      }
    }
  ]
}

NOTE: Kindly Replace these placeholders

<your-username> with your GitHub username.
<your-repo> with your repository's name.
<branch-name> with the branch name (e.g., main or master)

After Replacing those placeholders, let's add the permission for the services this role will allow the GitHub action to provision, for simplicity I'm giving it PowerUser permission but again change them according to needs.

STEP III

With the IAM role in place, it’s time to configure our GitHub Actions workflow. Here, we’ll set up a YAML file to interact with AWS services using the dynamic credentials generated by the assumed role

name: Deploy to AWS

on:
  push:
    branches:
      - master

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      # Step 1: Checkout code
      - name: Checkout repository
        uses: actions/checkout@v3

      # Step 2: Configure AWS credentials using OIDC
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ secrets.AWS_REGION }}

      # Step 3: Example AWS command (S3 upload in this case)
      - name: Upload files to S3
        run: |
          aws s3 cp ./12.png s3://${{ secrets.S3_BUCKET_NAME }}/

      # Step 4: (Optional) Additional AWS CLI commands or deployment steps
      - name: Example additional AWS command
        run: |
          aws ec2 describe-instances

There are a couple of things which you need to understand

permission block contains 2 fields id-token and content. By id-token we are setting OIDC to be used, by using content: read we are allowing the workflow to read the repo files. Rest is simple

After the setup is completed here are my workflow screenshots

The bucket containing the uploaded file from the repo

GitHub Action Logs

At this point, your GitHub Actions pipeline is securely configured to interact with AWS services. Next, we’ll integrate Terraform into the pipeline to demonstrate how to provision infrastructure dynamically.

STEP IV

Now the last leg Running the CI/CD with Terraform For that we need to write the Terraform script and modify the action yml file.

workflow.yml file

name: Terraform EC2 Provisioning

on:
  push:
    branches:
      - master

permissions:
  id-token: write
  contents: read

jobs:
  terraform:
    runs-on: ubuntu-latest

    steps:
      # Step 1: Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v3

      # Step 2: Configure AWS credentials using OIDC
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ secrets.AWS_REGION }}

      # Step 3: Set up Terraform CLI
      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.5.0

      # Step 4: Initialize Terraform
      - name: Terraform Init
        run: terraform init

      # Step 5: Plan Terraform changes
      - name: Terraform Plan
        run: terraform plan -out=tfplan

      # Step 6: Apply Terraform changes
      - name: Terraform Apply
        run: terraform apply -auto-approve tfplan

Now some Terraform scripts

main.tf

provider "aws" {
  region = var.region
}

resource "aws_instance" "example" {
  ami           = var.ami_id
  instance_type = var.instance_type

  tags = {
    Name = "ExampleInstance"
  }
}

output "instance_id" {
  value = aws_instance.example.id
}

output "public_ip" {
  value = aws_instance.example.public_ip
}

terraform.tfvars

region        = "eu-west-2"
ami_id        = "ami-0b2ed2e3df8cf9080" # Replace with your preferred AMI ID
instance_type = "t2.micro"

variables.tf

variable "region" {
  description = "AWS region"
  type        = string
  default     = "eu-west-2"
}

variable "ami_id" {
  description = "AMI ID for the EC2 instance"
  type        = string
}

variable "instance_type" {
  description = "Instance type for the EC2 instance"
  type        = string
  default     = "t2.micro"
}

With these Terraform scripts in place, the pipeline can now provision an EC2 instance as part of the CI/CD process. Let’s run the workflow and see the results in action.

Checking the Github Logs

And my friend, now you know how to configure the pipeline without using the static credentials stored in GitHub Secrets.

Now that everything is set up, we can observe the results of our secure and dynamic CI/CD pipeline in GitHub Actions logs and AWS resources. This demonstrates the power of OIDC integration in real-world DevOps workflows.

Conclusion

By integrating OIDC (OpenID Connect) with AWS and GitHub Actions, we enhance security and simplify the CI/CD process. Instead of relying on static credentials stored in GitHub secrets, we use dynamically generated, short-lived credentials through AWS STS.

This approach offers several key benefits:

Improved Security: No sensitive credentials are stored in CI/CD tools, reducing the risk of accidental exposure or misuse.
Granular Access Control: Using IAM trust policies, access can be tightly scoped to specific repositories, branches, and workflows.
Automation-Friendly: Dynamic credentials streamline workflows, making them more robust and easier to maintain.
Reduced Attack Surface: Temporary credentials expire quickly, minimizing the impact of potential leaks.

Thank you for Reading if you face any issues feel free to ask in the comments

AWS Lambda Layer

Ashutosh Singh — Sun, 16 Jun 2024 14:18:31 +0000

This is something I was stuck on while deploying the lambda function, even though the code was only a few 100 lines I had to deploy the function with a zip file including all the node dependencies unnecessarily, it was quite annoying and I'm having this feeling you felt the same way that why you landed over here.

Let's get started...

This is quite simple, it is made just for the problem I've discussed above i.e. Take away the dependencies and focus on code.

Official Definitions:
A Lambda layer is a .zip file archive that contains supplementary code or data. Layers usually contain library dependencies, a custom runtime, or configuration files.
If you are interested in reading more about it here's the link.

We can start using it now that we know what the lambda layer is.

STEP I
Search lambda in the service list and go to the layer on the left side.

STEP II
Now we gonna create a package that we'll upload in layers

NOTICE: The path of the folders is important you can't mess this up otherwise it won't work. Different runtimes have different path like Im using node

My folder structure is like this

/layers
|------- /nodejs
            |----- /node_modules
            |----- package.json
            |----- package-lock.json

If you wanna check out other runtime paths I suggest you should check the table given here

Make sure any modules you're adding are executable in Linux as lambda layers are executed in Amazon-Linux(Linux).

Now Zip the folder layers.zip or anything you wanna name it.

STEP III
Head towards the lambda page. Now we will upload the zip to lambda layers by creating a new layer.

Name the layer anything you want.
Don't forget to add the other details like architecture and runtime these 2 are the most important.

After you're done click on Create and done

Now you can attach this layer to any of your lambda functions and just call the package as you write normally. You don't have to do anything to integrate it. Enjoy the freedom of writing the code on the browser or make any changes to it on the go without worrying about the package or zipping it.

Thank you

GitHub Action with EC2 and SSH

Ashutosh Singh — Sat, 03 Feb 2024 19:11:13 +0000

Sometimes we are stuck with a use case which is not very efficient
but are essentials for the pipeline or CI/CD there are so many reasons why this could arise, cost, time & effort, it's not production we can do whatever we want!!

Here's How

you can connect any virtual machine whether it's deployed on AWS, Azure or GCP they all have something in common,
SSH either password or .pem file this method will work just fine.
I know this is not what we as a DevOps Guy prefer but you have to make something out of this situation you're stuck, right !!

For this, I'm gonna use GitHub Action, SSH DEPLOY action and AWS(I mean why not).

STEP I

Setup your authentication for my case ACCESS KEY & SECRET KEY
Add them to GitHub Secret

Password is the .pem key for the instances we gonna deploy the application.

NOTICE: After this setup the HOST, USERNAME, and PORT(if you have changed ur default SSH port) in the variable section

Here's the GitHub Action



name: Deployment to server
on:
    workflow_run:
        workflows: ["Docker Image CI"]
        types: 
            - completed
jobs:

  Deploy:
    name: Deploy
    runs-on: ubuntu-latest
    if: github.event.workflow_run.conclusion == 'success'

    steps:
        - uses: easingthemes/ssh-deploy@v5.0.0
          name: Deploy over SSH
          with:
            SSH_PRIVATE_KEY: ${{ secrets.PASSWORD }}
            REMOTE_HOST: ${{ vars.HOST }}
            REMOTE_USER: ${{ vars.USERNAME }}
            SCRIPT_AFTER: |
                ./script
                // PUT THE COMMANDS HERE

And Voila!! here you go I like this GitHub action due to its simplicity and ease of use with private keys.

Thank you for reading.
Feel free to reach out for any suggestions.

AWS ALB with NGINX INGRESS CONTROLLER

Ashutosh Singh — Mon, 01 May 2023 08:17:50 +0000

So if you are wondering how to integrate the AWS application load balancer with Nginx/Istio to get the traffic into the cluster so this is it.

You might ask why this article so let me tell you what I'm looking for when I say aws alb/nlb and ingress controller.

I know there are bunch of components missing but you got the idea right!! only 1 ALB/NLB unless u have some other use case where you need bunch of LB

LB: LoadBalancer; A: Application; N: Network
just to avoid any confusions.

Before moving forward let's discuss why this setup

Before

If you know Kubernetes(K8s) you know they support 3 type of networking, build natively we called them service

ClusterIP
NodePort
LoadBalancer

you can read more about them from K8s official docs
We are not interested in above 2 only LoadBalancer so what it does is that when you are using cloud services in our case EKS we can directly provision a loadbalancer for our services to ingress the traffic.
But the problem with this is how many LB we can create until we ran out of money coz we use many services and according to this there's going to be a lot of LB.

So you get the problem right we can't create LB everytime we need to let the traffic inside, so the great guys at K8s decided we need something and they came up with INGRESS the whole idea was to save cost and reduce management this is what I think 😁 coz it sure does for me!

AFTER

Moving on we can create the setup which showed in the starting only 1 LB is sufficient for K8s cluster we don't need to create different LB for different Services.

PROCESS

There are 4 stage in this from creating the cluster to deploying the application and then opening it in browser.

STAGE I

Spin Up the EKS cluster, you can do it from the aws console, cli. I love cli and there's a best tool to do this eksctl
Setup this tool you need aws cli configure plus you must have the permissions.

eksctl create cluster -f cluster.yaml



apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: DevOps-Prod
  region: ap-south-1
  version: "1.26"
managedNodeGroups:
  - name: ng-1
    instanceType: m5.large
    desiredCapacity: 2
    volumeSize: 80
    labels: { role: workers }

Give it 15mins or so it will complete the creation and the cluster will be up then

STAGE II

Now we'll install something called AWS LoadBalancer Controller.
I'm not going into details coz AWS blogs are great you just need to follow them here's the link
TIP: I prefer the eksctl

STAGE III

Make sure the pods are running by running the command
kubectl get po -n kube-system
If your namespace is kube-system

Now we need to install the Nginx Ingress Controller again not going into deep here's the link

So we need to do some changes over here to achieve our noble goal of having 1 LB
TIP: Install it with Helm
make sure you change the service type of chart from LoadBalancer to NodePort.
You find it in the values.yaml or if you're using manifest file the look for the service block just make sure you do this.

NOTICE: It's important that you do this otherwise it won't work

Now after successfully deploying this you need to check which NodePort is being utilized it's mostly in above 3000 make sure you wrote it down somewhere.
And check the readiness-probe for the deployment of nginx controller



readinessProbe:
failureThreshold: 30
httpGet:
path: /healthz

something like this check it for yourself and now we are going to last phase.

STAGE IV

After everything is deployed and you have the NodePort and Path of the health-check you going to apply the below file.

You also need the certificate imported in a service called ACM
Amazon Certificate Manager from which you will get the arn of that certificate which you need to update in the file



apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress-connect-nginx
  namespace: kube-system
  annotations:
    # Ingress Core Settings
    kubernetes.io/ingress.class: "alb"
    alb.ingress.kubernetes.io/scheme: internet-facing
    # Health Check Settings
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/healthcheck-port: 30000 # Make sure you add the NodePort over here
    alb.ingress.kubernetes.io/healthcheck-path: /healthz # Put the path of readiness probe over here
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'
    alb.ingress.kubernetes.io/success-codes: '200'
    alb.ingress.kubernetes.io/healthy-threshold-count: '2'
    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'
    ## SSL Settings
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-west-2:122221113322:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # make sure you update your certificate arn over here
    #alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-1-2017-01 #Optional (Picks default if not used)
    # redirect all HTTP to HTTPS
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
spec:
  rules:
  - http:
      paths:
        - path: /*
          pathType: ImplementationSpecific
          backend:
            service:
              name: ssl-redirect
              port:
                name: use-annotation
        - path: /*
          pathType: ImplementationSpecific
          backend:
            service:
              name: ingress-nginx-controller # Make sure you name the service correctly by checking the name of it nginx ingress controller service nothing else
              port:
                number: 80

If you open the above file in vscode or text-editor you'll find the comment that I wrote for you guys where you need to supply the NodePort and Health-check path and name of the service of ingress controller, arn of the certificate after doing all the changes apply with following

kubectl apply -f ingress.yaml

After running this command you'll see that there's a ALB is provisioning and target group is created to check the instance health check once it's checked and alb is fully provisioned you can hit the url of the alb see the 404 NOT FOUND from nginx
and this confirm that response is coming from nginx.

ENDING

You can deploy the application and expose the service with ingress and try to hit the url mentioned in the ingress file before this you need to update the records too if using ROUTE53 or any other domain registrar and that's it

CONCLUSION

I hope this works for you if not plz reach out to me I'm happy to help make sure the to update the values which I commented and it will work for you.

AWS XRAY with FASTAPI

Ashutosh Singh — Wed, 12 Apr 2023 05:09:26 +0000

Hi Guys, I think you stumble upon the article after a very long search of

How to integrate AWS Xray with application written with FASTAPI python?

So you are not alone I have searched for a very long time and this is what I found which works for me, there are something which I don't understand it's just there😅.

First, let's take a quick look at what AWS X-Ray is. AWS X-Ray is a distributed tracing system that allows you to visualize the entire lifecycle of a request across all of your microservices. With X-Ray, you can quickly identify performance bottlenecks, troubleshoot errors, and understand the dependencies between your services.
If You wanna read more about aws xray here the link

Let's Start.

First you need to know where you are going to deploy the application EC2, EBS, or EKS. I have deployed it on EKS so I'll use that over here, but all of them will work with little bit of changes.

Installation of ADOT Collector

For those who are wondering what's this? AWS Distro for OpenTelemetry, and for those who were thinking that they can get away without installing it you were wrong as I am🥲, I thought it too but can't so here the link you can follow to install it for EKS.

After you have decided and installed the collector with your prefer way of installing (I prefer Daemonset) remember the service name we have to mention it in application.

Integration

There are some python packages that you need to install

opentelemetry-distro==0.36b0
opentelemetry-exporter-otlp==1.15.0
opentelemetry-exporter-otlp-proto-grpc==1.15.0
opentelemetry-exporter-otlp-proto-http==1.15.0
opentelemetry-instrumentation==0.36b0
opentelemetry-instrumentation-asgi==0.36b0
opentelemetry-instrumentation-aws-lambda==0.36b0
opentelemetry-instrumentation-boto3sqs==0.36b0
opentelemetry-instrumentation-botocore==0.36b0
opentelemetry-instrumentation-dbapi==0.36b0
opentelemetry-instrumentation-fastapi==0.36b0
opentelemetry-instrumentation-grpc==0.36b0
opentelemetry-instrumentation-logging==0.36b0
opentelemetry-instrumentation-pymongo==0.36b0
opentelemetry-instrumentation-requests==0.36b0
opentelemetry-instrumentation-sqlalchemy==0.36b0
opentelemetry-instrumentation-sqlite3==0.36b0
opentelemetry-instrumentation-starlette==0.36b0
opentelemetry-instrumentation-urllib==0.36b0
opentelemetry-instrumentation-urllib3==0.36b0
opentelemetry-instrumentation-wsgi==0.36b0
opentelemetry-propagator-aws-xray==1.0.1
opentelemetry-proto==1.15.0
opentelemetry-sdk==1.15.0
opentelemetry-sdk-extension-aws==2.0.1
opentelemetry-semantic-conventions==0.36b0
opentelemetry-util-http==0.36b0

I know it's never ending list trust me, but without these my application wasn't even starting so I don't know about these but it works I hope it works for you too.

Main Code

# OpenTelemetry Configuration
# Basic packages for your application
# Add imports for OTel components into the application
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor


# Import the AWS X-Ray for OTel Python IDs Generator into the application.
from opentelemetry.sdk.extension.aws.trace import AwsXRayIdGenerator

# Sends generated traces in the OTLP format to an ADOT Collector running on port 4317
otlp_exporter = OTLPSpanExporter(endpoint="http://xray-collector-collector.amazon-cloudwatch:4317")
# Processes traces in batches as opposed to immediately one after the other
span_processor = BatchSpanProcessor(otlp_exporter)
# Configures the Global Tracer Provider
trace.set_tracer_provider(TracerProvider(active_span_processor=span_processor, id_generator=AwsXRayIdGenerator()))



# Using the AWS resource Detectors
import opentelemetry.trace as trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.extension.aws.resource.ec2 import (
    AwsEc2ResourceDetector,
)
from opentelemetry.sdk.resources import get_aggregated_resources

trace.set_tracer_provider(
    TracerProvider(
        resource=get_aggregated_resources(
            [
                AwsEc2ResourceDetector(),
            ]
        ),
    )
)

app = FastAPI()

@app.get("/test")
def test():
    return {"message": "Hello This is testing"}

You might be thinking why I copy pasted the whole code, it's coz when I was searching I couldn't make any sense of the code so I thought why not just pour it all.

Make sure you set your own endpoint url in the otlp_exporter
otherwise it won't send any traces.

Dockerfile

# Pull base image
FROM python:3.8

# Set enviroment variables
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV PYTHONPATH=/code
ENV VIRTUAL_ENV=/opt/venv
RUN python3 -m venv $VIRTUAL_ENV
ENV PATH="$VIRTUAL_ENV/bin:$PATH"


# Added OpenTelemetry Collector attributes

ENV OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_REQUEST=".*"
ENV OTEL_RESOURCE_ATTRIBUTES='service.name=aws-xray-test'


# Set work directory
WORKDIR /code

# Install dependencies
COPY requirements.txt /code/

RUN pip install -r requirements.txt  --no-cache-dir

# Copy project
COPY . /code/

ENTRYPOINT ["opentelemetry-instrument","/opt/venv/bin/python", "-m", "uvicorn", "main:app"]
CMD ["--reload", "--host", "0.0.0.0", "--port", "8000"]

NOTE: see the Entrypoint and the ENV make sure you set them

And My Wonderful reader if you made it till here than I hope your Integration is successful

Conclusion

In conclusion, integrating AWS X-Ray with your FastAPI application is a simple and effective way to gain visibility into the performance and behavior of your application. With X-Ray, you can quickly identify performance bottlenecks, troubleshoot errors, and understand the dependencies between your services. So why not give it a try today?

Plus If you face any issue with above steps plz reach out to me
here's my linkedin

FREE VPN with AWS

Ashutosh Singh — Tue, 27 Sep 2022 07:00:58 +0000

So,

You Want a Free VPN for securing you're connection, you don't want the third party to sneak up behind you and see or steal your data, you are not alone, we all want that, easy way buy a premium vpn there are tons of out there, but we they are paid, so lets have our own VPN.

Without Further Delay lets get started,

PREQUISTE

AWS ACCOUNT
LITTLE BIT OF LINUX

We are going to use the service name LightSail in here, you ask why? Well, first we can run the sever for free (3 Months) if you are well-passed you're free tier of AWS.

Lets go to LightSail Console

Let's create the Instance

We can use any OS amazon-linux-2, ubuntu we just needs to know the package name for the same, here I'm going with ubuntu:20.04LTS

Choose the Plan According to you're needs and select it

While waiting for the instance to provision for you lets go to Network tab and create a static-IP for our VPN

Name the IP with anything, choose the Instance in which you want to attach the static-IP

Let's connect to the instance with SSH, LightSail give us web-based ssh and terminal based, for terminal based we need the key, Download the Default key from here

and lets start executing some linux commands.

PART II

Start the SSH connection



ssh ubuntu@<IP> -i <path-to-key>

Install the Wireguard



sudo -i
apt update 
apt install wireguard -y

After Installing it, we need to enable the port forwarding so that after connecting to instance we can still use the internet freely
run the following command to do so



vim /etc/sysctl.d/10-wireguard.conf

and add the following line



net.ipv4.ip_forward=1

After adding the line execute the following command to make it permanent



sysctl -p /etc/sysctl.d/10-wireguard.conf

After enabling the Port Forwarding lets move to the Wireguard directory



cd /etc/wireguard

NOTICE: Important We are generating key for the server make sure that you don't share any private key from here.

Execute the following commands



wg genkey | tee server.key | wg pubkey > server.pub

wg & wg-quick is command-line tool for interacting with Wireguard.
We will be using these file in our next step.

Now Let's create the configuration file,

for our VPN here whatever you want to name the configuration file you can name it and it will create a interface with the same name
but it must contain the .conf



vim vpn.conf

Add these line into it



[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = <server.key>
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Make sure you add the server.key content here the file we created earlier

Let's Enable the VPN

run the following command to start it



systemctl enable --now wg-quick@vpn

Verify it's running successfully



systemctl status wg-quick@vpn

PART III

So our VPN Server is now running but we need to give the access to user, for that we need to generate some more files using the wg but I love the GUI so after doing some digging I found this amazing dashboard thanks to the author I can do everything from Dashboard only

Install the Dashboard

Here the github link
let's clone the repo



git clone -b v3.0.6 https://github.com/donaldzou/WGDashboard.git wgdashboard

change the directory & execute some commands



cd wgdashboard/src
chmod u+x wgd.sh
./wgd.sh install
chmod -R 755 /etc/wireguard
apt install python3-pip -y
pip3 install -r requirements.txt
./wgd.sh start

Make Sure the port 10086 being used by running



netstat -tnlp

And we are done here

Back to LightSail

Let Open these port
51820 UDP
10086 TCP
By going into the networking tab

PART IV

We are in the ENDGAME

Open the Dashboard by going to
public-ip-of-instance:10086
In my case http://3.111.147.192:10086/

Default Creds
username: admin password: admin
After logging in

Go to the Setting Page

change the
Peer Remote Endpoint (This will be change globally, and will be apply to all peer's QR code and configuration file.)
From anything like this

to You're Public IP of the Instance in my case 3.111.147.192

And then Go to the Configuration Page

Click on the Blue Add Button on the Lower Right
Add the Username and Download the File by clicking on the small green button.

Go to WireGuard Client And add the tunnel by importing the downloaded file and click
ACTIVATE

If Everything is right you will be connected to the VPN check your IP to verify it.

That's How We can have our own VPN

If any question plz feel free to ask in the comments

KeyCloak with Nginx Ingress

Ashutosh Singh — Sun, 07 Aug 2022 16:21:00 +0000

Hello there, If you came here I guess you are also tired of finding the solution to Deploy KeyCloak with Ingress(Nginx) in Kubernetes (K8s), I have faced the some issue that are not available very openly, so I'm here to make sure you didn't go through the pain I have gone through 😅 so let's start.

Perquisite

Kubernetes Cluster(can create with KOps), Ingress Controller (Nginx)

Step I

Select Which chart you want to use, there are 2 helm chart

Bitnami KeyCloak
Codecentric KeyCloak

Feel Free to Use anyone of these you can just google them or click on the link provided above. For this Example we'll use the Bitnami KeyCloak, personally I think it's easier to deploy with this chart.

Step II

So I guess you decided to use the Bitnami Chart too, so there are few thing you need to take care otherwise the deployment will fail.

NOTICE

Make sure you have set the password for the external database by passing into values.yaml

externalDatabase.password

postgresql.auth.password

These 2 field should have same value otherwise you'll run into postgres error and pod will go crashback-loop
And Since we are using Nginx as Ingress-Controller we are going to to enable the ingress

ingress.enabled

ingress.hostname

ingress.pathType

I hope you are finding these value in values.yaml and overwriting them, now most Important thing since we are using Application Load Balancer in our case (I'll attach the link how to do that too soon.)
I have configure it in such a way that Before ALB all traffic is in HTTPS and from there in HTTP if you have the same case
make sure you have done this change.

proxy: edge

And You can configure the username and its password as well I hope you'll find the values.

Now You can deploy the helm chart with updated values and the wait for few seconds as it will take some time grab a water bottle for yourself 🍾.

STEP III

Confirmation that it's running successfully try the kube-proxy command to proxy the port to you're local system and see if it's running if yes then we can move forward, if not 🥺 plz check the configuration that you have made or feel free to ask in comments.

STEP IV

If you have done this step while setting up the ingress it's well and good but if not you are like me😊.

KeyCloak needs some headers to work behind proxy as it's mentioned here

We need to configure our Nginx Ingress Controller to pass the headers so after digging for 5 Days I found this,
We need to create a configmap which contains the following data

kind: ConfigMap apiVersion: v1 metadata: name: <chart-name-with-which-deployed>-nginx-ingress-controller namespace: <namespace-in-which-deployed-nginx-ingress-controller> data: use-forwarded-headers: "true" forwarded-for-header: "X-Forwarded-For"

and make sure the name is correct otherwise it will not work, to verify it's working see the logs of the pod

nginx-controller-nginx-ingress-controller

You'll see something like

Found the configmap needed to reload backend, reload complete

not exactly but something like this and you're done

Now go to your hostname that associated with keycloak you'll be able to access the admin-panel without issue.

Let's Discuss the Error if These Steps are not Completed

First if you didn't set the password whenever you'll upgrade the helm chart you'll loose the connection with postgres as the by default password is randomly generated it will change after upgrade so make sure you have provided the password.

Second if the header are not making through Ingress You'll not be able to access the admin console rather than you'll be stuck with

/admin/master/console

if it's already configure you'll not face this error.

Third too many redirect

This is due the proxy=passthrough which lead to this error.
And its default value so make sure if your tls terminate at loadbalancer or proxy which is in front of keycloak then you have to use the

proxy: edge

and it will start working

And

My Friend if you have done all this right you will be able to see the login screen of admin console

Thank you for reading this long hope, it help you

Feel Free to ask any question

KOps using Gossip DNS

Ashutosh Singh — Mon, 07 Mar 2022 06:37:59 +0000

KOPS?? you read it right! Kops with Gossip DNS

So I want to apologies for posting this late. Anyways without any delay let's get started.

What is KOPS ?

let me borrow this line from the official definition,
"it's the kubectl of K8s clusters"

I like this line very much coz it's the simplest form that can make you understand what is KOps.

Use Case of KOps

Suppose you wanted to create a self managed cluster but don't want to use the kubeadm and managed the infrastructure etc.
KOps is the answer to all of those queries.

It creates the Production grade Cluster to use for Development/Testing or just fun

To create Cluster you need 2 Things

Cloud Account (AWS ,GCP ,Azure etc).
A DNS/hostname/website anything you wanna call it.

But most of us don't want to buy or own a website name neither we want to buy a domain name so what can we do to solve this

Gossip DNS comes into play.

you can choose anyname but it must end with '.k8s.local' and you're ready to go.

Lets talk about Cloud Account

So here we need the admin access coz we need to create user and give it the permission, you can check the permission from the official doc here.

You also need a S3 bucket, so that KOps can save the cluster configuration on the cloud so that even other member of your team can use the same configuration to create their own cluster.
"NOTE: Bucket Versioning need to be enable & Bucket should be in us-east-1 other wise you need to do some more steps"

and you're done just run
kops create cluster --state <your-bucket-name> --name <name-of-your-cluster>

you can set these flag into env for easier use

After running the command it will show you the config file in which everything is mention

You just need to run the same command with --yes
kops create cluster --state <your-bucket-name> --name <name-of-your-cluster> --yes

Saying it will create production grade cluster is a little bit off from my point of view but there are 2-3 things you need to do before you can hand it over to someone like

Setting up metric server in K8s
Setting the config file expiry date longer
Installing the CNI

NOTE: Its better to specify the CNI in the starting, when we are creating the config file for our cluster

Otherwise it's a mess to configure the CNI coz it need to match the CIDR of k8s, for me I have to delete the cluster and create it again coz I didn't have anything critical over there.
So choose it first

You can check the about CNI and metric server if you just google it with KOps as keyword you can get everything.

And Thanks For Reading the long Article guys

You can checkout all the command flag from the official docs
I have made this for article for the GOSSIP DNS mostly coz I wasn't able to find any article about it.

Read every bit of the article coz it helps to setup everything and feel free to ask any question or error I'll try my best to solve them.

SAIL

Ashutosh Singh — Mon, 03 Jan 2022 14:29:17 +0000

Happy New Year Guys!

I know it's a bit late but.... you understand it

You probably have guessed the todays topic by seeing the cover Image or title, "LightSail".

So I was just going through Upwork and I have seen some work related to "AWS LightSail". I have not worked with LightSail ever but just read about it a bit, it's the simplest way of using cloud... basically AWS cloud 😁😁.

From my 1 day experience of using LightSail or I can say 1 hour
All I can say is that ""It's really the simplest way of utilizing the resources of AWS"", from deploying the Virtual Machine, Application, Container, Load Balancer it have it all in a very clear and precise order, They too have a very good documentation for the common use cases. I have read one of them regarding deployment of WordPress application or instance. And It's really good.

So, lets move on to the Technical Stuffs 🔥

The first image that you'll see after opening the LightSail service

Speaking of Truth there's really not much of things to learn about LightSail or I have mistaken, please let know more about it in comments.

So, Why do we have this service ?
According to me it's for those who are new to cloud like very new just know about some terms like instance/vm, load balancers, databases, etc.

It have all the service, that are required by someone, who is not expert or know about cloud like the database, container, storage, snapshots(backups). They are just there if you just see the above image you'll find it by just looking it.
I know this sound a bit ridiculous but think from the perspective of a person who barely know AWS it's easy start for them.
You don't have find the Services from service panel that we generally do, we don't have to configure much everything is pretty much already configure for us that's a plus point.

Pricing

Well I have not compare the pricing with other services because every service is unique in it's own way but here you find more about it.
You basically have 3 months of free tier limit so if you want to check it out please do and let me know about your experience.

Again there wasn't much to discuss or learn but still I would suggest please give it a try so that at least when someone is talking you know about it.

You can use it as a staging or development environment if you don't want to get into the trouble of configuring the services or you have just started your business

Again it's a very easy, simplest way for now I think to use the AWS resources

But do keep in mind there is not much of option available to you when you use them, from my side I can't think of a option but if you're looking for some specific functionality do check the official page of LightSail.