nully0x

A note on ArgoCD behind Traefik — double TLS

2026-06-02T00:00:00+00:00

I deployed ArgoCD behind Traefik with cert-manager issuing a Let's Encrypt certificate for cd.mywebsite.co</code>. DNS resolved correctly, the cert was issued and ready, the ingress was configured — but the URL returned a 307</code> redirect loop instead of the ArgoCD login page.</p>

The Symptom</h3>
$</span> curl</span> -vk</span> https://cd.mywebsite.co</span> 2>&1 |</span> head</span> -20</span></span>
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256</span></span>
* Server certificate:</span></span>
*   subject:</span> CN</span>=</span>cd.mywebsite.co</span></span>
*   issuer:</span> C</span>=</span>US</span>;</span> O</span>=</span>Let's Encrypt; CN=R10</span></span>
< HTTP/2 307</span></span>
< location: https://cd.mywebsite.co/</span></span></code></pre>
TLS was fine. The cert was valid. But the response was a 307</code> redirect back to itself.</p>
Checking the Traefik Logs</h3>
The Traefik access logs confirmed the redirect was coming from the ArgoCD server, not Traefik:</p>
$</span> kubectl logs</span> -n</span> traefik</span> -l</span> app=traefik</span> --tail=50</span> |</span> grep</span> argocd</span></span>
"GET / HTTP/1.1"</span> 307 58</span> "-" "-" "argocd-argocd-server-cd-mywebsite-co@kubernetes" "http://10.120.1.9:8080"</span></span></code></pre>
Traefik was terminating TLS and forwarding plain HTTP to the ArgoCD server on port 8080. But ArgoCD was also serving its own TLS by default, so it saw an HTTP request and issued a 307</code> redirect to HTTPS — creating a loop.</p>
The ArgoCD Server Args</h3>
$</span> kubectl get deploy</span> -n</span> argocd argocd-server</span> -o</span> jsonpath='{.spec.template.spec.containers[0].args}'</span></span>
[</span>"/usr/local/bin/argocd-server"</span>]</span></span></code></pre>
No flags. ArgoCD defaults to TLS-enabled mode, so it was doing its own TLS termination on top of Traefik's.</p>
The Fix</h3>
ArgoCD reads its configuration from the argocd-cmd-params-cm</code> ConfigMap via environment variables. The deployment already has ARGOCD_SERVER_INSECURE</code> wired to read from server.insecure</code> in that ConfigMap — it just wasn't set.</p>
# k8s/argocd/cmd-params-cm.yaml</span></span>
apiVersion</span>:</span> v1</span></span>
kind</span>:</span> ConfigMap</span></span>
metadata</span>:</span></span>
  name</span>:</span> argocd-cmd-params-cm</span></span>
  namespace</span>:</span> argocd</span></span>
data</span>:</span></span>
  server.insecure</span>:</span> "true"</span></span></code></pre>
Applied and rolled out:</p>
$</span> kubectl apply</span> -f</span> k8s/argocd/cmd-params-cm.yaml</span></span>
$</span> kubectl rollout restart deploy argocd-server</span> -n</span> argocd</span></span></code></pre>Verification</h3>
$</span> curl</span> -vk</span> https://cd.mywebsite.co</span> 2>&1 |</span> head</span> -5</span></span>
< HTTP/2 200</span></span>
< content-type: text/html;</span> charset</span>=</span>utf-8</span></span></code></pre>
The ArgoCD UI loaded. No more redirect loop.</p>
Why this works</h3>
When a reverse proxy (Traefik, Nginx, etc.) terminates TLS, the application behind it should not also terminate TLS. The --insecure</code> flag tells ArgoCD to serve plain HTTP on port 8080, trusting the proxy to handle encryption.</p>
The traffic flow becomes:</p>
Client (HTTPS :443)</span></span>
  → Traefik (TLS termination, uses cert-manager cert)</span></span>
    → ArgoCD server (plain HTTP :8080)</span></span></code></pre>
ArgoCD hot-reloads the argocd-server-tls</code> secret and</p>



A note on code style
2026-03-07T00:00:00+00:00

Security vs UX</h1>
Most code style discussions focus on the surface: readability, maintainability, or performance. But there's an argument that shapes decisions the conflict between writing code that protects the system and code that serves the user.</p>
A small example from a sign-in implementation illustrates this.</p>
The User-Focused Approach (Semantic Clarity)</h3>
When a user submits credentials, the server looks up the user by email. Two things can go wrong: the user doesn't exist, or the database throws an error. Clean, semantically correct code would handle them differently:</p>
if</span> (</span>!</span>user</span>) {</span></span>
  // Client knows to check their spelling</span></span>
  return new</span> ApplicationError</span>(</span>"Invalid email or password"</span>,</span> 401</span>)</span></span>
}</span></span>
</span>
if</span> (</span>user</span> instanceof</span> Error</span>) {</span></span>
  // Client knows the system is struggling</span></span>
  return new</span> ApplicationError</span>(</span>"Internal server error"</span>,</span> 500</span>)</span></span>
}</span></span>
</span></code></pre>
This is user-focused code. The client gets an accurate signal. A 401</code> means "check your credentials." A 500</code> means "something went wrong on our end, try again."</p>
The Security-Focused Approach (The Information Leak)</h3>
Security-focused code looks unintuitive based on UX. It intentionally collapses distinct failures into a single, vague response:</p>
if</span> (</span>user</span> instanceof</span> Error</span>) {</span></span>
  Logger</span>.</span>error</span>(</span>`Error fetching user during sign-in`</span>,</span> user</span>)</span></span>
  // Intentionally returning 401 instead of 500</span></span>
  return new</span> ApplicationError</span>(</span>"Invalid email or password"</span>,</span> 401</span>)</span></span>
}</span></span>
</span>
if</span> (</span>!</span>user</span>) {</span></span>
  return new</span> ApplicationError</span>(</span>"Invalid email or password"</span>,</span> 401</span>)</span></span>
}</span></span>
</span></code></pre>
Why?</strong> Returning a 500</code> for a DB error leaks information. An attacker can observe: "this email returns 401, that email returns 500."</em> From that difference, they can infer whether an account exists. This is User Enumeration</strong>.</p>
The Side Channel (Timing Attacks)</h3>
The tension goes deeper than status codes. Even if the response body is identical, the time</strong> it takes to process the request can leak the same information.</p>
If a database lookup for a non-existent user returns in 10ms, but a bcrypt</code> password comparison for an existing user takes 300ms, the attacker still wins. Security-focused code might introduce artificial delays to ensure every auth request takes the same amount of time. To a performance-focused dev, this looks like a bug. To a security focused dev, that just normal.</p>
The Broader Principle</h3>
Security-focused code often violates our intuitions about "good" code:</p>

Generic messages</strong> look like poor error handling.</li>
Uniform response times</strong> look like performance regressions.</li>
Redundant checks</strong> look like over-engineering.</li>
</ul>
Neither is wrong. The problem is when a codebase doesn't document a given piece of code to which it focuses on. A dev seeing the collapsed 401</code> without context will flag it as a bug and they'd be right, by the normal rules.</p>
Which should you use?</h3>
When security shapes a code decision, make it visible. The comment isn't for the compiler; it's for the future version of yourself who will look at this and think "this looks wrong."</p>
Security-focused code and user-focused code can coexist, but they need to be legible to each other. The style isn't arbitrary. The master it serves should be declared.</p>


A note on git fsck
2026-03-05T00:00:00+00:00
Recovering Dropped Changes via Git Dangling Commits</h2>
I recently hit a scenario where I mistakenly dropped test files after a branch cleanup. The files were staged and committed on an unintended branch, in an attempt to clean-up, I mistakenly dropped the commit. git status</code> showed a clean tree, and the files were physically gone from the disk.</p>
In Git, objects (commits, blobs, trees) aren't immediately deleted when a branch is removed. They become "dangling" until the garbage collector runs.</p>
1. Identify the Loss</h3>
The working tree was clean, but tests/unit/</code> was missing.</p>
$</span> git log</span> --oneline -5</span></span>
1c8b1bb</span> implement auth middleware</span></span>
32ac0cd</span> Merge pull request</span> #25 </span></span>
...</span></span>
</span>
$</span> ls tests/unit/</span></span>
ls:</span> cannot access 'tests/unit/': No such file or directory</span></span>
</span></code></pre>2. Scanning for Dangling Objects</h3>
Since the commit was no longer reachable via any branch or the reflog (if the reflog was also cleared), git fsck</code> is the tool to verify the database integrity and find "lost" objects.</p>
$</span> git fsck</span> --lost-found</span></span>
Checking</span> object directories: 100%</span> (256/256), done.</span></span>
dangling</span> commit b6c8f8efbb7d1ce8c53e04611ee4d8d40d52e092</span></span>
dangling</span> commit 25cc8b34b9346d9e084402d96cd2d1278f2338cd</span></span>
</span></code></pre>3. Inspecting the Fragments</h3>
I used git show</code> with --stat</code> to find which dangling commit held the missing test files.</p>
$</span> git show b6c8f8efbb7d1ce8c53e04611ee4d8d40d52e092</span> --stat</span></span>
commit</span> b6c8f8efbb7d1ce8c53e04611ee4d8d40d52e092</span></span>
Author:</span> nully0x</span> <</span>myemail@something.co</span>m></span></span>
Date:</span>   Thu Mar</span> 5</span> 19:19:16</span> 2026</span> +0100</span></span>
</span>
    add</span> testing</span></span>
</span>
 tests/unit/middleware/authenticate.test.ts</span> |</span> 229</span> +++++++++++++++++++++++++++++</span></span>
 tests/unit/services/jwt.test.ts</span>            |</span> 128</span> ++++++++++++++++</span></span>
 2</span> files changed,</span> 356</span> insertions</span>(</span>+</span>)</span></span></code></pre>4. Restoration</h3>
Since the object is a valid commit, I simply cherry-picked the hash back into the current branch.</p>
$</span> git cherry-pick b6c8f8efbb7d1ce8c53e04611ee4d8d40d52e092</span></span>
[feat-auth-middleware d31c34f] add testing</span></span>
 2</span> files changed,</span> 356</span> insertions</span>(</span>+</span>)</span></span>
 create</span> mode</span> 100644</span> tests/unit/middleware/authenticate.test.ts</span></span>
 create</span> mode</span> 100644</span> tests/unit/services/jwt.test.ts</span></span>
</span></code></pre>Why this works</h3>
Git's storage model is additive. When you "delete" a commit, you are usually just deleting the reference</strong> (the branch pointer) to that commit. The actual commit object persists in .git/objects</code> until:</p>

git gc</code> runs (usually triggered after a certain number of loose objects).</li>
The object exceeds the gc.pruneExpire</code> grace period (defaulting to 2 weeks for unreachable objects).</li>
</ol>
As long as you haven't run git gc --prune=now</code>, your "deleted" work is likely still recoverable via fsck</code>.</p>


Resolving DNS Resolution Issues in Minikube for Kubernetes Service
2024-10-31T00:00:00+00:00
When using Kubernetes on Minikube, you might encounter DNS resolution errors that prevent your containers from reaching external resources. This can cause issues for jobs that rely on fetching packages or updates from the internet. A typical error might look like this:</p>
Temporary failure resolving 'deb.debian.org'
WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.18/main: temporary error (try again later)</p>
This guide provides a step-by-step solution to resolve DNS issues in Minikube, configure CoreDNS, and ensure stable access to external repositories.</p>

Prerequisites:</p>
</blockquote>

Minikube installed and running locally.</li>
Basic knowledge of Kubernetes, Kubernetes jobs, and how to access Minikube.</li>
kubectl CLI configured to interact with your Minikube instance.</li>
</ul>
Problem Overview</h3>
When running a job or pod in Minikube, if you encounter errors indicating DNS failures (like Temporary failure resolving 'deb.debian.org'), this is usually due to DNS misconfiguration within the Minikube environment. Minikube uses CoreDNS for internal DNS resolution, and by default, it forwards DNS requests to the local system’s /etc/resolv.conf. However, this may fail if local DNS configurations are restricted or unreliable.</p>
Here's an example of the type of error you might encounter in job logs:</p>
Temporary</span> failure resolving 'deb.debian.org'</span></span>
Failed</span> to fetch http://deb.debian.org/debian/dists/bookworm/InRelease</span></span>
Unable</span> to locate package kubectl</span></span></code></pre>
The issue prevents packages from being installed, which can disrupt jobs that need specific tools, like kubectl or ssh-keygen.</p>

To fix this issue:</p>
</blockquote>

Modify the CoreDNS configuration in Minikube to directly use external DNS servers (e.g., Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1).</li>
Restart CoreDNS pods to apply changes.</li>
Verify that DNS resolution is working from within the Minikube cluster.</li>
</ul>
Step 1: Edit the CoreDNS ConfigMap</h3>
In Kubernetes, DNS settings are managed by the CoreDNS ConfigMap located in the kube-system namespace. Follow these steps to configure CoreDNS to forward requests to reliable external DNS servers.</p>
Run the following command to open the CoreDNS ConfigMap in an editor:</p>
kubectl</span> edit configmap coredns</span> -n</span> kube-system</span></span></code></pre>
Update the forward configuration within the Corefile to use external DNS servers 8.8.8.8 and 1.1.1.1 instead of /etc/resolv.conf. Your modified Corefile should look like this for the forward section:</p>
forward . 8.8.8.8 1.1.1.1 {</span></span>
max_concurrent 1000</span></span>
}</span></span></code></pre>
Save and close the editor. Kubernetes will automatically apply the ConfigMap changes.</p>
Step 2: Restart CoreDNS Pods</h3>
To apply the DNS changes, the CoreDNS pods need to be restarted:</p>
kubectl</span> delete pod</span> -n</span> kube-system</span> -l</span> k8s-app=kube-dns</span></span></code></pre>
This command deletes the existing CoreDNS pods, and Kubernetes will recreate them automatically with the new configuration.</p>
Step 3: Verify DNS Resolution</h3>
Once the CoreDNS pods restart, it’s essential to verify that DNS resolution works correctly within the Minikube environment.</p>
Run a Test Pod: Launch a temporary pod with DNS utilities installed:</p>
kubectl</span> run</span> -i --tty</span> dnsutils</span> --image=tutum/dnsutils --restart=Never --</span> /bin/sh</span></span></code></pre>
Test DNS Resolution: Inside the pod’s shell, test DNS resolution with the following commands:</p>
nslookup</span> deb.debian.org</span></span>
ping</span> -c 4</span> deb.debian.org</span></span></code></pre>
Expected output for nslookup:</p>
Server:</span>         8.8.8.8</span></span>
Address:</span>        8.8.8.8#53</span></span>
</span>
Non-authoritative</span> answer:</span></span>
deb.debian.org</span>  canonical name = debian.map.fastlydns.net.</span></span>
Name:</span>   debian.map.fastlydns.net</span></span>
Address:</span> 151.101.1.130</span></span></code></pre>
If you see an IP address returned without errors, the DNS is correctly configured.</p>
Step 4: Retry the Kubernetes Job</h3>
With DNS resolution working, re-run any Kubernetes job or pod that was previously failing due to DNS issues.</p>
For example, if you were using a job to generate SSH keys and create a Kubernetes secret, redeploy the job:</p>
kubectl</span> delete job/pod</span>  <</span>job-nam</span>e></span></span>
kubectl</span> apply</span> -f</span> <</span>your-job-manifest.yam</span>l></span></span></code></pre>
Then, monitor the job’s logs to verify that it installs packages successfully:</p>
kubectl</span> logs</span> -f</span> job/</span><</span>job-nam</span>e> (could</span> be pod name as well</span>)</span></span></code></pre>Troubleshooting</h3>
Common Errors and Fixes</p>


Temporary Failure Resolving ‘deb.debian.org’: This error usually means the CoreDNS configuration is not applied correctly. Double-check the forward block in the CoreDNS ConfigMap and ensure that you specified valid DNS IPs.</p>
</li>

No External Connectivity in the Pod: If ping or nslookup fails, the problem may be with Minikube’s network configuration. Restart Minikube and verify that you’re using a network that allows external internet access.</p>
</li>
</ul>
Resetting DNS to Defaults</h3>
If you want to reset the CoreDNS configuration to its default state, simply remove the custom DNS IPs and revert to using /etc/resolv.conf:</p>
forward . /etc/resolv.conf {</span></span>
max_concurrent 1000</span></span>
}</span></span></code></pre>
Delete the CoreDNS pods to apply changes.</p>
Summary</h3>
In this guide, we covered how to resolve DNS issues in a Minikube-powered Kubernetes environment by modifying CoreDNS to use reliable external DNS servers. This fix is essential for jobs and pods that require stable internet access to install packages or interact with external APIs.</p>
By following these steps, you should be able to:</p>

Configure CoreDNS for reliable external DNS.</li>
Resolve DNS resolution errors in Kubernetes jobs.</li>
Troubleshoot DNS connectivity in Minikube.</li>
</ul>


A note on provisioning SSL on cloud instance or VPS
2024-08-02T00:00:00+00:00
Introduction</h2>
Securing websites with SSL/TLS certificates is crucial for protecting user data and maintaining trust. This article is a guide on provisioning SSL certificates using Let's Encrypt and managing an Nginx web server on EC2 or any Virtual Private Server (VPS).</p>
Provisioning SSL Certificates with Let's Encrypt</h2>
Let's Encrypt offers a free and automated way to obtain SSL/TLS certificates. Here's how to provision an SSL certificate on your EC2 instance or VPS:</p>
Installing Certbot</h3>
Certbot is the official client for Let's Encrypt. To install it on Ubuntu with Nginx:</p>
sudo</span> apt-get update</span></span>
sudo</span> apt-get install certbot python3-certbot-nginx</span></span></code></pre>Obtaining the Certificate</h3>
With Certbot installed, you can obtain an SSL certificate:</p>
sudo</span> certbot</span> --nginx</span></span></code></pre>
This command will guide you through the process, asking for your domain name and handling the Nginx configuration automatically.</p>
Choosing the Authentication Method</h3>
Let's Encrypt typically uses HTTP validation for domain verification. Certbot handles this process automatically by temporarily modifying your web server configuration.</p>
Setting Up Automatic Renewal</h3>
Let's Encrypt certificates are valid for 90 days. Set up automatic renewal to maintain uninterrupted SSL protection:</p>


Test the renewal process:</p>
sudo</span> certbot renew</span> --dry-run</span></span></code></pre></li>

Enable automatic renewal (on systems with systemd):</p>
sudo</span> systemctl enable certbot.timer</span></span>
sudo</span> systemctl start certbot.timer</span></span></code></pre></li>
</ol>
Managing Nginx Web Server</h2>
Efficient management of your Nginx server is crucial for maintaining a secure and performant web presence.</p>
Basic Nginx Management Commands</h3>

Start Nginx: sudo systemctl start nginx</code></li>
Stop Nginx: sudo systemctl stop nginx</code></li>
Restart Nginx: sudo systemctl restart nginx</code></li>
</ul>
Applying Configuration Changes</h3>
After modifying Nginx configuration files, apply changes without service interruption:</p>
sudo</span> systemctl reload nginx</span></span></code></pre>Monitoring Nginx Status</h3>
Check the current status of Nginx:</p>
sudo</span> systemctl status nginx</span></span></code></pre>Best Practices and Considerations</h2>

Regularly check Nginx error logs at /var/log/nginx/error.log</code> for potential issues.</li>
Keep your system and Nginx up to date to protect against vulnerabilities.</li>
Use sudo systemctl enable nginx</code> to ensure Nginx starts automatically on system boot.</li>
Customize your Nginx configuration to optimize performance and security for your specific needs.</li>
</ol>
Conclusion</h2>
Provisioning SSL certificates with Let's Encrypt and effectively managing your Nginx web server are essential skills for maintaining a secure and reliable web presence on EC2 or any VPS. By following this guide, you can ensure your website is protected with HTTPS and your web server is running smoothly.</p>
For more detailed information, consult the Certbot documentation</a> and the Nginx documentation</a>.</p>

nully0x

A note on ArgoCD behind Traefik — double TLS

A note on code style

A note on git fsck

Resolving DNS Resolution Issues in Minikube for Kubernetes Service

A note on provisioning SSL on cloud instance or VPS

Introduction</h2> Securing websites with SSL/TLS certificates is crucial for protecting user data and maintaining trust. This article is a guide on provisioning SSL certificates using Let's Encrypt and managing an Nginx web server on EC2 or any Virtual Private Server (VPS).</p>

Provisioning SSL Certificates with Let's Encrypt</h2> Let's Encrypt offers a free and automated way to obtain SSL/TLS certificates. Here's how to provision an SSL certificate on your EC2 instance or VPS:</p>

Choosing the Authentication Method</h3> Let's Encrypt typically uses HTTP validation for domain verification. Certbot handles this process automatically by temporarily modifying your web server configuration.</p>

Managing Nginx Web Server</h2> Efficient management of your Nginx server is crucial for maintaining a secure and performant web presence.</p>

Introduction</h2>
Securing websites with SSL/TLS certificates is crucial for protecting user data and maintaining trust. This article is a guide on provisioning SSL certificates using Let's Encrypt and managing an Nginx web server on EC2 or any Virtual Private Server (VPS).</p>

Provisioning SSL Certificates with Let's Encrypt</h2>
Let's Encrypt offers a free and automated way to obtain SSL/TLS certificates. Here's how to provision an SSL certificate on your EC2 instance or VPS:</p>

Choosing the Authentication Method</h3>
Let's Encrypt typically uses HTTP validation for domain verification. Certbot handles this process automatically by temporarily modifying your web server configuration.</p>

Managing Nginx Web Server</h2>
Efficient management of your Nginx server is crucial for maintaining a secure and performant web presence.</p>