AI 에이전트 Zero Trust 파이프라인: SPIFFE/SPIRE + Cedar 실전 구축
하드코딩 시크릿 없이 에이전트에 암호학적 신원을 부여하고, 정책으로 모든 행동을 결정론적으로 제어하기
읽기 전 권장 배경지식: Kubernetes Pod·서비스어카운트 개념, mTLS의 기본 원리. 클라우드 네이티브 운영 경험이 있는 백엔드/인프라 개발자에게 최적화된 글입니다.
AI 에이전트가 데이터베이스를 쿼리하고, 외부 API를 호출하고, 다른 에이전트를 오케스트레이션하는 환경이 빠르게 확산되고 있습니다. 그런데 이 에이전트들은 "누구"로서 행동하고 있을까요? 대부분의 현장에서는 여전히 하드코딩된 API 키나 장기 유효 토큰에 의존합니다. Gartner는 2028년까지 엔터프라이즈 업무 결정의 15% 이상이 에이전트 AI로 처리될 것이라 전망하는데, 이 에이전트들이 검증되지 않은 자격증명으로 움직인다면 어떤 일이 벌어질지 생각해볼 필요가 있습니다.
HashiCorp를 비롯한 업계 보고서들은 엔터프라이즈 환경에서 머신 신원(서비스 계정, API 키, 봇 자격증명)이 사람 신원보다 수십 배 많아졌다고 분석합니다. 보안 연구자들이 시연한 PoC(개념증명)에서는 탈옥된 에이전트가 정찰, 자격증명 탈취, 데이터 유출까지 자율적으로 수행하는 시나리오가 공개되기도 했습니다.
이 글을 읽으면 하드코딩된 시크릿 없이 AI 에이전트에 암호학적 신원(SVID)을 부여하고, Cedar 정책으로 에이전트의 모든 행동을 결정론적으로 제어하는 완전한 Zero Trust 파이프라인을 이해할 수 있습니다.
이 글에서는 SPIFFE/SPIRE로 에이전트 프로세스에 신원을 발급하고, Cedar 정책 엔진과 연결해 신원 확인 → 정책 평가 → 접근 허용/거부의 일관된 파이프라인을 단계별로 살펴봅니다.
핵심 개념
SPIFFE와 SPIRE: "이 프로세스는 누구인가?"에 답하는 방법
SPIFFE(Secure Production Identity Framework For Everyone)는 클라우드 네이티브 환경에서 워크로드에 암호학적으로 검증 가능한 신원을 부여하는 오픈 표준입니다. API 키나 패스워드 같은 정적 시크릿 대신, 플랫폼이 직접 "이 프로세스가 실행 중인 환경"을 증명해주는 방식입니다.
SPIRE(SPIFFE Runtime Environment)는 이 명세의 레퍼런스 구현체로, SPIRE Server와 SPIRE Agent 두 컴포넌트로 구성됩니다.
┌─────────────────────────────────────────────────────┐
│ SPIRE Server │
│ - 트러스트 번들(Root CA) 관리 │
│ - 등록된 워크로드 항목 저장 │
│ - SVID 서명 및 발급 │
└──────────────────────┬──────────────────────────────┘
│ mTLS
┌──────────────────────▼──────────────────────────────┐
│ SPIRE Agent (DaemonSet) │
│ - 노드 어테스테이션 (k8s_sat / AWS IID / GCP GCE) │
│ - 워크로드 어테스테이션 (PID, k8s Service Account) │
│ - Workload API (Unix socket) 제공 │
└──────────────────────┬──────────────────────────────┘
│ Unix Socket
┌─────────────▼─────────────┐
│ AI 에이전트 프로세스 │
│ SVID 수령 및 자동 갱신 │
└───────────────────────────┘어테스테이션(Attestation): 워크로드의 신원을 주변 환경에서 수집한 증거로 검증하는 과정입니다. Kubernetes 환경에서는 주로
k8s_sat(Service Account Token) 또는k8s_psat(Projected Service Account Token) 어테스터가 사용됩니다. "이 Pod가 진짜ai-agents네임스페이스의orchestrator서비스어카운트로 실행 중인가?"를 kubelet API로 직접 확인합니다.
SPIFFE가 "신원의 언어"를 정의하면, SPIRE가 실제 환경에서 그 신원을 발급합니다. 그다음은 Cedar가 발급된 신원으로 무엇을 허용할지 결정할 차례입니다.
SVID: 신원이 담기는 두 가지 형태
SPIRE가 워크로드를 검증하면 SVID(SPIFFE Verifiable Identity Document)를 발급합니다. SPIFFE ID는 spiffe://trust-domain/path 형태의 URI로, 두 가지 포맷으로 표현됩니다.
| 포맷 | 구조 | 검증 방식 | 적합한 환경 |
|---|---|---|---|
| X.509-SVID | X.509 인증서의 SAN URI 필드에 SPIFFE ID 삽입 | 트러스트 번들(Root CA)로 인증서 서명 검증 | mTLS, 서비스 메시(Istio, Envoy) |
| JWT-SVID | SPIRE Server가 서명한 JWT | SPIRE의 JWKS 엔드포인트 또는 Workload API 번들로 서명 검증 | HTTP REST API, Authorization 헤더 |
# X.509-SVID 발급 확인
spire-agent api fetch x509 \
-socketPath /run/spire/sockets/agent.sock
# 출력 예시:
# SPIFFE ID: spiffe://prod.example.com/ns/ai-agents/sa/orchestrator
# 유효기간: 5분 (TTL 설정에 따라)
# Subject Alternative Name URI: spiffe://prod.example.com/ns/ai-agents/sa/orchestratorCedar의 Policy Decision Point(PDP)는 JWT-SVID를 수신하면, SPIRE의 트러스트 번들(JWKS 엔드포인트 또는 Workload API 번들)로 서명을 검증한 뒤 SPIFFE ID를 추출합니다. 이렇게 검증된 신원만이 Cedar 정책 평가에 사용됩니다.
Cedar: 정책을 코드로, 결정을 예측 가능하게
Cedar는 AWS가 개발한 오픈소스 정책 언어로, PARC 모델(Principal, Action, Resource, Context)로 접근 제어 규칙을 표현합니다. OPA(Rego)와 비교해 문법이 직관적이고, **정책 분석(policy analysis)**을 지원해 정책 충돌이나 도달 불가능한 규칙을 CI 단계에서 사전에 탐지할 수 있습니다.
// Cedar 정책의 기본 구조
permit (
principal is WorkloadIdentity, // 누가
action == Action::"invoke_model", // 무엇을
resource == ModelEndpoint::"gpt-v2" // 어디에
)
when {
principal.spiffe_id == "spiffe://prod.example.com/ns/ai-agents/sa/orchestrator"
};forbid-wins 원칙: Cedar에서
forbid와permit규칙이 동시에 매칭되면 항상forbid가 우선합니다. 기본 정책은 deny-all이므로, 명시적으로permit이 없으면 모든 요청이 거부됩니다.
단, Cedar 정책에서 principal.spiffe_id 같은 속성은 자동으로 존재하지 않습니다. 아래 실전 적용 섹션의 schema.json에서 WorkloadIdentity 엔티티 타입과 그 속성을 직접 정의해야 하며, 이 과정을 건너뛰면 cedar validate가 오류를 반환합니다.
전체 Zero Trust 파이프라인 흐름
SPIFFE가 신원을 정의하고, SPIRE가 발급하고, Cedar가 그 신원으로 결정을 내립니다. 세 레이어가 결합되면 다음 흐름이 완성됩니다.
AI 에이전트 프로세스 기동
↓
SPIRE Agent: 워크로드 어테스테이션
(kubelet API → Pod 서비스어카운트·네임스페이스 검증)
↓
SPIRE Server: X.509-SVID 또는 JWT-SVID 발급
↓
에이전트가 SVID를 제시하며 서비스 호출
↓
Policy Decision Point (PDP)
JWT-SVID 검증(JWKS/트러스트 번들) → SPIFFE ID 추출 → Cedar 정책 평가
↓
접근 허용 or 거부 (기본: deny-all) + 결정 로깅실전 적용
예시 1: Kubernetes AI 에이전트 파이프라인 — SPIRE 설정부터 mTLS까지
AI 추론 서버(vLLM, Triton 등)와 오케스트레이션 에이전트를 Kubernetes에 배포하는 시나리오입니다. SPIRE Agent를 DaemonSet으로 배치하고, 에이전트 Pod에 SVID를 발급해 모델 서빙 서버와 mTLS를 맺도록 합니다.
1단계: Cedar 스키마 정의
Cedar 정책에서 principal.spiffe_id를 사용하려면 먼저 스키마에 WorkloadIdentity 엔티티 타입과 속성을 등록해야 합니다. 이 파일 없이는 cedar validate가 알 수 없는 속성이라며 오류를 반환합니다.
// schema.json
{
"": {
"entityTypes": {
"WorkloadIdentity": {
"shape": {
"type": "Record",
"attributes": {
"spiffe_id": { "type": "String", "required": true }
}
}
},
"ModelEndpoint": {},
"DataStore": {
"shape": {
"type": "Record",
"attributes": {
"classification": { "type": "String", "required": true }
}
}
},
"Environment": {}
},
"actions": {
"invoke_model": {
"appliesTo": {
"principalTypes": ["WorkloadIdentity"],
"resourceTypes": ["ModelEndpoint"]
}
},
"write_data": {
"appliesTo": {
"principalTypes": ["WorkloadIdentity"],
"resourceTypes": ["DataStore"]
}
},
"read_data": {
"appliesTo": {
"principalTypes": ["WorkloadIdentity"],
"resourceTypes": ["DataStore"]
}
}
}
}
}2단계: SPIRE Server에 워크로드 등록
# AI 오케스트레이터 에이전트 등록
spire-server entry create \
-spiffeID spiffe://prod.example.com/ns/ai-agents/sa/orchestrator \
-parentID spiffe://prod.example.com/k8s-workload-registrar/node \
-selector k8s:ns:ai-agents \
-selector k8s:sa:orchestrator-sa \
-ttl 300 # SVID 유효기간 5분 설정
# 모델 서빙 서버 등록
spire-server entry create \
-spiffeID spiffe://prod.example.com/ns/inference/sa/vllm-server \
-parentID spiffe://prod.example.com/k8s-workload-registrar/node \
-selector k8s:ns:inference \
-selector k8s:sa:vllm-sa \
-ttl 3003단계: spiffe-helper 사이드카로 SVID 파일시스템 마운트
spiffe-helper는 SVID를 파일시스템에 자동으로 쓰고 만료 전 갱신해주는 사이드카입니다. helper.conf에서 어느 경로에 어떤 파일명으로 저장할지 지정합니다.
# /etc/spiffe-helper/helper.conf
agent_address = "/run/spire/sockets/agent.sock"
cmd = "echo"
cmd_args = "svid-rotated"
cert_dir = "/run/secrets/svid"
svid_file_name = "svid.pem"
svid_key_file_name = "key.pem"
svid_bundle_file_name = "bundle.pem"
renew_signal = "SIGUSR1"# k8s deployment 일부 — sidecar 패턴
containers:
- name: ai-orchestrator
image: my-agent:latest
volumeMounts:
- name: spiffe-workload-api
mountPath: /run/spire/sockets
readOnly: true
- name: svid-volume
mountPath: /run/secrets/svid
- name: spiffe-helper
image: ghcr.io/spiffe/spiffe-helper:latest
args: ["-config", "/etc/spiffe-helper/helper.conf"]
volumeMounts:
- name: spiffe-workload-api
mountPath: /run/spire/sockets
- name: svid-volume
mountPath: /run/secrets/svid
- name: helper-config
mountPath: /etc/spiffe-helper
volumes:
- name: spiffe-workload-api
hostPath:
path: /run/spire/sockets
type: Directory
- name: svid-volume
emptyDir:
medium: Memory # 메모리 내 저장으로 디스크 노출 최소화
- name: helper-config
configMap:
name: spiffe-helper-config4단계: Cedar 정책으로 모델 호출 제어
// policies/ai-agent-policy.cedar
// 오케스트레이터만 모델 추론 호출 허용
permit (
principal is WorkloadIdentity,
action == Action::"invoke_model",
resource == ModelEndpoint::"gpt-inference-v2"
)
when {
principal.spiffe_id == "spiffe://prod.example.com/ns/ai-agents/sa/orchestrator"
};
// PII 데이터 스토어에 대한 쓰기 작업 전면 금지
forbid (
principal,
action == Action::"write_data",
resource is DataStore
)
when { resource.classification == "PII" };
// 분석 에이전트는 비PII 데이터만 읽기 허용
permit (
principal is WorkloadIdentity,
action == Action::"read_data",
resource is DataStore
)
when {
principal.spiffe_id == "spiffe://prod.example.com/ns/ai-agents/sa/analytics"
&& resource.classification != "PII"
};5단계: Cedar 정책 유효성 검증 (CI/CD에서 실행)
# 스키마 파일을 기준으로 정책 검증
cedar validate \
--schema schema.json \
--policies policies/
# 특정 요청 시뮬레이션 — 정책 평가 결과 확인
cedar authorize \
--policies policies/ \
--schema schema.json \
--principal 'WorkloadIdentity::"spiffe://prod.example.com/ns/ai-agents/sa/orchestrator"' \
--action 'Action::"invoke_model"' \
--resource 'ModelEndpoint::"gpt-inference-v2"' \
--context '{}'
# 출력: ALLOW예시 2: CI/CD Zero Trust 파이프라인 — 하드코딩 시크릿 완전 제거
GitHub Actions 러너나 GitLab CI 잡이 실행될 때 JWT-SVID를 발급받아 HashiCorp Vault에 인증하는 패턴입니다. 파이프라인 어느 곳에도 AWS 자격증명이나 API 키가 존재하지 않습니다.
# JWT-SVID 요청 및 토큰 추출
JWT_TOKEN=$(spire-agent api fetch jwt \
-socketPath /run/spire/sockets/agent.sock \
-audience vault.prod.internal \
| jq -r '.svids[0].token')
# JWT-SVID로 Vault 인증 → 단기 AWS 자격증명 획득
vault write auth/jwt/login \
role="ci-deploy-role" \
jwt="${JWT_TOKEN}"
# Vault가 반환한 단기 자격증명으로 AWS 배포 수행
# (자격증명 TTL: 15분, 파이프라인 완료 후 자동 만료)Cedar에서 SPIFFE ID 패턴 매칭이 필요한 경우, str:: 확장 함수를 활용하시면 됩니다.
// CI/CD 배포 권한 정책
// staging 환경: gitlab CI 파이프라인 전체 허용
// str:: 확장 함수로 SPIFFE ID 경로 패턴 매칭
permit (
principal is WorkloadIdentity,
action == Action::"deploy",
resource == Environment::"staging"
)
when {
str::startsWith(principal.spiffe_id, "spiffe://prod.example.com/ci/gitlab/")
&& str::endsWith(principal.spiffe_id, "/deploy")
};
// production 배포: main 브랜치 파이프라인만 허용
permit (
principal is WorkloadIdentity,
action == Action::"deploy",
resource == Environment::"production"
)
when {
principal.spiffe_id == "spiffe://prod.example.com/ci/gitlab/main/deploy"
&& context.approval_count >= 2
};예시 3: 멀티 에이전트 신뢰 체인 — WIMSE 위임 토큰 패턴
에이전트 A가 에이전트 B를 호출할 때, 에이전트 A의 전체 권한이 에이전트 B로 그대로 전파되면 안 됩니다. WIMSE(Workload Identity in Multi-System Environments) 위임 토큰 패턴을 활용하면 각 홉(hop)마다 스코프를 좁힌 토큰을 사용할 수 있습니다.
에이전트 A (오케스트레이터)
SVID: spiffe://prod/ns/agents/sa/orchestrator
권한: invoke_model, read_data, delegate
↓ 위임 토큰 요청 (SPIRE에 스코프 명시)
SPIRE Server
→ 에이전트 B용 제한 토큰 발급
→ 스코프: read_data만 허용, TTL: 2분
↓ 제한 토큰 전달
에이전트 B (분석 워커)
위임 토큰으로만 동작
invoke_model 호출 시도 → Cedar가 거부
(에이전트 A가 탈취되어도 에이전트 B 권한은 최소화)Lateral Movement 차단: 각 에이전트가 서로 다른 스코프의 토큰을 사용하므로, 한 에이전트가 침해되더라도 공격자는 해당 에이전트의 제한된 스코프 내에서만 움직일 수 있습니다. 전체 파이프라인으로의 횡적 이동이 구조적으로 차단됩니다.
SPIRE + Cedar 연결: Policy Decision Point 직접 구현하기
SPIRE와 Cedar를 실제로 연결하는 핵심은 Policy Decision Point(PDP)입니다. PDP는 JWT-SVID를 수신해 신원을 검증한 뒤 Cedar 정책을 평가합니다. 다음은 Go로 작성한 PDP의 핵심 흐름입니다.
// pdp/authorize.go
package pdp
import (
"context"
"os"
cedar "github.com/cedar-policy/cedar-go"
"github.com/spiffe/go-spiffe/v2/svid/jwtsvid"
"github.com/spiffe/go-spiffe/v2/workloadapi"
)
type AuthRequest struct {
RawJWT string // Authorization 헤더의 JWT-SVID
Action string // Cedar Action 이름
Resource string // Cedar Resource ID
}
func Authorize(ctx context.Context, req AuthRequest) (bool, error) {
// 1. Workload API에서 트러스트 번들(JWKS) 획득 → JWT-SVID 서명 검증
client, _ := workloadapi.New(ctx)
defer client.Close()
bundles, _ := client.FetchJWTBundles(ctx)
svid, err := jwtsvid.ParseAndValidate(
req.RawJWT, bundles, []string{"pdp.prod.internal"},
)
if err != nil {
return false, err // 검증 실패 → 즉시 거부
}
// 2. Cedar 정책 로드
policyBytes, _ := os.ReadFile("policies/ai-agent-policy.cedar")
ps, _ := cedar.NewPolicySet("policy.cedar", policyBytes)
// 3. 검증된 SPIFFE ID를 Cedar 엔티티 속성으로 주입
principalUID := cedar.NewEntityUID("WorkloadIdentity", svid.ID.String())
entities := cedar.EntityMap{
principalUID: {
UID: principalUID,
Attributes: cedar.NewRecord(cedar.RecordMap{
"spiffe_id": cedar.String(svid.ID.String()),
}),
},
}
// 4. Cedar 정책 평가 → 결정 반환
decision, _ := ps.IsAuthorized(entities, cedar.Request{
Principal: principalUID,
Action: cedar.NewEntityUID("Action", req.Action),
Resource: cedar.NewEntityUID("ModelEndpoint", req.Resource),
})
return decision == cedar.Allow, nil
}이 30줄 내외의 코드가 SPIRE의 신원 검증과 Cedar의 정책 평가를 하나의 파이프라인으로 연결합니다. JWT-SVID의 서명은 SPIRE Workload API에서 가져온 트러스트 번들(JWKS)로 검증하고, 검증된 SPIFFE ID를 Cedar 엔티티 속성으로 주입해 정책 평가에 활용하는 구조입니다.
실무에서 가장 흔한 실수
실전 적용 과정에서 반복적으로 나타나는 문제들을 미리 확인하면 시행착오를 줄일 수 있습니다.
-
SVID TTL을 기본값(1시간)으로 방치하는 경우 — 탈취된 SVID가 1시간 동안 유효하게 됩니다. AI 에이전트 워크로드는 5~15분으로 짧게 설정하고, 자동 갱신 주기를 TTL의 절반 이하로 맞추는 것을 권장합니다.
-
Cedar 정책을
permit위주로만 작성하고forbid를 생략하는 경우 — 기본 deny-all에permit만 추가하면 충분해 보이지만, PII 접근이나 프로덕션 직접 쓰기 같은 특수 케이스는 명시적forbid로 이중 보호하는 것이 안전합니다. -
트러스트 도메인 경로 설계를 초기에 대충 잡는 경우 —
spiffe://prod.example.com/agent1처럼 평탄한 구조로 시작하면 나중에 네임스페이스·팀·환경 구분이 불가능해집니다. 초기부터spiffe://prod.example.com/ns/{namespace}/sa/{service-account}형태의 계층적 경로를 설계하는 것을 권장합니다.
장단점 분석
장점
| 항목 | 내용 |
|---|---|
| Secret Zero 해결 | 정적 API 키·패스워드 없이 암호학적 신원으로 대체해 자격증명 유출 위험을 근본적으로 제거합니다. |
| 자동 갱신 | SVID 만료 전 SPIRE가 자동 재발급해 수동 시크릿 교체 작업이 사라집니다. |
| 정책 분석 가능 | cedar validate로 정책 충돌·도달 불가 규칙을 CI 단계에서 사전에 탐지할 수 있습니다. |
| 멀티 플랫폼 신원 표준 | Kubernetes, VM, 베어메탈, 클라우드 무관하게 동일한 신원 표준이 적용됩니다. |
| 감사 가능성 | 모든 신원 발급과 정책 결정이 로그로 기록되어 SOC2, GDPR 등 규정 준수 대응이 용이합니다. |
| 트러스트 도메인 페더레이션 | 멀티 클라우드·멀티 조직 간 신원을 연결할 수 있습니다. |
단점 및 주의사항
| 항목 | 내용 |
|---|---|
| 운영 복잡성 | SPIRE Server HA 구성, 트러스트 번들 배포, 업스트림 CA 관리가 까다롭습니다. Tornjak(관리 UI) 도입과 Helm 차트 배포 표준화로 부담을 줄일 수 있습니다. |
| 부트스트랩 신뢰 문제 | 최초 노드 어테스테이션 시 SPIRE Agent 자체의 신원을 검증하는 주체가 필요합니다. 클라우드 플랫폼 어테스터(AWS IID, GCP GCE)를 활용하는 것을 권장합니다. |
| Cedar 학습 곡선 | PARC 모델과 스키마 정의에 익숙해지는 시간이 필요하며, 복잡한 시나리오에서 정책이 방대해질 수 있습니다. cedar validate CI 통합으로 점진적 도입이 가능합니다. |
| 레이턴시 오버헤드 | 모든 요청마다 Cedar 정책 평가를 삽입하면 레이턴시가 증가합니다. 결정 결과 캐싱(TTL: 수 초)과 사이드카 패턴 활용이 효과적입니다. |
| AI 에이전트의 동적 특성 | LLM 기반 에이전트는 런타임에 새로운 툴을 동적으로 호출할 수 있어 정적 정책이 모든 경우를 커버하기 어렵습니다. 툴 카탈로그 사전 등록과 미등록 툴 호출 시 기본 거부 정책이 권장됩니다. |
| 에코시스템 성숙도 | SPIFFE/Cedar 통합 SDK가 아직 성숙기 이전 단계여서 직접 통합 코드 작성이 필요한 경우가 많습니다. cedar-go, cedar-policy(Rust) 중 언어 스택에 맞는 바인딩을 선택하시면 됩니다. |
트러스트 도메인(Trust Domain): SPIFFE 신원 공간의 최상위 단위입니다.
spiffe://prod.example.com처럼 도메인 단위로 신뢰 범위를 구분하며, 멀티 클러스터 환경에서는 트러스트 도메인 페더레이션으로 서로 다른 클러스터 간 SVID 검증이 가능합니다.
마치며
이 글을 통해 SPIFFE/SPIRE로 AI 에이전트에 암호학적 신원을 발급하고, Cedar 정책으로 모든 행동을 결정론적으로 제어하는 Zero Trust 파이프라인의 전체 그림을 이해하셨을 것입니다.
지금 바로 시작해볼 수 있는 3단계가 있습니다.
-
로컬에서 SPIRE 환경을 먼저 경험해보시기 바랍니다. 공식 Kubernetes Quickstart(
https://spiffe.io/docs/latest/try/getting-started-k8s/)를 따라 minikube에 SPIRE Server + Agent를 배포하고,spire-agent api fetch x509명령으로 SVID가 실제로 발급되는 과정을 확인해보시면 아키텍처가 훨씬 구체적으로 이해됩니다. -
Cedar 플레이그라운드(
https://www.cedarpolicy.com/en/playground)에서 자신의 워크로드에 맞는 정책을 작성해볼 수 있습니다. 이 글의schema.json을 기반으로WorkloadIdentity엔티티를 정의하고,cedar authorize로 허용/거부 결과를 즉시 확인해보시면 Cedar의 동작 방식에 빠르게 익숙해질 수 있습니다. -
두 기술을 연결하는 Policy Decision Point를 직접 구현해보시기 바랍니다. 위의
pdp/authorize.go예시를 출발점으로, SPIRE의 Workload API에서 JWT-SVID를 받아 cedar-go에 넘기는 흐름을 직접 실행해보시면 전체 파이프라인이 실제로 어떻게 동작하는지 체감하실 수 있습니다.
다음 글: Istio 서비스 메시와 SPIRE를 통합해 Envoy 사이드카가 SVID를 자동으로 처리하도록 구성하고, 멀티 클러스터 환경에서 트러스트 도메인 페더레이션을 설정하는 실전 가이드
참고 자료
- SPIFFE 공식 문서 - SPIRE Concepts
- SPIFFE 공식 문서 - Workload Registration
- SPIFFE 공식 문서 - Kubernetes Quickstart
- HashiCorp: SPIFFE - Securing the identity of agentic AI and non-human actors
- HashiCorp: Zero trust for agentic systems — managing non-human identities at scale
- Red Hat: Zero Trust for autonomous agentic AI systems (2026)
- arXiv: Establishing Workload Identity for Zero Trust CI/CD
- arXiv: A Novel Zero-Trust Identity Framework for Agentic AI
- Cedar Policy Language 공식 문서
- cedar-policy GitHub
- AWS: Secure AI agents with Policy in Amazon Bedrock AgentCore
- AWS: Policy in Amazon Bedrock AgentCore 공식 문서
- StrongDM: Cedar Policy Language 완전 가이드 2026
- OPA vs Cedar vs Zanzibar 비교 가이드 2025
- Microsoft Agent Governance Toolkit (GitHub)
- Microsoft: Agent Governance Toolkit Architecture Deep Dive
- GitGuardian: Getting Started With SPIFFE for Multi-Cloud Secure Workload Authentication
- Cerbos: MCP and Zero Trust — Securing AI Agents With Identity and Policy
- WEF: Non-human identities — Agentic AI's new frontier of cybersecurity risk
- WIMSE IETF 워킹그룹