Forem: Mohammad-Ali A'RÂBI

7 Noob Git Tips

Mohammad-Ali A'RÂBI — Tue, 14 Apr 2026 15:53:41 +0000

#Git_Noob_Tip is a title for a set of beginner-friendly git tips that I tweet every week. At the time this post is being published, I have tweeted 7 of those, and I'm going to compile them together into this post. I'll also add context and more details.

Tip 1. Delete Remote Branch

// Detect dark theme var iframe = document.getElementById('tweet-1517458191910531072-746'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1517458191910531072&theme=dark" }

Deleting a local branch is rather easy:

git branch -d <branch>

The -d flag checks if the branch is merged and then deletes it. To delete a local branch no matter what, we have to use the big D:

git branch -D <branch>

Then, it comes to deleting a remote branch from git's CLI:

git push origin --delete <branch>

Of course, one can delete a remote branch using the UI application that manages the remote repo, e.g. GitHub or GitLab. But this is handier.

Also, to check what remote branches there are, you can list them using:

git branch --remote

Tip 2. Rename or Move a File

// Detect dark theme var iframe = document.getElementById('tweet-1519994911654825984-770'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1519994911654825984&theme=dark" }

So, once I went to work and my colleague told me: "We should tell John to change his script to do that." Of course, the script was written by me. What did John do? He moved the script to a subdirectory and changed two lines of it.

Git usually gets confused when you rename/move a file and change its content at the same time. Git would think the old file was deleted and a new file was created. All of the version history is simply lost.

To prevent such things from happening, one should rename or move, using git:

git mv <src> <dest>

Instead of doing:

mv <src> <dest>

Tip 3. Rebase When Pulling Master

// Detect dark theme var iframe = document.getElementById('tweet-1522531843446390785-488'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1522531843446390785&theme=dark" }

When pushing, your local branch must be ahead of the remote branch, otherwise, the push is rejected. This is called the "fast-forward rule". In the case of a feature branch, one can force-push, but one should never force-push to master.

So, always keep your local master ahead.

That is done by rebasing. When you want to update your master branch with the remote repo, and especially when you have local changes, do a rebase pull:

git pull --rebase origin master

Otherwise, a merge commit might be created on your local repo and you can never push to master again.

Tip 4. Git Default Branch

// Detect dark theme var iframe = document.getElementById('tweet-1525068639631814659-755'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1525068639631814659&theme=dark" }

A bit of context: Until some 2 years ago, the default branch of every git repository was called "master". It was a synonym for "the default branch". Then there was an initiative to change this because it was offensive to some people. GitHub was the first one to react and changed the default branch name to "main". On git, the default branch name stayed "master", but an option was added to change it.

So, until recently, if you initialize a git repo locally, the default branch name would be master:

git init

This behavior was changed in the last version, and now it actively asks you to "set" a default branch name before it allows you to init. This is done as follows:

git config --global init.defaultBranch <name>

Some popular names are the following:

master: the original name
main: the one popularized by GitHub
trunk: the name used by the older version control tool, SVN
development: used in the repos with a certain workflow

Tip 5. Stash Message

// Detect dark theme var iframe = document.getElementById('tweet-1527605134318096384-435'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1527605134318096384&theme=dark" }

Git stash is a place to store your unfinished work to do things like changing the branch or pulling the latest changes. Then one can pop the changes and continue working.

Although the stash is designed not to become too large, it might. I usually end up having 20 different stashed changes and not knowing what is what and finally dropping them all.

This can be avoided by adding a message to your stash:

git stash push -m <message>

Then, when you want to look at your stash, you also see the messages:

git stash list

Tip 6. Auto-Stash

// Detect dark theme var iframe = document.getElementById('tweet-1530144576970924032-548'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1530144576970924032&theme=dark" }

This one is a child of tips 3 and 5. First of all, if we want to rebase every time we pull, why not make it the default? Also, if we want to stash our uncommited changes every time we pull/rebase, why not make it automated? That's what this tip is about:

git config --global pull.rebase true
git config --global rebase.autoStash true

By setting these config values, next time you have some changes in your local, you can still do a pull. The changes will be stashed, a rebase will happen on your branch, and the changes will be poped from the stash.

Tip 7. Push Default Branch

// Detect dark theme var iframe = document.getElementById('tweet-1532703423941984260-924'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1532703423941984260&theme=dark" }

Let's say you created a new branch locally, named my-fantastic-branch, and you want to push it to the remote repo. The first time you're pushing, you need to specify the name again and instruct git that this is your "upstream" branch from now on so that git creates the branch on the remote repo:

git push --set-upstream origin my-fantastic-branch

This is usually tedious and prevents people from using descriptive branch names. To avoid this and set the remote branch to have the same name as the local one by default:

git config --global push.default current

Next time on push, there is no need to repeat yourself.

Securing Asgard: Why I Built a Card Game Suite for Docker Security

Mohammad-Ali A'RÂBI — Fri, 03 Apr 2026 12:28:14 +0000

This is a submission for the DEV April Fools Challenge

What I Built

What do you do when you have a series of narrative-driven Docker security workshops featuring 10 elite "Commandos" fighting CVE monsters in Asgard?

You could write more documentation. You could add more tests. Or, you could do the most "anti-value" thing possible: Build a full-featured arcade suite where these security characters play Blackjack and Swiss Jass.

Presenting the Asgard Arcade: A collection of four utterly useless but technically over-engineered games designed to distract developers from actual security work while simultaneously drilling "Security Metaphors" into their brains.

The Lore: Docker Commandos & Black Forest Shadow

The Docker Commandos are a team of 10 elite specialists, each representing a core Docker security feature (e.g., Gord is docker init, Jack is docker scout). Their journey began in the Black Forest Shadow universe—a dark fantasy retelling of container security where warriors fight shadowy monsters called CVEs in the year 1865.

From the 19th-century Black Forest to the futuristic golden districts of Asgard, these characters teach DevSecOps through immersive storytelling.

Black Forest Shadow — A Dark Fantasy Guide to Docker and Kubernetes Security - Docker and Kubernetes Security - Docker and Kubernetes Security

A dark fantasy novel set in the Black Forest of 1865 that teaches Docker and Kubernetes security through narrative — covering CVE hunting, SBOM generation, runtime hardening, and container security.

dockersecurity.io

The Games:

Asgard Siege (Tactical Defense): A game where you must counter CVE threats (like "The Supply Chain Hydra") by deploying the correct Commando. Choose wrong, and Asgard's security level crashes.
Blackjack with Jack: Standard Blackjack, but against Angra (the shadow villain). If you are dealt Jack (the Cyborg Commando), you get a "Scout Bonus" to see the dealer's hidden card.
Asgardian Jass (Schieber): A 4-player Swiss trick-taking game. We replaced standard suits with Shields, Attestations, Hardened Images, and Signatures. Jack is the "Bure" (highest trump).
The Reference Deck: A simple card-comparison game to learn the "Power," "Stealth," and "Legacy" stats of each character.

Demo

You can experience the arcade yourself at dockersecurity.io/commandos (scroll down to the "Asgard Arcade") or jump directly into a game below:

The Tactical Siege

Docker and Kubernetes Security

From supply chain to runtime: build safer images, lock down clusters, instrument logging & audit trails, and stay ahead of emerging threats. The comprehensive guide by Mohammad-Ali A'râbi.

dockersecurity.io

Blackjack with Jack

Docker and Kubernetes Security

From supply chain to runtime: build safer images, lock down clusters, instrument logging & audit trails, and stay ahead of emerging threats. The comprehensive guide by Mohammad-Ali A'râbi.

dockersecurity.io

Asgardian Jass

Docker and Kubernetes Security

From supply chain to runtime: build safer images, lock down clusters, instrument logging & audit trails, and stay ahead of emerging threats. The comprehensive guide by Mohammad-Ali A'râbi.

dockersecurity.io

Code

The project is built within the official DockerSecurity.io website repository.

How I Built It

Full Disclosure: Every single game in this arcade, the UI components, the AI logic, and even this very blog post were entirely developed and written by Gemini CLI, an interactive agent. I simply provided the "utterly useless" vision, and the agent executed the over-engineering.

Built with Next.js 14, Tailwind CSS, and Radix UI.

The Jass Engine: Features a heuristic AI for your partner (Evie) and opponents (Angra & Jack the Miner) that follows suit rules, handles trump logic, and manages complex turn states.
Dynamic State: Utilizes React state machines to manage trick resolution, "Zero-Day Exploit" dealer logic in Blackjack, and the deteriorating security level of Asgard during sieges.
Accessible Visuals: Custom character portraits with responsive aspect ratios and high-visibility suit indicators (e.g., Shields for SBOMs, Fingerprints for Identity).

Prize Category

I am submitting this for the Community Favorite category.

While it solves exactly zero real-world security vulnerabilities, it turns the grueling task of learning supply-chain security (SBOMs, Provenance, VEX) into a series of addictive arcade games. It’s the ultimate "Anti-Value" tool: it encourages developers to spend their "Build Time" playing cards with a cyborg cowboy instead of fixing their Dockerfile.

Created by Mohammad-Ali A'râbi (Docker Captain) & Gemini CLI

Dockerizing a Java 26 Project with Docker Init

Mohammad-Ali A'RÂBI — Tue, 31 Mar 2026 13:56:57 +0000

Docker Init was introduced in Docker Desktop 4.27, before LLMs became the default answer to everything. It's a "smart" interactive wizard that analyzes your project and generates:

A Dockerfile (multi-stage, production-ready)
A compose.yaml file
A .dockerignore file
A README.Docker.md with build and run instructions

What makes it valuable is that it's deterministic—not a probabilistic guess. It produces the same correct output every time, following Docker's own best practices.

Technical Requirements

Docker Desktop 4.27 or later

Create a New Project

I'm using a Spring Boot project. Because it's early Spring now and I haven't touched one in a while—so let's go.

Head to start.spring.io and create a project with:

Project: Maven
Language: Java
Spring Boot: 4.0.5 (or whatever the latest stable is)
Packaging: Jar
Java: 26

I used these coordinates, but pick your own:

Group: io.dockersecurity
Artifact: hello-wowlrd
Package Name: io.dockersecurity.hello-wowlrd

Download, unzip, and step into the directory:

cd hello-wowlrd

Run Docker Init

As my British friend say, "It's Docker, innit?"

docker init

The interactive wizard detects your Java project automatically. Accept "Java", confirm the source directory and Java version, and enter the port:

? What application platform does your project use? Java
? What's the relative directory (with a leading .) for your app? ./src
? What version of Java do you want to use? 26
? What port does your server listen on? 8080

Docker Init generates four files. The one that matters most is the Dockerfile:

# syntax=docker/dockerfile:1

################################################################################
# Stage 1: resolve and download dependencies
FROM eclipse-temurin:26-jdk-jammy as deps

WORKDIR /build

COPY --chmod=0755 mvnw mvnw
COPY .mvn/ .mvn/

RUN --mount=type=bind,source=pom.xml,target=pom.xml \
    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests

################################################################################
# Stage 2: build the application
FROM deps as package

WORKDIR /build

COPY ./src src/
RUN --mount=type=bind,source=pom.xml,target=pom.xml \
    --mount=type=cache,target=/root/.m2 \
    ./mvnw package -DskipTests && \
    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar

################################################################################
# Stage 3: extract Spring Boot layers
FROM package as extract

WORKDIR /build

RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted

################################################################################
# Stage 4: minimal runtime image
FROM eclipse-temurin:26-jre-jammy AS final

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

COPY --from=extract build/target/extracted/dependencies/ ./
COPY --from=extract build/target/extracted/spring-boot-loader/ ./
COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
COPY --from=extract build/target/extracted/application/ ./

EXPOSE 8080

ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]

This is already a proper multi-stage build: separate stages for dependency resolution, compilation, layer extraction, and a minimal runtime image with a non-root user. Gord would approve.

A Note on Java 26 Base Images

The generated Dockerfile references eclipse-temurin:26-jdk-jammy and eclipse-temurin:26-jre-jammy. Since Java 26 was just released, these Eclipse Temurin images may not be fully available on Docker Hub yet.

Swap them out for SAP Machine images instead—SAP's free OpenJDK distribution ships Java 26 on Ubuntu 24.04 (Noble Numbat):

sapmachine:26-jdk-ubuntu-noble
sapmachine:26-jre-ubuntu-noble

Find them on Docker Hub: hub.docker.com/_/sapmachine. Just replace eclipse-temurin with sapmachine in both FROM lines.

Build and Run

docker compose up --build

The generated compose.yaml is minimal:

services:
  server:
    build:
      context: .
    ports:
      - 8080:8080

The application starts, and immediately stops with exit code 0. That's expected: there's no HTTP endpoint to keep it alive.

Add a Controller

Create src/main/java/io/dockersecurity/hellowowlrd/HelloController.java:

package io.dockersecurity.hellowowlrd;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

    @GetMapping("/")
    public String hello() {
        return "Hello, Docker Security!";
    }
}

Add the Spring Web dependency to pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Build and run again:

docker compose up --build

Verify:

curl http://localhost:8080
# Hello, Docker Security!

See It Live — Jfokus 2026

I presented Docker Init and Docker security at Jfokus in Stockholm in February 2026. If you want to see the commands in action rather than reading about them, the full talk is on YouTube:

Conclusion

Java 26 just shipped and Docker Init handles it cleanly out of the box—multi-stage build, layer extraction, non-root user, bind mounts for caching. You get a production-ready Dockerfile in under a minute. When Eclipse Temurin catches up, swap the base images back. Until then, SAP Machine has you covered.

Docker Init is Gord's move. The rest of the Commandos handle what comes after.

The Docker Commandos

Docker Init is assigned to Commando 1: Gord. In the Docker Commandos workshop, each Docker security feature is taught through a character on a mission to defend Asgard from CVE monsters. The ten commandos are:

Gord — docker init: establish a secure base from day one ← you are here
Rothütle — SBOM: inventory every dependency in your image
Jack — Docker Scout: hunt CVEs across your supply chain
The Valkyrie — SBOM Attestations: cryptographically sign your component inventory
Artemisia — Docker Hardened Images: near-zero-CVE base images
Mina — VEX Exemptions: mark false-positive CVEs as not exploitable
RuinTan — VEX Attestations: attach signed exemptions to your image
Captain Ahab — Docker Bake: codify your entire build pipeline in one file
Evie — Cosign: sign images and attestations cryptographically
Agent Null — Zero-Day Defense: harden against unknown, unpatched threats

The workshop has been delivered at WeAreDevelopers World Congress, Jfokus, and Rabobank. More at dockersecurity.io/commandos.

The Complete Docker Read List: Q1 2026 Edition

Mohammad-Ali A'RÂBI — Thu, 26 Mar 2026 17:21:39 +0000

2026 has been phenomenal in the number of books published on Docker or by Docker Captains so far. So, I decided to compile the books published in the first quarter of 2026 into an article for more people to discover them.

You can also read the article here, which looks slightly better.

1️⃣ Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security

Author: Mohammad-Ali A'râbi (Docker Captain)

If you've ever thought learning about Kubernetes and container hardening was a bit dry, Mohammad-Ali A'râbi is here to prove you wrong. Black Forest Shadow is a highly creative, dark fantasy guide to Docker and Kubernetes security.

—Claude

What it's about: The book weaves complex concepts like runtime security, SBOM generation, and container hardening into an exciting narrative set in the mystical Black Forest of 1865.
Why you should read it: It transforms standard cybersecurity challenges—like tracking down CVEs and preventing lateral movement—into an immersive, story-driven adventure. It's ideal for developers and security engineers seeking a distinctive, memorable approach to DevSecOps.
Where to get it:

2️⃣ The Rust Programming Handbook: An End-to-end Guide to Mastering Rust Fundamentals

Author: Francesco Ciulla (Docker Captain)

Rust is the new C, and it's been on my list for 5 years now. Now, finally, I know which book to read to learn it. Written by my dear friend and fellow Docker Captain, Francesco Ciulla, who has been teaching Rust for many years now.

What it's about: This handbook takes you from foundational syntax to advanced features like memory safety and concurrency models. Crucially for this list, it includes dedicated, hands-on sections on Dockerizing and deploying your Rust applications!
Why you should read it: It bridges the gap between beginner tutorials and production-ready coding for low-level system components or high-performance web services.
Where to get it:
- Packt Publishing
- Walmart

3️⃣ Docker for Front-end Developers (Featuring React.js)

Author: Kristiyan Velkov (Docker Captain)

Front-end developers, rejoice! As a backend engineer, it has always been hard for me to onboard frontend people to Docker, because I spoke Klingon for them. My dear friend, Docker Captain Kristiyan Velkov, has done an awesome job writing a containerization guide specifically tailored to how front-end engineers think, build, and ship. I should say, it also looks good.

What it's about: Moving past backend-centric explanations, this book walks you through containerizing real-world applications (with a heavy focus on React). You'll learn how to write clean Dockerfiles, configure NGINX properly, implement multi-stage builds, and handle caching securely.
Why you should read it: It's a purely practical, visually-driven guide that teaches you how to take full ownership of your environments without getting bogged down in abstract backend theory.
Where to get it:

4️⃣ The Ultimate Docker Container Book (Fourth Edition)

Author: Dr. Gabriel N. Schenker

Hitting shelves on March 31, 2026, this absolute heavyweight of a book clocks in at over 750 pages and leaves no stone unturned. Jeez, I need an extra bookshelf just for this book's weight.

What it's about: It takes you from basic container concepts all the way to running production-grade platforms. The fourth edition places a massive new emphasis on security, enterprise governance, compliance, and AI-driven automation patterns.
Why you should read it: It is designed for system administrators, DevOps engineers, and architects who need to build and scale secure, future-ready container platforms across major cloud providers.
Where to get it:
- Packt Publishing

5️⃣ Docker: Das Praxisbuch für Entwickler und DevOps-Teams (5th Edition)

Authors: Bernd Öggl & Michael Kofler

For the German-speaking tech community, the definitive Docker reference guide gets a major Q1 2026 update.

What it's about: A comprehensive, 580+ page practical guide covering everything from setting up Docker to CI/CD pipelines, GitLab integration, Swarm, and Kubernetes orchestration.
Why you should read it: It's an excellent, hands-on resource that balances basic principles with advanced, modern use cases like modernizing legacy applications and working with specialized databases.
Where to get it:
- Rheinwerk Verlag

Honorable Mentions from 2025

Well, while researching the new 2026 Docker books, I stumbled upon a recent video by Bret Fisher interviewing the author of a rather interesting book. That inspired me to add this honorable mentions section. I promise my original intention wasn't to sneak my own book in here, but hey, it just happened!

Learn Docker in a Month of Lunches (Second Edition)

Author: Elton Stoneman

Published in 2025, this is the much-anticipated update to one of the most beloved Docker books on the market.

What it's about: A complete refresh of the classic guide. It breaks down Docker fundamentals into digestible, daily lessons. This edition covers multi-platform builds, the latest cloud container services, and navigating the modern Kubernetes ecosystem.
Why you should read it: If you are a beginner looking for a structured, manageable way to learn—or an experienced dev needing to catch up on years of ecosystem changes—this is the gold standard.
Where to get it:
- Manning Publications

Getting Started with Docker (2025 Edition)

Author: Nigel Poulton (Docker Captain)

Nigel Poulton's fast-paced introduction to Docker received a significant 2025 update, adding a dedicated chapter on running local LLMs with Docker Model Runner — including building a multi-container chatbot app.

What it's about: A streamlined, hands-on guide to container fundamentals, Docker Compose, and microservices — now with a practical AI chapter for developers who want to run models locally.
Why you should read it: It's the quickest path from zero to productive with Docker, and the new AI content makes it uniquely relevant for 2025 and beyond.
Where to get it:
- Leanpub

Docker and Kubernetes Security

Author: Mohammad-Ali A'râbi (Docker Captain)

A DevOps Dozen 2025 finalist for Best DevOps Book of the Year, this practical guide covers container security across the full development lifecycle—from build to production.

What it's about: Ten chapters spanning supply chain security (SBOMs, OCI 1.1 attestations, vulnerability scanning with Docker Scout, Trivy, and Snyk) and runtime protection with Falco, RBAC, and Kubernetes pod security.
Why you should read it: It is the most comprehensive hands-on resource available for teams serious about securing their container platforms end-to-end.
Where to get it:
- DockerSecurity.io
- Amazon

Conclusion

The Docker and Kubernetes ecosystem has never had a stronger reading list, to be completely humble! From dark fantasy security guides to hands-on Rust handbooks and front-end containerization primers, Q1 2026 proves that the community is producing more creative, accessible, and production-focused material than ever before.

Stay tuned as more books are coming in Q2. I'm involved in reviewing one of them, so I'm excited for the quarter to come.

Have a book that should be on this list? Leave a comment.

Reflecting on 2025: Author Debut, New Horizons, and Milestones

Mohammad-Ali A'RÂBI — Fri, 02 Jan 2026 17:16:36 +0000

In 2025, I reached a milestone that reshaped my professional trajectory: I published my first book, Docker and Kubernetes Security. What began as a long-term writing project evolved into a broader body of work—spanning technical articles, conference talks, community initiatives, and a narrative-driven security series. The book was later nominated for the Best DevOps Book of 2025 Award, placing it alongside established titles such as The Phoenix Project Graphic Novel and marking a defining moment in my journey as an author and educator.

TL;DR: Numbers, Numbers, Numbers

Here's the year at a glance:

DEV.to articles published: 37 📝
Medium articles published: 31 📝
Of these, 24 were the Container Security Advent Series, available on DEV.to and Medium.
Git Weekly LinkedIn newsletters written: 18 📰
Conference/meetup talks delivered: 4 🎤
Book published: 1 📚
- "Docker and Kubernetes Security" (nominated for Best DevOps Book of 2025 Award) 🏆

Docker and Kubernetes Security: A Milestone Achieved
Black Forest Shadows: Container Security Advent Series
Blog Posts
Conference and Meetup Talks
Docker Meetup Black Forest and Cloud Native Freiburg
LFX Mentorship Program
Podcast Appearances
2026 Goals
Final Thoughts

Docker and Kubernetes Security: A Milestone Achieved

The book took almost two years to write and half a year to publish. Together with the book, I launched DockerSecurity.io.

Get the free sample chapter: DockerSecurity.io/free-chapter
Get an ebook or a signed copy with 40% discount using code YEAR2025: buy.DockerSecurity.io
Locate your Amazon store link: DockerSecurity.io

The website has a blog of its own, with the following articles published in 2025:

Docker and Kubernetes Security - The Best DevOps Book of the Year Finalist - Docker and Kubernetes Security

From supply chain to runtime: build safer images, lock down clusters, instrument logging & audit trails, and stay ahead of emerging threats. Learn from Mohammad-Ali A'râbi's comprehensive guide.

dockersecurity.io

Black Forest Shadows: Container Security Advent Series

In December, I published a 24-day Advent series on container security, titled "Black Forest Shadows." The series was published both on DEV.to and Medium.

The series follows stories of Gord and Jack, among others, as they navigate Black Forest of 1865 and face shadowy monsters called "CVEs". The series combines folklore with practical container security tips that mimic the in-world challenges.
You have met these characters before: on my book's back cover, and in the preface.

Also, I'm compiling the entire Advent series into a book, which will be published in early 2026.

Mohammad-Ali A'RÂBI

Dec 1 '25

Day 1 — Beginning the Security Advent: Defense in Depth (The Red Bear Inn)

#docker #adventofcode #security #kubernetes

Comments

2 min read

Blog Posts

Posts about Docker and container security:

Docker Exercises: Part I: A set of exercises that I prepared for a Docker workshop.
Run GenAI Models Locally with Docker Model Runner: An introduction to Docker Model Runner.
Docker Deep Dive Workshop at WeAreDevelopers: A writeup on the workshop I did in WAD Berlin.
The Largest NPM Supply Chain Attack Ever and How to Defend Against It: About the NPM supply chain attack of September 2025.
I Just Published My Book: Docker and Kubernetes Security: About my book.
Open-Source Docker Book for Hacktoberfest: A new project for Hacktoberfest.
Top 5 Container Security Books in 2026: A curated list of container security books for 2026.
Docker Hardened Images Are Free.

Posts about git:

20 Git Tips for 20 Years of Git: Git Yearly issue of 2025.
Git Submodule Update: How to update your git submodules.
7 Basic Git Commands: Seven git commands everyone should know.
How to Fixup a Commit: How to create a "fixup" commit.

Conference and Meetup Talks

In 2025, I delivered four talks at various conferences and meetups:

Bake a Docker Cake at PlatformCon (June 2025)
Docker Deep Dive Workshop at WeAreDevelopers World Congress in Berlin (July 2025)
5 Docker Commandos at #cTENcf Birthday Bash Freiburg (October 2025)
Node.js Supply Chain Security + dhi at Node.js Meetup #46 in Berlin (November 2025)

Docker Meetup Black Forest and Cloud Native Freiburg

The Docker Meetup Black Forest continued to thrive in 2025, with regular events held at JobRad's campus in Freiburg. We were able to bring together Docker enthusiasts from the region and beyond to share knowledge and experiences. We were honored to welcome the following Docker Captains as speakers:

Timo Stark, traveling to Freiburg from Nuremberg
Jonas Scholz, traveling to Freiburg from Karlsruhe
Lize Raes, traveling to Freiburg from Basel, Switzerland
Julian König, local Docker Captain from Freiburg

In addition, we joined our forces together with DevOps Meetup Freiburg to create the Cloud Native Freiburg group, which is a CNCF Chapter. I also launched Dockburg.com as a community hub for both meetup communities.

LFX Mentorship Program

In 2025, I had the privilege of joining the Linux Foundation's LFX Mentorship Program as a mentor. Here is my mentorship profile. There are three graduated mentees listed under my profile, as well as 24 active mentees.

Podcast Appearances

In 2025, I had the opportunity to appear on a couple of podcasts and live-streams:

The latter appearances were part of the Docker Captains Summit 2025.

2026 Goals

As we enter 2026, I already have three confirmed talks at major conferences:

Dockerize Securely: SBOMs + Attestations + Bake at Jfokus 2026 in Stockholm, Sweden (February 3, 2026)
Java Supply Chain Security with Docker at JCON Europe 2026 in Cologne, Germany (April 20, 2026)
Defense Against the Dark Arts: NPM Attack at EnterJS 2026 in Mannheim, Germany (June 16, 2026)

I'm also working on two articles for JAVAPRO magazine, to be published in early 2026 (print version distributed at JCON Europe 2026).

Apart from these, here are my goals for 2026:

Complete and publish the "Black Forest Shadows" advent series as a book. 📖
Continue to grow the Docker and Kubernetes Security community through meetups and online content. 🌐
Become a CNCF Ambassador. 🤝
Start with my Git Kaizen project, inspired by my Git Weekly series. 🥋

What else should I put on the list? Let me know!

Final Thoughts

Looking back, 2025 was the year I stopped treating writing, speaking, and community work as side projects and started approaching them as a coherent, long-term craft. It clarified where I create the most value: at the intersection of engineering, security, and storytelling. Going into 2026, the focus is no longer on proving that I can ship—but on refining, deepening, and scaling what already works, while staying curious enough to explore new formats and ideas.

Day 24 — Design for Resilience (The Last Stand)

Mohammad-Ali A'RÂBI — Wed, 24 Dec 2025 10:11:00 +0000

As Angra advances, Gord whispers to Rothütle, "You stand here and not there, and that's our victory today."

Then she raises her sword.

YAML gets close to Rothütle, holding his dagger ready.

"You brought a dagger to a sword fight," Rothütle says, smirking.

Then as YAML marches forward, Rothütle swings his sword and cuts off YAML's hand.

"You have a long hand, but you're short-sighted," Rothütle adds, stepping back. "You let Angra creep into your mind too easily."

YAML steps back in pain, clutching his stump.

Jack gets furious, and Gord punches him in the face, knocking him to the ground.

Angra roars, and a dark mist envelops the area. Angra, as a solid shadow, now aflame, comes forward and starts attacking Gord.

Rothütle steps forward, blocking the shadow's strikes with his shield. But Gord stops him.

"Run," she says. "You need to live."

Gord stabs the shadow with her sword, but it gets stuck in the shadow's body.

The shadow stabs Gord back. She stands still.

Jack attacks Rothütle from behind, but something penetrates the air and hits Jack in the shoulder.

The dragon-archer arrives, and Jack looks at the dragon-archer in shock.

"My mission here is complete," Jack says, and flees into the forest.

The shadow starts launching fireballs around.

A fireball heads toward Rothütle, he blocks it with the shield, but a smaller one hits his arms, burning him.

"Run!" the dragon-archer shouts to Rothütle.

"I'll hold them off."

"Don't despair," Gord says weakly, "We have won this day."

Then she stands up, pulls her sword off the shadow, and swings it at the shadow, chopping its head off.

The shadow roars and turns into twelve smaller shadows.

Gord looks at Rothütle, exhausted, as if she's not ready to fight anymore.

Then she nods to the dragon. He grabs Rothütle and flies into the sky.

"No!" Rothütle shouts, looking back at Gord, who is fighting the shadows alone.

As they ascend, Rothütle faints, exhausted from his burns...

Security Tip #24 — Design for Resilience

Not every system can be saved.

When compromise becomes inevitable, sometimes the goal is no longer to win —

it is to ensure that what matters can escape.

Protect identities, backups, and recovery paths.
Accept that some components must be sacrificed.
Prioritize the survival of critical assets.

A secure system isn't the one that never falls.
It's the one that lets the future continue.

The story doesn't end here...

Stay tuned for the book Black Forest Shadow, coming out in February 2025.

Day 23 — Secure By Design (Black Forest Shadow)

Mohammad-Ali A'RÂBI — Tue, 23 Dec 2025 12:58:44 +0000

Gord and Rothütle take Jack to the castle. As they enter the courtyard, YAML emerges from the shadows, holding a small box.

"Looking for this?" he says, handing the box to Gord.

Then the sky grows dark, and a cold wind sweeps through the forest.

A large dark figure starts to materialize in front of them.

"It's Angra," Gord whispers.

"The Architect is free now," Jack says, stepping back.

Then Jack and YAML go and stand beside the dark figure.

"YAML was on my side all along," Angra's voice echoes through the stone walls.

"So your tall friend is not so useless after all," Rothütle mutters.

"Don't bet on it," Gord replies.

"You can't stop me now," Angra continues.

"So Jack was just a distraction," Rothütle says, realizing the truth.

"We were playing into Angra's hands all along."

"So, you have a miner, a useless moving tower, and some shadows that vanish in torchlight," Gord shouts, facing Angra.

"That makes you unstoppable?"

Angra snarls. Jack picks up an axe and YAML draws his dagger.

Tip of the day: Misconfiguration is an attacker's best friend. Secure your systems by design.

Security Tip #23 — Secure by Design

Angra wins not by strength, but by exploiting weaknesses in the defenders' design.

YAML, who was supposed to be the guard, opened the door for the enemy.

It's the same with your YAML configurations and infrastructure as code. If misconfigured, they can open the door to attackers.

Here are some best practices to ensure your systems are secure by design:

Use secure defaults: Start with the most restrictive settings and only open up what is necessary.
Implement the principle of the least privilege: Ensure that users and services have only the permissions they need to perform their tasks.
Pod Security Standards: There are three predefined Pod Security Standards in Kubernetes: Privileged, Baseline, and Restricted. Use the Restricted profile for production workloads to minimize security risks and only allow necessary capabilities.
Drop unnecessary capabilities: Docker containers run with a default set of Linux capabilities. You can drop all capabilities and only add back the ones you need using the cap_drop and cap_add options in your Docker Compose or Kubernetes manifests.

Pod Security Standards Example

apiVersion: v1
kind: Namespace
metadata:
  name: default
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted

Here, the default namespace is configured to enforce the Baseline Pod Security Standard and audit against the Restricted standard.
This means that any pods created in this namespace must comply with the Baseline standard, and any violations of the Restricted standard will be logged for auditing purposes.

Dropping Unnecessary Capabilities Example

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      capabilities:
        drop: ["ALL"]
        add: ["NET_ADMIN"]

In this example, the Nginx container drops all Linux capabilities and only adds back the NET_ADMIN capability, which is necessary for network administration tasks.

Learn Docker and Kubernetes Security

These two examples were taken from my book Docker and Kubernetes Security, currently 40% off.

Chapter 6 covers securing containers in Kubernetes, including Pod Security Standards and capability management.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.

Day 22 — Chained Attack (The Final Confrontation)

Mohammad-Ali A'RÂBI — Mon, 22 Dec 2025 14:36:03 +0000

As Gord, Rothütle, and Jack are talking, a CVE jumps off a tree and attacks Gord.

"The Architect told me everything about you," Jack says.

"You're an innovator yourself. The Architect is oil to innovation's engine."

"I have seen what is your Architect capable of," Rothütle says, facing Jack.

"He's dangerous. Who can conjure such things?" he says, pointing at the CVE.

Jack smirks. "That's the cue for me to take the keys."

Then he sprints toward her, but Rothütle steps in front of him, raising his shield.

Gord is still fighting the CVE. Rothütle hits Jack's arm with the shield.

Gord sees her chance and slashes the CVE with her sword. It dissolves into mist.

Then Rothütle hits Jack again, this time knocking the axe from his hand.

Jack is distracted, trying to retrieve his weapon. Gord steps forward and points her sword at his throat.

"This ends now, Jack," she says. "Perhaps you should join your Architect friend."

Jack glares at her, "This is not over yet."

"Where is YAML?" Rothütle asks, looking around...

Tip of the day: Attacks rarely come alone. Breaches succeed when multiple weaknesses are exploited at once.

Security Tip #22 — Chained Attacks

Jack doesn't win by strength.

He wins by timing, coordination, and exploiting multiple weaknesses at once.

This mirrors real-world attacks:

Chain known CVEs with privilege escalation exploits.
Use social engineering, perhaps, to gain more access.
Exploit misconfigurations alongside software vulnerabilities.

Defensive takeaways:

Assume attacks are composed and multi-faceted.
Implement defense in depth: multiple layers of security controls.
Correlate signals across systems to detect complex attack patterns.

Winning the fight isn't stopping one attacker — it's preventing the chain.

📘 Learn Docker and Kubernetes Security

To learn how legacy systems impact modern container security — and how to modernize safely — check out my book Docker and Kubernetes Security, currently 40% off.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.

Day 21 — Balancing Speed and Security (Confrontation with Jack)

Mohammad-Ali A'RÂBI — Sun, 21 Dec 2025 14:26:40 +0000

The trio, Gord, Rothütle, and YAML, arrive at the foot of Schattenburg Castle.

The castle is visible on the hilltop, surrounded by dense forest, glowing faintly in the moonlight.

Gord opens a hidden door on the ground. There is a hole in the ground with swords and shields hanging on the walls.

She grabs a shield and a sword, handing them over to Rothütle. "We need to be ready for anything."

"What about him?" Rothütle asks, pointing to YAML.

Gord hesitates for a moment, then hands him a dagger. "You can defend yourself with this."

Closer to the castle, there is a shadow standing among the trees. It steps forward, a bearded man with a two-sided axe.

"Jack," Gord says grimly.

"I've been expecting you," Jack replies with a thick accent. "Your security measures are good, but not good enough."

"What do you want?" Gord asks calmly.

"The best man who can design your defenses is imprisoned in the castle," Jack says.

"Release him to me, and I will leave you in peace."

"He's not your decision to make," Gord replies firmly. "Now leave, before I show you the last bit of my security."

"You understand, don't you?" Jack says facing Rothütle.

"The Architect is helping Carl with his innovations. She's holding back knowledge that belongs to the world."

A shadow moves among the trees...

Tip of the day: Moving fast and breaking things is not a security strategy. Defend your critical assets.

Security Tip #21 — The Balance Between Speed and Security

In today's fast-paced world, security is often seen as a hindrance to speed and innovation. But something that hinders your innovation the most, is going out of business due to a security breach.

Security breaches are costly. They lead to downtime, data loss, and reputational damage. In many cases, they can even lead to the end of a business.

The key to balancing speed and security is to integrate security into your development process. This means adopting a DevSecOps approach, where security is considered at every stage of the software development lifecycle.

This includes:

Automated security testing: Integrate security testing into your CI/CD pipeline to catch vulnerabilities early.
Shift-left security: Involve security teams early in the development process to identify and mitigate risks.
Education and training: Ensure that developers are aware of security best practices and understand the security implications of their code and the dependencies they use.

The sooner in the process you address security, the easier and cheaper it is. You don't want to let Jack walk all over your defenses before addressing the vulnerabilities.

📘 Learn Docker and Kubernetes Security

There is a dedicated chapter on coding securely in my book Docker and Kubernetes Security, currently 40% off.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.

Day 20 — Incident Response (The Ambush)

Mohammad-Ali A'RÂBI — Sat, 20 Dec 2025 10:11:00 +0000

On their way back to Schattenburg, Rothütle and YAML Voorhees move cautiously through the dense forest. Then, suddenly, a shadow is on the path ahead, with eyes glowing in the dim light.

"Give me the light," Rothütle says to YAML, taking his lantern. "Now you can draw your sword."

"But I don't have a sword," YAML replies, confused.

"What? Then how are you going to fight the CVE? With your charm?" Rothütle snaps.

"CVE?" YAML asks.

Rothütle starts looking for something sharp in his pocket, finding only a pen. He grips it tightly, and steps forward.
Whispering to himself, "You can apply for the most useless Guardian of the year award later."

From the shadows, a figure steps forward. It tries to take the lantern from Rothütle, but he stabs the pen into its arm. The figure recoils, and returns to the shadows.

"Let's move," Rothütle says, breathing heavily. Then he sees a CVE grabbing YAML from behind.

He rushes to help, but as he approaches, YAML hits the ground, blowing the lantern out.

"Let's fall back to Gord," YAML gasps, struggling to get up. "She can help us."

Then a bright silhouette appears in the darkness. Gord steps forward, sword drawn, wearing a white cloak.
As she approaches, the CVE dissolves into mist.

"Good to see you, Gord," Rothütle says, relieved. "Nice cloak!"

Gord smiles faintly, pulling off the white cloak and giving it to Rothütle.

"Here, it keeps the CVEs away."

Tip of the day: When under attack, fall back, regroup, and restore stability.

Security Tip #20 — Incident Response: Fallback, Regroup, Restore

When an attack is active, forward motion is the fastest way to make things worse.

Rothütle and YAML don't win by fighting harder.

They survive by falling back to a position where protection still exists.

This is how real incident response works.

1. Fallback — Stop the Bleeding

Isolate affected systems.
Cut network access if needed.
Disable compromised credentials or workloads.
Accept partial downtime to prevent full compromise.

If visibility is gone, assume the attacker still has access.

2. Regroup — Re-establish Control

Restore logging and monitoring.
Verify which systems are still trustworthy.
Identify blast radius before touching production.
Communicate clearly: who owns decisions, who investigates.

Chaos kills response effectiveness faster than attackers do.

3. Restore — Rebuild from Known-Good State

Rebuild systems from clean images.
Redeploy from verified pipelines.
Rotate secrets after containment.
Bring services back gradually, validating at each step.

Never "clean" a compromised system. Replace it.

The Core Lesson

Incidents are not won by heroics.

They are survived by discipline, retreat, and controlled recovery.

Fall back.

Regroup.

Restore stability.

Everything else is noise.

📘 Learn Docker and Kubernetes Security

To learn how legacy systems impact modern container security — and how to modernize safely — check out my book Docker and Kubernetes Security, currently 40% off.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.

Day 19 — Secret Management (The Okterakt)

Mohammad-Ali A'RÂBI — Fri, 19 Dec 2025 13:35:21 +0000

The trio arrives at a cliff. Gord hits the ground with her sword, and then there is a rumble. A hidden pathway reveals itself, leading down the cliffside.

"Stay here," Gord instructs Rothütle and YAML. "I will take a look." She descends the path cautiously.

Rothütle and YAML wait outside. After a few tense minutes, Rothütle hears a movement from among the trees. He looks back at YAML and he seems calm. Then he descends the path as well to find Gord.

Gord is in a chamber carved into the cliffside. In the center is a pedestal with an ornate box—the artifact. Gord approaches it carefully.

"There is someone here in the shadows," Rothütle says, stepping into the chamber.

"Take the artifact and run," a voice hisses from the darkness. A whisper in Rothütle's ear. "It will protect you."

He steps back sharply, checking the shadows. Gord understands immediately. "It's Angra," she says. "Ignore him."

Then she gives Rothütle a long look. "It was a great journey we had together, don't you think?"

Rothütle nods, confused. "Yes, but what do you mean?"

"I just had a moment alone here, and...," Gord pauses.

"You can go to the castle with YAML while I secure the Okterakt."

Rothütle hesitates. "How much longer do you need? I think I can stand guard outside for a bit."

She steps closer and punches him lightly in the shoulder.

"See you in the castle, Rothütle."

Rothütle leaves the chamber reluctantly and tells YAML that they need to head back to the castle. As they walk away, Rothütle glances back at the chamber one last time.

Tip of the day: Keep your secrets safe!

Security Tip #19: Secret Management

In a Kubernetes cluster, secrets such as passwords, tokens, and keys need to be managed securely. Kubernetes provides a built-in resource called Secrets to store sensitive information. However, it's crucial to follow best practices for secret management to ensure the security of your applications.

I have seen many cases where secret resources were stored in plain text within YAML files, committed to version control. This is a major security risk, as anyone with access to the repository can retrieve the secrets.

Here are some best practices for managing secrets in Kubernetes:

Use a dedicated secret management tool like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault to store and manage secrets securely.
You can connect these tools to Kubernetes using external secret operators, which automatically sync secrets from the external store to Kubernetes Secrets.
Avoid storing secrets in plain text within YAML files or version control systems.
Use Kubernetes RBAC to restrict access to secrets only to the necessary service accounts and users.
Regularly rotate secrets to minimize the risk of compromise.
Use Infrastructure as Code (IaC) tools to randomly generate secrets during deployment, rather than hardcoding them.

Angra is out there whispering in the shadows, and Jack is trying to steal your secrets. Don't let them succeed!

📘 Learn Docker and Kubernetes Security

To learn how legacy systems impact modern container security — and how to modernize safely — check out my book Docker and Kubernetes Security, currently 40% off.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.

Day 18 — Misconfiguration (YAML Voorhees)

Mohammad-Ali A'RÂBI — Thu, 18 Dec 2025 13:10:21 +0000

The forest thickens as they approach Sonnenwacht castle. The night arrives early and unexpectedly.

"It's the longest night of the year," Rothütle whispers.

A figure steps from the shadows—tall, cloaked, face hidden beneath a mask.

"What are you doing out here?" Gord says, not expecting to see him.

The figure answers calmly, "I was looking for you. There has been some disturbance."

Gord turns back to Rothütle, "Meet YAML Voorhees. He's a guardian of the Order, and the prison warden."
She looks back at YAML Voorhees as she delivers the last sentence, blaming him for leaving his post.

"What kind of name is that?" Rothütle asks.

"It's short for Yvo Adrianus Matthijs Laurens Voorhees," YAML replies. "But everyone calls me YAML."

"What kind of disturbance?" Gord asks.

YAML Voorhees hesitates, looking at Rothütle. Gord nods for him to continue.
"Jack is here," YAML says quietly. "He's looking for the artifact. We need to secure it."

"So he's really here," Rothütle mutters.

"There is no time, come with me," Gord says, gripping her sword tightly.

Tip of the day: Misconfiguration in YAML files can lead to security vulnerabilities. Always validate and lint your YAML configurations before deploying them.

Security Tip #18: YAML Configuration Security

Kubernetes is complicated, and so are its configuration files. YAML files are used extensively to define Kubernetes resources, but misconfigurations can lead to security vulnerabilities. Always check the YAML files for common mistakes and security issues before deploying them.

You can use SAST tools to scan your YAML files for misconfigurations and vulnerabilities.
Always commit the configuration files to version control to track changes and review them.
Use Helm charts to manage complex configurations and ensure consistency across environments.

📘 Learn Docker and Kubernetes Security

To learn how legacy systems impact modern container security — and how to modernize safely — check out my book Docker and Kubernetes Security, currently 40% off.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.

Forem: Mohammad-Ali A'RÂBI

7 Noob Git Tips

Tip 1. Delete Remote Branch

Tip 2. Rename or Move a File

Tip 3. Rebase When Pulling Master

Tip 4. Git Default Branch

Tip 5. Stash Message

Tip 6. Auto-Stash

Tip 7. Push Default Branch

Securing Asgard: Why I Built a Card Game Suite for Docker Security

What I Built

The Lore: Docker Commandos & Black Forest Shadow

Black Forest Shadow — A Dark Fantasy Guide to Docker and Kubernetes Security - Docker and Kubernetes Security - Docker and Kubernetes Security

The Games:

Demo

The Tactical Siege

Docker and Kubernetes Security

Blackjack with Jack

Docker and Kubernetes Security

Asgardian Jass

Docker and Kubernetes Security

Code

How I Built It

Prize Category

Dockerizing a Java 26 Project with Docker Init

Technical Requirements

Create a New Project

Run Docker Init

A Note on Java 26 Base Images

Build and Run

Add a Controller

See It Live — Jfokus 2026

More Links

Conclusion

The Docker Commandos

The Complete Docker Read List: Q1 2026 Edition

1️⃣ Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security

2️⃣ The Rust Programming Handbook: An End-to-end Guide to Mastering Rust Fundamentals

3️⃣ Docker for Front-end Developers (Featuring React.js)

4️⃣ The Ultimate Docker Container Book (Fourth Edition)

5️⃣ Docker: Das Praxisbuch für Entwickler und DevOps-Teams (5th Edition)

Honorable Mentions from 2025

Learn Docker in a Month of Lunches (Second Edition)

Getting Started with Docker (2025 Edition)

Docker and Kubernetes Security

Conclusion

Reflecting on 2025: Author Debut, New Horizons, and Milestones

TL;DR: Numbers, Numbers, Numbers

Table of Contents

Docker and Kubernetes Security: A Milestone Achieved

Docker and Kubernetes Security - The Best DevOps Book of the Year Finalist - Docker and Kubernetes Security

Black Forest Shadows: Container Security Advent Series

Day 1 — Beginning the Security Advent: Defense in Depth (The Red Bear Inn)

Blog Posts

Conference and Meetup Talks

Docker Meetup Black Forest and Cloud Native Freiburg

LFX Mentorship Program

Podcast Appearances

2026 Goals

Final Thoughts

Day 24 — Design for Resilience (The Last Stand)

Security Tip #24 — Design for Resilience

Day 23 — Secure By Design (Black Forest Shadow)

Security Tip #23 — Secure by Design

Pod Security Standards Example

Dropping Unnecessary Capabilities Example

Learn Docker and Kubernetes Security

Day 22 — Chained Attack (The Final Confrontation)

Security Tip #22 — Chained Attacks

📘 Learn Docker and Kubernetes Security

Day 21 — Balancing Speed and Security (Confrontation with Jack)

Security Tip #21 — The Balance Between Speed and Security

📘 Learn Docker and Kubernetes Security

Day 20 — Incident Response (The Ambush)

Security Tip #20 — Incident Response: Fallback, Regroup, Restore

1. Fallback — Stop the Bleeding

2. Regroup — Re-establish Control

3. Restore — Rebuild from Known-Good State

The Core Lesson

📘 Learn Docker and Kubernetes Security