feat(ap4): defend forwarded identity headers
This commit is contained in:
@@ -49,3 +49,22 @@ Nginx 컨테이너 IP를 전용 Compose subnet에서 고정하고 oauth2-proxy
|
||||
trusted proxy를 그 단일 IP로 제한합니다. 다만 이 단계에서는 backend
|
||||
8081이 로컬 호스트에 열려 있어 신뢰 헤더를 직접 위조할 수 있습니다.
|
||||
그 재현 조건은 마지막 feature에서 제거합니다.
|
||||
|
||||
## 마지막 단계: 신뢰 경계와 헤더 스푸핑 방어
|
||||
|
||||
`feature/keycloak-header-spoofing-defense`에서는 신뢰 경계를 실제
|
||||
네트워크와 application 양쪽에서 강제합니다.
|
||||
|
||||
1. backend 8081과 oauth2-proxy 4180은 host에 publish하지 않습니다.
|
||||
브라우저가 접근 가능한 application 포트는 Nginx 8088뿐입니다.
|
||||
2. Nginx는 client가 보낸 `X-Auth-Request-User`, email, 내부 토큰을
|
||||
그대로 전달하지 않고 oauth2-proxy 결과와 server-side 토큰으로
|
||||
항상 덮어씁니다.
|
||||
3. backend는 `X-Auth-Request-User`와 `X-Internal-Auth-Token`이 모두
|
||||
유효할 때만 edge identity를 받아들이며 token은 constant-time으로
|
||||
비교합니다.
|
||||
|
||||
shared token은 방어 심층화 수단입니다. 운영에서는 Secret Manager나
|
||||
orchestrator secret으로 주입하고 주기적으로 교체해야 합니다. 서비스
|
||||
간 mTLS 또는 service mesh identity를 사용할 수 있다면 단순 shared
|
||||
token보다 강한 workload identity로 대체하는 편이 좋습니다.
|
||||
|
||||
Reference in New Issue
Block a user