Programming

In Part 1, you isolated processes with Linux namespaces. In Part 2, you added filesystem isolation with pivot_root and OverlayFS. Now it is time to finish the container runtime. In this final part, you will: Add cgroups to limit memory and CPU Set up virtual ethernet pairs for container networking Build a CLI with Cobra Run the final container and compare it with Docker Cgroups: Resource Limits Namespaces control what a process can see. Cgroups control what a process can use. Without cgroups, a container could use all the memory on the host and crash everything. ...

In Part 1, you built a process with isolated namespaces. It has its own hostname, its own process tree, and its own network stack. But it still shares the host’s filesystem. That is dangerous. The containerized process can read /etc/shadow, write to /usr/bin, or delete anything on the host. We need to give the container its own filesystem. In this part, you will: Understand chroot and pivot_root Download and set up a minimal root filesystem Implement pivot_root in Go Add OverlayFS for layered filesystems (just like Docker images) Mount /proc inside the isolated filesystem Preparing a Root Filesystem A container needs a root filesystem — a directory that contains everything a Linux system needs: /bin, /lib, /etc, /proc, and so on. ...

Containers are not virtual machines. They are just Linux processes with extra isolation. In this series, you will build a mini Docker from scratch in Go. No frameworks. No libraries. Just Go and Linux system calls. By the end of this three-part series, you will have a working container runtime that can: Isolate processes with Linux namespaces Create a separate filesystem with OverlayFS Limit resources with cgroups Set up networking with virtual ethernet pairs Run commands through a CLI In this first part, you will learn what containers really are and how to isolate processes using Linux namespaces. ...

In Part 1, we built a TCP server with SET, GET, and DEL. In Part 2, we added expiry, persistence, and pub/sub. Now we add more data types, benchmark our implementation, and make it production-ready. In this final part, we add: INCR — atomic integer increment LPUSH, LPOP, LRANGE — list operations Benchmarks against real Redis Graceful shutdown with signal handling Better error handling throughout Adding INCR INCR atomically increments a number stored at a key. If the key does not exist, it starts at 0. If the value is not a number, it returns an error. This is how real Redis counters work. ...

In Part 1, we built a TCP server that speaks the Redis protocol. We implemented SET, GET, and DEL commands with in-memory storage. But real Redis has many more features. In this part, we add three important features: Key expiry — keys that delete themselves after a timeout Persistence — saving data to disk so it survives restarts Pub/Sub — publish and subscribe messaging between clients Key Expiry In real Redis, you can set a key with an expiration time. After that time, the key disappears. This is useful for caches, sessions, and rate limiting. ...

Have you ever wondered how Redis works under the hood? In this mini-series, we build a Redis clone from scratch in Rust. No magic. Just a TCP server, a protocol parser, and a HashMap. By the end of this series, you will have a working key-value store that speaks the real Redis protocol. You can connect to it with redis-cli and run commands. This is Part 1. We will build: ...

This is the final article in the Security for Developers series. It brings everything together into a single, actionable checklist you can use for every project. Bookmark this page and review it whenever you start a new project or prepare for a security review. How to Use This Checklist Each item is marked with a priority level: P0 (Critical): Do this before going to production. Skipping it means you are vulnerable. P1 (High): Do this within the first week of production. Important for security posture. P2 (Medium): Do this within the first month. Improves defense in depth. P3 (Low): Nice to have. Do when you have time. Authentication Checklist # Item Priority Details 1 Hash passwords with bcrypt or Argon2 P0 Never store plaintext. Use cost factor 12+ for bcrypt. 2 Enforce minimum password length of 8 characters P0 NIST recommends 8+ characters. Do not require special characters. 3 Use HTTPS for all authentication endpoints P0 Credentials in transit must be encrypted. 4 Implement account lockout after failed attempts P1 Lock after 5-10 failed attempts for 15-30 minutes. 5 Use JWT with short expiration (15-60 min) P1 Combine with refresh tokens for longer sessions. 6 Sign JWTs with RS256 or EdDSA (not HS256 for distributed) P1 Asymmetric signing prevents key sharing. 7 Store tokens in httpOnly cookies (not localStorage) P1 Prevents XSS from stealing tokens. 8 Implement refresh token rotation P1 Invalidate old refresh token on each use. 9 Validate JWT signature and expiration on every request P0 Never trust a token without validation. 10 Support multi-factor authentication (MFA) P2 TOTP or WebAuthn. SMS is better than nothing. 11 Check passwords against breached lists (Have I Been Pwned) P2 Reject passwords that appear in known breaches. 12 Log all authentication events P1 Successful and failed logins, password changes. Reference: Tutorial #2: Authentication ...

In the previous tutorial, you learned about security logging and monitoring. Now let us secure where your code runs. Docker containers are everywhere, but the default configuration is not secure enough for production. In this article, you will learn how to harden Docker containers, scan images for vulnerabilities, and manage secrets safely. Why Container Security Matters Containers provide isolation, but they are not virtual machines. By default: Containers run as root — if an attacker breaks out, they have root on the host Docker images contain hundreds of packages, many with known vulnerabilities Secrets are often baked into images or passed as environment variables (visible in process lists) Network ports are exposed by default — more attack surface A compromised container can lead to: ...

In the previous tutorial, you learned how to scan dependencies for vulnerabilities. But what happens when an attack is already in progress? Without proper logging and monitoring, you will not know until it is too late. In this article, you will learn what to log, what never to log, how to detect attacks, and how to set up meaningful alerts. The OWASP Top 10 lists “Security Logging and Monitoring Failures” as A09 because most breaches go undetected for months. ...

In the previous tutorial, you learned how to protect your application with security headers. But even if your code is perfect, a single vulnerable dependency can compromise everything. In this article, you will learn how to scan dependencies for vulnerabilities, prevent supply chain attacks, and keep your software secure. The Supply Chain Problem Modern software depends on hundreds of third-party packages. A typical Node.js project has 500-1500 dependencies. A Go project has 50-200. Each dependency is code written by someone else — and any of them could contain a vulnerability. ...