Forem: francotel

Building a Secure Serverless Upload Pattern on AWS with Terraform 🚀

francotel — Sun, 08 Mar 2026 17:09:57 +0000

𝗗𝗶𝗿𝗲𝗰𝘁 𝘂𝗽𝗹𝗼𝗮𝗱𝘀. 𝗭𝗲𝗿𝗼 𝗯𝗮𝗰𝗸𝗲𝗻𝗱 𝗯𝗼𝘁𝘁𝗹𝗲𝗻𝗲𝗰𝗸𝘀. 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲-𝗴𝗿𝗮𝗱𝗲 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆.

🧠 𝗔 𝗥𝗲𝗮𝗹-𝗪𝗼𝗿𝗹𝗱 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 (𝗧𝗵𝗮𝘁 𝗜 𝗞𝗲𝗲𝗽 𝗦𝗲𝗲𝗶𝗻𝗴)

A few weeks ago, I was reviewing a system where users were uploading files (some >300MB).

The original flow looked “reasonable”:

Frontend uploads the file to the backend
Backend processes the request
Backend uploads the file to S3
Backend responds

But in practice, the system was 𝗳𝗮𝗹𝗹𝗶𝗻𝗴 𝗮𝗽𝗮𝗿𝘁:

❌ Timeouts
❌ Lambda memory spikes
❌ High AWS bills
❌ Angry users

And the root cause was always the same:

𝗧𝗵𝗲 𝗯𝗮𝗰𝗸𝗲𝗻𝗱 𝘀𝗵𝗼𝘂𝗹𝗱 𝗡𝗘𝗩𝗘𝗥 𝗵𝗮𝗻𝗱𝗹𝗲 𝗳𝗶𝗹𝗲 𝘂𝗽𝗹𝗼𝗮𝗱𝘀 𝗶𝗻 𝗮 𝘀𝗲𝗿𝘃𝗲𝗿𝗹𝗲𝘀𝘀 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲.

💡 𝗧𝗵𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 𝗧𝗵𝗮𝘁 𝗙𝗶𝘅𝗲𝘀 𝗘𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴
The solution is a 𝘄𝗲𝗹𝗹-𝗸𝗻𝗼𝘄𝗻 𝗯𝘂𝘁 𝗼𝗳𝘁𝗲𝗻 𝗺𝗶𝘀𝘂𝘀𝗲𝗱 𝗽𝗮𝘁𝘁𝗲𝗿𝗻:

👉 𝗦𝟯 𝗣𝗿𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗥𝗟𝘀

Instead of uploading files 𝘵𝘩𝘳𝘰𝘶𝘨𝘩 your backend, you let the client upload 𝗱𝗶𝗿𝗲𝗰𝘁𝗹𝘆 𝘁𝗼 𝗦𝟯, but in a 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱, 𝘁𝗲𝗺𝗽𝗼𝗿𝗮𝗿𝘆, 𝗮𝗻𝗱 𝘀𝗲𝗰𝘂𝗿𝗲 𝘄𝗮𝘆.

This is the same pattern used by:
● Fintech platforms
● Healthcare systems
● Large SaaS products

🧩 𝗛𝗼𝘄 𝘁𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗪𝗼𝗿𝗸𝘀
𝗛𝗶𝗴𝗵-𝗹𝗲𝘃𝗲𝗹 𝗳𝗹𝗼𝘄:

1️⃣ Client asks permission to upload a file
2️⃣ API Gateway → Lambda generates a 𝗣𝗿𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗥𝗟
3️⃣ Client uploads 𝗱𝗶𝗿𝗲𝗰𝘁𝗹𝘆 𝘁𝗼 𝗦𝟯 using PUT
4️⃣ Backend never touches the file

🎯 Result:
● Zero bottlenecks
● Minimal Lambda execution time
● Lower cost
● Better UX

🔐 𝗪𝗵𝗮𝘁 𝗜𝘀 𝗮 𝗣𝗿𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗥𝗟 (𝗜𝗻 𝗦𝗶𝗺𝗽𝗹𝗲 𝗧𝗲𝗿𝗺𝘀)?

Think of a presigned URL as:
🎟️ 𝗔 𝘁𝗲𝗺𝗽𝗼𝗿𝗮𝗿𝘆, 𝘀𝗶𝗻𝗴𝗹𝗲-𝗽𝘂𝗿𝗽𝗼𝘀𝗲 𝘁𝗶𝗰𝗸𝗲𝘁
● Valid only for a few minutes
● Allows only one specific action (e.g. PUT)
● Scoped to a single object
● No AWS credentials exposed

Once it expires → 𝗶𝘁’𝘀 𝘂𝘀𝗲𝗹𝗲𝘀𝘀.

⚙️ 𝗟𝗮𝗺𝗯𝗱𝗮: 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝗣𝗿𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗥𝗟 (𝗡𝗼𝗱𝗲.𝗷𝘀)

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({ region: "us-east-1" });

export const handler = async (event) => {
  const { fileName, contentType } = JSON.parse(event.body);

  const key = uploads/${Date.now()}-${fileName};

  const command = new PutObjectCommand({
    Bucket: process.env.BUCKET_NAME,
    Key: key,
    ContentType: contentType,
  });

  const uploadUrl = await getSignedUrl(s3, command, {
    expiresIn: 300, // 5 minutes
  });

  return {
    statusCode: 200,
    body: JSON.stringify({ uploadUrl, key }),
  };
};

[!WARNING]
⚠️ 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁:
The Lambda never sees the file, it only authorizes the upload.

🛡️ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗟𝗮𝘆𝗲𝗿𝘀 (𝗪𝗵𝗮𝘁 𝗠𝗮𝗸𝗲𝘀 𝗧𝗵𝗶𝘀 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻-𝗥𝗲𝗮𝗱𝘆)

This PoC follows 𝗿𝗲𝗮𝗹 𝗲𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀, not just demos.

🔐 𝟭. 𝗦𝗵𝗼𝗿𝘁-𝗹𝗶𝘃𝗲𝗱 𝗨𝗥𝗟𝘀
● 5–10 minutes max
● Enough for upload, useless afterward

🔐 𝟮. 𝗜𝗔𝗠 𝗟𝗲𝗮𝘀𝘁 𝗣𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲

Lambda role can 𝗼𝗻𝗹𝘆 do:

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

Nothing else.

🔐 𝟯. 𝗣𝗿𝗶𝘃𝗮𝘁𝗲 𝗦𝟯 𝗕𝘂𝗰𝗸𝗲𝘁
● No public access
● No ACL tricks
● Only presigned URLs work

🔐 𝟰. 𝗦𝗮𝗻𝗶𝘁𝗶𝘇𝗲𝗱 𝗢𝗯𝗷𝗲𝗰𝘁 𝗡𝗮𝗺𝗲𝘀
● UUID-based keys
● No user-controlled paths
● No path traversal risks

🔐 𝟱. 𝗖𝗢𝗥𝗦 𝗖𝗼𝗿𝗿𝗲𝗰𝘁𝗹𝘆 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗲𝗱

Because 𝗖𝗢𝗥𝗦 𝗶𝘀 𝗮𝗹𝘄𝗮𝘆𝘀 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝘁𝗵𝗶𝗻𝗴 𝘁𝗵𝗮𝘁 𝗯𝗿𝗲𝗮𝗸𝘀 😅

🧱 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗮𝘀 𝗖𝗼𝗱𝗲 𝘄𝗶𝘁𝗵 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺

Everything is deployed using 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺, so the architecture is:
● Reproducible
● Auditable
● Ready for CI/CD

Core components:
● S3 bucket
● Lambda
● IAM roles
● API Gateway (HTTP API)

📌 𝘐𝘯 𝘵𝘩𝘦 𝘱𝘰𝘴𝘵 𝘐 𝘧𝘰𝘤𝘶𝘴 𝘰𝘯 𝘵𝘩𝘦 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗮𝗻𝗱 𝗽𝗮𝘁𝘁𝗲𝗿𝗻.
𝘛𝘩𝘦 𝗳𝘂𝗹𝗹 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝘭𝘪𝘷𝘦𝘴 𝘪𝘯 𝘵𝘩𝘦 𝘳𝘦𝘱𝘰𝘴𝘪𝘵𝘰𝘳𝘺.

📂 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 (𝗦𝗶𝗺𝗽𝗹𝗲 𝗯𝘆 𝗗𝗲𝘀𝗶𝗴𝗻)

aws-s3-presigned-url-lambda-terraform/
├── 01-s3.tf
├── 02-lambda.tf
├── 04-api.tf
├── client/
│   ├── index.html
│   ├── index.html.tpl
│   ├── logo-client.png
│   └── logo-s3.png
├── dev.tfvars
├── drawio/
│   ├── aws-s3-presignend.gif
│   ├── aws-s3-url.drawio
│   ├── image-2.png
│   └── image.png
├── lambda-function.zip
├── main.tf
├── Makefile
├── provider.tf
├── README.md
├── security/
│   ├── checkov.yaml
│   └── trivy.yaml
├── src/
│   ├── index.mjs
│   ├── node_modules/
│   ├── package-lock.json
│   └── package.json
├── terraform.tfstate
├── terraform.tfstate.backup
├── tfplan
├── tfplan.json
├── variables.tf
└── versions.tf

🎯 Minimal, readable, and focused on the pattern.

🧪 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁𝘀 𝘁𝗼 𝗥𝘂𝗻 𝘁𝗵𝗲 𝗣𝗼𝗖

This PoC assumes:

✅ macOS
✅ Terraform already installed
✅ AWS CLI already authenticated

No extra setup. No magic.

🚀 𝗪𝗮𝗻𝘁 𝘁𝗵𝗲 𝗙𝘂𝗹𝗹 𝗪𝗼𝗿𝗸𝗶𝗻𝗴 𝗣𝗼𝗖?

I published the complete implementation here:

👉 𝗵𝘁𝘁𝗽𝘀://𝗴𝗶𝘁𝗵𝘂𝗯.𝗰𝗼𝗺/𝗳𝗿𝗮𝗻𝗰𝗼𝘁𝗲𝗹/𝗮𝘄𝘀-𝘀𝟯-𝗽𝗿𝗲𝘀𝗶𝗴𝗻𝗲𝗱-𝘂𝗿𝗹-𝗹𝗮𝗺𝗯𝗱𝗮-𝘁𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 (𝗵𝘁𝘁𝗽𝘀://𝗴𝗶𝘁𝗵𝘂𝗯.𝗰𝗼𝗺/𝗳𝗿𝗮𝗻𝗰𝗼𝘁𝗲𝗹/𝗮𝘄𝘀-𝘀𝟯-𝗽𝗿𝗲𝘀𝗶𝗴𝗻𝗲𝗱-𝘂𝗿𝗹-𝗹𝗮𝗺𝗯𝗱𝗮-𝘁𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺)

You’ll find:
● Full Terraform code
● Lambda (Node.js 20)
● Test scripts
● Architecture diagram

Clone it, deploy it, break it, improve it.

🎯 𝗙𝗶𝗻𝗮𝗹 𝗧𝗵𝗼𝘂𝗴𝗵𝘁

If your backend is still handling file uploads, you’re paying more 𝗮𝗻𝗱 scaling less.

This pattern:
● Reduces cost
● Improves reliability
● Scales naturally
● Matches real-world cloud architectures

Inspiration and References

This project was inspired by the AWS blog post:

Securing Amazon S3 presigned URLs for serverless applications https://aws.amazon.com/blogs/compute/securing-amazon-s3-presigned-urls-for-serverless-applications/

The article explores several best practices for securing presigned
URLs in serverless architectures, including checksum validation,
expiration strategies, and least-privilege IAM policies.

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

NestJS in Production: 20 Default Configurations That Can Break Your Kubernetes Cluster (A DevOps Story)

francotel — Thu, 26 Feb 2026 02:15:16 +0000

😱 Production went down… because of a default setting

Have you ever seen this?

The dev team ships a new feature using a modern, elegant, enterprise-ready framework like NestJS.Everything works perfectly on local.QA passes.Production deploys.

And suddenly…

500 errors everywhere
Kubernetes pods restarting
Logs that tell you absolutely nothing

The root cause?

👉 A 100kb default request body limit that nobody knew existed.

Yes. That tiny default almost ruined our Friday night. 😅

As a DevOps engineer working with Kubernetes and Azure, this was a wake-up call. NestJS is an amazing framework—but defaults are not production-ready by magic.

This post is not about blaming developers.It’s about shared responsibility.

Framework defaults are convenient.Production environments are not.

Below are 20 NestJS defaults and behaviors that every DevOps engineer should be aware of when NestJS lands in a Kubernetes cluster.

1️⃣ The 100kb That Almost Killed PROD (Body Parser)

NestJS (with Express under the hood) uses body-parser.By default, it only accepts 100kb for JSON payloads.

If your API handles file uploads, base64 payloads, or large requests, you’ll get a PayloadTooLargeError that often becomes a silent 500.

👉 Fix it explicitly in main.ts:

   app.use(bodyParser.json({ limit: '10mb' }));

Lesson: defaults are optimized for demos, not real traffic.

2️⃣ HTTP Timeouts Are Not Infinite

Node’s HTTP server does not wait forever.

Long-running requests, slow downstream services, or blocked connections can slowly exhaust your pod resources.

Configure:

server.timeout
keepAliveTimeout
Or enforce limits at the Ingress / Load Balancer level

DevOps takeaway: timeouts are part of capacity planning.

3️⃣ The Logger That Doesn’t Log (in Production)

console.log is fine… until it isn’t.

In production you want:

Structured logs (JSON)
Correlation IDs
Compatibility with ELK, Datadog, Azure Monitor

Use app.useLogger() with pino or winston.

Logs are not for developers.They are for incident response.

4️⃣ Shutdown Hooks: Kubernetes Is Not Polite

When Kubernetes terminates a pod, it sends SIGTERM.
If your app ignores it:

In-flight requests are dropped
Users see 5xx errors
You lose trust

Enable graceful shutdown:

  app.enableShutdownHooks();

And drain traffic properly.

5️⃣ Environment Variables: .env Is Not Production

@nestjs/config looks for .env files by default.

In Kubernetes, configuration comes from:

Environment variables
ConfigMaps
Secrets

Avoid filesystem dependencies:

   ConfigModule.forRoot({  ignoreEnvFile: process.env.NODE_ENV ===  'production',});

6️⃣ Global Modules: Convenience vs Control

@global() modules feel nice.

They also:

Hide dependencies
Increase coupling
Complicate testing
Make scaling harder

What’s convenient for development can be painful in production.

7️⃣ Dependency Injection Can Betray You

Custom providers and factories can introduce:

Circular dependencies
Runtime undefined errors

These issues often appear only under load.
Use dependency graphs and be suspicious of “magic”.

8️⃣ Global Exception Filters Are Mandatory

Without a global exception filter:

Errors are inconsistent
Stack traces may leak
Logs are unstructured

Always normalize errors:

   app.useGlobalFilters(...)

Predictable errors = predictable operations.

9️⃣ Guards Can Kill Performance

Guards run before interceptors and pipes.
Heavy logic here (rate limiting, DB calls) affects every request.
Security ≠ expensive execution.

🔟 Shipping start:dev to Kubernetes (Yes, It Happens)

Always:

Build with npm run build
Run node dist/main.js

Otherwise you get:

Huge images
Dev dependencies in prod
Slower startups

I’ve seen 2GB images because of this.

1️⃣1️⃣ CacheModule Is Not Shared

In-memory cache:

Is pod-local
Is volatile
Breaks consistency in clusters

For real workloads, use Redis or another external store.

1️⃣2️⃣ Scheduled Tasks Can Block the Event Loop

@nestjs/schedule runs inside the same process.

Long-running jobs = slower APIs.

Move heavy work out or make it truly async.

1️⃣3️⃣ Correlation Headers Belong to Middleware

Headers like:

X-Request-ID
X-Correlation-ID

Should be:

Global
Mandatory
Documented

Not copy-pasted across controllers.

1️⃣4️⃣ Health Checks Must Be Honest

Kubernetes doesn’t care if port 3000 responds.

It cares if:

DB is reachable
Queues are alive
Dependencies are healthy

Liveness ≠ Readiness.

1️⃣5️⃣ Response Size Is a Memory Problem

Large payloads = memory pressure.

Pagination is not optional.It’s a survival mechanism.

1️⃣6️⃣ API Versioning Is a Day-One Decision

No versioning = broken clients later.

NestJS supports:

URI versioning
Header versioning

Pick one early.

1️⃣7️⃣ WebSockets Don’t Scale by Default

WebSocket connections stick to a pod.

For horizontal scaling, you need:

Redis adapters
Message brokers

Stateful connections break stateless assumptions.

1️⃣8️⃣ Database Connection Pools Matter

Default pool sizes are usually small.

Multiply that by pod replicas and you’ll hit DB limits fast.

Tune pools intentionally.

1️⃣9️⃣ Axios Has No Timeout (Yes, Really)

NestJS HttpModule uses Axios.
Axios defaults:

No timeout

One hanging dependency can block your service forever.

Always set timeouts.

2️⃣0️⃣ Swagger Is Not Decoration

Outdated Swagger docs cause:

Misuse
Invalid payloads
Production incidents

Automate updates. Treat docs as code.

🧠 Final Thought: DevOps Is Not Just YAML

NestJS is enterprise-ready, but enterprises are messy.

Scalability doesn’t come from frameworks alone.It comes from Dev and Ops understanding how software behaves under pressure.

So next time NestJS lands in your cluster, don’t just review Kubernetes manifests.

👉 Open main.ts.

It might save your weekend.

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

🧠 Cómo Sobrevivir a Múltiples Cuentas de GitHub sin Perder Tu Sanidad Mental (y Tu Trabajo)

francotel — Wed, 18 Feb 2026 15:10:34 +0000

🌅 𝗘𝗹 𝗠𝗼𝗺𝗲𝗻𝘁𝗼 𝗱𝗲𝗹 𝗣á𝗻𝗶𝗰𝗼: 𝟮 𝗔𝗠, 𝗩𝗶𝗲𝗿𝗻𝗲𝘀 𝗽𝗼𝗿 𝗹𝗮 𝗡𝗼𝗰𝗵𝗲

𝘨𝘪𝘵 𝘱𝘶𝘴𝘩 𝘰𝘳𝘪𝘨𝘪𝘯 𝘮𝘢𝘪𝘯

𝗘𝗥𝗥𝗢𝗥: 𝗣𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻 𝗱𝗲𝗻𝗶𝗲𝗱 (𝗽𝘂𝗯𝗹𝗶𝗰𝗸𝗲𝘆). ❌

Mi corazón se detuvo por 3 segundos.

Eran las 2 de la madrugada. Mi jefe necesitaba el hotfix para la demo con el cliente en Asia en 6 horas. Y yo, desde mi laptop personal, estaba viendo cómo el universo conspiraba contra mi fin de semana.

El problema: 𝗚𝗶𝘁𝗛𝘂𝗯 𝗻𝗼 𝘀𝗮𝗯í𝗮 𝘀𝗶 𝗲𝗿𝗮 "𝗗𝗲𝘃 𝗣𝗲𝗿𝘀𝗼𝗻𝗮𝗹" 𝗼 "𝗗𝗲𝘃 𝗖𝗼𝗿𝗽𝗼𝗿𝗮𝘁𝗶𝘃𝗼". Y estaba usando la identidad equivocada.

𝘚𝘶𝘦𝘯𝘢 𝘧𝘢𝘮𝘪𝘭𝘪𝘢𝘳? 🥲

Si alguna vez has:
● Trabajado en una startup y tenido tu proyecto personal 🏠
● Sido contratista para múltiples clientes 💼
● Entrado a una empresa que te exige cuenta corporativa de GitHub 🏢
● Tenido que hacer un commit urgente desde tu laptop personal 🔥

...este post es para ti.

📖 𝗟𝗮 𝗛𝗶𝘀𝘁𝗼𝗿𝗶𝗮 𝗥𝗲𝗮𝗹: 𝗖ó𝗺𝗼 𝘂𝗻𝗮 𝗘𝗺𝗽𝗿𝗲𝘀𝗮 𝗖𝗮𝘀𝗶 𝗣𝗶𝗲𝗿𝗱𝗲 𝘂𝗻 𝗖𝗹𝗶𝗲𝗻𝘁𝗲 𝗽𝗼𝗿 𝗦𝗦𝗛-𝗞𝗲𝘆𝘀 𝗠𝗮𝗹 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝗱𝗮𝘀

Trabajo en 𝗧𝗲𝗰𝗵𝗖𝗼𝗿𝗽, una consultora que maneja proyectos para 15+ clientes diferentes. Cada cliente requiere:

● Cuenta separada de GitHub 🔐
● SSH-keys diferentes 🗝️
● Repos privados aislados 📦

𝗘𝗹 𝗰𝗮𝗼𝘀 𝗱𝗶𝗮𝗿𝗶𝗼:
● Devs haciendo commits con identidad equivocada 😱
● CI/CD pipelines fallando por permisos 🔥
● 3 horas semanales de soporte técnico resolviendo estos problemas ⏰

𝗘𝗹 𝗰𝗼𝘀𝘁𝗼: $15,000 USD/año en productividad perdida. 💸

🎯 La Solución que Cambió Todo: Multi-SSH Keys como un Pro

Paso 1: El Diagnóstico (Entendiendo el Problema)

¿𝗤𝘂é 𝗸𝗲𝘆𝘀 𝘁𝗶𝗲𝗻𝗲𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗺𝗲𝗻𝘁𝗲?

ls -la ~/.ssh/

¿𝗤𝘂é 𝘂𝘀𝘂𝗮𝗿𝗶𝗼 𝗲𝘀𝘁á 𝘂𝘀𝗮𝗻𝗱𝗼 𝗚𝗶𝘁 𝗮𝗵𝗼𝗿𝗮?

git config user.email

Paso 2: La Cirugía - Crear Keys Separadas

# 𝗞𝗲𝘆 𝗽𝗲𝗿𝘀𝗼𝗻𝗮𝗹 (𝗹𝗮 𝗾𝘂𝗲 𝘆𝗮 𝘁𝗶𝗲𝗻𝗲𝘀)
~/.ssh/id_rsa

# 𝗞𝗲𝘆 𝗽𝗮𝗿𝗮 𝗲𝗹 𝘁𝗿𝗮𝗯𝗮𝗷𝗼 𝗲𝗻 𝗙𝗶𝗻𝗧𝗲𝗰𝗵𝗖𝗼𝗿𝗽
ssh-keygen -t rsa -b 4096 -C "tu@fintechcorp.com" -f ~/.ssh/fintech_rsa

# 𝗞𝗲𝘆 𝗽𝗮𝗿𝗮 𝗲𝗹 𝗰𝗹𝗶𝗲𝗻𝘁𝗲 𝗘-𝗰𝗼𝗺𝗺𝗲𝗿𝗰𝗲 
ssh-keygen -t rsa -b 4096 -C "tu@ecomcliente.com" -f ~/.ssh/ecom_rsa

🎨 Imagina que cada key es una llave física diferente para oficinas distintas.

Paso 3: El Archivo Mágico (~/.ssh/config)

# 👤 𝗬𝗢 (𝗣𝗲𝗿𝘀𝗼𝗻𝗮𝗹) - 𝗠𝗶 𝗶𝗱𝗲𝗻𝘁𝗶𝗱𝗮𝗱 𝘀𝗲𝗰𝗿𝗲𝘁𝗮
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  AddKeysToAgent yes

# 💼 𝗙𝗶𝗻𝗧𝗲𝗰𝗵𝗖𝗼𝗿𝗽 - 𝗠𝗶 𝘆𝗼 𝗰𝗼𝗿𝗽𝗼𝗿𝗮𝘁𝗶𝘃𝗼
Host github.com-fintech
  HostName github.com
  User git
  IdentityFile ~/.ssh/fintech_rsa
  AddKeysToAgent yes

# 🛒 𝗘𝗰𝗼𝗺𝗖𝗹𝗶𝗲𝗻𝘁𝗲 - 𝗘𝗹 𝗽𝗿𝗼𝘆𝗲𝗰𝘁𝗼 𝗾𝘂𝗲 𝗽𝗮𝗴𝗮 𝗹𝗮𝘀 𝘃𝗮𝗰𝗮𝗰𝗶𝗼𝗻𝗲𝘀
Host github.com-ecom
  HostName github.com
  User git
  IdentityFile ~/.ssh/ecom_rsa
  AddKeysToAgent yes

💡 Tip Pro: Piensa en esto como rutas de enrutamiento en una red compleja - cada host alias dirige el tráfico al destino correcto con las credenciales apropiadas.

🔑 Paso 4: El Registro en GitHub (El Paso que Nadie Debe Saltarse)

4.1 Copia tu llave pública al portapapeles

# Para macOS (pbcopy)
cat ~/.ssh/ecom_rsa.pub | pbcopy

# Para Linux (xclip)
cat ~/.ssh/ecom_rsa.pub | xclip -selection clipboard

# Para Windows (PowerShell)
Get-Content ~/.ssh/ecom_rsa.pub | Set-Clipboard

4.𝟮 𝗔𝗴𝗿é𝗴𝗮𝗹𝗮 𝗮 𝘁𝘂 𝗰𝘂𝗲𝗻𝘁𝗮 𝗱𝗲 𝗚𝗶𝘁𝗛𝘂𝗯

Ve a 𝗚𝗶𝘁𝗛𝘂𝗯.𝗰𝗼𝗺 (𝗵𝘁𝘁𝗽𝘀://𝗴𝗶𝘁𝗵𝘂𝗯.𝗰𝗼𝗺/) → 𝗦𝗲𝘁𝘁𝗶𝗻𝗴𝘀 (tu foto de perfil) ⚙️
En el menú lateral, haz clic en "𝗦𝗦𝗛 𝗮𝗻𝗱 𝗚𝗣𝗚 𝗸𝗲𝘆𝘀" 🔑
Haz clic en el botón verde "𝗡𝗲𝘄 𝗦𝗦𝗛 𝗸𝗲𝘆" o "𝗔𝗱𝗱 𝗦𝗦𝗛 𝗸𝗲𝘆" ➕
En el formulario:

𝗧𝗶𝘁𝗹𝗲: Un nombre descriptivo (ej: "MacBook Pro Work", "Personal Laptop", "Franco - Work")
𝗞𝗲𝘆 𝘁𝘆𝗽𝗲: "Authentication Key" (mantén el default)
𝗞𝗲𝘆: Pega el contenido de tu portapapeles (la llave pública)

Haz clic en "𝗔𝗱𝗱 𝗦𝗦𝗛 𝗸𝗲𝘆" ✅

Paso 5: El Truco del Clonado Inteligente

❌ 𝗔𝗻𝘁𝗲𝘀 (𝗳𝗮𝗹𝗹𝗮𝗯𝗮 𝘀𝗶𝗲𝗺𝗽𝗿𝗲)
git clone git@github.com:fintechcorp/proyecto-secreto.git

✅ 𝗗𝗲𝘀𝗽𝘂é𝘀 (𝗳𝘂𝗻𝗰𝗶𝗼𝗻𝗮 𝗽𝗲𝗿𝗳𝗲𝗰𝘁𝗼)
git clone git@github.com-fintech:fintechcorp/proyecto-secreto.git

📊 𝗥𝗲𝘀𝘂𝗹𝘁𝗮𝗱𝗼𝘀 𝗥𝗲𝗮𝗹𝗲𝘀 𝗲𝗻 𝗺𝗶 𝗘𝗺𝗽𝗿𝗲𝘀𝗮 (𝗠é𝘁𝗿𝗶𝗰𝗮 𝗾𝘂𝗲 𝗜𝗺𝗽𝗼𝗿𝘁𝗮)

𝗔𝗻𝘁𝗲𝘀 𝗱𝗲 𝗹𝗮 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝗰𝗶ó𝗻 (𝗘𝗻𝗲 𝟮𝟬𝟮𝟱):
🔴 12 incidentes/mes por credenciales incorrectas
🔴 8 horas/mes de soporte DevOps
🔴 3 devs frustrados renunciaron (ok, esto no fue solo por SSH, pero ayudó)

𝗗𝗲𝘀𝗽𝘂é𝘀 (𝗝𝘂𝗻 𝟮𝟬𝟮𝟱):
🟢 0 incidentes por credenciales
🟢 0 horas de soporte (autogestionado)
🟢 Devs pueden cambiar de contexto en <1 minuto

𝗜𝗺𝗽𝗮𝗰𝘁𝗼 𝗳𝗶𝗻𝗮𝗻𝗰𝗶𝗲𝗿𝗼:

"𝘈𝘩𝘰𝘳𝘳𝘢𝘮𝘰𝘴 $12,000 𝘢𝘭 𝘢ñ𝘰 𝘴𝘰𝘭𝘰 𝘦𝘯 𝘵𝘪𝘦𝘮𝘱𝘰 𝘥𝘦 𝘵𝘳𝘰𝘶𝘣𝘭𝘦𝘴𝘩𝘰𝘰𝘵𝘪𝘯𝘨" - 𝘊𝘛𝘖 𝘥𝘦 𝘛𝘦𝘤𝘩𝘊𝘰𝘳𝘱

🎮 Bonus: El Debugging Mode (Cuando Algo Sale Mal)

Comandos de Diagnóstico Rápido:

# ¿𝗤𝘂é 𝗸𝗲𝘆 𝗲𝘀𝘁á 𝘂𝘀𝗮𝗻𝗱𝗼 𝗦𝗦𝗛?
ssh -T git@github.com-fintech

𝗗𝗲𝗯𝗲𝗿í𝗮𝘀 𝘃𝗲𝗿: "𝗛𝗶 @𝘂𝘀𝘂𝗮𝗿𝗶𝗼-𝗳𝗶𝗻𝘁𝗲𝗰𝗵! 𝗬𝗼𝘂'𝘃𝗲 𝘀𝘂𝗰𝗰𝗲𝘀𝘀𝗳𝘂𝗹𝗹𝘆 𝗮𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗲𝗱..."

# ¿𝗤𝘂é 𝘂𝘀𝘂𝗮𝗿𝗶𝗼 𝘁𝗶𝗲𝗻𝗲 𝗚𝗶𝘁 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝗱𝗼?
cat .git/config | grep email

# 𝗩𝗲𝗿 𝘁𝗼𝗱𝗮𝘀 𝗹𝗮𝘀 𝗸𝗲𝘆𝘀 𝗰𝗮𝗿𝗴𝗮𝗱𝗮𝘀
ssh-add -l

# 𝗧𝗲𝘀𝘁 𝗱𝗲 𝗰𝗼𝗻𝗲𝘅𝗶ó𝗻 𝘃𝗲𝗿𝗯𝗼𝘀𝗲 (𝗰𝘂𝗮𝗻𝗱𝗼 𝘁𝗼𝗱𝗼 𝗳𝗮𝗹𝗹𝗮)
ssh -vT git@github.com-fintech

# 🔥 LIMPIAR TODO Y EMPEZAR DE CERO (cuando hay caos)
ssh-add -D
# Esto elimina TODAS las llaves del agente SSH
# Útil cuando tienes conflictos de keys o credenciales mezcladas

Errores Comunes y Soluciones:

Error	Causa	Solución Mágica
`Permission denied`	Key incorrecta	Verifica `~/.ssh/config`
`Could not open connection`	Alias mal escrito	`github.com-empresa` vs `github.com_empresa`
`User email incorrecto`	Git local mal config	`git config user.email`

🧭 ¿Y si trabajamos juntos?

Este proyecto es una base.En CrossCloudX, diseñamos pipelines a la medida para empresas financieras, consultoras o startups con visión.
¿Te interesa un piloto en tu empresa?

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

GitHub Actions + Security Scanning: Cómo Integrar Trivy y Checkov en tu Pipeline

francotel — Mon, 19 Jan 2026 02:06:04 +0000

🚨 La Pesadilla que Todos los DevOps Tememos

Era un martes cualquiera cuando recibí la alerta: "Vulnerabilidad CRÍTICA detectada en producción". Nuestra aplicación, que servía a miles de usuarios, tenía una vulnerabilidad de día cero que alguien había logrado explotar.

¿El culpable? Una imagen Docker que habíamos desplegado la semana anterior.

La peor parte: ¡La vulnerabilidad ya existía cuando publicamos la imagen! Había pasado por nuestro pipeline CI/CD sin que nadie la notara.

En ese momento entendí algo crucial: si tu pipeline no valida seguridad, estás desplegando ciegamente.

🛡️ La Solución: Integrar Security Scanning en GitHub Actions

Después de esa experiencia, me propuse crear un pipeline que nunca más permitiera que vulnerabilidades llegaran a producción. Así nació este proyecto que hoy comparto contigo.

🔍 El Problema que Resolvemos

# Así era nuestro workflow ANTES:
- name: Build Docker Image
  run: docker build -t mi-app .


- name: Push to Registry  
  run: docker push mi-app:latest

# ¡Sin validaciones de seguridad!

Resultado: Vulnerabilidades, secretos expuestos, configuraciones inseguras... todo llegando a producción.

🚀 La Arquitectura de Nuestro Pipeline Seguro

Nuestro nuevo pipeline tiene 4 fases críticas:

1. 🐳 Construcción con Etiquetas Inteligentes

# Tags únicos por commit + ambiente
IMAGE_TAG_SHA: "sha-${GITHUB_SHA::7}"
IMAGE_TAG_ENV: "${{ inputs.target_env }}-latest"

🔍 Escaneo de Vulnerabilidades con Trivy

- name: Security Scan con Trivy
  run: |
    docker run --rm \
      -v $(pwd):/src \
      aquasec/trivy:latest \
      image --severity CRITICAL,HIGH \
      mi-imagen:${TAG}

Trivy nos ayuda a encontrar:

Vulnerabilidades en paquetes del sistema
Dependencias con CVEs conocidos
Secretos expuestos accidentalmente
Configuraciones inseguras

3. 🏗️ Validación de Dockerfile con Checkov

- name: IaC Security con Checkov
  run: |
    docker run --rm \
      bridgecrew/checkov \
      --file Dockerfile \
      --framework dockerfile

Checkov revisa que nuestro Dockerfile siga mejores prácticas:

¿Usuario root? ❌
¿Paquetes sin actualizar? ❌
¿Secretos hardcodeados? ❌

4. 🚫 Bloqueo Automático en Fallos

La magia está aquí: si hay vulnerabilidades CRÍTICAS o ALTAS, el pipeline SE DETIENE.

if [ "$VULNERABILIDADES" -gt 0 ]; then
  echo "❌ WORKFLOW BLOQUEADO"
  echo "Hay $VULNERABILIDADES problemas de seguridad"
  exit 1
fi

📊 Dashboard de Seguridad en Tiempo Real

Lo mejor de todo: todo aparece automáticamente en GitHub Actions Summary:

🐳 Reporte de Escaneo - Trivy
══════════════════════════════

📊 Resumen General
──────────────────
| Tipo              | Severidad  | Cantidad |
|-------------------|------------|----------|
| Vulnerabilidades  | 🔴 CRÍTICA | 2        |
| Vulnerabilidades  | 🟠 ALTA    | 9        |
| Total             |            | 11       |

🏗️ Checkov Security Scan  
══════════════════════════

✅ Todos los checks pasaron (22 passed, 0 failed)

🎯 El Resultado: Confianza Automatizada

Antes:

"Ojalá no haya vulnerabilidades"
Auditorías manuales cada 3 meses
Incidentes de seguridad recurrentes

Después:

✅ Cada commit validado automáticamente
✅ Cada imagen escaneada antes de publicar
✅ Cada despliegue con reporte de seguridad
✅ Cero vulnerabilidades en producción desde la implementación

💡 Lecciones Aprendidas

1. Seguridad ≠ Lentitud

Muchos piensan que agregar security scanning hará lento el pipeline. ¡Falso! Nuestros escaneos agregan solo 2-3 minutos.

2. Fail Fast es Mejor que Fail in Production

Preferimos que falle el pipeline (y notifique al desarrollador) a que falle en producción (y afecte a usuarios).

3. Los Reportes Son Tu Mejor Aliado

Un reporte claro y automático hace que los equipos entiendan y arreglen los problemas, no solo los "parcheen".

🚀 Implementa en 3 Pasos Sencillos

==================================

Paso 1: Clona y explora

git clone https://github.com/francotel/docker-image-security-scan  
cd docker-image-security-scan

Paso 2: Examina el workflow

Revisa .github/workflows/publish-nginx-image.yml - ¡todo está listo para usar!

Paso 3: Adapta a tu caso

Modifica nombres de imágenes, registros y políticas según tu stack.

📈 Impacto Inmediato

Detección: De trimestral a en cada commit
Cobertura: De muestras a 100% de imágenes
Confianza: De "espero" a "sé que está validado"

🤝 ¿Cómo Contribuir?

El proyecto está activo en github.com/francotel/docker-image-security-scan

¿Ideas para mejorar?

Notificaciones en Slack/Teams
Dashboard histórico
Escaneo automático de imágenes base
Policy as Code personalizado

🎯 ¡Hazlo Hoy!

Ventajas clave:

✅ Gratuito (open source)
✅ Simple (un archivo YAML)
✅ Efectivo (bloquea problemas reales)

Acción inmediata:

⭐ Dale estrella al repo
🐑 Haz fork y adapta
💬 Comenta en issues

¿Listo para seguridad automatizada?👉 github.com/francotel/docker-image-security-scan

#DevSecOps #GitHubActions #DockerSecurity

¡No te lo pierdas! Sígueme en LinkedIn para estar al tanto de todas las actualizaciones y futuros artículos:

☕ Apóyame con un café

Si este contenido te ha sido útil y quieres apoyarme para seguir creando más, considera invitarme un café. ¡Tu apoyo hace la diferencia! 🥰

¡Gracias por leer y hasta la próxima! 👋

🚀 ¡Despídete del Caos de Configs! Mi Viaje con Azure App Configuration: Escalabilidad, Seguridad y 0 Downtimes en Microservicios

francotel — Thu, 13 Nov 2025 03:04:45 +0000

💭 Imagina esto:

Eres un desarrollador apasionado (como yo 😅) que lleva semanas lidiando con configs dispersos entre YAMLs, repositorios Git y variables de entorno olvidadas.

Tus microservicios en Node.js, Python y Go crecen rápido, pero cada cambio —por mínimo que sea, como actualizar un db.host— termina en reinicios manuales, merge conflicts y noches sin dormir tratando de entender por qué algo rompió en producción. 😵‍💫

Un viernes (sí, otro viernes de deploys peligrosos), decidí que ya era suficiente. Ese día conocí a Azure App Configuration, y fue como pasar del caos al control total.

☁️ El Giro de la Historia: Cómo App Configuration Salvó Mi Proyecto

Primero, abrí el Portal de Azure y creé mi App Configuration Store — literalmente un par de clics.

De pronto tenía un repositorio centralizado de configuraciones donde podía definir:

🔑 Key-Value pairs (app.name=MiServicio)
🚦 Feature flags para rollouts dinámicos
🔐 Referencias a secretos en Key Vault

Mi código cambió de esto:

// El viejo infierno 😅
const dbHost = process.env.DB_HOST || 'localhost';

a esto:

// El nuevo orden ⚡️
const dbHost = await client.getConfigurationSetting({ key: 'db.host' });

Y sin reiniciar nada.
Los SDKs de Azure cachean los valores localmente, así que ni latencia ni downtime.

Cada microservicio —desde mi clúster de Kubernetes hasta mis pipelines— empezó a hablar el mismo idioma de configuración.

💎 Ventajas que Brillaron en Mis Entrevistas

Cuando comencé a implementar Azure App Configuration, no solo resolví problemas técnicos: también logré destacar en entrevistas de arquitectura y DevOps. Cada punto fuerte del servicio se transformó en una historia concreta que demostraba control, escalabilidad y visión de futuro.

🌍 Escalabilidad sin límites

Azure maneja miles de requests con un 99.9% de disponibilidad garantizada.

En mi demo, App Configuration procesó más de 10,000 lecturas diarias sin una sola caída — ideal para entornos híbridos con microservicios distribuidos en Kubernetes o AKS.

💡 Ejemplo que compartí en una entrevista: “Gracias al cacheo local del SDK, mis servicios siguieron operando incluso durante una breve desconexión del Portal de Azure.”

🔐 Seguridad empresarial

La integración con Azure Key Vault fue un cambio de juego.

En lugar de almacenar contraseñas o tokens directamente, App Configuration solo guarda la referencia segura del secreto.

{
  "uri": "https://myvault.vault.azure.net/secrets/db-password"
}

🧩 Demo en Acción: App Configuration + Node.js + Terraform

Para llevar esta historia más allá del papel, preparé una demo funcional que combina Azure App Configuration, Terraform y Node.js en un entorno totalmente automatizado.

El servidor Node.js renderiza en tiempo real los valores definidos en App Configuration — título, color de fondo y tamaño de fuente — sin necesidad de reiniciar el contenedor.

🧠 Cada cambio que hagas desde el Portal de Azure se refleja automáticamente en la UI del servidor.

📦 Puedes revisar el código completo y probarlo tú mismo en mi repositorio:

👉 https://github.com/francotel/azure-app-config-terraform-demo

🧭 ¿Y si trabajamos juntos?

Este proyecto es una base.En CrossCloudX, diseñamos pipelines a la medida para empresas financieras, consultoras o startups con visión.
¿Te interesa un piloto en tu empresa?

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

🛡️ Elimina secretos, escanea dependencias y duerme tranquilo: Así funciona un pipeline moderno DevSecOps

francotel — Thu, 24 Jul 2025 22:56:00 +0000

🔍 “¿Y si hoy tu build revelara una clave secreta en producción?”

💣 “¿Y si una librería obsoleta estuviera exponiendo tu app bancaria sin que lo sepas?”

Esta es la historia real de cómo un pipeline bien diseñado salvó a un equipo de infraestructura de un incidente de seguridad mayor.

☁️ El dilema: Seguridad vs Velocidad

Muchos equipos de desarrollo y DevOps se enfrentan al mismo conflicto:“¿Cómo integramos seguridad sin frenar nuestros despliegues?”

En consultorías, bancos y empresas tech, he visto pipelines que usan hojas de Excel para reportar vulnerabilidades. Sí, Excel en pleno 2025. 🧟‍♂️

La consecuencia:

Secretos hardcodeados en el código fuente 😱
Dependencias con vulnerabilidades críticas 🐛
Mala visibilidad en auditorías 🔍

💡 La solución: Un pipeline CI con visión DevSecOps

He creado una PoC que automatiza seguridad desde el primer push, sin sacrificar la velocidad.
🔗 Repositorio público: gitsecops-cicd-poc

👇 ¿Qué incluye esta primera fase CI?

Etapas del pipeline:

Etapa	Herramienta	Qué detecta 🕵️
`Checkout Code`	GitHub Actions	Descarga del código
`Cache Trivy`	Trivy	Optimiza tiempos
`Secrets Scan`	Trivy	🔐 Claves, tokens
`Configs Scan`	Trivy	🛡️ Permisos inseguros
`Build Docker Image`	Docker	Compilación controlada
`Dependencies Scan`	Trivy (SCA)	📦 CVEs en libs y SO
`Notify`	Slack Webhook	📢 Alertas en tiempo real

🧪 ¿Por qué Trivy?

Trivy no solo escanea imágenes Docker.También detecta:

Secrets en el código fuente (AWS keys, tokens, etc.)
Errores de configuración en YAMLs
Vulnerabilidades en dependencias (package.json, requirements.txt, etc.)
CVEs a nivel de sistema operativo (Alpine, Debian, etc.)

⚠️ Todo esto en menos de 2 minutos por pipeline.

🧠 Caso de uso empresarial

👉 Contexto: Consultora de seguridad financiera
Una fintech tenía múltiples microservicios desplegados sin control de versiones ni escaneo de imágenes.
Con este pipeline CI se logró:

Detectar más de 30 secretos hardcodeados antes del merge
Visibilidad en Slack de cada build inseguro
Aprobación interna de seguridad sin llenar formularios

Resultado: Cumplieron auditoría SOX en tiempo récord. 🎯

🔜 ¿Y el CD?

Este post cubre solo la etapa CI.La segunda parte incluirá:

Despliegue en ambientes segregados (Dev, UAT, Prod)
Validación post-deploy
Políticas de rollback
Escaneo en tiempo de ejecución

🛠️ ¿Cómo empezar?

Clona el repo 👉 git clone https://github.com/francotel/gitsecops-cicd-poc
Agrega tu workflow.yml desde la carpeta .github/workflows
Crea tu webhook de Slack para recibir alertas
🎯 Ejecuta un push y deja que Trivy haga su magia

🧠 Bonus: Hacks que usamos

🔄 Cacheo de Trivy para escanear más rápido
🕵️‍♂️ Reglas personalizadas para detectar secretos locales
🔐 Uso de chmod 777 como trampa para validación
🤖 Notificación temprana al equipo antes del merge

🧯¿Por qué esto es mejor que Excel?

ExcelDevSecOps PipelineManual, lento, reactivoAutomático, veloz, proactivoRequiere validación humanaIntegración directa al códigoDifícil de auditarLogs en tiempo realSilos entre equiposSeguridad como parte del DevOps

🧭 ¿Y si trabajamos juntos?

Este proyecto es una base.En CrossCloudX, diseñamos pipelines a la medida para empresas financieras, consultoras o startups con visión.
¿Te interesa un piloto en tu empresa?
📩 Escríbeme o abre un issue en el repo: gitsecops-cicd-poc

📌 TL;DR

✅ Pipeline CI moderno con Trivy
✅ Escaneo de secretos, dependencias y configuración
✅ Notificación directa a Slack
✅ Base sólida para DevSecOps real

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

Run IBM DataPower in Docker in 5 Minutes! 🚀 (No IBM Cloud Needed!)

francotel — Tue, 03 Jun 2025 03:09:24 +0000

"IBM DataPower is a powerful API gateway, but it's usually locked behind complex setups. Let’s run it locally with Docker—no licenses or cloud accounts required!"

🔧 What You’ll Need

Docker installed (👉 Install guide)
5 minutes of time
Terminal (Bash or ZSH)

🔍 Before We Start: About Skopeo

Need to check container versions before downloading? Skopeo is your friend! This handy tool lets you:

🔎 Inspect images without pulling them
🏷️ List available versions (tags)
🔄 Copy images between registries

skopeo list-tags docker://icr.io/cpopen/datapower/datapower-limited

📂 Step 1: Prep Your Workspace

mkdir datapower && cd datapower

Using version 2018.4.1.9 (stable and widely compatible):

# Pull the specific DataPower version
docker pull icr.io/cpopen/datapower/datapower-limited:2018.4.1.9

Launch the container with persistent configs

docker run -it \
  -v $PWD/config:/drouter/config \
  -v $PWD/local:/drouter/local \
  -e DATAPOWER_ACCEPT_LICENSE=true \
  -e DATAPOWER_INTERACTIVE=true \
  -p 9090:9090 \
  -p 9022:22 \
  -p 8000-8010:8000-8010 \
  --name idg \
  icr.io/cpopen/datapower/datapower-limited:2018.4.1.9

🔧 Key Notes (Best Practices!)

🚪 Ports Management

Auto-port assignment: For multi-container setups, use -p 8000 (let Docker choose host port)
Port conflicts? Remap the WebGUI (e.g., -p 9191:9090 → access via http://localhost:9191)

📂 Folder Structure

datapower/
├── config/ # Stores all configurations (edit directly!)
└── local/ # For certificates, scripts (XSLT/JS), and keys

🔐 Security Must-Dos

First step: Change default credentials (admin/admin)!
Production tip: Disable DATAPOWER_INTERACTIVE to avoid log clutter

🌐 Step 2: Enable the Web GUI

In the running container's CLI:

   configure; web-mgmt 0 9090;  # Activates WebGUI

Access it:
URL: https://localhost:9090
Credentials: admin / admin (change this!)

Cleanup:

docker stop idg && docker rm idg

🏁 Conclusion

You've now got IBM DataPower running in Docker in just minutes! Key takeaways:

✓ Local testing without expensive hardware

✓ Persistent configs via Docker volumes

✓ Full access to WebGUI and CLI

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

Kubernetes 1.33: Change Pod Size Without Restart! (No More Problems!)

francotel — Fri, 30 May 2025 02:23:57 +0000

😅 The Problem Every DevOps Knows

Imagine this: It's midnight, your app has too many users, and your Pods need more CPU and memory. But in Kubernetes, changing resources means:

Delete and restart the Pods (bye-bye, active connections!)
Wait for a rolling update (more waiting time)
Hope there's no downtime (but there's always some)

Until now, changing Pod resources required a restart. But with Kubernetes 1.33, this is no longer true! 🎉

🚀 What's New? Pods That Grow Without Restarting!

Now you can:
✅ Increase/Decrease CPU and memory without restarting
✅ Works with StatefulSets (great for databases!)
✅ Choose if the Pod restarts on errors

Real-life example:

Problem: An API gets 10x more traffic than usual
Old way: Rolling update → 30 seconds of downtime
New way: kubectl patch → 0 downtime

💡 How to Use It? (Easy Code Example 🛠️)

1. Create a Pod with resize policy

apiVersion: v1
kind: Pod
metadata:
  name: scalable-app
spec:
  containers:
  - name: web
    image: nginx
    resources:
      requests:
        cpu: "1"
        memory: "1Gi"
      limits:
        cpu: "2"
        memory: "2Gi"
    resizePolicy:  # The magic is here!
    - resourceName: cpu
      restartPolicy: NotRequired  # No restart if it fails
    - resourceName: memory
      restartPolicy: NotRequired

2. Change resources while running

kubectl patch pod scalable-app -p '{
  "spec": {
    "containers": [{
      "name": "web",
      "resources": {
        "requests": {"cpu": "2", "memory": "2Gi"},
        "limits": {"cpu": "3", "memory": "3Gi"}
      }
    }]
  }
}'

Done! The Pod keeps running with more resources.

🏢 Why Is This Good for Companies?

🔄 Less downtime → Better for important apps
💰 Save cloud costs → Reduce resources when not needed
📈 Handle traffic spikes fast → No waiting for deployments
🗃️ Better for databases → No restarts to change memory

⚠️ Any Problems?

Not all runtimes support it yet (check your CRI)
You need to configure it (add resizePolicy)
New feature = possible bugs (test first in staging)

🔚 Conclusion: A Big Step for Kubernetes

Now you can change Pod resources without restarting. No more choosing between "low resources" or "risky restarts".

Will you try it? Tell me in the comments! 👇

📌 Did you like this? Share and follow for more Kubernetes/DevOps posts. 🚀

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

Misconfigured S3 Buckets: Detect and Remediate with AWS Config + Lambda

francotel — Wed, 07 May 2025 17:55:24 +0000

🚨 1. The Hidden Danger: S3 Buckets Left Public

Many developers create S3 buckets using the default console settings, CLI scripts, or even automation templates (like CloudFormation or Terraform) — without fully reviewing access policies.

🎯 What could go wrong?

public-read or public-write is enabled by mistake
Bucket policies allow Principal: "*"
Static websites are deployed with no access restrictions
Files contain sensitive data: .env, backup.zip, user-data.csv

Case Study

A dev team created a bucket to share app logs for debugging. The bucket had public access, and after 3 weeks it was indexed by a search engine. It contained logs with API keys and customer email addresses.

💸 This resulted in an internal audit and months of cleanup work.

🔎 2. What Causes These Misconfigurations?

Rushed deployment with aws s3api create-bucket
CI/CD pipelines that skip security checks
Inexperienced teams who don't understand IAM or bucket policy syntax
Copy-pasted infrastructure templates with bad defaults
Developers assume "private unless shared" — but S3 can default to public

⚠️ 3. Consequences of Misconfigured Buckets

Impact	Description
🕵️‍♂️ Data Exposure	Customer data, code, secrets available online
💰 Cost Spike	Public write access can be exploited to store malware or pirated files
❌ Compliance Violation	Breach of GDPR, HIPAA, SOC2 or ISO27001
📉 Reputational Damage	Public trust loss, press coverage
🛠️ Incident Response	Reactive patching, forensic work, legal reports

✅ 4. How to Fix It Automatically

💡 Best combo: AWS Config + Lambda

🧭 AWS Config

Monitors and evaluates your AWS resources against a list of compliance rules. For S3, it can detect:

Public read/write access
Missing encryption
Logging not enabled

⚙️ AWS Lambda

Executes custom code to fix non-compliant resources, instantly and automatically.

Together, they create a self-healing cloud security workflow.

🛡️ AWS Config Rules: Managed vs. Custom (S3 Security Demo)

Feature	🔧 Managed Rules (AWS)	⚡ Custom Rules (Your Code)
🚀 Setup Speed	✅ Instant (~1 minute)	⏳ 15-30 mins (coding required)
🔧 Maintenance	🤖 Fully automated by AWS	👨💻 Your team maintains
💡 Intelligence	📜 Fixed logic (CIS benchmarks)	🧠 Your custom business logic
🔒 S3 Protection	🛡️ Basic security checks	🛡️🛡️🛡️ Advanced protection
💸 Cost	💰 Included in Config pricing	💰💰 + Lambda costs
🛠️ Demo Ready?	❌ Too generic	✅ Perfect for custom demos!

I'm Choosing Custom Rules for Precision Targeting 🎯

🔐 Auto-Securing S3 Buckets with AWS Config & Lambda

🚀 Full Architecture & Deployment Code on GitHub

This automated solution protects your S3 buckets by:

Detecting risks → Unencrypted buckets/public access
Auto-fixing issues → Enforces KMS encryption & security settings
Maintaining compliance → Continuous AWS Config monitoring

✨ Key Features:

Terraform-powered infrastructure
Python Lambda remediation logic
Zero-touch security enforcement
Demo mode included for testing

📦 GitHub Repo Includes:

✅ Complete Terraform deployment

✅ Lambda source code

✅ Architecture diagrams

✅ Step-by-step instructions

🔗 Get the Code →

🔄 Before Fix

🚨 Non-compliant bucket:

No encryption ❌
Public access allowed ❌

⚡ After Auto-Remediation

✅ Encryption enabled (KMS)

✅ Public access blocked

🕒 Compliance achieved in <1 minute

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

🛠️ Automate AMI Builds with Packer + EC2 Image Builder

francotel — Tue, 15 Apr 2025 11:37:27 +0000

📦 DevOps Battle for Golden Images in AWS

🧭 1. Why Automate AMI Builds?

Golden AMIs ensure that all your EC2 instances start with consistent, hardened, and pre-configured environments.

❌ Manual builds = human errors, time waste, inconsistent images

✅ Automated builds = repeatable, secure, auditable

⚔️ 2. Packer vs EC2 Image Builder: The Showdown

Feature	🧰 Packer	🖼️ EC2 Image Builder
🔧 Configuration Language	JSON or HCL	YAML or Console
🔄 Integration with CI/CD	✅ Very flexible	⚠️ Limited (manual triggers, EventBridge workaround)
🛡️ Security Controls	✅ Custom via hardening scripts	✅ SSM + IAM roles
📦 Output Formats	AMIs, Docker, Vagrant, etc.	AMIs (only)
☁️ AWS Native	❌ Third-party tool	✅ Fully managed
📜 Logging & Visibility	CLI or external	✅ CloudWatch logs, detailed history
🧪 Testing AMIs	Manual or via external tools	✅ Supports testing phases (e.g., InSpec)
💰 Cost	Low (runs in your own infra)	Low, but requires pipeline resources

🏁 TL;DR:

Use Packer when you need portability and full control.

Use EC2 Image Builder when you prefer AWS-native, low-maintenance pipelines.

🔧 3. Demo: Building a Hardened Ubuntu AMI in Both Tools

Option A: Using Packer + HCL

Define ubuntu.pkr.hcl:

packer {
  required_plugins {
    amazon = {
      version = ">= 1.2.8"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

source "amazon-ebs" "ubuntu" {
  ami_name      = "learn-packer-linux-aws"
  instance_type = "t2.micro"
  region        = "us-west-2"
  source_ami_filter {
    filters = {
      name                = "ubuntu/images/*ubuntu-jammy-22.04-amd64-server-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["099720109477"]
  }
  ssh_username = "ubuntu"
}

build {
  name    = "learn-packer"
  sources = ["source.amazon-ebs.ubuntu"]
  provisioner "shell" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get install -y nginx",
    ]
  }
}

Build the image:

packer init .
packer build ubuntu.pkr.hcl

Option B: Using EC2 Image Builder

Create a Recipe

Example component in YAML:

name: install-nginx
description: Install Nginx
phases:
  build:
    commands:
      - apt update
      - apt install -y nginx

Create a Pipeline with:

Source AMI: Ubuntu 22.04
Build Component: install-nginx
Test Component (optional): e.g., check Nginx service
Output: AMI in target region

Trigger manually or via EventBridge for automation (e.g., weekly builds)

🎯 5. Conclusions & Recommendations

Verdict:

🧰 Use Packer if:

You want cross-cloud image creation

You need integration with existing pipelines

You're comfortable managing infrastructure

🖼️ Use EC2 Image Builder if:

You're all-in on AWS

You want minimal setup with native controls

You want to integrate with AWS Config, IAM, and SSM easily

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

Friday Deployments: A Horror Story 💀

francotel — Fri, 21 Mar 2025 15:11:06 +0000

It was 4:55 PM on a Friday at SpookyCloud Inc.. Alice, the lead developer, stretched her arms and smiled.

"Just one last deployment before the weekend!" she said.

Bob, the DevOps engineer, looked up in horror. "Wait... you’re deploying on a Friday?"

"Relax, it’s just a small update. What could go wrong?" Alice laughed as she ran:

git push origin main

☠️ Big mistake.

🚨 The Chaos Begins

At 5:02 PM, alerts flooded Slack:

🔥 500 Internal Server Error!

🔥 Database connection failed!

🔥 API Gateway timeout!

The production site was down.

Bob frantically checked the logs:

kubectl logs -l app=backend --tail=20

👀 ERROR: Missing database migration

Alice gasped. "Oh no... I forgot to apply the migration!"

Bob tried to roll back:

kubectl rollout undo deployment backend

⚠️ FAILED: Image not found

😨 The rollback failed. They were trapped.

⏳ The Longest Friday Night

By 7:30 PM, Bob and Alice were still debugging. Their Slack statuses changed to:

🛠️ “Fixing production 😭”

By 9:45 PM, the CTO joined the call:

"Why are we down? Who pushed to main on a Friday?"

Alice turned pale. She felt a chill down her spine.

"It was me... I thought it was safe..." she whispered.

The CTO sighed. "Well, guess what? We’re all working late now."

By 1:15 AM, they finally fixed the issue. The site was back, but their weekend was ruined.

📜 Lessons from the Nightmare

🕵️‍♂️ Never deploy on a Friday.

📋 Test in staging first.

🔄 Always have a rollback plan.

🛑 Feature flags are your friend.

🔥 Don't Let This Happen to You

Do you really want to risk your weekend?

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊

🧟‍♂️ The Zombie Server That Wouldn’t Die 💀

francotel — Wed, 12 Mar 2025 22:47:05 +0000

🕛 The Midnight Nightmare

It was midnight at SpookyCloud Inc.. The office was dark, and the only light came from Bob’s laptop screen. He was tired, ready to go home when suddenly...

🔔 Slack Alert: "EC2 instance terminated"

"Finally," Bob sighed. That old server was deleted weeks ago.

But then...

🔔 Slack Alert: "EC2 instance running"

Bob’s heart skipped a beat. "No... no way," he whispered.

He opened the AWS console — there it was, running again. He stopped it once more.

🔔 Slack Alert: "EC2 instance running"

😨 The server was back... again.

💀 The Monster Grows Stronger

Every time Bob stopped the server, it returned — stronger and angrier. The CPU usage climbed higher, draining resources like a hungry beast.

Bob checked the logs... nothing. No deployments, no cron jobs. It was as if the server had a mind of its own.

He grabbed his keyboard and typed:

aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[*].Instances[*].[InstanceId,Tags]'

📋 The result? No tags. No owner. No clues.

"It's a ghost..." Bob muttered.

👁️ The Forgotten Curse

Digging deeper, Bob discovered the truth — the server belonged to a forgotten Auto Scaling Group from an ex-employee. Each time the server died, the group brought it back to life... like a cursed tomb opening again and again.

Bob’s fingers shook as he ran this final command:

aws autoscaling delete-auto-scaling-group \
  --auto-scaling-group-name "zombie-asg" \
  --force-delete

⚰️ The server was gone. For real this time.

📜 The Moral of the Story

Like any good fable, Bob learned important lessons that night:

🧟‍♂️ Always tag your resources. A tagless server is a mystery waiting to haunt you.
🧟‍♂️ Clean up old environments. Forgotten test systems may return from the grave.
🧟‍♂️ Review your Auto Scaling Groups. Hidden triggers can summon the undead.
🧟‍♂️ Automate cleanup tasks. Don’t leave ghost servers to haunt your bill.

🤝 Let's Connect!

If you find this repository useful and want to see more content like this, follow me on LinkedIn to stay updated on more projects and resources!

If you’d like to support my work, you can buy me a coffee. Thank you for your support!

Thank you for reading! 😊