<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Postgresql on Patoune-IT</title><link>https://www.patoune-it.fr/tags/postgresql/</link><description>Recent content in Postgresql on Patoune-IT</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Wed, 27 May 2026 10:00:00 +0200</lastBuildDate><atom:link href="https://www.patoune-it.fr/tags/postgresql/index.xml" rel="self" type="application/rss+xml"/><item><title>Se connecter à une base Azure sans accès direct via socat et kubectl port-forward</title><link>https://www.patoune-it.fr/posts/2026-05-27-azure-db-kubectl-portforward/</link><pubDate>Wed, 27 May 2026 10:00:00 +0200</pubDate><guid>https://www.patoune-it.fr/posts/2026-05-27-azure-db-kubectl-portforward/</guid><description>&lt;p>En environnement professionnel, les bases de données Azure (PostgreSQL, MySQL, SQL Server…) sont souvent exposées uniquement via un &lt;strong>Private Endpoint&lt;/strong> : elles ne sont accessibles qu&amp;rsquo;au sein du réseau privé Azure, sans aucune IP publique. Résultat : depuis son poste de développement, il est impossible de s&amp;rsquo;y connecter directement avec un client comme DBeaver ou &lt;code>psql&lt;/code>.&lt;/p>
&lt;p>Pourtant, le cluster AKS (Azure Kubernetes Service) qui tourne dans le même VNet, lui, y a accès. Ce guide explique comment exploiter ce fait pour créer un tunnel sécurisé jusqu&amp;rsquo;à la base, sans modifier les règles réseau ni ouvrir le moindre port public.&lt;/p></description></item></channel></rss>