<?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>Envoy on paval.io</title><link>https://danielpaval.github.io/tags/envoy/</link><description>Recent content in Envoy on paval.io</description><generator>Hugo -- 0.145.0</generator><language>en</language><lastBuildDate>Wed, 05 Mar 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://danielpaval.github.io/tags/envoy/index.xml" rel="self" type="application/rss+xml"/><item><title>To Envoy or not to Envoy</title><link>https://danielpaval.github.io/posts/2025-03-05-to-envoy-or-not-to-envoy/</link><pubDate>Wed, 05 Mar 2025 00:00:00 +0000</pubDate><guid>https://danielpaval.github.io/posts/2025-03-05-to-envoy-or-not-to-envoy/</guid><description>&lt;p>I recently came across the need for a reusable microservice in the form of an OCI / Docker image to meet different authentication and authorization requirements depending on the end project and environment. While the current limited set of possible security configurations is handled by the microservice itself, I analyzed the possibility of delegating this aspect to a specialized sidecar container living in the same Kubernetes pod.&lt;/p>
&lt;p>After a bit of prompt engineering and wanting to consider something else than NGINX I decided to first try &lt;a href="https://www.envoyproxy.io/">Envoy Proxy&lt;/a>. Long story short, here&amp;rsquo;s a Docker Compose setup:&lt;/p></description></item></channel></rss>