<?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>Permissions on katzir.xyz</title><link>https://katzir.xyz/tags/permissions/</link><description>Recent content in Permissions on katzir.xyz</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 25 Jun 2026 09:16:56 -0400</lastBuildDate><atom:link href="https://katzir.xyz/tags/permissions/index.xml" rel="self" type="application/rss+xml"/><item><title>IAM Roles in Your Infrastructure</title><link>https://katzir.xyz/posts/identity/</link><pubDate>Thu, 25 Jun 2026 09:16:56 -0400</pubDate><guid>https://katzir.xyz/posts/identity/</guid><description>&lt;p&gt;Most places treat identity and access management like paperwork. Someone needs access, a ticket gets filed, a permission gets granted, and everybody moves on. It&amp;rsquo;s the path of least resistance, but it&amp;rsquo;s also how you end up with an environment where nobody really knows who (or what) has access to what, and auditing anything becomes an archaeology project.&lt;/p&gt;
&lt;p&gt;Really, we should think about IAM as part of how a system is designed, not something that happens after the design is done. Who can touch what, how services authenticate to each other, what happens when someone leaves, these are all load-bearing decisions, not afterthoughts. Of course, many of us actually &lt;!-- raw HTML omitted --&gt;inherit&lt;!-- raw HTML omitted --&gt; systems that are pre-designed, which actually does seem like an archeaology project whether we want it to or not. I&amp;rsquo;ve taught courses on Windows Server and Active Directory, and I try to give my students realistic (read messy) environments to inherit, since they&amp;rsquo;re not going to get a clean forest when they walk into a Windows shop that&amp;rsquo;s been using AD for 25 years.&lt;/p&gt;</description></item></channel></rss>