obsidian/infra/domain-boundaries.md

---
title: 도메인 경계 — netbis vs ironclad (cross-domain 운영)
updated: 2026-04-27
tags: [infra, domain, netbis, ironclad, zlambda, moc]
---

# 도메인 경계와 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 등)에만 적용

## 관련 정본

- [[../services/netbis|netbis 정본]] — netbis 도메인/zone/NPM 호스트 상세
- [[../services/bunnycdn-security|BunnyCDN 보안]] — ironclad 자체 풀존 (iron-jp/iron-kr 등) 보안 layer
- [[security/crowdsec-safeline|CrowdSec / SafeLine]] — CrowdSec acquisition / 시나리오 / netbis-cf-firewall
- [[security/cloudflare|Cloudflare (kappa account)]] — ironclad CF zone / Workers / Turnstile
- [[compute/zlambda|zlambda]] — 다리 호스트 상세
- [[compute/infra-hosts|인프라 호스트 인덱스]] — incus / K3s 호스트 전반
- [[../history/2026-04-23-netbis-npm-vl-collection|history: NPM → VL 수집 도입]]
- [[../history/2026-04-23-netbis-firewall-bouncer-migration|history: netbis-cf-firewall 마이그레이션]]
- [[../history/2026-04-25-netbis-cf-firewall-rebuild|history: netbis-cf-firewall 재구축]]
- [[../history/2026-04-25-netbis-npm-vector-msg-rewrite|history: NPM Vector _msg 재합성]]
- [[../history/2026-04-26-bouncer-consolidation|history: bouncer 단일화]]