DEV Community: sai kiran jv

Lesson 2: Killing Port 22 - How to Securely Manage Linux in the Cloud

sai kiran jv — Sun, 08 Feb 2026 17:03:24 +0000

🚀 The Challenge
Most beginners open Port 22 to the entire world so they can SSH into their servers. This is a massive mistake. In minutes, bots will start brute-forcing your server. Today, I built a server with zero inbound ports.

🛠️ The Solution: AWS Systems Manager (SSM)
Instead of using an SSH key (which is a file that can be leaked), I used IAM Roles.

I gave my EC2 an IAM Identity (AmazonSSMManagedInstanceCore).
I closed all inbound firewall rules.
I connected via the AWS browser console.

🐧 Hardening the OS
Once inside, I didn't just leave it "stock." I performed three critical hardening steps:

Patch Management: Upgraded all packages to the latest security versions.
Audit: Used ss -tulpn to verify that no hidden services were listening.
Persistence: Enabled dnf-automatic so the server self-patches security updates daily.

Day 1: Locking the Front Door

sai kiran jv — Sat, 07 Feb 2026 19:18:25 +0000

I’ve officially started my deep dive into DevSecOps. Before I write a single line of application code or launch a server, I need to secure my base. In the cloud, Identity is the new Perimeter. If your identity management is weak, your entire infrastructure is vulnerable.

The "Root" Problem
When I first created my AWS account, I had the Root User. This user is a "God Mode" account—it can delete everything and has no restrictions.

Rule #1 of DevSecOps: Never use the Root user for daily tasks. It’s like carrying the master key to a skyscraper on your keychain while walking through a crowded city. If you lose it, you lose the building.

🛠️ What I Did: The Hardening Checklist
1. MFA Everywhere
Multi-Factor Authentication (MFA) is not optional. I enabled a virtual MFA (Google Authenticator) for my Root account immediately. Even if my password leaks, a hacker can't get in without my physical phone.

2. Created the "Daily Driver" (IAM Admin)
I created a specialized IAM user named devsecops-admin. Instead of giving it "God Mode," I:

Created a User Group called Administrators.
Attached the AdministratorAccess policy to the Group, not the user (Best practice!).
Added my user to that group.

3. Set a Custom Account Alias
Nobody wants to remember a 12-digit AWS Account ID. I created an alias so my login page is professional: https://[my-custom-name].signin.aws.amazon.com/console

4. The "Nuclear" Option: Deleted Root Access Keys
I checked my Root user's security credentials and ensured there were zero active Access Keys. If you have keys for your Root user, delete them now. Use IAM roles or users for CLI access instead.

💡 Key Takeaway
Security isn't something you "add" at the end of a project; it starts with how you log in. By shifting security to the very first step (Identity), I’ve already reduced my account's risk by 90%.

Next Step: Lesson 2 — Hardening the Linux OS and launching my first secure EC2 instance.

Beyond DevOps: My Journey to Mastering DevSecOps in 2026

sai kiran jv — Sat, 07 Feb 2026 19:01:15 +0000

In 2026, building fast isn't enough, you have to build securely. We've all seen the headlines: data breaches, leaked credentials, and supply chain attacks. As a DevSecOps engineer in training, my goal is to prove that security shouldn't be a bottleneck. Instead, it should be an automated, invisible part of the development process.

🏗️ The Project: A Cloud-Native "Fortress"
Over the next few weeks, I am building and documenting a complete, end-to-end DevSecOps pipeline. This isn't just a "Hello World" project. I will be:

Hardening AWS Cloud infrastructure from the ground up.
Automating security scans for every line of code (SAST & SCA).
Containerizing applications with Docker and securing them with Trivy.
Orchestrating with Kubernetes (Amazon EKS) using Zero-Trust policies.
Defending the runtime with real-time threat detection (Falco).

🗺️ The Roadmap
I have broken my learning into 6 core modules, and I'll be posting my notes and "gotchas" for every single lesson:

Module 1: The Secure Foundation (Identity & Networking)
Module 2: The Automation Engine (CI/CD Security)
Module 3: Container Security (Docker & ECR)
Module 4: Kubernetes Mastery (EKS & RBAC)
Module 5: Infrastructure as Code (Terraform & Policy)
Module 6: Observability & AI-Driven Defense

🤝 Why I’m Blogging This
They say you don't truly know a topic until you can explain it to someone else. I’m "Learning in Public" to:

Solidify my knowledge.
Build a portfolio that shows I can communicate technical security concepts.
Help others who are starting their cloud security journey.

Buckle up. In my next post (Lesson 1), we start by locking down the front door: AWS Identity and Access Management.