From 1154d2f550113f7839f7196f6e3215ea67cac188 Mon Sep 17 00:00:00 2001 From: happybell80 Date: Tue, 17 Mar 2026 22:51:31 +0900 Subject: [PATCH] docs: record rb8001 slack signing secret recovery --- ...ents_signature_mismatch_and_500_mapping.md | 5 ++ ...secret_오값복구_및_실유입검증.md | 49 +++++++++++++++++++ 2 files changed, 54 insertions(+) create mode 100644 journey/worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md diff --git a/journey/troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md b/journey/troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md index 5cbfcdf..cbb7030 100644 --- a/journey/troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md +++ b/journey/troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md @@ -88,6 +88,11 @@ - `/gateway/slack/events` 실유입 기준으로 200/403 분포를 24시간 관찰 - 재발 시 게이트웨이 원문 body 전달(`content=raw_body`) 경로와 nginx 로그를 시각 동기화해 재검증 +## 후속 복구 + +- 2026-03-17 실제 재발은 게이트 본문 전달 문제가 아니라 24서버 `rb8001`의 `SLACK_SIGNING_SECRET` 오값과 compose 빈값 덮어쓰기 구조가 직접 원인이었습니다. +- 상세 복구 기록: [rb8001 Slack Signing Secret 오값 복구 및 실유입 검증](../worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md) + ## 관련 파일 - `robeing-gateway/app/routers/slack.py` diff --git a/journey/worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md b/journey/worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md new file mode 100644 index 0000000..375b693 --- /dev/null +++ b/journey/worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md @@ -0,0 +1,49 @@ +--- +tags: [robeing, rb8001, slack, signing-secret, recovery, worklog] +--- + +# rb8001 Slack Signing Secret 오값 복구 및 실유입 검증 + +**날짜**: 2026-03-17 +**작성자**: Codex + +## 왜 + +- 23서버 게이트를 거쳐 24서버 `rb8001`까지 Slack 이벤트가 도달했지만, `rb8001`에서 `Invalid Slack signature`가 반복되어 로빙이 응답하지 못했습니다. +- 로그 기준 직접 증상은 `2026-03-17 22:23:41`, `22:23:42`, `22:24:43`, `22:37:30`, `22:37:31`, `22:37:36`, `22:37:37`의 `Invalid Slack signature`였습니다. + +## 무엇을 확인했는가 + +1. 24서버 `rb8001` 실행 환경에서 `SLACK_SIGNING_SECRET`, `SLACK_BOT_TOKEN`, `SLACK_APP_TOKEN`, `JWT_SECRET_KEY`, `SERVICE_API_KEY`가 비어 있던 상태를 확인했습니다. +2. `rb8001`의 `docker-compose.yml`이 `env_file` 값을 쓰는 동시에 `${...}` 셸 치환으로 같은 키를 다시 주입하고 있었고, 호스트 셸에 값이 없어서 빈 문자열로 덮어쓰고 있음을 확인했습니다. +3. Slack 앱 `A092HLQA1NW`의 실제 `Signing Secret`은 `995cdf...af22`인데, 당시 `rb8001`에는 다른 값이 들어가 있음을 확인했습니다. +4. 문서와 코드 기준 정상 경로는 `Slack -> 23서버 게이트(/gateway/slack/events) -> 24서버 rb8001(/api/slack/events)`이며, 이번 장애의 직접 원인은 게이트 이전이 아니라 24서버 런타임 시크릿 오값이었습니다. + +## 어떻게 복구했는가 + +1. `/home/admin/workspace-config/secrets.env`에 누락된 Slack/JWT/API 키를 SSOT로 복구했습니다. +2. `rb8001/docker-compose.yml`에서 `${SLACK_*}`, `${JWT_SECRET_KEY}` 등 셸 치환으로 SSOT 값을 덮어쓰던 항목을 제거해 `env_file`만 단일 출처로 사용하도록 정리했습니다. +3. `SLACK_SIGNING_SECRET`를 실제 Slack 앱 값으로 교체했습니다. +4. `rb8001` 컨테이너를 재생성했습니다. + +## 검증 + +1. `rb8001` 컨테이너가 `healthy` 상태로 기동했습니다. +2. 컨테이너 환경에 `SLACK_SIGNING_SECRET`, `SLACK_BOT_TOKEN`, `SLACK_APP_TOKEN`, `JWT_SECRET_KEY`, `SERVICE_API_KEY`가 정상 주입됨을 확인했습니다. +3. 현재 `SLACK_SIGNING_SECRET`으로 서명한 `POST /api/slack/events` 테스트가 `200`과 challenge 응답을 반환했습니다. +4. 실유입 로그에서 `2026-03-17 22:49:58` 시점 `POST /api/slack/events HTTP/1.1" 200 OK`, `Event: message from U09BQSN72UT: 로빙?`, `Scheduling async processing`가 기록되어 실제 Slack 이벤트가 서명 단계 통과 후 처리되기 시작했음을 확인했습니다. + +## 원인값 + +- 24서버 `rb8001`의 `SLACK_SIGNING_SECRET`가 운영 Slack 앱의 실제 값과 달랐습니다. +- 동시에 `docker-compose.yml`의 `${...}` 셸 치환이 `env_file` 기반 SSOT를 빈 문자열로 덮어쓰는 구조여서, 복구 이후에도 재발 가능성이 있었습니다. + +## 재발 방지 + +1. 운영 시크릿은 `/home/admin/workspace-config/secrets.env`만 SSOT로 사용합니다. +2. `docker-compose.yml`에서 같은 키를 `${...}`로 다시 주입하지 않습니다. +3. Slack 앱 시크릿 교체 시 `workspace-config/secrets.env`와 실행 컨테이너 환경을 함께 검증합니다. + +## 관련 문서 + +- [Gateway Slack Events 서명 불일치 및 500 매핑 이슈 정리](../troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md)