howto

Konfiguration von Traefik mit CRDs

Wie bereits in Teil 1 der Artikelreihe zu Traefik angedeutet, kann man Traefik nicht nur über Annotationen und über Parameter von Deployment bzw. Chart konfigurieren, sondern auch mit Custom Resource Definitions (CRDs). Hierbei wird die sogenannte dynamische Konfiguration von Traefik dann nicht mehr über Annotationen an den zu verwaltenden Objekten wie einem Ingress gemacht, sondern statisch als eigenständiges Objekt, welches unabhängig konfiguriert wird.

Ob man das als Vorteil oder Nachteil sieht, hängt stark von der eigenen Benutzung und auch der Designphilosophie des (hoffentlich vorhandenem) Code Repository ab. CRDs zu benutzen ist bestimmt nicht gerade zielführend mit einer kleinen k3s-Instanz, die eine handvoll Dienste nach außen verfügbar macht. Mit steigender Komplexität ist es aber weder trivial noch ratsam, die Logik komplett in der Hand von Annotationen zu lassen.

read more

How to run your own DNS resolver (using DNS-over-HTTPS) in Kubernetes using cloudflared

We recently had a blog post on how to secure your DNS traffic using DNS-over-TLS or DNS-over-HTTPS (German only). The article gave an introduction on how to run dnsdist as a local resolver on Debian11. In this case, dnsdist would accept queries using DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH).

This surely is the right solution for those scenarios, where your clients are capable of speaking DoT or DoH natively. But what if they don’t? In this case you can create your own resolver that listens on the “usual” aka unencrypted DNS ports. The DNS traffic on your local network is then unencrypted, which might or might not be acceptable depending on your threat analysis. Once the requests have reached your local resolver, it will forward them using DoH to a server of your choice. Which one to pick is up to you, a list of available servers can be found at DNSprivacy.org.

In this article, we will run our own resolver in Kubernetes using a helm chart for cloudflared. Despite the name, it can be used with many different endpoints, not just the ones from Cloudflare.

read more

Running the Blocky ad-blocking dns-proxy in Kubernetes

Blocky is a dns-proxy capable of blocking undesired content, i.e. ads or malware. It supports blocklist-based filtering, supports new DNS protocols like DoH (DNS-over-HTTPS) or DoT (DNS over TLS) and a gazillion of other features. It is being provided as a docker image, and while docker is a fascinating piece of software, who choses to run things in plain Docker when you can do so in Kubernetes? While not everyone might be running Kubernetes at home, with k3s this is really easy. And it uses the same Kubernetes resources you see in data centers and edge locations and windparks and cars and whatnot.

read more

Verschlüsseltes DNS selber machen

Seit einiger Zeit gibt es Bestrebungen, die Namensauflösung kryptographisch abzusichern. Dafür existiert auf der einen Seite mit DNSsec eine Technik, die eigene Zone zu signieren und so gefälschte DNS-Antworten zu verhindern. Auf der anderen Seite existieren mit DNS over TLS (DoT) und DNS over HTTPS (DoH) zwei Techniken, mit denen die Anfragen zwischen Client und Resolver verschlüsselt werden können. Standardmäßig funktioniert die Namensauflösung komplett unverschlüsselt und kann beispielsweise vom Internet Service Provider oder dem Betreiber eines öffentlichen WLANs mitgelesen oder sogar verändert werden. Mit der Verschlüsselung kann das Mitlesen von DNS-Abfragen auf der Netzwerkverbindung zwischen Client und Resolver verhindert werden, zwischen Resolver und Nameserver bleibt sie unverschlüsselt. Auf dieser Verbindung ist eine Zuordnung der Anfragen zu einem Client in der Regel nicht möglich, weiterhin können viele Anfragen direkt aus dem Resolver-Cache beantwortet werden. Meist sind es jedoch große Konzerne, welche die dafür nötigen Resolver zur Verfügung stellen. Damit wird das eigentlich dezentrale DNS letztendlich doch wieder an wenigen Stellen zentralisiert.

Das muss aber nicht sein, denn der Betrieb eines eigenen Resolvers für DoT und DoH ist möglich. Die folgende Anleitung zeigt, wie das geht.

read more

Der Traefik Ingress Controller

Sollte man sich schon mal k3s, die kleine Kubernetes-Distribution von Rancher Labs, angeschaut oder allgemein in der Kubernetes-Dokumentation über die zusätzlichen Controller gestolpert sein, so wird man vielleicht schonmal “Traefik” gelesen haben und sich fragen: was ist das eigentlich?

read more

Netzwerk-Probleme beim Upgrade auf Proxmox 7 vermeiden

Nach dem Upgrade von Proxmox 6 auf Proxmox 7 kommt es teilweise zu Problemen mit dem Netzwerk. Der Host ist in diesen Fällen nach dem abschließenden Reboot nicht mehr erreichbar. Eines dieser Probleme ist im Upgrade-Leitfaden von Proxmox beschrieben – einem anderen soll sich dieser Artikel widmen.

read more

Let’s-Encrypt-Zertifikate für interne Hosts

Viele Webseiten verwenden Zertifikate von Let’s Encrypt zur Absicherung des Datenverkehrs zwischen Benutzer und Server. Dies hat vor allem zwei Gründe: Zum einen sind diese Zertifikate kostenlos, zum anderen lässt sich die Erneuerung automatisieren, sodass abgelaufene...

read more

Pi-KVM nutzen

Hersteller von Server-Hardware haben unterschiedliche Lösungen, um remote, also ohne Monitor und Tastatur, auf ihre Server zugreifen zu können. Entweder man entscheidet sich für solch einen Hersteller, oder man hat einen „Wildwuchs“ an Hardware und somit unterschiedliche Arten des Remote-Zugriffs. In diese Bresche will Pi-KVM zwar nicht schlagen – aber es ist damit möglich, zur initialen Installation und Einrichtung eine „moderne“ und einheitliche Oberfläche zu nutzen. Weiterhin kann es auf postalischem Weg zu einem Kunden versendet werden und so ohne großen Aufwand Zugriff auf die Remotekonsole bieten.

read more