chore: JWT_PRIVATE_KEY를 pinlog-secrets-prod에 등록하고 Secret 전달 workflow로 운영에 주입한다

[cherry-go-round]

운영 서명 키를 실제로 넣는 작업이다. #101이 문제를 기록했고, #100이 머지되며 전달 수단이 생겼다 — 그래서 #101 본문의 절차(인프라가 수동으로 SealedSecret을 만든다)는 지금 기준으로 낡았다. 이 이슈는 새 수단으로 실행하는 부분만 다룬다.

지금 상태 — 확인한 것

.github/workflows/seal-runtime-secrets.yml(#100, BI-26)이 pinlog-secrets-prod Environment의 시크릿을 읽어 Infra SealedSecret Draft PR을 만든다. 그 Environment에 9개 중 7개가 이미 등록되어 있다.

시크릿	등록	담당
GOOGLE_CLIENT_ID · GOOGLE_CLIENT_SECRET	✅	—
KAKAO_CLIENT_ID · KAKAO_CLIENT_SECRET	✅	—
NAVER_CLIENT_ID · NAVER_CLIENT_SECRET	✅	—
PINLOG_AI_INTERNAL_SECRET	✅	값이 AI 쪽과 같아야 한다(#102)
JWT_PRIVATE_KEY	❌	이 이슈
PINLOG_INFRA_SECRET_PR_TOKEN	❌	인프라 — 직접 발급·등록 예정(#102 코멘트)

즉 workflow는 이 두 개가 채워지기 전까지 실행할 수 없다. 하나는 이 이슈, 하나는 인프라 소관이다.

왜 지금 해야 하는가

키가 없으면 JwtKeyProvider가 기동할 때 임시 키쌍을 만든다. 운영에서는 배포·재시작마다 전체 사용자 로그아웃이고, replicaCount가 2 이상이면 간헐적 401이 상시 발생한다(#101의 표). 재현이 안 되는 로그인 실패로 나타나서 원인을 찾기 어려운 종류의 고장이다.

이 작업은 prod 프로파일 활성화를 기다리지 않는다. private-key: ${JWT_PRIVATE_KEY:}가 application.yml의 base 설정이라 프로파일이 꺼진 지금도 주입한 값이 그대로 읽힌다. 프로파일 활성화(=fail-fast 복원)는 #101·#102의 순서 문제로 남고, 실제 사용자 피해는 이 이슈만으로 사라진다.

할 일

• RSA 2048 PKCS#8 PEM 키를 만든다. 저장소에 커밋하지 않는다(public 저장소다)

  openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out jwt-prod.pem

• Team-PinLog/back → Settings → Environments → pinlog-secrets-prod에 JWT_PRIVATE_KEY로 등록한다. PEM 전문을 개행 그대로 붙여 넣는다

• 인프라가 PINLOG_INFRA_SECRET_PR_TOKEN을 등록했는지 확인한다 (없으면 workflow가 PR을 만들 수 없다)

• Seal backend runtime secrets workflow를 수동 실행(workflow_dispatch)한다

• 생성된 Infra Draft PR을 인프라와 함께 검토·병합한다

• 로컬 개발용으로도 필요하면 .env에 넣는 방법을 configuration.md·BT-05 기준으로 안내한다(선택)

주의 두 가지

PEM 개행. JwtKeyProvider.fromPem이 파싱 전에 replaceAll("\s", "")로 공백·개행을 모두 지운다. 그래서 실제 개행이 들어간 PEM 원문을 그대로 넣으면 된다. 반대로 \n 두 글자 문자열로 치환해 넣으면 역슬래시가 남아 base64 디코딩이 깨진다 — 로컬 .env에 \n으로 적는 방식(properties 파서가 실제 개행으로 되돌린다)과 다르므로 혼동하지 않는다.

키 회전은 구현되어 있지 않다. kid 헤더만 심어 뒀고 여러 키를 동시에 검증하지 않는다. 한번 정한 키를 바꾸면 그 시점에 전체 로그아웃이 되고, 키를 잃어버리는 경우도 같다. 등록한 값을 안전하게 보관해야 한다(BD-31).

완료 조건

• pinlog-secrets-prod에 JWT_PRIVATE_KEY가 등록된다
• Seal backend runtime secrets workflow가 성공하고 Infra SealedSecret PR이 생성된다
• 운영 파드의 환경변수에 JWT_PRIVATE_KEY가 주입된다
• 배포·재시작 후에도 기존 세션이 유지된다 (임시 키 생성 경로를 타지 않는다)
• 저장소 어디에도 PEM 원본이 커밋되지 않는다

참고

• [INFRA] 운영에 prod 프로파일이 꺼져 있다 — fail-fast 미작동, API 문서가 외부에 열려 있다 #101 — 문제 기록. 본문의 "해야 할 일(인프라)" 절차는 chore(S15P11A705-154): add runtime secret handoff workflow #100 이후 이 이슈로 대체된다. 그 이슈의 SPRING_PROFILES_ACTIVE=prod는 여기 범위가 아니다
• [INFRA] 운영에 PINLOG_AI_BASE_URL이 없다 — 실패가 조용히 삼켜진다 #102 — PINLOG_AI_INTERNAL_SECRET·PINLOG_AI_BASE_URL. 프로파일 활성화의 선행 조건이며 시연 범위 결정을 기다리는 중이다
• docs/development/configuration.md — JWT_PRIVATE_KEY는 운영 필수

[minyongP]

우선순위 근거 추가 — 이 workflow가 실행되기 전까지 운영 구글 로그인이 아예 안 됩니다.

본문은 이 이슈의 피해를 "배포·재시작마다 전체 로그아웃"으로 적고 있는데, 실제로는 그 앞 단계가 이미 막혀 있습니다. 같은 workflow가 구글 자격증명도 함께 봉인하기 때문입니다(seal-runtime-secrets.yml 22~31행: JWT_PRIVATE_KEY·GOOGLE_*·KAKAO_*·NAVER_*·PINLOG_AI_INTERNAL_SECRET).

지금 운영 상태:

$ curl -sI https://pin-log.com/api/core/v1/auth/authorize/google | grep -i location
location: https://accounts.google.com/o/oauth2/v2/auth?response_type=code
  &client_id=unset
  &redirect_uri=https://pin-log.com/api/core/v1/auth/google/callback
  &...

GOOGLE_CLIENT_ID가 Environment에는 등록되어 있으나 아직 봉인·주입되지 않아 application.yml의 기본값 unset이 그대로 나갑니다. 구글은 그런 클라이언트를 모르니 invalid_client으로 거부하고, https://pin-log.com/login 에서 로그인 자체가 성립하지 않습니다.

즉 이 이슈는 "세션 유지 품질" 문제가 아니라 로그인 기능 정지를 푸는 작업입니다. 남은 차단 요소는 본문 표 그대로 두 개(JWT_PRIVATE_KEY 등록, PINLOG_INFRA_SECRET_PR_TOKEN 등록)입니다.

완료 조건에 하나 빠져 있습니다 — 구글 콘솔의 승인된 리디렉션 URI.

자격증명이 주입되면 인가 요청은 위 URL의 redirect_uri를 그대로 씁니다.

https://pin-log.com/api/core/v1/auth/google/callback

이 값이 운영 OAuth 클라이언트에 등록되어 있지 않으면 invalid_client이 redirect_uri_mismatch로 바뀔 뿐 로그인은 여전히 안 됩니다. 등록 여부는 콘솔에서만 확인할 수 있어 이 이슈에서 판단하지 못했습니다. 완료 조건에 다음 항목을 더하는 것을 제안합니다.

• 운영 OAuth 클라이언트(웹)에 https://pin-log.com/api/core/v1/auth/google/callback이 승인된 리디렉션 URI로 등록되어 있다
• 실제 브라우저로 로그인을 끝까지 완료한다 (invalid_client·redirect_uri_mismatch 둘 다 나오지 않는다)

Team-PinLog/infra에 같은 내용으로 열었던 이슈 2건(#87·#88)은 중복이라 닫고 이쪽으로 모았습니다.

[minyongP]

인프라 요청 — PINLOG_INFRA_SECRET_PR_TOKEN 등록 부탁드립니다. @tpals0409

JWT_PRIVATE_KEY는 이쪽에서 등록합니다(RSA 2048 PKCS#8 PEM 생성 완료). 그러면 봉인 정책 infra/policy/sealedsecrets/back-prod.yaml이 요구하는 7개 키가 모두 채워집니다.

JWT_PRIVATE_KEY   ← 이쪽에서 등록
GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET   ✅ 등록됨
KAKAO_CLIENT_ID  / KAKAO_CLIENT_SECRET    ✅ 등록됨
NAVER_CLIENT_ID  / NAVER_CLIENT_SECRET    ✅ 등록됨

남는 것은 PINLOG_INFRA_SECRET_PR_TOKEN 하나입니다. pinlog-secrets-prod Environment에 현재 등록된 시크릿을 확인했습니다.

$ gh api repos/Team-PinLog/back/environments/pinlog-secrets-prod/secrets --jq '.secrets[].name'
GOOGLE_CLIENT_ID
GOOGLE_CLIENT_SECRET
KAKAO_CLIENT_ID
KAKAO_CLIENT_SECRET
NAVER_CLIENT_ID
NAVER_CLIENT_SECRET
PINLOG_AI_INTERNAL_SECRET

이 값이 없으면 워크플로가 봉인까지 하고도 Infra remote credential is unavailable로 끝납니다(sealedsecret_infra_pr.py). 필요한 권한은 스크립트가 쓰는 API 기준으로 이렇게 읽힙니다 — 확정은 발급하시는 쪽에서 봐 주세요.

대상	필요 권한	쓰는 곳
Team-PinLog/infra	contents write, pull requests write	automation/secrets-back-prod 브랜치 갱신 + Draft PR 생성
Team-PinLog/back	actions read	실행 출처 검증 시 actions/runs/{run_id} 조회

왜 지금인가

이 값이 등록되기 전까지 운영 구글 로그인이 복구되지 않습니다. 같은 워크플로가 구글 자격증명도 함께 봉인하기 때문에, 지금 https://pin-log.com/login 에서 로그인이 아예 성립하지 않는 상태(client_id=unset → invalid_client)가 이 토큰 하나에 걸려 있습니다. 앞 코멘트의 측정 결과 그대로입니다.

등록해 주시면 워크플로를 수동 실행하고, 생성되는 infra Draft PR을 함께 검토하겠습니다. Environment에 승인 규칙은 걸려 있지 않아(protection rules 없음) 두 값이 채워지면 바로 실행됩니다.

[minyongP]

완료 조건 대부분이 07-30에 충족됐습니다 — 확인 결과만 남깁니다. 작성자 이슈라 상태는 그대로 뒀습니다.

본문 표의 차단 요소 두 개가 모두 채워졌고, 워크플로가 성공했습니다.

$ gh api repos/Team-PinLog/back/environments/pinlog-secrets-prod/secrets --jq '.secrets[].name'
GOOGLE_CLIENT_ID
GOOGLE_CLIENT_SECRET
JWT_PRIVATE_KEY                  ← 채워짐
KAKAO_CLIENT_ID
KAKAO_CLIENT_SECRET
NAVER_CLIENT_ID
NAVER_CLIENT_SECRET
PINLOG_AI_INTERNAL_SECRET
PINLOG_INFRA_SECRET_PR_TOKEN     ← 채워짐

Seal backend runtime secrets   run 30526570990   2026-07-30T08:24:32Z   success

앞선 9회(08:01~08:22)는 실패했고 마지막 실행만 성공했습니다. 결과물도 병합됐습니다.

infra 5ed376d  chore: refresh back prod owner Secret (#101)
  + secrets/prod/back-owner-secrets.sealedsecret.yaml   (7개 키 봉인)
    apps/prod/back/values.yaml:57  envFrom.secretRef: back-owner-secrets

완료 조건 대조

조건	상태
pinlog-secrets-prod에 JWT_PRIVATE_KEY 등록	✅
워크플로 성공 + Infra SealedSecret PR 생성	✅ (infra #101 병합)
운영 파드에 JWT_PRIVATE_KEY 주입	✅ envFrom
저장소에 PEM 원본 미커밋	✅ 봉인된 암호문만
배포·재시작 후 세션 유지	재시작 전후를 직접 재보지 않아 미확인

제가 코멘트로 덧붙였던 구글 로그인 차단도 풀렸습니다. client_id=unset이 실제 값으로 바뀌었습니다.

$ curl -sI https://pin-log.com/api/core/v1/auth/authorize/google | grep -i location
location: https://accounts.google.com/o/oauth2/v2/auth?response_type=code
  &client_id=1001254181664-macme54tvpugcsqohd1r26nbu2aksdbn.apps.googleusercontent.com
  &redirect_uri=https://pin-log.com/api/core/v1/auth/google/callback&...

redirect_uri_mismatch 여부와 실제 브라우저 완주는 확인하지 못했습니다. 그 두 가지만 보시고 닫으시면 될 것 같습니다.

SPRING_PROFILES_ACTIVE=prod는 본문대로 이 이슈 범위 밖이고 #101에 남아 있습니다. 다만 이 작업으로 그쪽 선행 조건이 전부 풀렸다는 점은 #101에 적어 뒀습니다.

[cherry-go-round]

완료로 닫습니다. 운영 로그인 완주를 확인했습니다.

완료 조건 대조

조건	상태	근거
pinlog-secrets-prod에 JWT_PRIVATE_KEY 등록	✅	Environment 시크릿 9개에 포함
워크플로 성공 + Infra SealedSecret PR 생성	✅	Seal backend runtime secrets 2026-07-30T08:24:32Z success → infra#101 병합
운영 파드에 JWT_PRIVATE_KEY 주입	✅	secrets/prod/back-owner-secrets.sealedsecret.yaml(7키) + apps/prod/back/values.yaml의 envFrom.secretRef
저장소에 PEM 원본 미커밋	✅	봉인된 암호문만
배포·재시작 후 세션 유지	⚠️ 기전으로 성립, 직접 측정은 안 함	아래
구글 콘솔 승인된 리디렉션 URI	✅	실제 브라우저 로그인 완주로 확인 — redirect_uri_mismatch가 나지 않았다

한 항목은 추론입니다

"배포·재시작 후에도 기존 세션이 유지된다"를 재시작 전후로 직접 재보지는 않았습니다.

성립하는 근거는 기전입니다 — 키가 envFrom으로 주입되므로 모든 파드가 같은 키로 서명·검증하고, kid는 공개키 thumbprint 기반이라 재시작해도 같은 값이 나옵니다. 즉 임시 키 생성 경로(JwtKeyProvider가 주입값이 비었을 때 타는 분기)를 더 이상 타지 않습니다.

측정으로 확정하려면 파드를 한 번 재시작하고 기존 쿠키로 보호 경로를 호출해 200이 나오는지 보면 됩니다. 다음 배포 때 자연히 확인되므로 그것을 위해 이 이슈를 열어 두지는 않습니다 — 깨지면 증상(배포마다 전면 로그아웃)이 즉시 드러납니다.

이 작업으로 함께 풀린 것

운영 구글 로그인 차단이 해소됐습니다. 같은 워크플로가 OAuth 자격증명도 봉인하므로, client_id=unset → invalid_client으로 로그인이 성립하지 않던 상태가 함께 풀렸습니다.

범위 밖으로 남는 것

• SPRING_PROFILES_ACTIVE=prod — #101에 남아 있습니다. 이 작업으로 그쪽 선행 조건(JWT_PRIVATE_KEY·PINLOG_AI_INTERNAL_SECRET 주입)이 전부 풀렸으므로, 프로파일을 켜면 fail-fast가 복원됩니다.
• 간헐적 OAUTH_FAILED — 로그인이 완주하는 것과 별개로 남아 있는 현상이며 S15P11A705-186·S15P11A705-187로 추적합니다.