https://blog.landryzetam.net/categories/security/Recent content in Security on Landry Zetam - Tech BlogHugo -- gohugo.ioen-usThu, 11 Jun 2026 00:00:00 +0000https://blog.landryzetam.net/posts/network-policy-vs-authorization-policy/Thu, 11 Jun 2026 00:00:00 +0000https://blog.landryzetam.net/posts/network-policy-vs-authorization-policy/<p>Kubernetes gives you two resources that both look like &ldquo;firewall rules for pods,&rdquo; and most teams deploy one and assume they got the other for free. They didn&rsquo;t. The two policies operate at different layers, speak different languages, and fail in completely different ways — and you almost certainly need both.</p> <h2 id="the-setup">The Setup</h2> <p>Picture a cluster running a service mesh (Istio, in my case) with a typical three-tier layout: an ingress gateway, a handful of API services, and a PostgreSQL database listening on port 5432. The security requirement sounds simple: only the API services should reach the database, and only the gateway should reach the APIs. The first instinct is to reach for <em>a</em> policy — and Kubernetes hands you two that both claim to do this. <code>NetworkPolicy</code> ships with Kubernetes itself (enforced by your CNI — Cilium, Calico). <code>AuthorizationPolicy</code> ships with Istio (enforced by the Envoy sidecar). Same goal on paper, very different machinery underneath.</p>https://blog.landryzetam.net/posts/lint-your-network-before-it-exists/Tue, 02 Jun 2026 00:00:00 +0000https://blog.landryzetam.net/posts/lint-your-network-before-it-exists/<p>Most network security failures aren&rsquo;t exotic. They&rsquo;re a security group left open to the whole internet on port 22, a subnet that auto-assigns public IPs to everything you launch into it, or a virtual network with flow logs never turned on so you have no record of what happened. The surprise isn&rsquo;t that these slip through — it&rsquo;s that you can catch every one of them <em>before a single resource exists</em>, by linting the infrastructure code the same way you lint application code.</p>https://blog.landryzetam.net/posts/secrets-management-with-sops-flux-gitops/Thu, 07 Aug 2025 00:00:00 +0000https://blog.landryzetam.net/posts/secrets-management-with-sops-flux-gitops/<h2 id="the-problem-secrets-in-gitops">The Problem: Secrets in GitOps</h2> <p>When I started my Kubernetes homelab journey, I quickly hit a wall that every GitOps practitioner faces: <strong>How do you store secrets in Git without compromising security?</strong></p> <p>The GitOps philosophy is beautifully simple - everything should be in Git. Your entire cluster state, all your applications, configurations, and yes, even secrets. But committing passwords, API keys, and certificates to a public (or even private) repository feels fundamentally wrong. It is wrong.</p>