Forem: Ali Alp

Introducing Tunnel Whisperer: Surgical Connectivity for Networks That Say "No"

Ali Alp — Fri, 06 Mar 2026 15:54:27 +0000

Your MRI scanner needs to talk to a cloud AI platform. Your vendor needs to reach a single maintenance port on a factory-floor PLC. Your data scientist needs to query an on-premise database from a cloud notebook. The firewall says no to all of them.

Tunnel Whisperer says yes.

Github page

The Problem Nobody Talks About

Enterprise networks are getting stricter. Firewalls block everything except port 443. Deep Packet Inspection kills anything that doesn't look like genuine HTTPS. Legacy devices — hospital scanners, industrial controllers, aging servers — can't run modern VPN clients. And even if you could install one, IT won't open a single inbound port.

This is the Connectivity Gap: the space between what your applications need and what your network allows.

Traditional solutions don't fit:

VPNs (WireGuard, Tailscale) require UDP ports or custom protocols — blocked by DPI.
Reverse proxies (ngrok) expose services to the public internet — a non-starter for healthcare and manufacturing.
SSH tunnels get flagged and dropped by next-gen firewalls.

We built Tunnel Whisperer to close this gap.

What Is Tunnel Whisperer?

Tunnel Whisperer is an open-source tool that creates resilient, port-to-port bridges across separated private networks. It wraps your TCP traffic inside a genuine TLS-encrypted HTTPS stream using Xray's VLESS+XHTTP protocol. To the network, it looks exactly like someone browsing a website.

Client Network             Public Cloud               Server Network
+--------------+        +------------------+        +--------------+
|  tw connect  |--443-->|     Relay VM     |<--443--|   tw serve   |
|              |  HTTPS |  Caddy + Xray    |  HTTPS |              |
| local ports  |        |  (reverse proxy) |        | SSH server   |
| :5432 :3389  |        |  Firewall: 80+443|        | port fwd     |
+--------------+        +------------------+        +--------------+

Your PostgreSQL client connects to localhost:5432. Your RDP client connects to localhost:3389. The traffic flows through an HTTPS tunnel to the server network, where it reaches the actual services. The applications on both ends have no idea a tunnel exists.

Why We Built It

We kept running into the same scenario: a customer with a legitimate connectivity need, a network that blocks everything, and no tool that threads the needle between "too broad" (VPN) and "too public" (ngrok).

Tunnel Whisperer is designed around three principles:

1. Surgical access, not broad connectivity. Each user gets access to exactly the ports they need — nothing more. No host-to-host networking, no route tables, no exposure of adjacent services.

2. Invisible to the network. The traffic is indistinguishable from regular HTTPS. No special ports, no unusual protocols, no signatures for DPI to flag.

3. Zero trust at the relay. The relay VM is a dumb pipe. It stores no SSH keys, no passwords, no application data. If it gets compromised, the attacker gets nothing useful — all plaintext remains encrypted by the SSH layer inside the tunnel.

How It Works: Three Layers of Encryption

Tunnel Whisperer stacks three encryption layers, each serving a different purpose:

Layer	What It Does
TLS 1.3 (outer)	Makes the traffic look like HTTPS. Caddy handles automatic Let's Encrypt certificates on the relay.
Xray VLESS + XHTTP (middle)	Routes users by UUID through the relay. XHTTP splits data into standard HTTP requests for resilience against connection timeouts.
SSH Ed25519 (inner)	End-to-end encryption between client and server. Public-key only — no passwords, no brute-force surface. Per-user `permitopen` restrictions lock each client to specific ports.

The relay terminates TLS but never sees the SSH-encrypted payload. Even if someone owns the relay, they can't read your data.

Real-World Use Cases

Healthcare: DICOM Through a Firewall

A hospital's MRI scanner needs to send images to a cloud AI platform for analysis. The scanner speaks DICOM on port 104 and can't install any software. Tunnel Whisperer runs on a gateway machine on the scanner's LAN, forwarding port 104 through the HTTPS tunnel to the cloud. The scanner sends to localhost:104 as if the AI platform were next door.

Manufacturing: Vendor Access to a Single Port

A machine vendor needs remote access to a PLC's maintenance port for diagnostics. Instead of a VPN that exposes the entire factory network, Tunnel Whisperer gives them access to exactly one port on one device. When the job is done, revoke the key — access gone.

Data Science: Cloud Notebook to On-Premise Database

A data scientist running Jupyter in the cloud needs to query a PostgreSQL database behind a corporate firewall. With Tunnel Whisperer, they connect to localhost:5432 and run queries as if the database were local. No VPN client, no firewall exceptions, no IT tickets.

Getting Started in 5 Minutes

Tunnel Whisperer ships as a single binary for Linux, Windows, and macOS. Build from source with Go 1.25+:

make build          # builds bin/tw

Server Side

tw dashboard                # open the web UI
tw create relay-server      # 8-step wizard: provision a relay VM
tw create user              # 5-step wizard: create a client with port restrictions
tw serve                    # start the server

The relay provisioning wizard handles everything: spinning up a VM on Hetzner, DigitalOcean, or AWS, configuring Caddy for TLS, installing Xray, and locking down the firewall to ports 80 and 443 only.

Client Side

The server admin sends you a config bundle (a zip file with your config and SSH keys). Then:

tw dashboard                # drag-and-drop the zip file
tw connect                  # you're in

That's it. Your configured ports are now available on localhost with automatic reconnection if the connection drops.

The Web Dashboard

Both server and client modes come with a browser-based dashboard for managing everything visually:

Server dashboard — create users, provision relays, monitor connected clients, stream logs in real-time, and open an interactive SSH terminal to the relay — all from the browser.

Client dashboard — upload config bundles, connect/disconnect with one click, and see your active tunnels with bandwidth stats.

No separate web app to deploy. The dashboard is embedded in the same tw binary.

Per-User Access Control

Every user gets:

A unique Xray UUID for relay routing
An Ed25519 key pair for SSH authentication
A permitopen directive restricting them to specific ports

# authorized_keys (auto-generated)
permitopen="127.0.0.1:5432",permitopen="127.0.0.1:3389" ssh-ed25519 AAAA... alice
permitopen="127.0.0.1:104" ssh-ed25519 AAAA... vendor-dicom

Alice can reach PostgreSQL and RDP. The vendor can reach the DICOM port. Neither can reach anything else. Revoking access is instant — remove the key from authorized_keys and the UUID from the relay config. No server restart needed.

Built for Resilience

Connections drop. Networks hiccup. Tunnel Whisperer handles it:

Auto-reconnection with exponential backoff (2s up to 30s max)
SSH keepalive every 15 seconds to detect dead connections early
XHTTP transport splits data into HTTP requests, surviving connection resets that would kill WebSocket-based tunnels
System service mode (tw service install) for auto-start on boot — Linux systemd, Windows SCM, or macOS launchd

Performance

We won't pretend there's zero overhead. Two relay hops and three encryption layers have a cost. Here are real numbers from our benchmarks (relay on Hetzner, ~30ms RTT):

Metric	Direct SSH	Tunnel Whisperer
Throughput (100 MB transfer)	112 MB/s	21 MB/s (~168 Mbps)
Database TPS (pgbench, 50 clients)	~1,790	~80-95
Database latency	~28 ms	~530-630 ms

Tunnel Whisperer excels at bulk transfers, streaming, and interactive sessions where human-speed interaction or continuous data flow hides the latency. For high-frequency RPC workloads with many small round-trips, you'll want to use connection pooling and place the relay geographically close to both endpoints.

The tradeoff is clear: you lose raw speed, but you gain connectivity where no other tool can get through.

How It Compares

	Tunnel Whisperer	VPNs (Tailscale/WireGuard)	Reverse Proxies (ngrok)
Scope	Surgical (port-to-port)	Broad (host-to-host)	Public (port-to-web)
DPI Resistance	High (genuine HTTPS)	Low (custom protocols)	Medium (standard HTTPS)
Deployment	Gateway/sidecar	Agent on every host	Dev/test
Infrastructure	Self-hosted	SaaS/hybrid	SaaS
Relay Compromise	No credential exposure	Varies	Provider-dependent

What's Next

Tunnel Whisperer is currently in alpha. The core tunnel, user management, dashboard, and multi-cloud relay provisioning are all working. Here's where we're heading:

UDP support for protocols that need it
Multi-relay topologies for geographic distribution
Observability — OpenTelemetry-format logging is already in progress
Pre-built binaries and package manager distribution

Get Involved

Tunnel Whisperer is MIT-licensed and open source.

GitHub: github.com/Tunnel-Whisperer/Tunnel-Whisperer
Documentation: tunnel-whisperer.github.io/Tunnel-Whisperer
Video Tutorial: Watch the walkthrough on YouTube

If you've ever stared at a firewall rule that blocks everything and thought "there has to be a better way" — give Tunnel Whisperer a try. We'd love your feedback, bug reports, and contributions.

Tunnel Whisperer — because sometimes the only way through is to whisper.

A practical, governance-first framework for turning your CI/CD pipeline into a secure, reproducible, and audit-defensible supply chain control point.

Ali Alp — Fri, 13 Feb 2026 13:56:25 +0000

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp ・ Feb 13

#devops #cicd #security #productivity

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp — Fri, 13 Feb 2026 13:50:52 +0000

CI/CD pipelines are amazing.

They build, test, package, sign, and ship our software in minutes. They automate what used to take days. They make modern development possible.

They also sit at one of the most dangerous control points in your entire system.

If you build regulated, safety-critical, or security-sensitive software, your CI pipeline is not “just automation.” It executes code, holds secrets, produces artifacts, and pushes to production.

That makes it part of your product’s trust boundary.

So the real question isn’t:

Is our application secure?

It’s this:

Is our build system defensible?

That’s where SCRIPTED CI comes in.

Why CI Is a Supply Chain Control Point

Most teams spend their security energy on:

Application security testing
API authentication
Infrastructure hardening
Runtime monitoring

All important.

But CI pipelines quietly:

Execute third-party code (GitHub Actions, plugins, integrations)
Access privileged credentials (cloud roles, signing keys, tokens)
Produce signed release artifacts
Modify repository state
Pull dependencies dynamically

If an attacker compromises your CI, they don’t need to break your runtime.

They can modify your build.

And if your build is compromised, your product is compromised.

That’s a supply chain problem.

The SCRIPTED Model

SCRIPTED is a governance-first way to think about CI security.
It turns abstract “best practices” into enforceable controls.

Letter	Principle	What It Means
S	Secure Secrets	Minimize and scope credentials in CI
C	Control Execution	Only run approved, immutable code
R	Repeatable Builds	Make builds deterministic
I	Isolated Runtime	Harden where builds execute
P	Policy Enforcement	Automate guardrails
T	Traceability	Make artifacts verifiable
E	Evidence	Be able to prove your controls
D	Defensible Design	Encode security in the system, not the process

Let’s walk through it.

S — Secure Secrets

CI pipelines often accumulate powerful credentials:

GITHUB_TOKEN with write access
Cloud deployment roles
Container registry credentials
Code signing certificates

The default mistake? Over-permissioned tokens.

Instead of this:

permissions: write-all

Do this:

permissions:
  contents: read
  packages: write

Other guardrails:

Don’t expose secrets to fork-based PR workflows
Use short-lived identities (OIDC) instead of static cloud keys
Separate build credentials from deployment credentials
Audit token usage regularly

If a job doesn’t need a permission, it shouldn’t have it.

Simple. Structural. Defensible.

C — Control Execution

CI runs code. Sometimes that code is yours. Sometimes it’s not.

Marketplace actions and plugins are convenient. They’re also external code entering your trust boundary.

This is unsafe:

uses: actions/checkout@v4

Why? Because tags can move.

This is safer:

uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3

Pin to a commit SHA.

That makes the reference immutable.

Stronger moves:

Mirror critical actions into your own org
Vendor high-risk actions locally
Maintain an allowlist of approved actions
Automatically fail builds that reference unpinned actions

Immutable references eliminate silent drift.

R — Repeatable Builds

If you rebuild a release from two years ago, do you get the same binary?

If not, you don’t have reproducibility.

And without reproducibility, you don’t have defensibility.

Instead of:

FROM node:latest

Use:

FROM node@sha256:...

Also:

Enforce lockfiles (go.sum, package-lock.json, etc.)
Pin toolchain versions
Eliminate dynamic dependency resolution
Avoid runtime internet downloads during build

Deterministic inputs must produce deterministic outputs.

Anything else is guesswork.

I — Isolated Runtime

Where your CI runs matters.

Public runners are convenient, but they are shared infrastructure.

For higher-assurance systems:

Use self-hosted runners
Make them ephemeral (destroy after each job)
Restrict outbound network access
Segregate runners by trust boundary

Treat CI runners as production infrastructure.

Because they are.

P — Policy Enforcement

Here’s a hard truth:

Guidelines are not controls.

A control that does not automatically fail is not a control.

If you say:

“All actions must be SHA pinned.”

Then enforce it.

Add a validation step that fails when:

An action is not pinned
Permissions are too broad
An unapproved marketplace action is referenced

Combine this with:

Branch protection
Required status checks
Policy-as-Code (OPA, Conftest, etc.)

Security must be encoded into the pipeline itself.

Otherwise, it will erode.

T — Traceability

For every artifact deployed to production, you should be able to answer:

What source commit built this?
What dependencies were included?
What toolchain was used?
Has it been modified since creation?

If you can’t answer those questions, incident response becomes speculation.

To fix that:

Generate an SBOM for every build
Produce cryptographic provenance (SLSA-style attestations)
Sign artifacts (Sigstore/Cosign)
Keep immutable build logs

This turns builds from opaque processes into verifiable records.

E — Evidence

Security that cannot be demonstrated does not exist.

In regulated environments, you will be asked to show:

How you control third-party execution
How you manage credentials
How you ensure reproducibility
How you maintain artifact lineage

So keep:

Architecture diagrams
Policy definitions
SBOM archives
Signature records
Audit logs

Evidence is not paperwork.
It’s proof of structural control.

D — Defensible Design

This is the outcome.

Not “we follow best practices.”

Not “we trust our team.”

Not “it should be fine.”

But:

Controls are enforced technically
Third-party execution is bounded
Privileges are minimized
Builds are deterministic
Artifacts are verifiable

You replace process-based assurances with structural guarantees.

That’s defensibility.

Phased Adoption (Don’t Boil the Ocean)

You don’t need to do everything at once.

Phase 1 — Baseline Risk Reduction (Weeks 1–4)

Pin all actions to SHAs
Reduce token permissions
Enable branch protection
Add basic workflow linting

Low effort. Immediate risk reduction.

Phase 2 — Structural Governance (Months 1–3)

Mirror critical actions internally
Introduce “Golden Workflows”
Enforce Policy-as-Code validation
Deploy ephemeral runners

Medium effort. Major risk reduction.

Phase 3 — Regulatory-Grade Assurance (Months 3–6)

Hermetic builds (no external network dependency)
SBOM for every artifact
Signed provenance attestations
Hardware-backed signing for releases

High effort. Audit-ready posture.

Why This Matters

CI pipelines:

Execute external code
Hold powerful secrets
Produce signed artifacts
Sit between source and production

They are part of your threat model.

In modern systems, the integrity of your product is inseparable from the integrity of its build process.

SCRIPTED CI isn’t about paranoia.

It’s about recognizing that the build is no longer a convenience layer.

It’s infrastructure.

And infrastructure must be governed.

If you’re operating in regulated environments, or just want to level up your supply chain security, I’d be curious:

Which part of SCRIPTED would be hardest to implement in your organization?

[Boost]

Ali Alp — Mon, 12 Jan 2026 17:39:36 +0000

A technical documentation to ultimate freedom in life

Ali Alp ・ Jan 12

#freedom

A technical documentation to ultimate freedom in life

Ali Alp — Mon, 12 Jan 2026 17:38:05 +0000

This is a default human behavior in C

alicommit-malp / freedom

A technical documentation to freedom in life for software developers :)

freedom

A technical documentation to freedom in life for software developers :)

This is a default human behavior in C

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    bool anger_event = false;
    
    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    if (anger_event) {
        printf("Show anger.\n");
    } else {
        printf("All is calm.\n");
    }

    return 0;
}

This is the upgraded human behavior after doing meditation

While practicing meditation, let thoughts enter but decide if you agree to process them, this will create the gap (freedom) over time.

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>
int main(void)
{
    bool anger_event = false;
    
    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    bool conscious_choice = !anger_event; // ← this

…

View on GitHub

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    bool anger_event = false;

    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    if (anger_event) {
        printf("Show anger.\n");
    } else {
        printf("All is calm.\n");
    }

    return 0;
}

This is the upgraded human behavior after doing meditation

While practicing meditation, let thoughts enter but decide if you agree to process them, this will create the gap (freedom) over time.

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    bool anger_event = false;

    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    bool conscious_choice = !anger_event; // ← this is freedom

    if (anger_event && conscious_choice) {
        printf("Show anger.\n");
    } else {
        printf("All is calm.\n");
    }

    return 0;
}

Diff

Worth sharing ?

When Events Meet Clusters: Building Reactive Micro-services on Kubernetes

Ali Alp — Wed, 10 Dec 2025 21:29:32 +0000

Modern users expect digital systems to feel alive. We touch, we swipe, we click—and we expect something to happen instantly. Yet many micro-services architectures still behave like a slow bureaucracy: they wait, they poll, they block, and under pressure they break. This article explores a simple but powerful idea:

Events can transform ordinary micro-services into reactive, self-organizing systems that scale and recover like living organisms.

This idea matters because most failures in distributed systems arise not from bad code, but from bad coordination. Services depend on each other too tightly. Scaling decisions arrive too late. Recovery mechanisms rely on brittle manual steps. And when demand surges suddenly, teams find themselves firefighting instead of innovating.

To understand how events solve this, we start with a question.

Why do micro-services still wait?

Think of a food-delivery app during a sudden rainstorm. Orders jump tenfold in a minute. Kitchens fill. Drivers vanish. The back-end is overwhelmed. Requests start queuing. API timeouts cascade. Users refresh endlessly. Engineers scramble.

But the underlying problem is simple:

Traditional micro-services react to stress after it hurts.

We rely on metrics like CPU, retries, and liveness probes—signals that come after something has already gone wrong. In biological terms, it’s like touching something hot and waiting for your brain to calculate the temperature before deciding to pull your hand away.

Systems that wait get burned.

So what would a system look like if it reacted instantly—before bottlenecks or failures reached the user?

Reactive micro-services: systems that respond, not poll

To explain reactive architecture, consider a train station:

Polling architecture: You walk to the platform every 30 seconds and ask, “Did the train arrive yet?”
Event-driven architecture: A loudspeaker announces, “Train arriving on platform 4.”

Reactive micro-services don’t keep checking. They listen. They respond. They scale when something actually happens. They recover by replaying what they missed.

To build such behavior, we combine three technologies—each playing a different role in the metaphor of a living system.

Kafka: the nervous system’s signal carrier

Kafka is the backbone of the event-driven organism.

It records every event in durable storage.
It broadcasts signals to any service that needs them.
It supports replay, allowing a service to rebuild state after failure.

If Kubernetes is the body, Kafka is the spinal cord, reliably delivering every neural signal down the line.

When a service dies, Kafka simply replays the events. When a new service appears, it can reconstruct exactly what happened before it joined. This behavior is essential for systems that heal themselves.

Knative: the reflex engine

If Kafka is the nervous system, Knative provides the reflex arc.

Touch something hot → your hand pulls back before your brain consciously processes the danger.

Knative Eventing works the same way:

It watches Kafka topics.
When an event arrives, Knative instantly activates the exact workload needed.
It scales consumers up under load and down to zero when idle.

This enables an infrastructure that responds proportionally to real-world events.

For example, a sudden spike in “OrderCreated” events results in instantaneous consumer scaling—not 60 seconds later, not after CPU hits 80%, but exactly when the load originates.

Kubernetes: the muscle and regeneration system

Kubernetes is the body’s musculature:

It runs containers reliably.
It heals failed pods.
It provides auto-scaling and stable infrastructure.
It maintains the cluster’s general health.

Kubernetes alone is not reactive—it lacks event understanding. But when paired with Kafka and Knative, it becomes the execution layer for a reactive organism.

Together, they form this dynamic:

Kafka senses.
Knative reacts.
Kubernetes adapts and stabilizes.

Patterns for building reactive micro-services

1. Event Choreography

Imagine a parcel moving through a logistics system:

Order placed
Payment confirmed
Package packed
Out for delivery

Each step reacts to the previous event. No central controller. No chain of API calls. Just events that trigger reactions.

2. Event Sourcing

Consider a bank account. Your balance is not stored; it is computed by summing all transactions. Event sourcing uses Kafka to store every change.

Benefits:

Perfect audit history
Ability to rebuild state anytime
Natural resilience to failure

3. CQRS with Kafka Streams

Commands update state. Queries read from a fast, materialized view.

This gives:

smooth scalability
predictable performance
clear separation of responsibilities

Kafka Streams keeps the views up to date in real time.

Why events reduce failures

Most system failures originate from coupling:

A slow service slows everything
A failing service breaks everything
A scaling service overloads everything

Events cut these chains.

Failures become local instead of global.
A bad consumer does not impact producers. A slow processor does not block others. If a consumer crashes, Kafka simply replays events until it recovers.

This is how living systems avoid dying from one malfunctioning cell.

Observability as the organism’s senses

Observability in reactive architectures is not about dashboards—it’s about understanding motion:

Kafka lag = congestion on a highway
Distributed tracing = route visualization
Knative auto-scaling logs = heartbeat signals

The goal is to see the system as an organism, reacting to stimuli and adapting continuously.

What organizations gain

Teams adopting this architecture see:

massive reductions in over-provisioning
better stability under unpredictable workloads
fewer cascading failures
simpler understanding of system behavior
improved developer autonomy

A reactive system frees engineers to build features rather than fight fires.

The idea worth sharing

At its core, this architecture re-frames how we think about distributed systems.

Reactive micro-services aren’t faster machines—they are better listeners.
They don’t wait. They don’t poll. They don’t rely on rigid chains of synchronous calls.

Instead, they respond to the world, recover from damage, scale when needed, and rest when idle.

This is the shift:

From systems that must be controlled
to systems that can self-organize.

And when events meet clusters, that shift becomes possible.

How the live Kubernetes DNS Tunneling Demo Was Scripted ? live at CDS 2025 Conference !

Ali Alp — Tue, 16 Sep 2025 12:43:57 +0000

In the talk CDS 2025 - Breaking Kubernetes for fun and profit
at the ContainerDays Conference 2025, you saw a live demo with moving panes, ASCII art, and Kubernetes commands that just flowed. Here’s the actual script that made it possible.

And here’s a breakdown of the script.

1. The Base: `demo-magic.sh`

The script begins with:

. demo-magic.sh

demo-magic.sh is a small Bash library that makes live demos smoother:

p "text" → prints a command (for narration only).
pe "command" → prints and executes the command.
pei "command" → prints, executes, and leaves pane open for interaction.
TYPE_SPEED=20 → controls how fast characters appear (20 ms per char).

This creates the “typed in front of you” effect without human typos.

2. Preparing a Clean Stage

echo "" > ~/kind.log
kind delete cluster > /dev/null 2>&1 || true
docker kill dnscat2-server> /dev/null 2>&1 || true
tmux kill-pane -a

This resets the environment so you can re-run the demo without leftovers:

Clear previous logs.
Delete any old kind cluster.
Kill the malicious dnscat2 server if running.
Kill all extra tmux panes.

3. Setting Up tmux Panes

tmux split-window -v -p 30
tmux select-pane -t 0 
tmux split-window -h -p 60
tmux select-pane -t 0
tmux clock-mode -t 2

This creates the demo “dashboard”:

Pane 0 (top-left): your main command area.
Pane 1 (bottom 30%): for ASCII visuals initially and later the attacker's DNS server.
Pane 2 (right 60%): for logs/status, with a live clock.

Then:

tmux send-keys -t 1 "watch -t jp2a --width=65 --height=31 Picture1.png |lolcat -a -s 10 -d 60" Enter

Pane 1 shows a looping ASCII-art hacker picture, colored with lolcat.

4. Audience Engagement

echo "Are you ready ???"
wait

wait pauses until you press Enter — a natural place to talk to the audience before starting the heavy steps.

5. Spinning Up the Cluster

tmux send-keys -t 2 " tail -f ~/kind.log" Enter
kind create cluster > ~/kind.log 2>&1 
kind get kubeconfig > ~/.kube/config
kind load docker-image alialp/dnscat2-client > /dev/null 2>&1 
kubectl config set-context --current --namespace demo

Pane 2 tails the log, so the audience sees cluster creation progress.
kind create cluster builds the Kubernetes-in-Docker cluster.
The dnscat2-client image is preloaded into the cluster.
Context is switched to the demo namespace.

6. Bringing in the Evil Server

tmux send-keys -t 1 C-c
tmux send-keys -t 1 "bash ./dns-evil-server.sh" Enter
kubectl create namespace demo

Pane 1 stops showing ASCII art and instead launches your malicious DNS server.
Namespace demo is created.

7. Manipulating CoreDNS

kubectl wait --namespace kube-system --for=condition=Ready pod --all --timeout=90s
kubectl replace -f coredns-cm.yaml --force
kubectl rollout restart -n kube-system deployment coredns
kubectl wait --namespace kube-system --for=condition=Ready pod --all --timeout=90s

This ensures the DNS manipulation ConfigMap is in place to support localhost DNS forwarding via docker and the CoreDNS is restarted cleanly.

8. Deploying the Malicious Client

tmux send-keys -t 2 C-c
tmux send-keys -t 2 "watch -t -d -n 1 -- kubectl get pods -n demo" Enter
pei "cat ./dnscat2-client-pod.yaml"
pe "kubectl apply -f dnscat2-client-pod.yaml"

Pane 2 now watches the demo namespace pods.
The manifest is shown (cat) then applied.
Audience sees the pod start running.

9. Waiting for Pod Readiness

while ! kubectl get pod dnscat-client -o jsonpath="{.status.phase}" 2>/dev/null | grep -q Running; do sleep 1; done;

This loop blocks until the pod is Running.

10. Switching Pane Colors and Sniffing Traffic

tmux select-pane -t 1 -P 'bg=#872736'; 
tmux send-keys -t 2 C-c
tmux send-keys -t 2 "kubectl sniff -n demo dnscat-client -o - |tshark -i -" Enter

Pane 1 background turns red to draw attention and shows that a DNS tunneling session has been created between the Kubernetes pod and the attacker's DNS server.
Pane 2 starts packet capture from the client pod, piping into tshark.

11. Showing Exfiltration in Action

kubectl exec -n demo pods/dnscat-client -- watch -t -d -n 1 ls -al  /home/

From Pane 0, the client is controlled via DNS tunneling — audience sees live file listings.

12. Ending the Demo

p "echo 'Press Enter to end the demo! '"
echo "✅ Demo complete!"
echo "Cleaning up..."
kind delete cluster
docker kill dnscat2-server
tmux kill-pane -a 
clear

Cleanup is automatic: cluster deleted, server killed, panes closed, screen cleared.

13. Why It Works

demo-magic handles timing and typing.
tmux gives multiple views: art, logs, live status.
send-keys lets you preload commands into panes, so nothing is manually retyped under stress.
wait gives natural narration breaks.
color and visuals keep the audience engaged.

14. Takeaway for Attendees

You can adapt the same approach for any technical live demo:

Pre-script your commands with demo-magic.
Use tmux to dedicate panes to visuals, background logs, and main typing.
Use ASCII art or colors to keep people looking at your screen.
Always add cleanup steps so you can rerun reliably.

Happy coding :)

At the recent Kubernetes Munich Summit, I introduced a concept called 4D Thinking—seeing beyond the visible to understand hidden context. The interest it sparked inspired me to write this article and share it more widely.

Ali Alp — Tue, 29 Jul 2025 13:01:59 +0000

Ali Alp

Jul 29 '25

4D Thinking: Every visible moment has an invisible backstory

#selfimprovement #productivity #career #mindset

Comments

4 min read

4D Thinking: Every visible moment has an invisible backstory

Ali Alp — Tue, 29 Jul 2025 12:35:43 +0000

Most of what we experience in life is filtered through the lens of the third dimension—what we can see, touch, hear, and measure. We often take situations, people, or images at face value. But what if we could train ourselves to think in a fourth dimension—not in a physics sense, but in a psychological and emotional sense? Let’s call it 4D Thinking: the practice of recognizing the unseen context behind what appears obvious.

In the age of curated images, polished presentations, and performative happiness, 4D Thinking is a much-needed mindset shift. It’s about asking: What’s the story I’m not seeing? What’s the cost behind that picture? What’s hidden behind the moment I’m witnessing?

The Vacation That’s Not What It Seems

You scroll past an ad online: a stunning tropical resort. A beautiful couple laughs as they leap into a crystal-clear pool, cocktails in hand. The sun glistens, their bodies are tan and toned, and the ocean hums in the background.

But 4D Thinking stops you from getting pulled into the fantasy.

You wonder: Is it unbearably hot there in the afternoon? Do the rooms smell of mildew after the daily downpours? Are there swarms of mosquitoes after sunset that make evenings uncomfortable? Maybe the couple is posing for the camera but just had an argument 10 minutes ago. Maybe that laughter is part of a staged shoot, and the moment disappears once the photographer clicks "save."

You’re not being cynical—you’re being aware. You're seeing dimension four: the context, the discomfort, the complexity behind the aesthetic.

The Couple on the Rainy Night

It’s a lonely, rainy Friday night. You’re stuck at home with no plans. Out your window, you catch a glimpse of a couple walking under one umbrella, dressed elegantly, laughing as they rush through the drizzle—clearly heading out for a romantic evening.

In 3D, it stings. You feel behind. Alone. Disconnected.

But in 4D? You imagine: Maybe this date has been planned for months, the only chance they had between conflicting schedules. Maybe they’re trying to rekindle something after a rough patch. Maybe one of them had a depressive episode and tonight is a rare spark of light after weeks of darkness. Or maybe this is the first and last date they'll ever have.

4D Thinking re-frames your assumptions. You realize you're not looking at a whole story—just a single page.

The CEO Behind the Curtain

In many workplaces, people see the CEO as the one with all the power, luxury, and respect. The fancy car. The corner office. The confident speeches.

But 4D Thinking says: Look deeper.

You ask: What does it feel like to carry the weight of hundreds of livelihoods? What kind of pressure comes with knowing that one wrong decision could mean layoffs or lawsuits? Do they get to sleep peacefully at night? Do they even talk to their family anymore? Are they lonely?

What if they’re exhausted? What if they fantasize about walking away from everything, just to feel human again?

When you see with 4D Thinking, power stops looking like freedom—and starts looking like sacrifice.

Why 4D Thinking Matters

We are bombarded with third-dimensional inputs—photos, posts, appearances, behaviors. But those are outputs, not full realities. Without context, we mistake fragments for wholes.

4D Thinking helps us:

Reduce envy by remembering that beauty and success often carry hidden burdens.
Cultivate empathy by realizing that everyone is fighting battles we cannot see.
Stay grounded by resisting the illusion that others live “better” or “easier” lives.
Become wise observers instead of quick judges.

It’s not about distrusting everything. It’s about understanding that every visible moment has an invisible backstory.

Other Everyday Examples of 4D Thinking

The influencer with the perfect life might be battling addiction, depression, or burnout off-camera.
The child acting out at school might be coping with violence or neglect at home.
The coworker who snapped at you might have just lost a loved one but didn’t want to talk about it.
The person who seems lazy might be dealing with chronic illness or deep fatigue that isn't visible.

Each of these examples becomes clearer—not in 3D, but in 4D.

How to Practice 4D Thinking

Pause before judging – The first impression is rarely the full picture.
Ask “What might be going on behind this?” – Context is everything.
Hold two truths at once – Someone can be both successful and struggling. Happy and hurting. Together and on the edge of breaking.
Stop comparing your behind-the-scenes to someone else's highlight reel – You’re not seeing their full footage.

Final Thought

4D Thinking is not about being pessimistic. It’s about being emotionally intelligent. The world often presents itself in clean, edited scenes. But life is messy, uncertain, and filled with layers.

When you begin to see those hidden layers, you stop being fooled by illusions—and you start becoming truly compassionate, resilient, and wise.

Because the truth is: behind every smiling face, every perfect scene, every polished success... there’s a story. And 4D Thinking helps you see it.

🇩🇪 Preparing for the German Naturalization Test ?

Ali Alp — Thu, 17 Jul 2025 15:13:01 +0000

Ali Alp

Jul 16 '25

🇩🇪 Einbürgerungstest / Naturalization Test — Made Easy

#productivity #anki #citizenship

Comments

4 min read

🇩🇪 Einbürgerungstest / Naturalization Test — Made Easy

Ali Alp — Wed, 16 Jul 2025 13:08:44 +0000

If you're applying for German citizenship or permanent residency, you’ll need to submit a certificate proving you’ve passed the Einbürgerungstest (naturalization test) to your local KVR.

To pass this test, you must study 310 questions—10 of which are specific to the federal state you live in.

You can find the official PDF with all the questions "As of May 7, 2025" here (BAMF site), which looks like this:

🚧 The Problem

Learning 310 questions from a plain PDF isn’t easy—especially if you’re still learning German. Many of the questions contain unfamiliar words, and constantly switching to translation apps or GPTs gets frustrating fast.

There are some apps available, but most are filled with ads or hidden costs, which makes the experience even worse.

As a software engineer, I knew there had to be a better way—and I found one that I’m now sharing for everyone who wants to pass the Einbürgerungstest peacefully and efficiently.

✅ The Solution

Before building anything myself, I checked GitHub and found this fantastic project:
👉 Anki German Citizen Test (by vlad-ds)

It does exactly what I had in mind: A free, ad-free, offline-friendly flashcard deck for Anki.

🧠 What is Anki ?

Anki is a free flashcard app that helps you remember things efficiently using spaced repetition. It shows you difficult questions more often and easier ones less often, so you learn faster and retain better.

🔧 How to Use It

Download and install Anki
👉 https://apps.ankiweb.net/
Import the flashcard deck
👉 Base deck (300 questions)

You’ll now see something like this:

When you click “Show Answer,” you’ll get:

✅ The correct answer
🧠 Explanations of all answer options
🌍 The English translation of the question

Here’s an example:

Correct Answer: hier Meinungsfreiheit gilt.

Explanation: The correct answer is "hier Meinungsfreiheit gilt," which translates to "there is freedom of expression here." Freedom of expression is a fundamental democratic right that allows individuals to express their opinions publicly, even if these opinions are critical of the government. This is protected by Germany's Basic Law, which ensures that citizens have the right to express themselves without fear of censorship or retribution.

Explanation of the Other Answers:

1. "Hier Religionsfreiheit gilt" (here there is freedom of religion):
- While freedom of religion is another essential democratic right in Germany, it primarily pertains to the ability to practice one's religious beliefs freely. It doesn't inherently ensure the right to criticize the government.

2. "Die Menschen Steuern zahlen" (people pay taxes):
- Although paying taxes is a civic duty in Germany, it does not correlate with the right to free speech or the ability to criticize the government. Tax payment is unrelated to the freedom of expression.

3. "Die Menschen das Wahlrecht haben" (people have the right to vote):
- The right to vote is crucial in a democracy, allowing citizens to participate in electing their leaders and shaping government policies. However, it does not directly grant individuals the freedom to speak against the government. Voting rights and freedom of expression are separate democratic rights.

In summary, freedom of expression ('Meinungsfreiheit') is the specific right that allows people in Germany to speak openly against the government, making it the correct answer.
-----------------------------
Translated question:

001. In Germany, people are allowed to openly say something against the government because ...

1. freedom of religion applies here.
2. people pay taxes.
3. people have the right to vote.
4. freedom of opinion applies here.

🎯 Smart Learning with Anki

Anki tracks how well you remember each card. After answering, you choose how easy or hard it was:

Based on your rating, Anki decides when to show the card again—so you focus more on what you struggle with.

🏙️ Don’t Forget the 10 State-Specific Questions

Each German state has 10 extra questions. Here's how to get the right ones:

Berlin deck (included in original repo):
👉 Berlin Questions
Bayern (Bavaria) deck (I added this one):
👉 Bayern Questions

🎉 Enjoy Learning the Einbürgerungstest — Ad-Free and In Peace!

Whether you're a newcomer or a long-term resident, this method makes the test way more approachable, even if you're still learning German.

Good luck—and see you on the other side of citizenship! 🇩🇪

🚨 Your Kubernetes Cluster Is a Ticking Time Bomb (Unless You Patch It)

Ali Alp — Wed, 14 May 2025 09:59:43 +0000

Ali Alp

May 14 '25

The Inevitable Decay: How Long Before an Unpatched Kubernetes Cluster Becomes Critically Vulnerable?

#kubernetes #security #devops #cloudnative

Comments 1

3 min read

Forem: Ali Alp

Introducing Tunnel Whisperer: Surgical Connectivity for Networks That Say "No"

The Problem Nobody Talks About

What Is Tunnel Whisperer?

Why We Built It

How It Works: Three Layers of Encryption

Real-World Use Cases

Healthcare: DICOM Through a Firewall

Manufacturing: Vendor Access to a Single Port

Data Science: Cloud Notebook to On-Premise Database

Getting Started in 5 Minutes

Server Side

Client Side

The Web Dashboard

Per-User Access Control

Built for Resilience

Performance

How It Compares

What's Next

Get Involved

A practical, governance-first framework for turning your CI/CD pipeline into a secure, reproducible, and audit-defensible supply chain control point.

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp ・ Feb 13

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Why CI Is a Supply Chain Control Point

The SCRIPTED Model

S — Secure Secrets

C — Control Execution

R — Repeatable Builds

I — Isolated Runtime

P — Policy Enforcement

T — Traceability

E — Evidence

D — Defensible Design

Phased Adoption (Don’t Boil the Ocean)

Phase 1 — Baseline Risk Reduction (Weeks 1–4)

Phase 2 — Structural Governance (Months 1–3)

Phase 3 — Regulatory-Grade Assurance (Months 3–6)

Why This Matters

[Boost]

A technical documentation to ultimate freedom in life

Ali Alp ・ Jan 12

A technical documentation to ultimate freedom in life

This is a default human behavior in C

alicommit-malp / freedom

A technical documentation to freedom in life for software developers :)

freedom

This is a default human behavior in C

This is the upgraded human behavior after doing meditation

This is the upgraded human behavior after doing meditation

Diff

Worth sharing ?

When Events Meet Clusters: Building Reactive Micro-services on Kubernetes

Why do micro-services still wait?

Reactive micro-services: systems that respond, not poll

Kafka: the nervous system’s signal carrier

Knative: the reflex engine

Kubernetes: the muscle and regeneration system

Patterns for building reactive micro-services

1. Event Choreography

2. Event Sourcing

3. CQRS with Kafka Streams

Why events reduce failures

Observability as the organism’s senses

What organizations gain

The idea worth sharing

How the live Kubernetes DNS Tunneling Demo Was Scripted ? live at CDS 2025 Conference !

And here’s a breakdown of the script.

1. The Base: demo-magic.sh

2. Preparing a Clean Stage

3. Setting Up tmux Panes

4. Audience Engagement

5. Spinning Up the Cluster

6. Bringing in the Evil Server

7. Manipulating CoreDNS

8. Deploying the Malicious Client

9. Waiting for Pod Readiness

10. Switching Pane Colors and Sniffing Traffic

11. Showing Exfiltration in Action

12. Ending the Demo

1. The Base: `demo-magic.sh`

🇩🇪 Einbürgerungstest / Naturalization Test — Made Easy

🇩🇪 Einbürgerungstest / Naturalization Test — Made Easy