DEV Community: Dhruv malaviya

Cloud Infrastructure Security in 2025: Why I Started Treating Every App Like a Fortress

Dhruv malaviya — Sat, 11 Jul 2026 10:51:57 +0000

A practical look at container escape risks, public-IP scanning, and how Firecracker microVMs on Krova Cloud changed how I think about cloud infrastructure security.

The moment I stopped trusting my own stack
A few months ago, I got that Slack message nobody wants:

"One of our containers is acting weird. High CPU. Unknown process. Can you check?"

It turned out to be a cryptominer. Not because someone hacked our app. Not because we leaked secrets. But because another tenant on the same host had a vulnerable container, and the attacker escaped into the shared kernel.

We didn't do anything wrong. We followed the playbook: updated images, minimal privileges, read-only root filesystems. But we were still sitting on the same kernel as everyone else.

That incident made me ask a question I'd never seriously considered:

What if the real cloud security problem isn't our configuration - it's the architecture underneath?

This post is the answer I found. It's about why I started thinking of every app as its own fortress, and how platforms like Krova Cloud make that practical.

The two lies we tell ourselves about cloud security
Lie #1: "Containers are isolated enough"
Containers isolate processes. They don't isolate kernels.

Every container on a host shares the same Linux kernel. That's by design — it's why containers are fast and lightweight. But it also means a single kernel vulnerability can compromise every container on that machine.

Recent CVEs like Dirty Pipe, CVE-2022-0847, and privilege-escalation chains have shown this repeatedly. You don't need a zero-day. You need one kernel bug and one noisy neighbor.

┌─────────────────────────────────────┐
│ Host Kernel │ ← one shared kernel
├─────────────┬─────────────┬─────────┤
│ Container 1 │ Container 2 │ Your │
│ (tenant) │ (tenant) │ app │
└─────────────┴─────────────┴─────────┘
If an attacker breaks out of any container, they can potentially touch yours.

Lie #2: "A public IP is just how servers work"
The second lie is that every server needs a public IP address.

It doesn't. But VPS providers hand them out by default because it's convenient. The problem? That IP is now on the internet 24/7, being scanned, brute-forced, and probed by bots.

Within minutes of launching a typical VPS, you'll see:

SSH brute-force attempts
Port scans on every service
Automated exploit attempts
Your security model becomes: "I have a public address, and I hope my firewall rules are perfect."

Spoiler: they usually aren't.

What if isolation meant a real kernel?
This is where microVMs come in.

A microVM is a lightweight virtual machine. Unlike a container, each microVM boots its own kernel. Unlike a traditional VM, it starts in milliseconds - fast enough to spin up and tear down like a container.

The technology behind this is Firecracker, the same isolation engine AWS uses for Lambda and Fargate. It's designed for:

Strong isolation (full VM boundary)
Fast startup (sub-second boot)
Low overhead (minimal resource usage)
High density (many VMs on one host)

┌─────────────────────────────────────────────┐
│ Host Hardware │
├─────────────────┬───────────────────────────┤
│ VM 1 │ VM 2 │ Your │
│ own kernel │ own kernel │ app │
└─────────────────┴───────────────┴──────────┘
Each VM has its own kernel. A kernel bug in one can't reach another.

How Krova Cloud turns microVMs into a security model
That's the theory. Krova Cloud is the practice.

Krova Cloud calls its microVMs Cubes. Each Cube is a Firecracker microVM with a few security-first design choices that directly solve the problems I mentioned:

But the part that matters most? It's not just secure , it's usable.

Spinning up a Cube: from zero to root in seconds
Here's what provisioning looks like with the Krova CLI:

Bash

`# Install the CLI
npm i -g @krovacloud/cli

Create a Cube

krova cubes create web-1 \
--cpu 2 \
--ram 4 \
--disk 40 \
--image ubuntu-24.04

SSH in with full root access

krova ssh web-1
root@web-1:~#`
No VPCs. No security groups. No IAM roles. No launch templates. Just a real VM, isolated by hardware virtualization, booted in under a second.

If you prefer code, the REST API is just as simple:

Bash

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \ -H "X-API-KEY: $KROVA_KEY" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "name": "web-1", "image": "ubuntu-24.04", "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }, "sshPublicKey": "ssh-ed25519 AAAA...", "region": "eu-central" }'
Same result: one isolated Cube, own kernel, no public IP.

What "no public IP" actually means for security
This is the part that took me a while to fully appreciate.

When a Cube has no public IP, it literally doesn't exist on the public internet. There's no address to scan. No port to probe. No brute-force target.

Inbound traffic only reaches your Cube through Krova Cloud's managed ingress layer:

Web traffic enters through a TLS-terminated edge
Your custom domain points to that edge, not to your Cube
The Cube origin stays hidden
Non-web services use explicit port mappings with IP allowlists
text

Internet → Krova Ingress (TLS, DDoS-mitigated)
↓
Hidden origin
↓
Your Cube (private IP)
Compare that to a standard VPS:

text

Internet → Your public IP
↓
Your server (ssh, db, api all exposed)
The difference is night and day. With no public IP, the attacker can't attack what they can't find.

Mapping Krova's design to real cloud security principles
Let's translate the Cube architecture into the security fundamentals we all know:

Defense in depth A Cube isn't just one layer of isolation. It's several:

Hardware virtualization via KVM
Separate kernel per VM
Jailer sandbox around the hypervisor
No public IP
Stateful default-deny firewall
IP-allowlisted port mappings
Managed TLS ingress
That's defense in depth without you configuring any of it.

Least privilege By default, nothing is reachable. You have to explicitly open a port. And when you do, you can lock it to a specific IP range.

Bash

# Example: open SSH only from your office IP krova ports add web-1 \ --protocol tcp \ --port 22 \ --allowed-ips 203.0.113.0/24
This is least privilege applied to networking.

Attack surface reduction No public IP means no SSH brute-forcing. No open database ports scanned by Shodan. No accidental exposure because someone misconfigured a security group.

The attack surface is reduced by architecture, not by hoping humans never make mistakes.

Isolation of failure If one Cube is compromised, the blast radius is that Cube. Not the host. Not other tenants. Not your entire stack.

When microVMs make sense (and when they don't)
I'm not here to say containers are dead. They're not. But I think we overuse them for workloads that need real isolation.

MicroVMs are a great fit for:
User-submitted code (judge0-style platforms, coding interviews)
AI agents that run arbitrary shell commands
CI/CD runners that should start clean every time
Multi-tenant SaaS where each customer needs isolation
Databases and stateful services that benefit from a real kernel
Anything handling untrusted data
Containers are still fine for:
Internal microservices with trusted code
Development environments
Workloads where density and speed matter more than isolation
Teams already heavily invested in Kubernetes
The key is choosing the right isolation model for the risk.

A cloud security checklist for 2025
Whether you use Krova Cloud, AWS, Azure, or a mix, here's my current checklist:

Markdown

□ Assume shared kernels can be compromised — isolate high-risk workloads
□ Avoid public IPs unless absolutely necessary
□ Use IP allowlists for any administrative access
□ Enable MFA for all cloud consoles and SSH jump hosts
□ Rotate access keys every 90 days (or use temporary credentials)
□ Block public access on all storage buckets by default
□ Scan repos for leaked secrets before every merge
□ Centralize logs and set alerts for root login, IAM changes, and public exposure
□ Test your incident response plan before you need it
□ Review your architecture choices as often as your code
The last one is the hardest — and the most important.

Why this changed how I build
Before the cryptominer incident, I thought cloud security was about configuration: the right IAM policies, the right firewall rules, the right patches.

I still think those matter. But I now believe the foundation matters more.

If your architecture assumes a shared kernel and a public IP, you're asking your configuration to be perfect forever. That's a losing game.

If your architecture gives every workload its own kernel and hides it from the public internet, you've made security the default. That's a much better place to operate from.

That's why I started using Krova Cloud for workloads where isolation matters. Not because it's a magic bullet, but because it aligns the default architecture with good security hygiene.

Try it yourself
If you're curious, you can spin up a Cube for free (signup doesn't require a card, and the first $5 top-up doubles to $10):

Bash

npm i -g @krovacloud/cli krova signup krova cubes create security-test --cpu 1 --ram 2 --disk 20 --image ubuntu-24.04 krova ssh security-test
Once inside, run ss -tlnp and notice something beautiful: there are no public listening ports. Your server exists, but it's invisible to the internet.

Final thoughts
Cloud infrastructure security isn't just about tools and checklists. It's about architecture.

Containers gave us speed. microVMs give us speed and isolation.

Platforms like Krova Cloud make that isolation practical for everyday developers. And in a world where kernel bugs and automated scanning are constants, I think that's worth paying attention to.

What's your take? Are you still comfortable with shared kernels for sensitive workloads? Or are you already exploring microVMs and Firecracker? Drop a comment — I'd love to hear what's working for you.

Resources
Krova Cloud
Krova Cloud Security
Firecracker microVMs
AWS Lambda under the hood
NIST SP 800-190: Application Container Security Guide

Thanks for reading.
If you found this helpful, hit the ❤️ and follow for more cloud security and infrastructure posts.

5 Cloud Security Mistakes That'll Get You Hacked (And How to Fix Them)

Dhruv malaviya — Wed, 01 Jul 2026 09:14:17 +0000

5 Cloud Security Mistakes That'll Get You Hacked
A friend's startup got breached last month.

Cause? Public S3 bucket with customer data.

Fix time? 5 minutes.

Damage? $50K + lost customer trust.

Don't be that startup. Here are the 5 mistakes I see every week

1. Wildcard IAM Policies ❌
JSON

{ "Action": "*", "Resource": "*" }

Fix — Be specific:

{ "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" }

2. Public Storage Buckets ❌
Fix — Block public access:

Bash

aws s3control put-public-access-block \ --account-id 123456789012 \ --public-access-block-configuration \ "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

3. No Encryption ❌
Fix — Enable default encryption:

hcl

`resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
bucket = aws_s3_bucket.my_bucket.id

rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
}
}
}`

4. Missing MFA ❌
Fix — Enforce via SCP:

JSON

{ "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} } }

5. No Monitoring ❌
Fix — Quick security scan:

Bash

`#!/bin/bash
echo "🔍 Checking public S3 buckets..."
aws s3api list-buckets --query 'Buckets[].Name' --output text | while read bucket; do
aws s3api get-public-access-block --bucket $bucket 2>/dev/null || echo "⚠️ $bucket: No public access block!"
done

echo "🔒 Checking open security groups..."
aws ec2 describe-security-groups \
--filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
--query 'SecurityGroups[].GroupName' --output text

echo "👤 Checking MFA..."
aws iam list-users --query 'Users[].UserName' --output text | while read user; do
aws iam list-mfa-devices --user-name $user --query 'MFADevices' --output text | grep -q . || echo "⚠️ $user: No MFA!"
done`

**Quick Tools
**Bash

pip install prowler prowler aws --checks cis_2.0

*Do This NOW
*

Enable S3 Block Public Access
Turn on default encryption
Enable MFA on root account
Run Prowler scan TL;DR: Least privilege + Encryption + MFA + Monitoring = 95% fewer breaches.

Like this? ❤️ Follow for more quick DevOps tips.

cloudsecurity #aws #devops

4 Shopify API & Headless Gotchas Every Developer Hits (And How to Fix Them)

Dhruv malaviya — Tue, 30 Jun 2026 10:35:00 +0000

When you first start building a custom Shopify app or a headless Next.js storefront, the ecosystem feels like magic.

Then you deploy to production, real customers start checking out, and your webhooks start silently failing at 2:00 AM.

Unlike standard web apps, e-commerce development has zero room for unhandled exceptions—a broken API call literally means lost revenue. Before you push your next Shopify integration, make sure you aren't falling into these 4 developer traps:

1. Ignoring Webhook Idempotency (Duplicate Orders)
Shopify’s webhook delivery system guarantees at-least-once delivery. This means during high-traffic sales, Shopify will frequently fire the exact same ORDERS_CREATE webhook two or three times for a single purchase.

If your backend unconditionally inserts records or triggers fulfillment emails, you will duplicate orders.

The Fix: Always grab the X-Shopify-Webhook-Id header and store it in Redis or your database with a 24-hour TTL before processing the payload:
JavaScript

const webhookId = req.headers['x-shopify-webhook-id'];

// Check if we already processed this exact webhook event const alreadyProcessed = await redis.get(webhook:${webhookId}`);
if (alreadyProcessed) {
return res.status(200).send('Duplicate webhook ignored');
}

await redis.set(webhook:${webhookId}, 'true', 'EX', 86400);
// Now safe to process order...`

2. Getting Throttled by GraphQL "Cost-Based" Limits
Unlike standard REST APIs that limit you to X requests per minute, Shopify’s GraphQL Admin API uses a Calculated Query Cost model (a leaky bucket holding 1,000 points).

If you write a deeply nested query fetching 50 products, their variants, and their inventory quantities all at once, a single query can cost 800 points and instantly trigger a THROTTLED error.

The Fix: Request only the scalar fields you strictly need, and use pagination cursors (first: 10, after: $cursor) instead of requesting massive arrays.

3. Exposing Admin API Keys in Client Bundles
When building headless storefronts (Next.js, Remix, Nuxt), developers frequently confuse Shopify's two primary APIs:

Storefront API: Public, unauthenticated (Safe for browser/client requests).
Admin API: Highly privileged (Strictly server-side only).
If you accidentally prefix your Admin API access token with NEXT_PUBLIC_ in your .env file, any user inspecting your site's JavaScript bundle can steal it and modify store products or customer data.

4. Assuming All Currencies Have 2 Decimal Places
If you are writing custom frontend pricing logic and format prices by doing Math.round(amount * 100) / 100, your code will break the moment the store expands internationally.

Currencies like the Japanese Yen (JPY) or South Korean Won (KRW) are zero-decimal currencies.

The Fix: Never manually parse decimal placement. Delegate formatting to native JavaScript Intl.NumberFormat:
JavaScript

const formattedPrice = new Intl.NumberFormat('en-US', { style: 'currency', currency: product.currencyCode, // e.g., 'USD' or 'JPY' }).format(product.amount);

🛡️ Quick Takeaway
When developing for Shopify, always program defensively against network duplicates, API cost throttling, and international edge cases.

What was the most frustrating bug you ran into while building a Shopify app or theme? Drop your debugging war story in the comments below! 👇 (Hit 🦄 or 💖 if this saved your webhook logic).

4 AWS Infrastructure Gotchas That Will Get Your Account Hacked (And How to Fix Them in Terraform)

Dhruv malaviya — Mon, 29 Jun 2026 13:03:23 +0000

We’ve all heard the horror stories: a developer pushes a quick Terraform module on Friday afternoon, and wakes up Monday to a $14,000 AWS bill because bots turned their staging environment into a Monero mining cluster.

The terrifying part about AWS security isn't sophisticated zero-day exploits—it’s default misconfigurations.

Before you run terraform apply today, audit your code against these 4 bite-sized security fixes:

1. Kill Wildcard (*) IAM Permissions
When you hit a 403 Access Denied error, it’s tempting to test with "Action": "", "Resource": "". If committed, a single app vulnerability lets attackers wipe your AWS account.

The Fix: Always hardcode least-privilege API actions and scope down to exact resource ARNs:
hcl

Action = ["dynamodb:GetItem", "dynamodb:Query"] Resource = "arn:aws:dynamodb:us-east-1:123456789012:table/prod-users"

2. Lock Down S3 Buckets Explicitly
Automated scanners enumerate millions of bucket names per hour. If you don't explicitly block public access, your uploads will be discovered and dumped.

The Fix: Always attach an explicit public access block to every bucket:
hcl

resource "aws_s3_bucket_public_access_block" "lockdown" { bucket = aws_s3_bucket.app_bucket.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true }

3. Never Open DB Ports to 0.0.0.0/0
Opening port 5432 (PostgreSQL) or 3306 (MySQL) to 0.0.0.0/0 so you can connect your local DB GUI invites automated brute-force bots within 10 minutes.

The Fix: Keep databases in private subnets. Only allow ingress from your app server's Security Group ID:
hcl

source_security_group_id = aws_security_group.app_server_sg.id
(Need local GUI access? Use AWS SSM Port Forwarding to tunnel in without open inbound ports).

4. Ditch Static CI/CD Access Keys
Stop generating AWS IAM Users with static .env Secret Access Keys for GitHub Actions deployments.

The Fix: Switch to OpenID Connect (OIDC) federation. Let GitHub Actions assume a temporary AWS IAM Role dynamically per run, generating short-lived tokens that expire immediately after deployment.

🛡️ The 5-Second Pre-Commit Check
Catch these footguns automatically before pushing code by running an open-source scanner in your terminal:

Bash

# Instantly flags open SGs, missing crypto, and wildcards trivy config ./terraform-dir

What is your favorite CLI tool for catching cloud infrastructure bugs? Drop it in the comments! 👇 (Hit 🦄 if this reminded you to check your security groups today).

I analyzed 30 winning dropshipping products. 7 patterns they all share.

Dhruv malaviya — Fri, 26 Jun 2026 09:15:30 +0000

Looked at 30 products running Meta + TikTok ads
profitably. 7 patterns every single one had:

PRICE: $25-$65
Below = thin margins. Above = harder impulse.

BUNDLE OPTIONS
"Buy 2 save 10% / Buy 3 save 15%" — every store had
this. None were single-product only.

VISUAL HOOK IN 3 SECONDS
Unique design, specific problem solved, or "wow factor."
Generic products failed.

REAL REVIEWS WITH PHOTOS
Not 5-star spam. Real, mixed reviews. Even negatives
build trust.

SHIPPING TIME ON PDP
Every store disclosed it directly. None hid it in FAQ.

STICKY ADD-TO-CART ON MOBILE
All 30 had it. If your Add to Cart scrolls off-screen
on mobile, you're losing sales.

POST-PURCHASE UPSELL
"Add this for $X" / subscription / bulk refill.
This is where AOV lives.

WHAT THEY DIDN'T HAVE

Live chat (only 4/30)
Exit-intent popups (only 2/30)
Countdown timers (only 3/30)
Countdown timers (only 3/30 — most had REAL shipping urgency instead)
Multiple payment options visible on PDP (most just had Shopify default)

The "guru tactics" aren't what winning stores use.

3 QUICK WINS

Pick products with visual hooks
Bundle by default
Fix PDP before scaling ads

Why I Switched to Krova.cloud - Better Security, No Overselling, 40% Cheaper

Dhruv malaviya — Thu, 11 Jun 2026 06:44:15 +0000

Hey Devs 👋

Tired of paying premium prices for oversold, shared-kernel cloud infrastructure? Same. Let me introduce you to Krova.cloud — here's why it caught my attention:

🔐 No Shared Kernel Each VM (called a Cube) runs its own isolated kernel via Firecracker microVM technology - same tech behind AWS Lambda. No shared kernel = no cross-tenant risk. Real isolation, not container-level illusions.

🌐 No Public IP Exposure Your Cube doesn't sit naked on the internet.

💾 Backups Done Right

✅ RAID 1 mirrored disks - drive failure won't kill your server
✅ Snapshots built-in - not a paid add-on
✅ Backups stored on separate redundant storage
📊 RAM & Disk - Sold 1:1 Most providers thin-provision their hardware and oversell it. Krova sells every GB of RAM and disk 1:1 with actual hardware. What you pay for is genuinely yours. No noisy neighbors. No surprise slowdowns.

💸 Price? 40%+ cheaper than AWS Lightsail, DigitalOcean & Vultr. Per-hour billing. No hidden fees. Custom-sized VMs - no forced bundles.

Free $5 credits to start - no credit card needed 👉 krova.cloud 🙌

Krova: a security-first “VPS” where your server has no public IP by default

Dhruv malaviya — Thu, 11 Jun 2026 05:19:33 +0000

Most “I got hacked” (or “why is this box getting hammered?”) stories I’ve seen start with the same default: every server gets a public IP.

I’ve been working on Krova — cloud compute that flips that default.

The 4 ideas (quick)
1) No public IP per server by default
A Krova “Cube” (server) lives on a private NAT’d network. There isn’t a public IP sitting out there waiting to get scanned.

2) No shared kernel
Each Cube runs as a Firecracker microVM with its own kernel - not shared-kernel containers.

3) Snapshots + restore/rollback
Built-in snapshots so “snapshot before upgrade → rollback if needed” is a normal workflow.

4) 1:1 RAM + disk (no overselling)
If you provision 4GB RAM + 40GB disk, that’s reserved 1:1 on the host (no thin-provisioning surprises).

What “using it” looks like
1) Create a Cube (pick vCPU/RAM/disk) and SSH in as root.
2) Deploy normally (systemd, Docker, packages -
3) Expose only what you need:

attach api.yourdomain.com → port 8080 (HTTPS)
open SSH (or Postgres) via a TCP mapping, allowlisted to your IP/VPN 4) Snapshot before risky changes. Restore if it breaks.

If you’re curious, the site is here:
https://krova.cloud/

I’d love feedback from folks who run infra:

Is “no public IP by default” a win, or does it break too many real-world workflows?
What would you want to see from snapshots/backups before trusting a newer provider?

Why I built my cloud platform on micro-VMs instead of containers (a security story)

Dhruv malaviya — Wed, 03 Jun 2026 07:55:21 +0000

Containers are great until you remember they all share one kernel. For a lot of workloads that's fine. But the moment you're running untrusted code, multi-tenant jobs, or anything you wouldn't want leaking into its neighbours, a single kernel exploit is the whole game. That worry is exactly why I made an early architecture call for my platform, Krova krova: no shared-kernel containers.

Enter Firecracker
Firecracker is the open-source micro-VM monitor AWS built to run Lambda and Fargate. Each instance is a real hardware-virtualized VM (KVM under the hood) with its own kernel, but it boots in around 125ms and carries almost none of the weight of a traditional VM. You get the isolation boundary of a VM with something close to the start-up feel of a container.

That trade-off is perfect for security-minded, ephemeral work:

Hypervisor-level isolation. Tenants are separated at the virtualization boundary, not by namespaces over a shared kernel.
Tiny attack surface. Firecracker deliberately ships a minimal device model, far less exposed than a full VM stack.

How Krova uses it

Every machine on Krova (a "Cube") is its own Firecracker micro-VM with its own kernel. They get private internal networking rather than a public IP each, ingress is explicit port mapping, and you can sleep or destroy a Cube the instant you're done. So "run something untrusted, then make it vanish" is the default path, not a thing you bolt on.

And because they boot in about a second and keep their disk between sleeps, the security model doesn't cost you convenience, which is usually the part that makes people skip isolation in the first place.