<?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>Peer-Authentication on homelab89</title>
    <link>https://blog.homelab89.com/tags/peer-authentication/</link>
    <description>Recent content in Peer-Authentication on homelab89</description>
    <generator>Hugo</generator>
    <language>ko-KR</language>
    <lastBuildDate>Sun, 07 Jun 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.homelab89.com/tags/peer-authentication/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Istio 보안은 PeerAuthentication·RequestAuthentication·AuthorizationPolicy 세 리소스가 &#34;transport 인증 · end-user 인증 · 인가&#34;의 역할을 분담한다</title>
      <link>https://blog.homelab89.com/docs/istio/security/resource-trio/</link>
      <pubDate>Sun, 07 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.homelab89.com/docs/istio/security/resource-trio/</guid>
      <description>&lt;div class=&#34;callout abstract&#34;&gt;
&lt;div class=&#34;ct&#34;&gt;이 문서가 다루는 것&lt;/div&gt;
&lt;p&gt;Istio의 워크로드 보안은 한 리소스가 아니라 &lt;strong&gt;세 CRD의 분업&lt;/strong&gt;으로 성립한다. PeerAuthentication은 서비스 간 transport 계층(mTLS)을 강제해 &lt;strong&gt;peer identity&lt;/strong&gt;(SPIFFE)를 확보하고, RequestAuthentication은 요청에 실린 JWT를 검증해 &lt;strong&gt;end-user identity&lt;/strong&gt;(claim)를 추출하며, AuthorizationPolicy는 앞 둘이 채워준 attribute를 입력받아 &lt;strong&gt;허용/차단&lt;/strong&gt;을 결정한다. 이 문서가 박으려는 단 하나의 멘탈모델: &lt;strong&gt;앞의 두 리소스는 신원을 &lt;em&gt;증명·추출&lt;/em&gt;만 하고 자기 자신은 거의 차단하지 않는다 — 실제 게이트는 AuthorizationPolicy 뿐&lt;/strong&gt;이다. 운영 사고의 대부분은 이 역할 경계를 혼동(PeerAuthentication STRICT를 인가로 착각, RequestAuthentication만 걸고 AuthorizationPolicy 누락)하는 데서 나온다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
