<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Identity and Access Management on Nalar</title>
    <link>https://nalar.dev/tags/identity-and-access-management/</link>
    <description>Recent content in Identity and Access Management on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 06 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/identity-and-access-management/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Separate Human and Service Identities</title>
      <link>https://nalar.dev/separate-human-and-service-identities/</link>
      <pubDate>Sun, 06 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/separate-human-and-service-identities/</guid>
      <description>&lt;p&gt;A developer needs a background job to read from an internal API. The fastest solution may be to reuse the developer&amp;rsquo;s own account, save its credential in the job, and move on.&lt;/p&gt;&#xA;&lt;p&gt;That shortcut quietly joins two different security problems. A human account is designed around a person&amp;rsquo;s login, employment, recovery, and interactive authentication. A service identity is used by software that runs without a person present. When one identity is forced to serve both roles, permissions become harder to limit, credentials are harder to rotate, and logs can no longer clearly tell whether an action came from a person or an automated workload.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
