Files

kaffa e68977a9d3 infra: 도메인 경계 정본 신규 (netbis vs ironclad cross-domain)

- infra/domain-boundaries.md 신규 — 두 영역 자산/계정/책임 분리 + cyclic 데이터 흐름 + 자산 매핑 + 추적 시 주의사항
- infra/_index.md에 도메인 경계 절 추가
- 기존 정본들(services/netbis, infra/security/crowdsec-safeline, services/bunnycdn-security 등)이 흩어져 갖던 cross-domain 정보의 단일 진입점

핵심 사실:
- netbis CF account != kappa CF account (별개)
- NPM 6대 origin은 netbis 자산, vl/CrowdSec/netbis-cf-firewall은 ironclad 인프라
- zlambda는 양 영역 다리 (Tailscale + Linode public IP 보유)
- netbis-cf-firewall은 ironclad 컨테이너 동거하지만 netbis CF API token으로 push

2026-04-27 07:38:47 +09:00

8.1 KiB

Raw Blame History

title, updated, tags

title

updated

도메인 경계와 cross-domain 운영

ironclad 자체 인프라가 netbis의 보안 운영을 위탁받아 처리하는 구조. 두 영역의 자산/계정은 별개지만, 데이터는 netbis에서 발생 → ironclad가 처리 → 결정은 netbis CF에 다시 적용되는 cyclic cross-domain 패턴.

이 정본은 그 경계와 흐름을 한 자리에 정리해서 다른 정본들이 흩어져 갖고 있는 책임/계정 정보의 단일 진입점 역할을 한다.

두 영역의 자산

영역	CF account	인프라 자산	책임
netbis	netbis CF account (별도, ID `8fcf3c7876332aba33e974cbbfdad951`)	netbis CF zone 6개 (`fall-vip` / `fall-mvp` / `fall-vip7` / `psd777` / `rss-555` / `rss-7790`) + NPM-1..6 (Linode Tokyo public 6대 호스트)	사용자 트래픽 종착점 (origin) — 외부 노출 도메인은 netbis 자산
ironclad	kappa CF account (`kappa@inouter.com`)	jp1/kr1/kr2/hp2 incus, K3s 서울/오사카, vl.inouter.com (VL), CrowdSec LAPI (jp1), netbis-cf-firewall, kappa CF zone (`keepanker.cv` / `actions.it.com` / `ironclad.it.com` / `servidor.it.com` / `inouter.com` / `anvil.it.com` 등)	인프라 본체 + 분석 layer + 자체 워크로드 (Outline / Gitea / Vault / 등)
zlambda	(중립)	NixOS Tokyo 호스트, Tailscale + Linode public IP 둘 다 보유	양 영역의 다리 — VL이 LAN-only(192.168.9.53)라 public NPM이 도달 못 함. HTTP relay로 투입

데이터 흐름 (cross-domain cyclic)

[사용자 요청]
     │
     ▼
[netbis CF zone (netbis 영역)]
   - netbis CF account의 6 zone (fall-vip 등)
   - netbis-cf-firewall이 IP List `crowdsec_managed_challenge` + Firewall Rule 적용
   - hit IP는 managed_challenge (CF 캡챠), miss는 통과
     │
     ▼ (CF 통과)
[NPM-1..6 origin (netbis 영역, Linode Tokyo public)]
   - nginx-proxy-manager proxy_v2 포맷 access log 기록
   - 응답을 사용자에 전달
     │
     │ access log (Vector 0.55 file→http)
     ▼
[zlambda Vector-relay (다리)]
   - Vector 0.45 http_server→elasticsearch
   - .relay = "zlambda" 태그 추가
     │
     ▼ (HTTP relay)
[vl.inouter.com (ironclad 영역, K3s logging ns)]
   - VictoriaLogs `npm-netbis` 인덱스에 적재
   - K3s 클러스터 LAN-only 자산
     │
     ▼ (CrowdSec acquisition tail query)
[CrowdSec LAPI (ironclad 영역, jp1 incus crowdsec 컨테이너)]
   - victorialogs source가 query OR로 NPM/APISIX/Traefik 통합 입수
   - NPM 라인은 Vector remap이 nginx combined 포맷으로 재합성한 _msg를 대상으로 grok
   - 시나리오 매칭 → LAPI decision (origin: crowdsec, scope: Ip)
     │
     ▼ (cscli decisions stream polling, 10s)
[netbis-cf-firewall (ironclad 영역, jp1 crowdsec 컨테이너에 동거)]
   - 같은 컨테이너에 LAPI + bouncer 동거지만 bouncer는 netbis CF API token으로 동작
   - origin filter `[crowdsec, cscli]` 적용 — CAPI/lists 30k+ 무시 (CF List 10k 한도 회피)
     │
     ▼ (Cloudflare API: netbis CF account)
[netbis CF IP List + Firewall Rule (netbis 영역)]
   - IP List `crowdsec_managed_challenge` 갱신
   - 6 zone × Firewall Rule managed_challenge 액션 자동 동기화
     │
     ▲ (다음 요청에 반영)
[사용자 요청 ← 차단/캡챠]

자산 → 도메인 매핑 (주요 노드)

노드 / 자산	도메인	비고
netbis CF account (`8fcf3c…`)	netbis	별도 계정
netbis CF zone × 6 (`fall-vip` 등)	netbis
NPM-1..6 (Linode Tokyo public)	netbis	사용자 origin
zlambda (NixOS, `139.162.71.52` + Tailscale `100.108.39.107`)	bridge	Vector relay 전용 — 자체 트래픽 종착 아님
Vault `secret/cloud/cloudflare-netbis`	bridge	netbis CF API token, ironclad Vault에 저장
netbis-cf-firewall (`cs-cloudflare-bouncer-1777082222`)	bridge	jp1 ironclad 컨테이너에 동거하지만 netbis CF에 push
jp1 incus `crowdsec` 컨테이너	ironclad	LAPI + netbis-cf-firewall 동거
vl.inouter.com (K3s logging ns)	ironclad	LAN-only, public 도달 불가
K3s 서울/오사카, kappa CF zone	ironclad	자체 워크로드 (Outline / Gitea 등)
kappa CF account (`d8e5997e…`)	ironclad

cross-domain 운영 패턴

패턴 1: 데이터 위탁 (netbis → ironclad)

netbis가 NPM 로그를 ironclad VL로 보낸다. 이유:

netbis는 자체 로그 분석 인프라 없음
ironclad가 CrowdSec/VictoriaLogs/시나리오 운영 노하우 보유
public NPM → LAN VL 도달 불가 → zlambda relay 필수

패턴 2: 결정 위탁 (ironclad → netbis CF)

ironclad CrowdSec이 netbis CF에 ban 결정을 push한다. 이유:

ironclad가 분석 결과 보유 (시나리오 매칭, IP-based decision)
netbis CF account에 직접 enforce해야 사용자 트래픽 차단 가능
별도 CF account 토큰을 ironclad Vault에 저장하고 ironclad 컨테이너에서 사용

패턴 3: 동거 (jp1 crowdsec 컨테이너)

한 컨테이너에 ironclad LAPI + netbis 전용 bouncer가 동거. 분리 안 한 이유:

bouncer가 LAPI를 같은 컨테이너 localhost로 호출 → 네트워크 hop 0
각자 다른 CF account 토큰 사용이라 사실상 격리됨
단 cscli bouncers list / cscli decisions list 같은 운영 시점에는 ironclad 운영자가 netbis bouncer 상태도 같이 본다 (의도된 합쳐진 운영 시점)

권한·시크릿 분리

시크릿	위치	용도
netbis CF API token (`firewall_bouncer_token`)	Vault `secret/cloud/cloudflare-netbis`	netbis CF Account Firewall Access Rules Write + Account Rule Lists Write + Zone Firewall Services Write
netbis CF zone 자체 관리 토큰	Vault `secret/cloud/cloudflare-netbis`	DNS / zone 설정 (별도)
kappa CF API key (kappa account)	Vault `secret/cloud/cloudflare`	ironclad zone 전체 (`global_api_key` 사용)
zlambda Vector relay basic auth	Vault `secret/cloud/vector-relay-netbis`	NPM-1..6 → zlambda HTTP 인증

netbis CF token은 ironclad 인프라가 netbis CF에 푸시하기 위한 위탁 권한이지 ironclad 자산 token 아님. 운영자(kappa)가 양쪽 자산 모두 관리하지만, 토큰 자체는 영역별로 분리.

추적 시 주의 (graphify / LLM 추론용)

CrowdSec 시나리오 매칭은 ironclad VL 데이터 위에서 일어남. 시나리오 발동된 IP가 어떤 netbis zone을 노렸는지 알려면 VL npm-netbis 인덱스의 host/path 필드를 backward query 필요
netbis-cf-firewall에 등록된 IP List는 netbis CF account에만 적용 — kappa CF zone에는 영향 없음
kappa zone (keepanker / actions / ironclad / servidor / inouter / anvil)에는 IP-list 기반 enforce layer 부재 (2026-04-26 cs-cf-worker-bouncer + bunny-cdn-bouncer 폐기 후) — 별도 보호 검토 필요
APISIX는 ironclad 인프라 자산 — netbis NPM 트래픽은 APISIX를 통과하지 않음. APISIX limit-req / chaitin-waf 등은 ironclad 자체 워크로드(Outline 등)에만 적용

8.1 KiB Raw Blame History Unescape Escape