From c1a1fcb041958bc36dc9afe8d8c4ebff38f310fb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=A1=EB=8C=80=EC=9D=BC?= Date: Wed, 10 Jun 2026 20:18:58 +0900 Subject: [PATCH] Fix local Docker startup configuration --- baron-sso/.env.sample | 6 +- baron-sso/compose.infra.yaml | 2 +- baron-sso/compose.ory.yaml | 4 +- baron-sso/docker-compose.yaml | 1 + baron-sso/docs/baronsso_structure_analysis.md | 238 +++++++ .../docs/baronsso_work_timeline_report.md | 588 ++++++++++++++++++ 6 files changed, 834 insertions(+), 5 deletions(-) create mode 100644 baron-sso/docs/baronsso_structure_analysis.md create mode 100644 baron-sso/docs/baronsso_work_timeline_report.md diff --git a/baron-sso/.env.sample b/baron-sso/.env.sample index af98d23..0a59e1f 100644 --- a/baron-sso/.env.sample +++ b/baron-sso/.env.sample @@ -98,7 +98,8 @@ BACKEND_URL=${USERFRONT_URL} OATHKEEPER_PUBLIC_URL=${USERFRONT_URL} # ory-stack 변수들 -ORY_POSTGRES_TAG=17-trixie +ORY_POSTGRES_TAG=17-alpine +CLICKHOUSE_TAG=24.6 ORY_POSTGRES_USER=ory ORY_POSTGRES_PASSWORD=EuBV5ywvXFehkggHQrnYo5727MseEi6i9 ORY_POSTGRES_DB=ory @@ -142,6 +143,7 @@ KRATOS_UI_URL=http://localhost:5000 HYDRA_ADMIN_URL=http://hydra:4445 # Oathkeeper가 /oidc 경로를 Hydra Public API로 라우팅합니다. HYDRA_PUBLIC_URL=${OATHKEEPER_PUBLIC_URL}/oidc +HYDRA_SYSTEM_SECRET=change-me-to-at-least-16-characters # 선택: Hydra 화면 핸드오프 URL을 USERFRONT_URL 기준 기본값과 다르게 둘 때만 설정합니다. # HYDRA_LOGIN_URL=https://sso.hmac.kr/login # HYDRA_CONSENT_URL=https://sso.hmac.kr/consent @@ -149,7 +151,7 @@ HYDRA_PUBLIC_URL=${OATHKEEPER_PUBLIC_URL}/oidc # Kratos allowed_return_urls 확장 목록 (콤마 구분, 선택) # 기본값은 KRATOS_UI_URL, USERFRONT_URL, 각 callback URL을 자동 포함합니다. -KRATOS_ALLOWED_RETURN_URLS_EXTRA=[] +KRATOS_ALLOWED_RETURN_URLS_EXTRA= KRATOS_ALLOWED_RETURN_URLS_JSON=["http://localhost:5000","http://localhost:5000/","https://sso.hmac.kr","https://sso.hmac.kr/","https://sso.hmac.kr/ko","https://sso.hmac.kr/ko/","https://sso.hmac.kr/en","https://sso.hmac.kr/en/","https://sso.hmac.kr/auth/callback","https://sso.hmac.kr/ko/auth/callback","https://sso.hmac.kr/en/auth/callback","http://localhost:5173/auth/callback","http://localhost:5174/auth/callback","http://localhost:5175/auth/callback","https://sso.hmac.kr/orgfront/auth/callback"] # Oathkeeper JWKS (내부 통신용) diff --git a/baron-sso/compose.infra.yaml b/baron-sso/compose.infra.yaml index 368b891..0a68758 100644 --- a/baron-sso/compose.infra.yaml +++ b/baron-sso/compose.infra.yaml @@ -25,7 +25,7 @@ services: restart: always clickhouse: - image: clickhouse/clickhouse-server:latest + image: clickhouse/clickhouse-server:${CLICKHOUSE_TAG:-24.6} container_name: baron_clickhouse restart: always volumes: diff --git a/baron-sso/compose.ory.yaml b/baron-sso/compose.ory.yaml index b8c6e55..d0348f6 100644 --- a/baron-sso/compose.ory.yaml +++ b/baron-sso/compose.ory.yaml @@ -94,7 +94,7 @@ services: - URLS_LOGIN=${HYDRA_LOGIN_URL:-${USERFRONT_URL}/login} - URLS_CONSENT=${HYDRA_CONSENT_URL:-${USERFRONT_URL}/consent} - URLS_ERROR=${HYDRA_ERROR_URL:-${USERFRONT_URL}/error} - - SECRETS_SYSTEM=${ORY_POSTGRES_PASSWORD} + - SECRETS_SYSTEM=${HYDRA_SYSTEM_SECRET:-${ORY_POSTGRES_PASSWORD}} volumes: - ./config/.generated/ory/hydra:/etc/config/hydra command: serve -c /etc/config/hydra/hydra.yml all --dev @@ -170,7 +170,7 @@ services: - public_net ory_clickhouse: - image: clickhouse/clickhouse-server:latest + image: clickhouse/clickhouse-server:${CLICKHOUSE_TAG:-24.6} container_name: ory_clickhouse environment: - CLICKHOUSE_USER=${ORY_CLICKHOUSE_USER:-ory} diff --git a/baron-sso/docker-compose.yaml b/baron-sso/docker-compose.yaml index 49fc026..a3e9cf6 100644 --- a/baron-sso/docker-compose.yaml +++ b/baron-sso/docker-compose.yaml @@ -28,6 +28,7 @@ services: - KETO_READ_URL=${KETO_READ_URL:-http://keto:4466} - KETO_WRITE_URL=${KETO_WRITE_URL:-http://keto:4467} - DB_HOST=postgres + - DB_PORT=5432 - CLICKHOUSE_HOST=clickhouse - CLICKHOUSE_PORT=${CLICKHOUSE_PORT_NATIVE:-9000} - CLICKHOUSE_USER=${CLICKHOUSE_USER:-baron} diff --git a/baron-sso/docs/baronsso_structure_analysis.md b/baron-sso/docs/baronsso_structure_analysis.md new file mode 100644 index 0000000..205afac --- /dev/null +++ b/baron-sso/docs/baronsso_structure_analysis.md @@ -0,0 +1,238 @@ +# Baron SSO 구조 분석 + +## 1. 이 시스템은 무엇인가 + +Baron SSO는 계열사 또는 화이트라벨 대상 서비스들의 로그인, 권한, 애플리케이션 연동을 중앙에서 관리하는 통합 인증/인가 허브입니다. 저장소의 설명과 구성 파일을 보면 단순 로그인 화면이 아니라 다음 역할을 함께 수행하는 IAM 플랫폼에 가깝습니다. + +- 사용자 인증과 계정 수명주기 관리 +- OAuth2/OIDC 기반 SSO와 RP(Relying Party) 연동 +- 권한 정책 및 접근 제어 관리 +- 관리자용 운영 화면, 개발자용 RP 관리 화면, 조직도/조직 컨텍스트 화면 제공 +- 감사 로그 수집과 운영 데이터 관리 + +핵심적으로는 Ory Stack을 자체 호스팅하고, Baron Backend가 비즈니스 규칙과 운영 기능을 담당하며, 여러 프론트엔드가 역할별 UI를 제공합니다. + +## 2. 전체 아키텍처 요약 + +현재 저장소는 하나의 애플리케이션이 아니라, 인증 인프라와 여러 사용자 인터페이스를 함께 운영하는 멀티 서비스 구조입니다. + +### 2.1 주요 계층 + +1. Ory 기반 IAM 계층 +2. Baron 자체 백엔드 계층 +3. 역할별 프론트엔드 계층 +4. 게이트웨이 및 인프라 계층 +5. 데이터 저장소 및 로깅 계층 + +### 2.2 구성 요소별 역할 + +#### Ory Stack + +`compose.ory.yaml` 기준으로 다음 컴포넌트를 별도 컨테이너로 운영합니다. + +- Kratos: 사용자 인증, 계정, self-service flow +- Hydra: OAuth2/OIDC 서버, 로그인/동의 흐름, 토큰 발급 +- Keto: 권한 관계 및 정책 기반 접근 제어 +- Oathkeeper: 프록시형 접근 제어 게이트 + +즉, Baron SSO의 인증/인가 핵심은 Ory를 기반으로 하고, Baron 코드는 그 위에서 비즈니스 로직과 운영 기능을 덧씌우는 구조입니다. + +#### Backend + +`backend`는 Go Fiber 기반 API 서버이며, 저장소 README 설명대로 Ory Stack과 여러 프론트엔드 사이의 주된 비즈니스 백엔드 역할을 수행합니다. + +역할은 다음과 같이 해석할 수 있습니다. + +- 프론트엔드가 호출하는 자체 API 제공 +- Ory Admin/Public API와 연동하여 로그인, 동의, RP 관련 흐름 제어 +- 감사 로그 적재 +- 테넌트, 사용자, 운영 데이터 처리 +- 외부 연동 기능 처리 + +`docker-compose.yaml`에서도 각 웹 프론트엔드가 `API_PROXY_TARGET=http://baron_backend:3000`으로 이 백엔드를 바라보도록 구성되어 있습니다. + +#### 프론트엔드 계층 + +역할이 나뉜 여러 UI가 함께 존재합니다. + +- `userfront`: 최종 사용자용 로그인/인증 UI, Flutter 기반 +- `adminfront`: 관리자용 운영 UI, React/Vite 기반 +- `devfront`: 개발자용 RP 및 연동 관리 UI, React/Vite 기반 +- `orgfront`: 조직/컨텍스트 시각화 및 관리 성격의 UI, React/Vite 기반 + +프론트엔드가 분리되어 있다는 점은 이 시스템이 단일 로그인 페이지 수준이 아니라, 사용자 포털과 운영 포털을 함께 포함하는 플랫폼임을 보여줍니다. + +#### Gateway + +`gateway`는 Nginx 기반 컨테이너이며 외부 진입점 역할을 담당합니다. `compose.infra.yaml`에서 `public_net`에 연결되어 있고, `USERFRONT_PORT`를 외부로 노출합니다. 따라서 사용자가 처음 접근하는 표면은 게이트웨이 또는 Oathkeeper를 포함한 프록시 계층을 통해 노출되는 구조로 볼 수 있습니다. + +#### 데이터 및 부가 인프라 + +저장소에는 인증 인프라용 저장소와 서비스 메타데이터용 저장소가 분리되어 있습니다. + +- PostgreSQL: Baron 메타데이터 저장 및 Ory 데이터 저장소 +- ClickHouse: 감사 로그 및 이벤트성 데이터 적재 +- Redis: 캐시/세션성 또는 보조 저장소 용도 +- Promtail, Blackbox Exporter, Vector: 로그/모니터링/전송 보조 구성 + +### 2.3 구조도 + +```mermaid +flowchart LR + User[User / Admin / Developer] --> Gateway[Nginx Gateway / Public Entry] + User --> WebApps[Frontends] + + subgraph Frontend Layer + UF[userfront\nFlutter] + AF[adminfront\nReact + Vite] + DF[devfront\nReact + Vite] + OF[orgfront\nReact + Vite] + end + + Gateway --> UF + AF --> BE + DF --> BE + OF --> BE + UF --> BE + + subgraph Service Layer + BE[Baron Backend\nGo + Fiber] + end + + subgraph IAM Layer + KR[Ory Kratos] + HY[Ory Hydra] + KE[Ory Keto] + OK[Ory Oathkeeper] + end + + BE --> KR + BE --> HY + BE --> KE + OK --> KR + OK --> HY + OK --> KE + + subgraph Data Layer + PG[(PostgreSQL)] + CH[(ClickHouse)] + RD[(Redis)] + end + + BE --> PG + BE --> CH + BE --> RD + KR --> PG + HY --> PG + KE --> PG +``` + +## 3. 개발 기술 스택 정리 + +### 3.1 백엔드 + +- Language: Go 1.26.2 +- Web Framework: Fiber v2 +- ORM/DB access: GORM, PostgreSQL driver, `lib/pq` +- IAM/OIDC 관련: `coreos/go-oidc`, `golang.org/x/oauth2`, `go-jose` +- Cache/infra: Redis, ClickHouse +- Test: Testify, Testcontainers +- 기타 연동: AWS SDK v2, SES + +즉, 백엔드는 Go 기반의 API 서버이면서 IAM 흐름을 직접 제어하는 오케스트레이션 계층입니다. + +### 3.2 사용자 프론트엔드 + +`userfront/pubspec.yaml` 기준 스택은 다음과 같습니다. + +- Framework: Flutter +- Language runtime: Dart SDK 3.10+ +- State management: Riverpod +- Routing: go_router +- 기타: easy_localization, qr_flutter, mobile_scanner, shared_preferences + +이를 보면 `userfront`는 웹 중심 React 앱이 아니라 Flutter 기반의 사용자 인증 UI이며, QR 로그인, 다국어, 로컬 상태 저장 등의 기능을 염두에 둔 구조입니다. + +### 3.3 운영/관리 프론트엔드 + +`adminfront`, `devfront`, `orgfront`는 공통적으로 현대적인 React 프론트엔드 스택을 사용합니다. + +- Framework: React 19 +- Build tool: Vite 8 +- Language: TypeScript 6 +- Styling: Tailwind CSS, tailwindcss-animate +- UI primitives: Radix UI +- Data fetching/cache: TanStack Query +- Form/validation: react-hook-form, zod +- Auth client: oidc-client-ts, react-oidc-context +- HTTP client: axios +- Test: Vitest, Playwright +- Lint/format: Biome + +`orgfront`는 여기에 `@xyflow/react`를 사용하고 있어 조직 구조나 컨텍스트 시각화 성격의 기능이 포함된 것으로 보입니다. + +### 3.4 공통/모노레포 구성 + +- Package manager: pnpm workspace +- 공통 패키지: `common` +- 공통 리소스: `locales` +- 코드 품질: Biome + +즉, 프론트엔드는 모노레포 형태로 운영되며 공통 UI/설정/로케일 자산을 공유합니다. + +### 3.5 인프라 및 배포 + +- Container orchestration: Docker Compose +- Reverse proxy: Nginx +- IAM platform: Ory Kratos, Hydra, Keto, Oathkeeper +- Database: PostgreSQL +- Analytics/Audit store: ClickHouse +- Cache: Redis +- Observability: Promtail, Vector, Blackbox Exporter + +## 4. 이 저장소에서 보이는 설계 특징 + +### 4.1 멀티테넌트 운영 시스템 성격 + +README와 `seed-tenant.csv`, 테넌트 import/export 관련 문서 이름들로 보아 이 시스템은 단일 서비스용 로그인 서버가 아니라, 여러 조직과 테넌트를 관리하는 멀티테넌트 IAM 운영 시스템입니다. + +### 4.2 인증과 운영 기능의 분리 + +인증 그 자체는 Ory Stack이 맡고, Baron Backend와 각 Frontend가 다음을 담당합니다. + +- 비즈니스 규칙 적용 +- 운영 UI 제공 +- 테넌트/사용자 관리 +- RP 등록 및 OIDC 연동 관리 +- 감사 로그와 운영성 기능 + +이 구조는 범용 IAM 엔진과 도메인 특화 운영 시스템을 분리한 설계로 볼 수 있습니다. + +### 4.3 감사와 추적 가능성을 중시 + +ClickHouse, Promtail, Vector, 감사 로그 관련 README 설명을 보면 운영 추적성과 감사 가능성을 중요한 요구사항으로 두고 있습니다. 특히 로그인/권한/관리자 작업의 추적을 고려한 구조로 해석됩니다. + +### 4.4 역할별 UI 분리 + +최종 사용자, 운영 관리자, 개발자, 조직 관리 성격의 UI가 분리되어 있어 권한과 업무 맥락에 따라 화면을 구분하는 B2B 운영 시스템의 전형적인 구조를 가집니다. + +## 5. 한 줄 요약 + +Baron SSO는 Ory Stack을 자체 호스팅 기반으로 사용하면서, Go 백엔드와 여러 역할별 프론트엔드를 결합해 구성한 멀티테넌트 SSO/IAM 운영 플랫폼입니다. 기술적으로는 Go + Fiber, Flutter, React + Vite + TypeScript, PostgreSQL, ClickHouse, Redis, Docker Compose, Ory 생태계를 중심으로 구성되어 있습니다. + +## 6. 분석 시 참고한 주요 근거 파일 + +- `README.md` +- `docker-compose.yaml` +- `compose.infra.yaml` +- `compose.ory.yaml` +- `backend/go.mod` +- `adminfront/package.json` +- `devfront/package.json` +- `orgfront/package.json` +- `userfront/pubspec.yaml` +- `pnpm-workspace.yaml` + +## 7. 주의사항 + +루트 README의 일부 프로젝트 구조 설명은 현재 저장소의 실제 구성과 완전히 일치하지 않을 수 있습니다. 예를 들어 `adminfront`, `devfront`, `orgfront`는 실제로 React/Vite 기반 패키지이고, `userfront`는 별도의 Flutter 애플리케이션입니다. 따라서 현재 구조 분석은 README 서술보다 실제 매니페스트와 compose 파일을 우선 기준으로 정리했습니다. \ No newline at end of file diff --git a/baron-sso/docs/baronsso_work_timeline_report.md b/baron-sso/docs/baronsso_work_timeline_report.md new file mode 100644 index 0000000..c3d0d68 --- /dev/null +++ b/baron-sso/docs/baronsso_work_timeline_report.md @@ -0,0 +1,588 @@ +# Baron SSO 작업 타임라인 보고서 + +## 1. 보고 목적 + +본 문서는 2026-06-10 기준 Baron SSO 저장소에 대해 진행한 분석 및 로컬 실행 준비 작업의 흐름을 시간 순서대로 정리한 보고서입니다. 사용자의 지시 내용, 확인한 사항, 발생한 문제, 검증 방법, 해결 결과 및 현재 잔여 이슈를 함께 기록합니다. + +## 2. 작업 개요 + +- 대상 저장소: Baron SSO +- 작업 목적: + - 시스템 구조 분석 + - 문서화 + - 로컬 브라우저 실행 방법 파악 + - 로컬 `.env` 구성 + - Docker 기반 실행 준비 + - 현재 환경의 미비점 식별 + +## 3. 타임라인별 작업 내역 + +### 단계 1. 저장소 구조 및 시스템 성격 분석 요청 + +#### 사용자 지시 +- 코드 파일들을 먼저 분석하고, `docs` 디렉토리에 Baron SSO 구조 분석 문서를 생성해 달라는 요청 +- 문서 파일명: `baronsso_structure_analysis.md` +- 포함 내용: + - 어떤 시스템인지 + - 아키텍처가 어떻게 되어 있는지 + - 개발 기술 스택 요약 + +#### 수행한 작업 +- 저장소의 핵심 문서와 설정 파일을 확인함 +- 주요 확인 대상: + - `README.md` + - `docker-compose.yaml` + - `compose.infra.yaml` + - `compose.ory.yaml` + - `backend/go.mod` + - `adminfront/package.json` + - `devfront/package.json` + - `orgfront/package.json` + - `userfront/pubspec.yaml` + - `pnpm-workspace.yaml` + +#### 확인 결과 +- Baron SSO는 단순 로그인 페이지가 아니라 멀티테넌트 SSO/IAM 운영 플랫폼 성격의 시스템으로 판단됨 +- 핵심 아키텍처는 self-hosted Ory Stack(Kratos, Hydra, Keto, Oathkeeper)을 중심으로 구성됨 +- Baron Backend는 Go + Fiber 기반 비즈니스/운영 API 서버 역할 +- 프론트엔드는 역할별로 분리되어 있음 + - `userfront`: Flutter 기반 사용자 UI + - `adminfront`: React/Vite 기반 관리자 UI + - `devfront`: React/Vite 기반 개발자 UI + - `orgfront`: React/Vite 기반 조직/시각화 UI +- 데이터 저장소로 PostgreSQL, ClickHouse, Redis 사용 +- Docker Compose 기반 멀티 서비스 구조임 + +#### 산출물 +- `docs/baronsso_structure_analysis.md` 생성 완료 + +#### 검증 +- 생성된 Markdown 파일에 대해 오류 진단 수행 +- 결과: 오류 없음 + +#### 해결/결론 +- 시스템 구조 분석 및 문서화 작업 완료 + +--- + +### 단계 2. 브라우저에서 어떤 주소를 띄워야 하는지 확인 요청 + +#### 사용자 지시 +- 분석 결과를 바탕으로 브라우저에서 어떤 창을 띄워야 하는지 알려 달라는 요청 + +#### 수행한 작업 +- 실행 절차와 노출 포트를 확인하기 위해 다음 자료를 검토함 + - `Makefile` + - `README.md`의 실행 절차 섹션 + - 각 frontend의 README/패키지 구성 + +#### 확인 결과 +- 기본 사용자 화면은 `userfront` +- 로컬 브라우저 기본 진입 주소는 `http://localhost:5000` +- 추가 접속 대상은 다음과 같음 + - `http://localhost:5173`: adminfront + - `http://localhost:5174`: devfront + - `http://localhost:5175`: orgfront + - `http://localhost:3000/health`: backend health check + +#### 문제점 +- 샘플 환경변수 파일의 일부 URL이 운영/스테이징 도메인 기준이어서 그대로 사용할 경우 로컬 로그인 리다이렉트가 꼬일 가능성이 있었음 + +#### 확인 방법 +- `.env.sample`의 URL 관련 항목과 README의 callback 규칙을 대조함 + +#### 해결/결론 +- 로컬에서는 `localhost` 기준 URL로 재정의해야 한다는 결론 도출 + +--- + +### 단계 3. Laragon 하위 배치 필요 여부 및 현재 환경 미비점 점검 요청 + +#### 사용자 지시 +- Laragon 디렉토리 하위에 위치시켜야 하는지 +- 현재 환경 셋팅에서 부족한 점이 무엇인지 확인해 달라는 요청 + +#### 수행한 작업 +- 실제 로컬 환경의 도구 설치 상태를 점검함 +- 점검 대상: + - Docker + - make + - bash + - go + - flutter + - node + - pnpm + - git + - `.env` 존재 여부 + - `config/.generated/auth-config.env` 존재 여부 + - Docker 엔진 파이프 상태 + +#### 확인 결과 +- 설치/확인됨: + - Docker CLI + - bash + - node + - git +- 미설치 또는 미확인: + - make + - go + - flutter + - pnpm +- 당시 기준 `.env` 없음 +- 당시 기준 `config/.generated/auth-config.env` 없음 +- 당시 Docker 엔진 연결이 정상 동작하지 않았음 + +#### 문제점 +- Docker 클라이언트는 있었으나 엔진 연결이 불안정하거나 미기동 상태였음 +- 실행에 필요한 `.env`와 auth config 생성 파일이 없음 +- 로컬 네이티브 개발 도구 일부가 누락되어 있었음 + +#### 확인 방법 +- PowerShell에서 각 명령어의 존재 여부와 버전 확인 +- Docker 연결 확인 + +#### 해결/결론 +- Laragon 하위에 둘 필요는 없고, 본 프로젝트는 이미 Docker Compose 기반으로 구성되어 있으므로 별도 Laragon 환경은 불필요하다고 판단 +- 핵심 미비점은 Laragon이 아니라 Docker 엔진 상태, `.env`, auth config, 네트워크/레지스트리 접근성이라는 점을 정리 + +--- + +### 단계 4. 포트포워딩만 하면 되는지, 현재 상태 기준 작업 순서 정리 요청 + +#### 사용자 지시 +- Docker는 설치돼 있는 것 같고 포트포워딩만 하면 될 것 같은데, 현재 상황을 파악해서 작업 순서를 알려 달라는 요청 + +#### 수행한 작업 +- 현재 포트 사용 현황과 환경 파일 존재 여부를 재확인함 +- 확인 포트: + - 3000 + - 5000 + - 5173 + - 5174 + - 5175 + - 5432 + - 6389 + - 8123 + +#### 확인 결과 +- 대부분 포트는 비어 있었음 +- `5432`는 이미 다른 프로세스가 점유 중이었음 +- `.env`와 `config/.generated/auth-config.env`는 여전히 없었음 + +#### 문제점 +- Baron SSO의 PostgreSQL 기본 포트와 기존 로컬 PostgreSQL 또는 다른 서비스 포트가 충돌할 가능성이 있었음 +- 포트포워딩만으로 해결되는 상황이 아니라, 리다이렉트 URL과 auth config 생성이 선행되어야 했음 + +#### 확인 방법 +- PowerShell의 포트 점유 확인 명령 사용 + +#### 해결/결론 +- `DB_PORT`를 `5433`으로 조정하는 방향을 제안함 +- 실행 전에 `.env`와 `config/.generated/auth-config.env`를 반드시 준비해야 한다고 정리함 + +--- + +### 단계 5. `.env.sample` 기준으로 로컬 `.env` 초안 정리 요청 + +#### 사용자 지시 +- `.env.sample`을 참조해서 로컬 실행용 `.env`를 정리해 달라는 요청 + +#### 수행한 작업 +- `.env.sample`을 기반으로 운영 도메인을 모두 localhost 기준으로 바꾸는 로컬용 설정 초안을 작성함 + +#### 핵심 반영 사항 +- `USERFRONT_URL=http://localhost:5000` +- `OATHKEEPER_PUBLIC_URL=http://localhost:5000` +- `HYDRA_PUBLIC_URL=http://localhost:5000/oidc` +- `KRATOS_BROWSER_URL=http://localhost:5000/auth` +- `KRATOS_UI_URL=http://localhost:5000` +- `ADMINFRONT_URL=http://localhost:5173` +- `DEVFRONT_URL=http://localhost:5174` +- `ORGFRONT_URL=http://localhost:5175` +- `DB_PORT=5433` + +#### 문제점 +- 기존 `.env.sample`에는 운영 도메인 기준 URL이 들어 있어 로컬 테스트에 그대로 쓰기 부적절했음 + +#### 확인 방법 +- `.env.sample`의 URL/콜백 관련 항목을 로컬 실행 목적에 맞게 재해석함 + +#### 해결/결론 +- 로컬 `.env` 초안 확정 + +--- + +### 단계 6. 실제 `.env` 생성 및 auth config 생성 요청 + +#### 사용자 지시 +- 위에서 정리한 로컬 `.env`를 실제로 적용해 바로 진행해 달라는 요청 + +#### 수행한 작업 +- 저장소 루트에 `.env` 파일 생성 +- 내용은 localhost 기반, `DB_PORT=5433`, 로컬 callback 기반으로 구성 + +#### 산출물 +- 루트 `.env` 생성 완료 + +#### 문제점 1 +- `scripts/auth_config.sh build` 실행 시 WSL 경로 인코딩 문제 발생 +- 경로에 한글/공백이 포함되어 있어 WSL 변환 경로에서 `cd`가 실패함 + +#### 확인 방법 1 +- WSL bash 경유 실행 +- Git Bash 경유 실행 +- 경로 문자열 확인 + +#### 해결 1 +- PowerShell에서 저장소 디렉토리로 먼저 이동한 뒤, 현재 작업 디렉터리를 Git Bash가 그대로 상속받도록 실행 방식 변경 +- 그 결과 경로 이동 문제 없이 스크립트 실행 성공 + +#### 검증 결과 +- `scripts/auth_config.sh build` 성공 +- 생성 파일: + - `config/.generated/auth-config.env` + +#### 추가 확인 내용 +- 스크립트 출력 기준 정상 생성 로그 확인 +- `hydra_url_match_mode: mapped_match` +- admin/dev/org callback 인식 확인 + +#### 해결/결론 +- `.env`와 `auth-config.env` 생성 완료 + +--- + +### 단계 7. Docker 네트워크 준비 및 스택 기동 시도 + +#### 사용자 지시 +- 로컬 실행을 바로 진행하는 방향으로 계속 작업 + +#### 수행한 작업 +- Docker Compose에서 요구하는 외부 네트워크를 생성함 +- 생성/확인한 네트워크: + - `baron_net` + - `ory-net` + - `hydranet` + - `kratosnet` + - `public_net` + +#### 이후 수행한 작업 +- 아래 명령과 동일한 방식으로 infra + Ory stack 기동 시도 + - `docker compose --env-file .env --env-file config/.generated/auth-config.env -f compose.infra.yaml -f compose.ory.yaml up -d` + +#### 문제점 +- Docker Hub 레지스트리 이미지 pull 단계에서 실패 +- 핵심 오류: + - `lookup registry-1.docker.io: no such host` + +#### 확인 방법 +- Docker Compose pull 로그 확인 +- 오류 메시지로 DNS/프록시/레지스트리 접근 문제 판단 + +#### 해결 상태 +- 아직 완전 해결되지 않음 +- 현재는 Docker Desktop이 외부 레지스트리(`registry-1.docker.io`)에 접근하지 못하는 상태로 판단됨 + +#### 현재 판단 +- 문제의 본질은 포트포워딩이 아니라 Docker Desktop 네트워크 또는 사내 프록시/DNS 설정임 + +--- + +### 단계 8. 사내 프록시 주소 정보가 `.env.sample`에 있는지 확인 요청 + +#### 사용자 지시 +- 사내 프록시 주소 정보가 `.env.sample` 파일에 있는지 확인해 달라는 요청 + +#### 수행한 작업 +- `.env.sample`과 저장소 전체에서 다음 키워드를 검색함 + - `proxy` + - `HTTP_PROXY` + - `HTTPS_PROXY` + - `NO_PROXY` + - `http_proxy` + - `https_proxy` + - `no_proxy` + +#### 확인 결과 +- `.env.sample`에는 사내 HTTP/HTTPS 프록시 주소 관련 변수는 없음 +- `.env.sample`의 `Proxy/Handoff` 섹션은 서비스 내부 공개 URL 라우팅 목적이지, 회사망 프록시 설정 목적이 아님 + +#### 문제점 +- 사용자가 필요로 한 것은 Docker Desktop이 외부 인터넷에 접속하기 위한 프록시 설정이었지만, 저장소 `.env`에는 해당 정보가 없음 + +#### 확인 방법 +- `.env.sample` 직접 검색 +- 전체 저장소 텍스트 검색 + +#### 해결/결론 +- 사내 프록시 주소는 저장소 내부 파일보다 다음 위치에서 확보해야 한다고 정리함 + - Docker Desktop 설정 + - Windows 환경변수 + - 사내 네트워크 문서 또는 IT 인프라팀 제공 정보 + +--- + +### 단계 9. 최근 터미널 수동 명령 실행 내역 반영 + +#### 사용자 수행 명령 +- PowerShell Extension 터미널에서 `cd baron-sso` 실행 + +#### 실행 당시 정보 +- 작업 전 현재 디렉터리: `C:\Users\user\Desktop\안건 파일\code_test` +- 명령 실행 후 대상 디렉터리: `C:\Users\user\Desktop\안건 파일\code_test\baron-sso` +- 종료 코드: `0` + +#### 확인 결과 +- 사용자가 저장소 루트 디렉터리로 정상 진입한 것으로 확인됨 + +#### 보고 의미 +- 이후 Docker Compose 명령, `.env` 확인, 설정 파일 검토 등의 후속 작업을 저장소 루트 기준으로 수행할 수 있는 상태가 되었음을 보여주는 실행 이력임 + +--- + +### 단계 10. Docker Desktop 재시작 이후 infra + Ory stack 재기동 및 1차 실패 분석 + +#### 사용자 지시 +- Docker Desktop을 다시 재시작했으니 현재 어디까지 진행됐는지 확인하고, 이어서 바로 진행해 달라는 요청 + +#### 수행한 작업 +- Docker 엔진 상태 확인 +- `docker pull alpine:latest`로 외부 레지스트리 접근 재검증 +- infra + Ory stack 재기동 시도 +- 실패 컨테이너 로그와 이미지 단독 실행 결과 확인 + +#### 확인 결과 +- Docker Desktop 엔진 자체는 정상 동작함 +- `docker pull alpine:latest` 성공으로 Docker Hub 접근 문제는 해소된 것으로 확인됨 +- 그러나 stack 기동 과정에서 아래 이미지들이 `exec format error`로 실패함 + - `postgres:17-trixie` + - `clickhouse/clickhouse-server:latest` + +#### 문제점 +- 초기에는 DNS/프록시 문제로 추정했으나, 재시작 후에는 이미지 태그 호환성 문제가 실제 실패 원인으로 드러남 +- 특히 Ory Postgres와 ClickHouse가 기동 전에 즉시 종료되어 이후 Ory 서비스 전체가 연쇄적으로 생성 상태에 머무름 + +#### 확인 방법 +- `docker compose ... up -d` 로그 확인 +- `docker logs ory_postgres` +- `docker run --rm postgres:17-trixie postgres --version` +- `docker run --rm clickhouse/clickhouse-server:latest clickhouse-server --version` + +#### 해결 +- 저장소 내 다른 템플릿과 CI 사용 태그를 대조함 +- 로컬 실행용 태그를 다음과 같이 조정함 + - `ORY_POSTGRES_TAG=17-alpine` + - `CLICKHOUSE_TAG=24.6` +- 관련 반영 파일: + - `.env` + - `.env.sample` + - `compose.infra.yaml` + - `compose.ory.yaml` + +#### 검증 결과 +- `postgres:17-alpine` 단독 실행 성공 +- `clickhouse/clickhouse-server:24.6` 단독 실행 성공 +- 재기동 시 `ory_postgres`, `baron_clickhouse`, `ory_clickhouse`가 정상 기동됨 + +#### 해결/결론 +- Docker Desktop 재시작 후 네트워크 문제는 해소되었고, 실제 잔여 문제는 일부 이미지 태그 선택 문제였음 + +--- + +### 단계 11. Oathkeeper 생성물 누락 및 Ory 설정 검증 실패 수정 + +#### 사용자 지시 +- stack 기동을 계속 진행하여 실제 서비스가 올라오게 해 달라는 요청 + +#### 수행한 작업 +- `ory_oathkeeper` 실패 로그 확인 +- `config/.generated/ory/oathkeeper` 디렉터리 상태 확인 +- Ory 설정 렌더 스크립트 재실행 +- 이후 Kratos/Hydra 실패 로그 추가 분석 + +#### 확인 결과 +- `ory_oathkeeper`는 `/etc/config/oathkeeper/entrypoint.sh`를 찾지 못해 시작 실패 +- 원인은 `config/.generated/ory/oathkeeper` 디렉터리가 비어 있었기 때문임 +- `scripts/render_ory_config.sh` 실행 시 Windows CRLF 개행 때문에 `.env` source 단계에서 오류 발생 +- 이를 우회해 렌더링 후에는 Oathkeeper 생성물이 정상 생성됨 +- 그 다음 단계에서 Kratos/Hydra가 아래 설정 검증 오류로 종료됨 + - Kratos: `selfservice.allowed_return_urls` 항목 중 `[]`가 배열 값으로 들어감 + - Hydra: `SECRETS_SYSTEM` 길이가 16자 미만이라 검증 실패 + +#### 문제점 +- `.generated/ory` 산출물이 빠져 있으면 compose 설정이 맞아도 Oathkeeper가 시작되지 않음 +- 로컬 `.env` 값 중 `KRATOS_ALLOWED_RETURN_URLS_EXTRA=[]`가 의도와 다르게 실제 배열 항목으로 렌더됨 +- Hydra가 DB 비밀번호(`orysecret`)를 시스템 시크릿으로 재사용하고 있었는데, 길이 정책을 만족하지 못함 + +#### 확인 방법 +- `docker logs ory_oathkeeper` +- `docker logs ory_kratos` +- `docker logs ory_hydra` +- 렌더된 `config/.generated/ory/kratos/kratos.yml` 확인 + +#### 해결 +- LF 개행 임시 파일을 사용해 `scripts/render_ory_config.sh`를 재실행하여 `config/.generated/ory` 재생성 +- `.env`에서 `KRATOS_ALLOWED_RETURN_URLS_EXTRA`를 빈 값으로 정리 +- `.env`에 `HYDRA_SYSTEM_SECRET` 추가 +- `compose.ory.yaml`에서 Hydra가 `SECRETS_SYSTEM=${HYDRA_SYSTEM_SECRET:-${ORY_POSTGRES_PASSWORD}}`를 사용하도록 수정 +- `.env.sample`에도 동일 정책 반영 + +#### 검증 결과 +- 생성 파일 확인: + - `config/.generated/ory/oathkeeper/entrypoint.sh` + - `config/.generated/ory/oathkeeper/oathkeeper.yml` + - `config/.generated/ory/oathkeeper/rules*.json` +- 재기동 후 `ory_kratos`, `ory_hydra`, `ory_keto`, `ory_oathkeeper`, `ory_vector` 정상 기동 +- `ory_stack_check`와 `baron-sso-init-rp-1`이 `Exited (0)`로 완료됨 + +#### 추가 확인 내용 +- Hydra RP 초기화 결과로 아래 클라이언트 등록 성공 확인 + - `adminfront` + - `devfront` + - `orgfront` + - `oathkeeper-introspect` + +#### 해결/결론 +- Ory stack 전체가 초기화와 내부 readiness 검증까지 통과함 + +--- + +### 단계 12. app stack 기동 시 backend DB 포트 오설정 문제 수정 + +#### 사용자 지시 +- 다음 작업을 계속 진행해 로컬 브라우저 접속까지 가능하게 해 달라는 요청 + +#### 수행한 작업 +- `docker-compose.yaml` 기준 app stack 서비스 확인 +- `backend`, `userfront`, `adminfront`, `devfront`, `orgfront` 기동 시도 +- 실패한 `backend` 로그 확인 + +#### 확인 결과 +- `adminfront`, `devfront`, `orgfront`는 먼저 기동됨 +- `backend`는 PostgreSQL 연결 단계에서 즉시 종료됨 +- 핵심 오류: + - `dial tcp ... postgres:5433: connect: connection refused` + +#### 문제점 +- 루트 `.env`의 `DB_PORT=5433`은 호스트 포트 충돌 회피용 값인데, backend 컨테이너 내부에서도 그대로 사용되고 있었음 +- 컨테이너 내부 네트워크에서는 `postgres:5432`로 붙어야 하므로, 호스트 노출 포트와 컨테이너 내부 접속 포트를 분리해야 했음 + +#### 확인 방법 +- `docker logs baron_backend` +- `docker-compose.yaml`의 backend environment 확인 +- backend 코드에서 `DB_PORT` 사용 위치 확인 + +#### 해결 +- `docker-compose.yaml`의 backend 환경변수에 `DB_PORT=5432`를 명시적으로 추가하여 컨테이너 내부 접속 포트를 고정함 + +#### 검증 결과 +- 재기동 후 `baron_backend`가 `healthy` 상태로 전환됨 +- 이어서 `baron_userfront`도 정상 기동됨 + +#### 해결/결론 +- 호스트 포트 회피용 설정과 컨테이너 내부 서비스 포트를 분리하여 backend 기동 문제 해결 + +--- + +### 단계 13. 로컬 브라우저 진입 주소 최종 검증 + +#### 사용자 지시 +- 지금 상태에서 실제 접속 가능한지까지 확인해 달라는 요청 + +#### 수행한 작업 +- app-facing 컨테이너 상태 확인 +- localhost 주소별 HTTP 응답 확인 + +#### 확인 결과 +- 정상 기동 확인 서비스 + - `baron_backend` + - `baron_userfront` + - `baron_adminfront` + - `baron_devfront` + - `baron_orgfront` + - `baron_gateway` +- `baron_gateway`도 최종적으로 `healthy` 상태 확인 +- HTTP 응답 코드 확인 결과 + - `http://localhost:5000` -> `200` + - `http://localhost:5173` -> `200` + - `http://localhost:5174` -> `200` + - `http://localhost:5175` -> `200` + +#### 실패했던 부분 +- 초기에는 `baron_gateway`가 `baron_userfront could not be resolved` 오류로 unhealthy 상태였음 +- 이는 userfront가 아직 뜨지 않았기 때문이며, app stack이 정상 기동된 뒤 해소됨 + +#### 해결/결론 +- Baron SSO 로컬 실행 스택이 브라우저 접속 가능한 상태까지 도달함 + +## 4. 현재까지 생성/변경된 주요 파일 + +- `docs/baronsso_structure_analysis.md` +- `.env` +- `config/.generated/auth-config.env` +- `config/.generated/ory/kratos/kratos.yml` +- `config/.generated/ory/hydra/hydra.yml` +- `config/.generated/ory/keto/keto.yml` +- `config/.generated/ory/oathkeeper/entrypoint.sh` +- `config/.generated/ory/oathkeeper/oathkeeper.yml` +- `compose.infra.yaml` +- `compose.ory.yaml` +- `docker-compose.yaml` +- `.env.sample` + +## 5. 현재까지 확인된 주요 문제 목록 + +### 5.1 로컬 환경 및 설정 문제 +- 초기에는 `.env`가 없었음 +- 초기에는 `config/.generated/auth-config.env`가 없었음 +- `5432` 포트가 이미 사용 중이었음 +- `make`, `go`, `flutter`, `pnpm`이 로컬에 없음 +- 로컬 `.env`의 일부 값이 컨테이너 내부 접속 포트와 외부 노출 포트를 혼용하고 있었음 + +### 5.2 경로 처리 문제 +- 저장소 경로에 한글/공백이 있어 WSL 경유 `bash` 실행 시 경로 변환 실패 발생 +- Windows CRLF 개행 때문에 Bash가 `.env`를 직접 source할 때 오류 발생 + +### 5.3 Docker 이미지 및 런타임 문제 +- `postgres:17-trixie`가 로컬 Docker 환경에서 `exec format error`로 실패 +- `clickhouse/clickhouse-server:latest`가 로컬 Docker 환경에서 `exec format error`로 실패 +- `config/.generated/ory/oathkeeper` 산출물 누락 시 Oathkeeper 시작 실패 +- Kratos allowed return URLs 렌더링 값 오류 +- Hydra system secret 길이 부족 오류 + +### 5.4 현재 남아 있는 참고 사항 +- gateway는 userfront가 떠 있기 전에는 unhealthy가 될 수 있음 +- `DB_PORT=5433`은 호스트 접속용이며, backend 컨테이너 내부 접속은 `5432` 고정이 필요함 + +## 6. 현재까지 해결된 항목 + +- Baron SSO 구조 분석 문서 작성 완료 +- 로컬 실행용 `.env` 작성 완료 +- `config/.generated/auth-config.env` 생성 완료 +- Docker 네트워크 생성 완료 +- 기본 서비스 포트 점검 완료 +- DB 포트 충돌 회피안(`5433`) 반영 완료 +- Docker Hub 접근 정상화 확인 완료 +- 로컬 호환 태그 기준 Ory Postgres/ClickHouse 기동 완료 +- `config/.generated/ory` 재생성 완료 +- Ory stack 전체 기동 및 readiness 검증 완료 +- Hydra RP 초기화 완료 +- backend DB 포트 오설정 수정 완료 +- app stack 기동 완료 +- localhost 브라우저 진입 주소 응답 확인 완료 + +## 7. 현재 미해결 항목 + +- 현 시점 기준 치명적 미해결 항목 없음 +- 다만 실제 로그인/회원가입/OIDC callback까지 포함한 사용자 시나리오 E2E 검증은 아직 별도로 수행하지 않음 + +## 8. 다음 권장 작업 순서 + +1. 브라우저에서 `http://localhost:5000`에 접속해 실제 로그인/회원가입 흐름 검증 +2. admin/dev/org front에서 OIDC redirect 및 callback 정상 동작 확인 +3. 필요 시 현재 로컬 실행용 수정사항을 README 또는 운영 문서에 반영 +4. 필요 시 `.env`의 로컬 전용 값과 배포 전용 값을 분리하는 정책 정리 + +## 9. 최종 요약 + +이번 작업에서는 Baron SSO 저장소 구조 분석과 문서화에서 출발해, 로컬 `.env` 및 auth config 생성, Docker 네트워크 준비, infra + Ory stack 기동, app stack 기동, 그리고 브라우저 접속 검증까지 순차적으로 완료했습니다. 진행 중 Docker Desktop 재시작 이후 레지스트리 접근 문제는 해소되었고, 이후에는 이미지 태그 호환성 문제, Ory 생성물 누락, Kratos/Hydra 설정 검증 오류, backend DB 포트 오설정 문제가 순차적으로 드러났습니다. 각 문제는 로그와 렌더 결과를 기준으로 원인을 확인한 뒤 태그 조정, 설정 재생성, 환경값 수정, compose 환경변수 보정으로 해결했습니다. 최종적으로 `http://localhost:5000`, `http://localhost:5173`, `http://localhost:5174`, `http://localhost:5175`가 모두 `200` 응답을 반환하는 상태까지 도달했습니다. \ No newline at end of file