From e68977a9d3b2f4b30abb4aef43df48af983938d7 Mon Sep 17 00:00:00 2001 From: kaffa Date: Mon, 27 Apr 2026 07:38:47 +0900 Subject: [PATCH] =?UTF-8?q?infra:=20=EB=8F=84=EB=A9=94=EC=9D=B8=20?= =?UTF-8?q?=EA=B2=BD=EA=B3=84=20=EC=A0=95=EB=B3=B8=20=EC=8B=A0=EA=B7=9C=20?= =?UTF-8?q?(netbis=20vs=20ironclad=20cross-domain)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- infra/_index.md | 8 ++- infra/domain-boundaries.md | 133 +++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+), 1 deletion(-) create mode 100644 infra/domain-boundaries.md diff --git a/infra/_index.md b/infra/_index.md index 36db0df..db7d3a6 100644 --- a/infra/_index.md +++ b/infra/_index.md @@ -1,6 +1,6 @@ --- title: infra 인덱스 -updated: 2026-04-16 +updated: 2026-04-27 tags: [moc, infra] --- @@ -15,3 +15,9 @@ tags: [moc, infra] | [[infra/security/_index\|security]] | 인증서, 시크릿, WAF, 접근 관리 | | [[infra/data/_index\|data]] | 데이터베이스, 스토리지, 백업 | | [[infra/platform/_index\|platform]] | 플랫폼 서비스, CI/CD, 모니터링, 위키 | + +## 도메인 경계 (cross-cutting) + +| 문서 | 설명 | +|------|------| +| [[domain-boundaries]] | netbis 영역 vs ironclad 영역 — 자산/계정/책임 분리 + cross-domain 데이터 흐름 | diff --git a/infra/domain-boundaries.md b/infra/domain-boundaries.md new file mode 100644 index 0000000..86735d8 --- /dev/null +++ b/infra/domain-boundaries.md @@ -0,0 +1,133 @@ +--- +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 단일화]]