Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 DongHyeonkaandClaude Opus 5
|
027c24ee27 | ||
|
DongHyeonkaandClaude Opus 5
|
df140ab218 | ||
|
DongHyeonkaandClaude Opus 5
|
df5af95cb3 | ||
|
DongHyeonkaandClaude Opus 5
|
6c310c93b7 |
@@ -0,0 +1 @@
|
||||
- generic [active] [ref=f50e1]: "{\"pattern\":\"AP3-backend-for-frontend\",\"principal\":\"labuser\",\"accessTokenStoredOnServer\":true,\"refreshTokenStoredOnServer\":true,\"browserTokenCount\":0,\"csrfProtectionEnabled\":true}"
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f51e3]:
|
||||
- banner [ref=f51e4]:
|
||||
- generic [ref=f51e5]: keycloak-patterns
|
||||
- main [ref=f51e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f51e8]
|
||||
- generic [ref=f51e12]:
|
||||
- generic [ref=f51e13]:
|
||||
- generic [ref=f51e14]: Username or email
|
||||
- textbox "Username or email" [active] [ref=f51e17]
|
||||
- generic [ref=f51e18]:
|
||||
- generic [ref=f51e19]: Password
|
||||
- generic [ref=f51e21]:
|
||||
- textbox "Password" [ref=f51e24]
|
||||
- button "Show password" [ref=f51e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f51e27]:
|
||||
- button "Sign In" [ref=f51e30] [cursor=pointer]
|
||||
@@ -0,0 +1,7 @@
|
||||
- main [ref=f52e2]:
|
||||
- heading "AP3 · Backend-for-Frontend" [level=1] [ref=f52e3]
|
||||
- paragraph [ref=f52e4]: 브라우저에는 OAuth token이 전혀 전달되지 않습니다. HttpOnly session cookie로 BFF만 호출하고, BFF가 서버 보관 access token을 Resource Server 요청에 붙입니다.
|
||||
- button "Keycloak 로그인" [ref=f52e5] [cursor=pointer]
|
||||
- button "token 경계 확인" [ref=f52e6] [cursor=pointer]
|
||||
- button "BFF 경유 API 호출" [ref=f52e7] [cursor=pointer]
|
||||
- button "CSRF token으로 상태 변경" [ref=f52e8] [cursor=pointer]
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f53e3]:
|
||||
- banner [ref=f53e4]:
|
||||
- generic [ref=f53e5]: keycloak-patterns
|
||||
- main [ref=f53e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f53e8]
|
||||
- generic [ref=f53e12]:
|
||||
- generic [ref=f53e13]:
|
||||
- generic [ref=f53e14]: Username or email
|
||||
- textbox "Username or email" [ref=f53e17]
|
||||
- generic [ref=f53e18]:
|
||||
- generic [ref=f53e19]: Password
|
||||
- generic [ref=f53e21]:
|
||||
- textbox "Password" [ref=f53e24]
|
||||
- button "Show password" [ref=f53e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f53e27]:
|
||||
- button "Sign In" [ref=f53e30] [cursor=pointer]
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f53e3]:
|
||||
- banner [ref=f53e4]:
|
||||
- generic [ref=f53e5]: keycloak-patterns
|
||||
- main [ref=f53e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f53e8]
|
||||
- generic [ref=f53e12]:
|
||||
- generic [ref=f53e13]:
|
||||
- generic [ref=f53e14]: Username or email
|
||||
- textbox "Username or email" [ref=f53e17]: labuser
|
||||
- generic [ref=f53e18]:
|
||||
- generic [ref=f53e19]: Password
|
||||
- generic [ref=f53e21]:
|
||||
- textbox "Password" [active] [ref=f53e24]: labpass
|
||||
- button "Show password" [ref=f53e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f53e27]:
|
||||
- button "Sign In" [ref=f53e30] [cursor=pointer]
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f53e3]:
|
||||
- banner [ref=f53e4]:
|
||||
- generic [ref=f53e5]: keycloak-patterns
|
||||
- main [ref=f53e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f53e8]
|
||||
- generic [ref=f53e12]:
|
||||
- generic [ref=f53e13]:
|
||||
- generic [ref=f53e14]: Username or email
|
||||
- textbox "Username or email" [ref=f53e17]: labuser
|
||||
- generic [ref=f53e18]:
|
||||
- generic [ref=f53e19]: Password
|
||||
- generic [ref=f53e21]:
|
||||
- textbox "Password" [active] [ref=f53e24]: labpass
|
||||
- button "Show password" [ref=f53e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f53e27]:
|
||||
- button "Sign In" [ref=f53e30] [cursor=pointer]
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f53e3]:
|
||||
- banner [ref=f53e4]:
|
||||
- generic [ref=f53e5]: keycloak-patterns
|
||||
- main [ref=f53e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f53e8]
|
||||
- generic [ref=f53e12]:
|
||||
- generic [ref=f53e13]:
|
||||
- generic [ref=f53e14]: Username or email
|
||||
- textbox "Username or email" [ref=f53e17]: labuser
|
||||
- generic [ref=f53e18]:
|
||||
- generic [ref=f53e19]: Password
|
||||
- generic [ref=f53e21]:
|
||||
- textbox "Password" [active] [ref=f53e24]: labpass
|
||||
- button "Show password" [ref=f53e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f53e27]:
|
||||
- button "Sign In" [ref=f53e30] [cursor=pointer]
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f54e3]:
|
||||
- banner [ref=f54e4]:
|
||||
- generic [ref=f54e5]: keycloak-patterns
|
||||
- main [ref=f54e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f54e8]
|
||||
- generic [ref=f54e12]:
|
||||
- generic [ref=f54e13]:
|
||||
- generic [ref=f54e14]: Username or email
|
||||
- textbox "Username or email" [ref=f54e17]
|
||||
- generic [ref=f54e18]:
|
||||
- generic [ref=f54e19]: Password
|
||||
- generic [ref=f54e21]:
|
||||
- textbox "Password" [ref=f54e24]
|
||||
- button "Show password" [ref=f54e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f54e27]:
|
||||
- button "Sign In" [ref=f54e30] [cursor=pointer]
|
||||
@@ -0,0 +1,16 @@
|
||||
- generic [ref=f54e3]:
|
||||
- banner [ref=f54e4]:
|
||||
- generic [ref=f54e5]: keycloak-patterns
|
||||
- main [ref=f54e6]:
|
||||
- heading "Sign in to your account" [level=1] [ref=f54e8]
|
||||
- generic [ref=f54e12]:
|
||||
- generic [ref=f54e13]:
|
||||
- generic [ref=f54e14]: Username or email
|
||||
- textbox "Username or email" [ref=f54e17]: labuser
|
||||
- generic [ref=f54e18]:
|
||||
- generic [ref=f54e19]: Password
|
||||
- generic [ref=f54e21]:
|
||||
- textbox "Password" [active] [ref=f54e24]: labpass
|
||||
- button "Show password" [ref=f54e26] [cursor=pointer]:
|
||||
- generic [aria-hidden] [ref=f54e27]:
|
||||
- button "Sign In" [ref=f54e30] [cursor=pointer]
|
||||
@@ -0,0 +1,12 @@
|
||||
=== 현재 클라이언트의 백채널 로그아웃 설정 ===
|
||||
--- bff-confidential ---
|
||||
"frontchannelLogout" : false,
|
||||
--- oauth2-proxy ---
|
||||
"frontchannelLogout" : false,
|
||||
|
||||
=== BFF 가 백채널 로그아웃 엔드포인트를 갖고 있는가 ===
|
||||
|
||||
=== 실제로 그 경로가 있는가 ===
|
||||
/logout/connect/back-channel/keycloak HTTP 302
|
||||
/backchannel-logout HTTP 302
|
||||
/oauth2/sign_out HTTP 302
|
||||
@@ -0,0 +1,8 @@
|
||||
=== IdP 쪽에만 백채널 로그아웃 URL 을 설정한다 ===
|
||||
client id: 9055fa46-6abb-4d6d-a339-8a9183bbf26d
|
||||
command terminated with exit code 1
|
||||
|
||||
=== 로그인 상태를 만든다 ===
|
||||
(브라우저에 이미 세션이 있다)
|
||||
Keycloak 세션: 2
|
||||
Redis: 2 키
|
||||
@@ -0,0 +1,28 @@
|
||||
=== 로그아웃 전 상태 ===
|
||||
Redis: 2 키
|
||||
keycloak-patterns 세션: 0
|
||||
|
||||
=== ★ IdP 로그아웃 — Keycloak 이 백채널 알림을 보낼 것이다 ===
|
||||
시각: 14:53:29
|
||||
|
||||
=== Keycloak 로그 — 백채널 요청을 보냈는가, 결과는 ===
|
||||
|
||||
=== BFF 로그 — 백채널 요청이 도착했는가 ===
|
||||
|
||||
=== 앱 세션이 정리되었는가 ===
|
||||
Redis: 2 키
|
||||
_oauth2_proxy-6b028a70f69c8f0da9966eb36972dff2
|
||||
bff:session:sessions:6e0d9af4-2c8f-47d2-bf83-8b1e9670c679
|
||||
=== 로그아웃 전 — 실제 세션이 있는가 ===
|
||||
keycloak-patterns 세션: 1
|
||||
Redis: 1 키
|
||||
|
||||
=== ★ IdP 로그아웃 → 백채널 알림 ===
|
||||
시각: 14:54:21
|
||||
|
||||
=== Keycloak 로그 ===
|
||||
|
||||
=== BFF 로그 — 요청이 왔는가 ===
|
||||
|
||||
=== 앱 세션 ===
|
||||
Redis: 1 키
|
||||
@@ -0,0 +1,15 @@
|
||||
=== IdP 세션은 실제로 끊겼는가 ===
|
||||
keycloak-patterns 세션: 0
|
||||
|
||||
=== ★ Keycloak 파드가 app1.hyeonworks.com 에 닿는가 ===
|
||||
DNS 해석:
|
||||
Address: 100.83.212.4
|
||||
|
||||
Non-authoritative answer:
|
||||
|
||||
HTTPS 도달:
|
||||
HTTP 200 (0 이면 못 닿음)
|
||||
|
||||
=== Keycloak 로그 전체에서 backchannel 흔적 ===
|
||||
keycloak-0: 0 줄
|
||||
keycloak-1: 0 줄
|
||||
@@ -0,0 +1,17 @@
|
||||
# C-2 — 백채널 로그아웃 증거
|
||||
|
||||
2026-09-04 16:30–16:55 KST
|
||||
해설: [`docs/experiment-c2-backchannel-logout.md`](../../experiment-c2-backchannel-logout.md)
|
||||
|
||||
| 파일 | 무엇을 보여주는가 |
|
||||
|---|---|
|
||||
| `01-current-state.txt` | 두 클라이언트 모두 `backchannelLogoutUrl` 없음 · BFF 소스에 `oidcLogout` 없음 · 후보 경로 셋 다 **302**(핸들러 없음) |
|
||||
| `02-configure-idp.txt` | IdP 쪽에만 `backchannel.logout.url` 설정 (점 표기는 실패, JSON 으로 성공) |
|
||||
| `03-logout-attempt.txt` | **살아 있는 세션(1)에 로그아웃 → IdP 세션 0, Redis 세션은 1 그대로.** Keycloak·BFF 로그에 흔적 없음 |
|
||||
| `04-reachability.txt` | **Keycloak 파드가 `app1.hyeonworks.com` 에 `HTTP 200` 으로 닿는다** — 네트워크 문제가 아님 |
|
||||
|
||||
## 핵심 세 줄
|
||||
|
||||
1. **백채널 로그아웃은 어느 쪽에도 구현되어 있지 않았다.** C-1 이 관측한 "전파 안 됨"의 원인이다.
|
||||
2. **IdP 쪽만 설정해도 소용없다.** 받을 엔드포인트와 `sid → 세션` 역인덱스가 앱에 있어야 한다.
|
||||
3. **도달성이 숨은 전제다.** 이 실험대는 닿지만, 앱이 사설망에 있으면 설정해도 조용히 실패한다.
|
||||
@@ -0,0 +1,15 @@
|
||||
=== 백업 전 상태 ===
|
||||
realms|clients|users|sessions|authclients = 2|15|2|3|1
|
||||
|
||||
=== pg_dump — 전체 덤프 ===
|
||||
시작: 14:59:30
|
||||
완료: 14:59:30
|
||||
크기: 394945 bytes (6956 줄)
|
||||
포함된 테이블 수: 101
|
||||
|
||||
=== 덤프에 세션이 들어 있는가 ===
|
||||
offline_user_session 언급: 13
|
||||
COPY public.offline_user_session (user_session_id, user_id, realm_id, created_on, offline_flag, data, last_session_refre
|
||||
E1q5xI7tt4U_WhZpW7rEPIF2 48b37d33-8419-49aa-9b5b-7731975be50c 7845f394-723a-4d07-b530-c7416b2e1d31 1788500836 0 {"ipAddr
|
||||
2ap3DyRiBF8OdMiqCodsJ0mp 48b37d33-8419-49aa-9b5b-7731975be50c 7845f394-723a-4d07-b530-c7416b2e1d31 1788501029 0 {"ipAddr
|
||||
Zsk4QcgXf_qgyMKzde5AG-Fz 48b37d33-8419-49aa-9b5b-7731975be50c 7845f394-723a-4d07-b530-c7416b2e1d31 1788501263 0 {"ipAddr
|
||||
@@ -0,0 +1,17 @@
|
||||
=== ★ 파괴 — 스키마를 통째로 지운다 ===
|
||||
시각: 14:59:47
|
||||
DROP SCHEMA
|
||||
CREATE SCHEMA
|
||||
남은 테이블: 0
|
||||
|
||||
=== 서비스 영향 ===
|
||||
https://auth.hyeonworks.com/realms/master HTTP 200
|
||||
https://app1.hyeonworks.com/ HTTP 200
|
||||
bff-555df79c97-6j86w 1/1 Running 0 49m
|
||||
bff-555df79c97-vgg6g 1/1 Running 0 49m
|
||||
keycloak-0 1/1 Running 0 4m15s
|
||||
keycloak-1 1/1 Running 0 4m38s
|
||||
|
||||
=== Keycloak 이 무엇을 말하는가 ===
|
||||
2026-09-04 05:58:02,598 WARN [org.keycloak.jgroups.protocol.KEYCLOAK_JDBC_PING2] (blocking-thread--p3-t2) Failed to fetch the cluster members from the database.: org.postgresql.ut
|
||||
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2904)
|
||||
@@ -0,0 +1,29 @@
|
||||
=== 무엇이 실제로 깨지는가 ===
|
||||
/.well-known/openid-configuration HTTP 500
|
||||
/protocol/openid-connect/certs HTTP 200
|
||||
토큰 발급 (DB 쓰기 필요) HTTP 400
|
||||
|
||||
=== ★ 복구 — 덤프에서 되돌린다 ===
|
||||
시작: 15:00:12
|
||||
완료: 15:00:13
|
||||
오류 줄: 0
|
||||
|
||||
=== 복구 후 데이터 ===
|
||||
realms|clients|users|sessions|authclients = 2|15|2|3|1
|
||||
=== 복구 직후 — 재시작 없이 되는가 ===
|
||||
+15초 well-known=200 토큰발급=200
|
||||
→ 재시작 없이 회복
|
||||
|
||||
=== 복구 전 세션이 살아났는가 ===
|
||||
user_session_id | realm
|
||||
--------------------------+-------------------
|
||||
E1q5xI7tt4U_WhZpW7rEPIF2 | master
|
||||
2ap3DyRiBF8OdMiqCodsJ0mp | master
|
||||
Zsk4QcgXf_qgyMKzde5AG-Fz | master
|
||||
vsDgCVo12-qX0CC63ZmYzbYF | keycloak-patterns
|
||||
(4 rows)
|
||||
|
||||
|
||||
=== 파드 재시작 횟수 ===
|
||||
keycloak-0 restarts=0
|
||||
keycloak-1 restarts=0
|
||||
@@ -0,0 +1,16 @@
|
||||
# D-1 — 백업·복구 리허설 증거
|
||||
|
||||
2026-09-04 16:55–17:05 KST
|
||||
해설: [`docs/experiment-d1-backup-restore.md`](../../experiment-d1-backup-restore.md)
|
||||
|
||||
| 파일 | 무엇을 보여주는가 |
|
||||
|---|---|
|
||||
| `01-backup.txt` | `pg_dump --clean --if-exists` — 395KB · 101 테이블 · **세션 데이터 포함** |
|
||||
| `02-destruction.txt` | `DROP SCHEMA public CASCADE` → 테이블 0개. **그런데 외부는 `HTTP 200`** — Keycloak 이 realm 캐시로 서빙한다 |
|
||||
| `03-restore.txt` | 깨지는 것과 안 깨지는 것(`certs` 200 / `well-known` 500 / 토큰 400) · **복구 1초 · 오류 0건 · 데이터 완전 일치 · 재시작 0회** |
|
||||
|
||||
## 핵심 세 줄
|
||||
|
||||
1. **데이터베이스를 통째로 비웠는데 서비스가 200 을 냈다.** 헬스체크는 "DB 가 살아 있다"만 보고 "데이터가 있다"는 안 본다.
|
||||
2. **복구는 1초, 오류 0건, 재시작 불필요.** 절차가 맞다는 것은 확인됐다.
|
||||
3. **RPO 는 두 겹이다** — 백업 주기 + A-3 에서 측정한 `synchronous_commit OFF` 손실. 그리고 이번 덤프는 호스트의 `/tmp` 에 있어 **같은 장애 도메인**이다.
|
||||
@@ -0,0 +1,9 @@
|
||||
=== D-1 의 교훈: 업그레이드 전에 백업한다 ===
|
||||
백업: 396333 bytes
|
||||
|
||||
=== 현재 버전과 스키마 상태 ===
|
||||
quay.io/keycloak/keycloak:26.7.0
|
||||
총 마이그레이션 수: 210
|
||||
|
||||
=== 로그인 상태 만들기 (업그레이드 후 살아남는지 볼 것) ===
|
||||
현재 세션: 4
|
||||
@@ -0,0 +1,17 @@
|
||||
=== ★ 롤백 시도: 26.7.0 → 26.0 ===
|
||||
시각: 15:02:20
|
||||
statefulset.apps/keycloak image updated
|
||||
+20초 keycloak-0:Running(1/1) keycloak-1:Running(0/1)
|
||||
+40초 keycloak-0:Running(1/1) keycloak-1:Running(0/1)
|
||||
+60초 keycloak-0:Running(1/1) keycloak-1:Running(0/1)
|
||||
+80초 keycloak-0:Running(1/1) keycloak-1:Error(0/1)
|
||||
+100초 keycloak-0:Running(1/1) keycloak-1:Running(0/1)
|
||||
+120초 keycloak-0:Running(1/1) keycloak-1:Error(0/1)
|
||||
+140초 keycloak-0:Running(1/1) keycloak-1:CrashLoopBackOff(0/1)
|
||||
+160초 keycloak-0:Running(1/1) keycloak-1:Running(0/1)
|
||||
|
||||
=== 새 파드가 무엇을 말하는가 ===
|
||||
2026-09-04 06:03:25,877 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: Failed to start server in (production) mode
|
||||
2026-09-04 06:03:25,877 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: liquibase.exception.ValidationFailedException: Validation Failed:
|
||||
2026-09-04 06:03:25,877 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: Validation Failed:
|
||||
2026-09-04 06:03:25,877 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) For more details run the same command passing the '--verbose' option. Also you can use '--help' to see the detai
|
||||
@@ -0,0 +1,20 @@
|
||||
=== 서비스는 살아 있는가 (StatefulSet 롤링이 막아줬다) ===
|
||||
https://auth.hyeonworks.com/realms/master HTTP 200
|
||||
Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
|
||||
ready 주소: [10.42.1.140]sed: -e expression #1, char 27: unknown option to 's'
|
||||
|
||||
=== Liquibase 오류 상세 ===
|
||||
2026-09-04 06:03:25,877 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: liquibase.exception.ValidationFailedException: Validation Failed:
|
||||
1 changesets check sum
|
||||
2026-09-04 06:03:25,877 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: Validation Failed:
|
||||
1 changesets check sum
|
||||
|
||||
=== ★ 앞으로 되돌린다 (26.7.0) ===
|
||||
statefulset.apps/keycloak image updated
|
||||
partitioned roll out complete: 2 new pods have been updated...
|
||||
keycloak-0 1/1 Running 0 10m
|
||||
keycloak-1 1/1 Running 0 28s
|
||||
|
||||
=== 데이터는 무사한가 ===
|
||||
realms|clients|migrations|sessions = 2|15|210|4
|
||||
외부 진입점 HTTP 200
|
||||
@@ -0,0 +1,16 @@
|
||||
# D-2 — 버전 업그레이드 증거
|
||||
|
||||
2026-09-04 17:05–17:15 KST
|
||||
해설: [`docs/experiment-d2-version-upgrade.md`](../../experiment-d2-version-upgrade.md)
|
||||
|
||||
| 파일 | 무엇을 보여주는가 |
|
||||
|---|---|
|
||||
| `01-pre-upgrade.txt` | 백업 396KB · 이미지 26.7.0 · **마이그레이션 210건** · 세션 4 |
|
||||
| `02-rollback-attempt.txt` | 26.0 으로 내리자 `Running(0/1) → Error → CrashLoopBackOff`. **`liquibase.exception.ValidationFailedException`** |
|
||||
| `03-roll-forward.txt` | **서비스는 `HTTP 200` 유지**(ready 주소 1개) · 오류 원인 `1 changesets check sum` · 26.7.0 복귀 후 마이그레이션 210·세션 4 그대로 |
|
||||
|
||||
## 핵심 세 줄
|
||||
|
||||
1. **롤백은 안 된다.** 체크섬이 안 맞아 Liquibase 가 기동 자체를 거부한다 — "모르는 변경"이 아니라 "아는 변경인데 정의가 다르다".
|
||||
2. **StatefulSet 이 사고를 절반에서 멈춰줬다.** 한 파드가 남아 외부 200 을 유지했다. replica 1 이었다면 전면 장애다.
|
||||
3. **실패한 기동은 스키마를 안 건드렸다.** 그래서 이미지만 되돌려도 복구됐다 — 이미 적용된 뒤였다면 DB 복구(D-1)가 필요하다.
|
||||
@@ -0,0 +1,17 @@
|
||||
=== 실험대의 Secret 목록 ===
|
||||
bff-secrets Opaque keys=1
|
||||
keycloak-lab-secrets Opaque keys=2
|
||||
oauth2-proxy-secrets Opaque keys=3
|
||||
|
||||
=== ★ base64 는 암호화가 아니다 — 한 줄로 읽힌다 ===
|
||||
keycloak-lab-secrets/POSTGRES_PASSWORD = lab-postgres-change-me
|
||||
keycloak-lab-secrets/KC_BOOTSTRAP_ADMIN_PASSWORD = lab-admin-change-me
|
||||
bff-secrets/KEYCLOAK_CLIENT_SECRET = bff-lab-secret
|
||||
oauth2-proxy-secrets/COOKIE_SECRET_A = lab-cookie-secret-aaaaaaaaaaaaaa
|
||||
|
||||
=== describe 는 값을 감춘다 (그래서 안전하다고 착각한다) ===
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
KEYCLOAK_CLIENT_SECRET: 14 bytes
|
||||
@@ -0,0 +1,23 @@
|
||||
=== k3s 의 데이터 저장소 ===
|
||||
Encryption Status: Disabled, no configuration file found
|
||||
|
||||
=== 저장 파일 ===
|
||||
total 23336
|
||||
drwx------ 2 root root 4096 Sep 2 09:12 .
|
||||
drwx------ 8 root root 4096 Sep 4 03:23 ..
|
||||
-rw-r--r-- 1 root root 13078528 Sep 4 06:05 state.db
|
||||
-rw-r--r-- 1 root root 32768 Sep 4 06:06 state.db-shm
|
||||
-rw-r--r-- 1 root root 10769712 Sep 4 06:06 state.db-wal
|
||||
|
||||
=== ★ 저장 파일에서 비밀번호가 그대로 보이는가 ===
|
||||
state.db 안의 평문 일치: 2
|
||||
=== 평문이 저장 파일에 있다는 것을 눈으로 ===
|
||||
client secret 평문 등장 횟수: 0
|
||||
|
||||
=== 누가 Secret 을 읽을 수 있는가 ===
|
||||
default SA: no
|
||||
(Role 이 없으면 네임스페이스에 별도 제한이 없다는 뜻)
|
||||
|
||||
=== 파드 안에서는 어떻게 보이는가 ===
|
||||
KEYCLOAK_CLIENT_SECRET=bff-lab-secret
|
||||
BFF_DB_PASSWORD=lab-postgres-change-me
|
||||
@@ -0,0 +1,15 @@
|
||||
# D-3 — 비밀 관리 증거
|
||||
|
||||
2026-09-04 17:15–17:25 KST
|
||||
해설: [`docs/experiment-d3-secret-management.md`](../../experiment-d3-secret-management.md)
|
||||
|
||||
| 파일 | 무엇을 보여주는가 |
|
||||
|---|---|
|
||||
| `01-base64-not-encryption.txt` | 실험대의 **모든 비밀이 명령 네 줄로** 평문 출력. `describe` 는 `14 bytes` 만 보여줘 착각을 준다 |
|
||||
| `02-at-rest.txt` | **`Encryption Status: Disabled`** · `state.db` 안에 비밀번호 평문 **2회 일치** · 파드 안에서는 `KEYCLOAK_CLIENT_SECRET=bff-lab-secret` 환경변수 · `default` SA 는 **읽을 수 없음** |
|
||||
|
||||
## 핵심 세 줄
|
||||
|
||||
1. **base64 는 감추려는 것이 아니라 YAML 에 바이트를 담기 위한 것이다.** `describe` 가 값을 가려 안전하다는 착각을 준다.
|
||||
2. **저장소 암호화가 꺼져 있고 노드 디스크에 평문이 있다.** 노드 디스크 하나가 전 클러스터의 비밀이다.
|
||||
3. **네 경로 중 RBAC 만 제 역할을 한다.** 그것이 실질적 방어선이며, 관리자에게는 아무 방어가 없다.
|
||||
@@ -0,0 +1,238 @@
|
||||
# C-2 — 로그아웃이 전 앱에 퍼지는가 (백채널 로그아웃)
|
||||
|
||||
브랜치 `feature/keycloak-c2-backchannel-logout` ·
|
||||
증거 [`docs/evidence/c2-backchannel-logout/`](evidence/c2-backchannel-logout/) ·
|
||||
2026-09-04 16:30–16:55 KST
|
||||
|
||||
선행: [`C-1`](experiment-c1-multi-app-sso.md) — **IdP 로그아웃이 앱에 전파되지 않는다**를 관측했다
|
||||
|
||||
---
|
||||
|
||||
## 0. 결론부터
|
||||
|
||||
| 확인 | 결과 |
|
||||
|---|---|
|
||||
| 백채널 로그아웃이 설정되어 있었는가 | **아니다.** 두 클라이언트 모두 `backchannelLogoutUrl` 없음 |
|
||||
| BFF 에 그 엔드포인트가 있는가 | **아니다.** 소스에 `oidcLogout` 설정이 없다 |
|
||||
| IdP 쪽만 설정하면 되는가 | **★ 안 된다.** 앱 세션이 그대로 남았다 |
|
||||
| Keycloak 이 앱 URL 에 닿기는 하는가 | **닿는다** (`HTTP 200`) — 네트워크 문제가 아니다 |
|
||||
|
||||
**C-1 이 관측한 "로그아웃이 안 퍼진다" 의 원인은 단순했다 —
|
||||
아무도 구현하지 않았다.**
|
||||
|
||||
---
|
||||
|
||||
## 1. 현재 상태 — 어느 쪽에도 없다
|
||||
|
||||
### IdP 쪽
|
||||
|
||||
```bash
|
||||
kcadm.sh get clients -r keycloak-patterns -q clientId=bff-confidential --fields attributes
|
||||
```
|
||||
|
||||
```
|
||||
frontchannelLogout : false
|
||||
(backchannel.logout.url 없음)
|
||||
```
|
||||
|
||||
`oauth2-proxy` 클라이언트도 마찬가지였다.
|
||||
|
||||
### 앱 쪽
|
||||
|
||||
```bash
|
||||
grep -rn "oidcLogout\|backchannel" bff/src/main/java/
|
||||
```
|
||||
|
||||
**아무것도 안 나온다.**
|
||||
|
||||
Spring Security 6.2+ 는 백채널 로그아웃을 지원하지만 **명시적으로 켜야 한다.**
|
||||
|
||||
```java
|
||||
.oidcLogout(oidc -> oidc.backChannel(Customizer.withDefaults()))
|
||||
```
|
||||
|
||||
이 설정이 없으면 `/logout/connect/back-channel/{registrationId}` 경로가
|
||||
**생기지 않는다.**
|
||||
|
||||
```
|
||||
/logout/connect/back-channel/keycloak HTTP 302 ← 로그인으로 리다이렉트
|
||||
/backchannel-logout HTTP 302
|
||||
/oauth2/sign_out HTTP 302
|
||||
```
|
||||
|
||||
**302 는 "그런 핸들러가 없어서 인증 요구로 떨어졌다"는 뜻**이다.
|
||||
엔드포인트가 있었다면 POST 를 받아 200 이나 400 을 돌려줬을 것이다.
|
||||
|
||||
---
|
||||
|
||||
## 2. IdP 쪽만 설정하고 시험했다
|
||||
|
||||
```bash
|
||||
kcadm.sh update clients/<id> -r keycloak-patterns \
|
||||
-s 'attributes={"backchannel.logout.url":"https://app1.hyeonworks.com/logout/connect/back-channel/keycloak",
|
||||
"backchannel.logout.session.required":"true"}'
|
||||
```
|
||||
|
||||
```
|
||||
backchannel.logout.session.required = true
|
||||
backchannel.logout.url = https://app1.hyeonworks.com/logout/connect/back-channel/keycloak
|
||||
```
|
||||
|
||||
### 살아 있는 세션에 로그아웃을 걸었다
|
||||
|
||||
```
|
||||
=== 로그아웃 전 ===
|
||||
keycloak-patterns 세션: 1
|
||||
Redis: 1 키
|
||||
|
||||
=== IdP 로그아웃 ===
|
||||
kcadm.sh create users/<id>/logout -r keycloak-patterns
|
||||
|
||||
=== 결과 ===
|
||||
keycloak-patterns 세션: 0 ← IdP 쪽은 끊겼다
|
||||
Redis: 1 키 ← ★ 앱 세션은 그대로다
|
||||
```
|
||||
|
||||
**IdP 세션만 사라지고 앱 세션은 남았다.** C-1 과 같은 결과다.
|
||||
|
||||
### 네트워크 문제가 아님을 확인했다
|
||||
|
||||
```
|
||||
=== Keycloak 파드가 app1.hyeonworks.com 에 닿는가 ===
|
||||
DNS 해석: Address: 100.83.212.4
|
||||
HTTPS 도달: HTTP 200
|
||||
```
|
||||
|
||||
**클러스터 안에서 공개 이름으로 앱에 닿는다.** 이 실험대는 tailnet + split DNS
|
||||
구성이라 헤어핀이 되는데, **운영에서는 안 되는 경우가 흔하다.**
|
||||
|
||||
> **백채널 로그아웃의 숨은 전제** — IdP 가 **앱의 공개 URL 로 서버에서 서버로**
|
||||
> 요청을 보낼 수 있어야 한다. 앱이 사설망에 있고 IdP 가 밖에 있으면
|
||||
> **설정을 해도 도달하지 못한다.** 그때는 로그도 안 남고 조용히 실패한다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 그래서 왜 안 퍼졌는가
|
||||
|
||||
```
|
||||
IdP 로그아웃
|
||||
├─ ① Keycloak 이 backchannel.logout.url 로 POST 를 보낸다 (설정함)
|
||||
├─ ② 앱이 그 POST 를 받는 엔드포인트를 갖고 있다 ★ 없다
|
||||
└─ ③ 앱이 logout token 을 검증하고 sid 로 세션을 찾아 지운다 ★ 없다
|
||||
```
|
||||
|
||||
**②와 ③이 없다.** ①만 설정해도 받을 사람이 없다.
|
||||
|
||||
Keycloak 로그에 `backchannel` 문자열이 **0줄**이었다 — 다만 이것만으로
|
||||
"보내지 않았다"고 단정할 수는 없다 (DEBUG 레벨일 수 있다).
|
||||
**확실한 것은 앱 세션이 남았다는 관측**이다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 개념 — 백채널 로그아웃의 구조
|
||||
|
||||
```
|
||||
사용자가 어느 앱에서든 로그아웃
|
||||
│
|
||||
▼
|
||||
Keycloak 이 SSO 세션에 붙은 client session 목록을 본다 (C-1 의 그 구조)
|
||||
│
|
||||
├──POST──▶ app1 의 backchannel.logout.url
|
||||
└──POST──▶ app2 의 backchannel.logout.url
|
||||
본문: logout_token (JWT)
|
||||
{ "sid": "...", "sub": "...", "events": {...} }
|
||||
```
|
||||
|
||||
### `sid` 가 여기서 쓰인다
|
||||
|
||||
**A-0 에서 확인한 그 `sid`** 다 — JWT·DB·관리 API 에서 같은 문자열이었던.
|
||||
|
||||
```
|
||||
logout_token 의 sid → 앱이 "그 sid 로 만든 내 세션"을 찾아 지운다
|
||||
```
|
||||
|
||||
**그래서 앱은 `sid → 자기 세션 ID` 역인덱스를 갖고 있어야 한다.**
|
||||
Spring Security 는 이를 위해 `OidcSessionRegistry` 를 쓰며,
|
||||
**여러 인스턴스가 있으면 그 레지스트리도 공유 저장소여야 한다** —
|
||||
B-1·B-2 에서 겪은 것과 **같은 문제가 한 겹 더 있다.**
|
||||
|
||||
### 부분 실패는 어떻게 되는가
|
||||
|
||||
```
|
||||
app1 로그아웃 성공, app2 는 응답 없음
|
||||
└─ Keycloak 은 재시도하는가? 얼마나?
|
||||
└─ 사용자는 app2 에서 여전히 로그인 상태다
|
||||
```
|
||||
|
||||
**로그아웃은 원자적이지 않다.** 앱이 늘어날수록 "일부만 로그아웃된 상태"가
|
||||
생길 확률이 올라간다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 겪은 문제
|
||||
|
||||
| 문제 | |
|
||||
|---|---|
|
||||
| `kcadm -s "attributes.backchannel.logout.url=..."` 이 exit 1 | 점 표기가 안 먹는다. **JSON 으로 통째로** 줘야 한다 |
|
||||
| 첫 시험이 무의미했다 | 로그아웃 전 IdP 세션이 **이미 0** 이었다. 끊을 대상이 없었다 |
|
||||
| 세션 수를 realm 없이 셌다 | C-1 과 같은 실수 — `master` 의 admin 세션이 섞인다 |
|
||||
| Keycloak 재시작 후 로그인 폼이 안 넘어갔다 | 인증 세션 쿠키가 무효화된 상태에서 폼을 재사용했다 |
|
||||
|
||||
**두 번째가 A층에서 반복한 교훈이다** — **주입 대상이 실제로 존재하는지
|
||||
먼저 확인한다.** 세션이 없는 상태에서 로그아웃을 걸고 "전파가 안 된다"고
|
||||
결론지을 뻔했다.
|
||||
|
||||
---
|
||||
|
||||
## 6. 구현하려면 무엇이 필요한가
|
||||
|
||||
| 계층 | 할 일 |
|
||||
|---|---|
|
||||
| **IdP** | 클라이언트마다 `backchannel.logout.url` 설정 (완료) |
|
||||
| **앱** | `.oidcLogout(oidc -> oidc.backChannel(...))` 활성화 |
|
||||
| **앱** | `OidcSessionRegistry` 를 **공유 저장소**로 (인스턴스가 여럿이므로) |
|
||||
| **네트워크** | IdP → 앱 공개 URL 도달 (이 실험대는 됨, 운영은 확인 필요) |
|
||||
| **oauth2-proxy** | **지원하지 않는다.** 별도 방안이 필요하다 |
|
||||
|
||||
**마지막이 C-1 과 맞물린다** — app1(BFF)은 구현할 수 있지만
|
||||
app2(oauth2-proxy)는 못 한다. **한 SSO 안에서 로그아웃 전파가 앱마다
|
||||
다르게 동작하게 된다.**
|
||||
|
||||
---
|
||||
|
||||
## 7. 재현 절차 (명령어)
|
||||
|
||||
```bash
|
||||
# 1. 현재 설정 확인 — 어느 쪽에도 없다
|
||||
kcadm.sh get clients -r keycloak-patterns -q clientId=bff-confidential --fields attributes
|
||||
grep -rn "oidcLogout\|backchannel" bff/src/main/java/
|
||||
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://app1.hyeonworks.com/logout/connect/back-channel/keycloak
|
||||
|
||||
# 2. IdP 쪽 설정 — 점 표기는 안 먹는다. JSON 으로
|
||||
kcadm.sh update clients/<id> -r keycloak-patterns \
|
||||
-s 'attributes={"backchannel.logout.url":"...","backchannel.logout.session.required":"true"}'
|
||||
|
||||
# 3. ★ 살아 있는 세션이 있는지 먼저 확인한다 (realm 을 join 해서)
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
|
||||
"select count(*) from offline_user_session us join realm r on r.id=us.realm_id
|
||||
where r.name='keycloak-patterns' and us.offline_flag='0'"
|
||||
|
||||
# 4. 로그아웃하고 앱 세션을 본다
|
||||
kcadm.sh create users/<user-id>/logout -r keycloak-patterns
|
||||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
|
||||
|
||||
# 5. 도달성 확인 — 클러스터 안에서 앱 공개 URL 로
|
||||
kubectl -n keycloak-lab run t --rm -i --restart=Never --image=curlimages/curl:8.11.1 \
|
||||
--command -- curl -s -o /dev/null -w '%{http_code}\n' https://app1.hyeonworks.com/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 다음에 남기는 것
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **구현** | `.oidcLogout()` 활성화 + `OidcSessionRegistry` 공유 |
|
||||
| **oauth2-proxy** | 백채널 로그아웃 미지원 — SSO 안에서 앱마다 동작이 갈린다 |
|
||||
| **운영** | IdP → 앱 도달성이 전제다. 안 되면 **조용히 실패한다** |
|
||||
| **B-2 와 연결** | 로그아웃이 지우는 것은 지금도 세 곳 중 하나뿐이다 |
|
||||
@@ -0,0 +1,246 @@
|
||||
# D-1 — 백업이 있다와 복구해봤다는 다르다
|
||||
|
||||
브랜치 `feature/keycloak-d1-backup-restore` ·
|
||||
증거 [`docs/evidence/d1-backup-restore/`](evidence/d1-backup-restore/) ·
|
||||
2026-09-04 16:55–17:05 KST
|
||||
|
||||
선행: [`A-2`](experiment-a2-database-loss.md) · [`A-3`](experiment-a3-database-crash.md)
|
||||
|
||||
---
|
||||
|
||||
## 0. 결론부터
|
||||
|
||||
| 측정 | 값 |
|
||||
|---|---|
|
||||
| 덤프 크기 / 시간 | **395KB · 1초 미만** (101개 테이블) |
|
||||
| 복구 시간 | **1초** (`15:00:12 → 15:00:13`), **오류 0건** |
|
||||
| 서비스 회복 | **재시작 없이 15초 이내** (`restarts=0`) |
|
||||
| 데이터 일치 | **완전 일치** — realms 2 / clients 15 / users 2 / sessions 3 / authclients 1 |
|
||||
| **RTO** | 약 **30초** (파괴 감지부터 서비스 복귀까지) |
|
||||
| **RPO** | **마지막 덤프 시점** + A-3 의 `synchronous_commit OFF` 손실 |
|
||||
|
||||
**그리고 예상 못 한 것 — 스키마를 통째로 지웠는데 서비스가 `200` 을 계속 냈다.**
|
||||
|
||||
---
|
||||
|
||||
## 1. 백업
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- pg_dump -U keycloak -d keycloak \
|
||||
--clean --if-exists > /tmp/keycloak-backup.sql
|
||||
```
|
||||
|
||||
```
|
||||
크기: 394945 bytes (6956 줄)
|
||||
CREATE TABLE: 101 개
|
||||
offline_user_session 언급: 13
|
||||
```
|
||||
|
||||
**세션도 덤프에 들어간다.**
|
||||
|
||||
```
|
||||
COPY public.offline_user_session (user_session_id, user_id, realm_id, created_on, offline_flag, data, ...)
|
||||
E1q5xI7tt4U_WhZpW7rEPIF2 48b37d33-... 7845f394-... 1788500836 0 {"ipAddr...
|
||||
```
|
||||
|
||||
| 옵션 | 뜻 |
|
||||
|---|---|
|
||||
| `--clean` | 복구 시 기존 객체를 **DROP 하고** 다시 만든다 |
|
||||
| `--if-exists` | 없는 객체를 DROP 할 때 오류를 내지 않는다 |
|
||||
|
||||
**두 옵션이 없으면 "이미 존재한다" 오류가 쏟아진다.**
|
||||
|
||||
---
|
||||
|
||||
## 2. 파괴
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
|
||||
-c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
|
||||
```
|
||||
|
||||
```
|
||||
DROP SCHEMA
|
||||
CREATE SCHEMA
|
||||
남은 테이블: 0
|
||||
```
|
||||
|
||||
### ★ 그런데 서비스가 살아 있었다
|
||||
|
||||
```
|
||||
https://auth.hyeonworks.com/realms/master HTTP 200
|
||||
https://app1.hyeonworks.com/ HTTP 200
|
||||
keycloak-0 / keycloak-1 1/1 Running
|
||||
```
|
||||
|
||||
**데이터베이스가 통째로 비었는데 `200` 이다.**
|
||||
|
||||
Keycloak 이 realm 정보를 **Infinispan `realms` 캐시**에서 서빙하기 때문이다
|
||||
(A-0 에서 그 캐시에 57개 엔트리가 있는 것을 봤다).
|
||||
|
||||
### 무엇이 깨지고 무엇이 안 깨지는가
|
||||
|
||||
```
|
||||
/protocol/openid-connect/certs HTTP 200 ← realm 키는 캐시에 있다
|
||||
/.well-known/openid-configuration HTTP 500 ← 이건 DB 를 본다
|
||||
토큰 발급 HTTP 400
|
||||
```
|
||||
|
||||
**부분적으로만 깨진다.** 헬스체크는 통과하고, 일부 엔드포인트는 정상이며,
|
||||
**로그인만 안 된다.**
|
||||
|
||||
```
|
||||
KEYCLOAK_JDBC_PING2: Failed to fetch the cluster members from the database
|
||||
```
|
||||
|
||||
> **A-2(DB 프로세스 정지)와 다른 모양이다.** 거기서는 커넥션이 아예 안 돼
|
||||
> readiness 가 DOWN 이 되고 전 파드가 Service 에서 빠졌다.
|
||||
> **여기서는 커넥션은 되고 테이블만 없다** — 헬스체크가 통과해버린다.
|
||||
>
|
||||
> **"DB 가 살아 있다"와 "데이터가 있다"는 다르다.** 헬스체크는 앞의 것만 본다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 복구
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab exec -i deploy/postgres -- psql -U keycloak -d keycloak \
|
||||
< /tmp/keycloak-backup.sql
|
||||
```
|
||||
|
||||
```
|
||||
시작: 15:00:12
|
||||
완료: 15:00:13
|
||||
오류 줄: 0
|
||||
```
|
||||
|
||||
**1초, 오류 없음.**
|
||||
|
||||
```
|
||||
복구 후: realms 2 | clients 15 | users 2 | sessions 3 | authclients 1
|
||||
백업 시: realms 2 | clients 15 | users 2 | sessions 3 | authclients 1
|
||||
```
|
||||
|
||||
**완전히 일치한다.**
|
||||
|
||||
### 서비스는 재시작 없이 돌아왔다
|
||||
|
||||
```
|
||||
+15초 well-known=200 토큰발급=200
|
||||
→ 재시작 없이 회복
|
||||
|
||||
keycloak-0 restarts=0
|
||||
keycloak-1 restarts=0
|
||||
```
|
||||
|
||||
**커넥션 풀이 이미 붙어 있었으므로 테이블이 돌아오자마자 동작했다.**
|
||||
A-2 에서 본 것과 같은 자가 회복이다.
|
||||
|
||||
### 세션도 살아났다
|
||||
|
||||
```
|
||||
user_session_id | realm
|
||||
--------------------------+-------------------
|
||||
E1q5xI7tt4U_WhZpW7rEPIF2 | master
|
||||
2ap3DyRiBF8OdMiqCodsJ0mp | master
|
||||
Zsk4QcgXf_qgyMKzde5AG-Fz | master
|
||||
vsDgCVo12-qX0CC63ZmYzbYF | keycloak-patterns
|
||||
```
|
||||
|
||||
**`persistent-user-sessions` 덕분에 세션이 백업 대상이 된다** (A-0).
|
||||
volatile 이었다면 세션은 애초에 DB 에 없으므로 **복구해도 전원 재로그인**이다.
|
||||
|
||||
---
|
||||
|
||||
## 4. RTO 와 RPO
|
||||
|
||||
```
|
||||
14:59:47 파괴
|
||||
15:00:12 복구 시작
|
||||
15:00:13 복구 완료
|
||||
~15:00:28 서비스 정상 확인
|
||||
|
||||
RTO ≈ 30초 (이 규모에서는 대부분이 사람의 판단 시간이다)
|
||||
```
|
||||
|
||||
### RPO 는 두 겹이다
|
||||
|
||||
```
|
||||
① 마지막 덤프 이후의 모든 변경 ← 백업 주기가 정한다
|
||||
② A-3 에서 측정한 synchronous_commit 손실 ← 수백 ms
|
||||
|
||||
실제 RPO = ① + ②
|
||||
```
|
||||
|
||||
**A-3 에서 "153건 중 4건 유실"을 측정한 것이 여기에 더해진다.**
|
||||
백업 주기만 보고 RPO 를 말하면 ②를 빠뜨린다.
|
||||
|
||||
### 이 실험대의 규모는 현실적이지 않다
|
||||
|
||||
| | 이 실험대 | 운영 |
|
||||
|---|---|---|
|
||||
| 덤프 크기 | 395KB | GB~TB |
|
||||
| 복구 시간 | 1초 | 분~시간 |
|
||||
| 세션 수 | 3 | 수만 |
|
||||
|
||||
**복구가 1초인 것은 데이터가 작기 때문**이며, **절차가 맞다는 것만 확인된다.**
|
||||
시간은 규모에 따라 완전히 달라진다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 이 실험이 검증한 것과 못 한 것
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| ✔ 덤프에 필요한 것이 다 들어간다 | realm·client·user·session·authorized client |
|
||||
| ✔ 복구 절차가 동작한다 | `--clean --if-exists` 로 오류 0 |
|
||||
| ✔ 서비스가 자가 회복한다 | 재시작 불필요 |
|
||||
| ✘ **노드가 죽은 경우** | A-4 에서 본 대로 **PVC 가 노드에 묶여 있다.** 노드가 안 돌아오면 덤프가 유일한 길인데, **덤프를 어디에 두느냐**가 문제가 된다 |
|
||||
| ✘ 대규모 복구 시간 | 데이터가 작아 측정 의미가 없다 |
|
||||
| ✘ 백업 자동화·보존·검증 | 이번엔 손으로 한 번 떴다 |
|
||||
|
||||
> **가장 중요한 미검증 항목이 "덤프를 어디에 두는가" 다.**
|
||||
> 이번 덤프는 `test-server:/tmp` 에 있다. **호스트가 죽으면 같이 사라진다.**
|
||||
> A-4 에서 PVC 가 노드에 묶인 것을 봤듯, **백업도 같은 장애 도메인에 있으면
|
||||
> 백업이 아니다.**
|
||||
|
||||
---
|
||||
|
||||
## 6. 재현 절차 (명령어)
|
||||
|
||||
```bash
|
||||
# 1. 백업 — --clean --if-exists 가 없으면 복구 때 오류가 쏟아진다
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- pg_dump -U keycloak -d keycloak \
|
||||
--clean --if-exists > keycloak-backup.sql
|
||||
|
||||
# 2. 무엇이 들어갔는지 확인 (세션이 있어야 한다)
|
||||
grep -c '^CREATE TABLE' keycloak-backup.sql
|
||||
grep -A3 'COPY public.offline_user_session' keycloak-backup.sql
|
||||
|
||||
# 3. 파괴
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
|
||||
-c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
|
||||
|
||||
# 4. ★ 무엇이 깨지는지 확인 — 전부 깨지지 않는다
|
||||
curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs
|
||||
curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/keycloak-patterns/.well-known/openid-configuration
|
||||
|
||||
# 5. 복구
|
||||
kubectl -n keycloak-lab exec -i deploy/postgres -- psql -U keycloak -d keycloak < keycloak-backup.sql
|
||||
|
||||
# 6. 데이터 대조 — 백업 시점의 수치와 같아야 한다
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
|
||||
"select (select count(*) from realm), (select count(*) from client),
|
||||
(select count(*) from user_entity),
|
||||
(select count(*) from offline_user_session where offline_flag='0')"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 다음 실험에 남기는 것
|
||||
|
||||
| 실험 | 이 실험이 준 것 |
|
||||
|---|---|
|
||||
| **D-2** 버전 업그레이드 | **백업이 전제다.** 스키마 마이그레이션은 되돌리기 어렵다 |
|
||||
| 운영 | **덤프를 다른 장애 도메인에 둔다** |
|
||||
| 관측 | **"DB 가 살아 있다"만 보는 헬스체크는 빈 DB 를 통과시킨다** |
|
||||
@@ -0,0 +1,213 @@
|
||||
# D-2 — 버전을 올리고 내릴 때 무엇이 일어나는가
|
||||
|
||||
브랜치 `feature/keycloak-d2-version-upgrade` ·
|
||||
증거 [`docs/evidence/d2-version-upgrade/`](evidence/d2-version-upgrade/) ·
|
||||
2026-09-04 17:05–17:15 KST
|
||||
|
||||
선행: [`D-1`](experiment-d1-backup-restore.md) — **백업이 전제다** ·
|
||||
[`A-8`](experiment-a8-rolling-restart.md) — 롤링 재시작이 안전하다는 것이 전제
|
||||
|
||||
---
|
||||
|
||||
## 0. 결론부터
|
||||
|
||||
| 확인 | 결과 |
|
||||
|---|---|
|
||||
| **롤백이 되는가** | **★ 안 된다.** `liquibase ValidationFailedException: 1 changesets check sum` |
|
||||
| 그때 서비스는 | **★ 살아 있다.** 한 파드가 남아 외부 `200` |
|
||||
| 앞으로 되돌리기 | **된다.** 정상 복구, 데이터 무사 |
|
||||
| 세션 | **유지** (4개 그대로) |
|
||||
|
||||
**"롤백 계획"을 세워두었다면 그 계획은 동작하지 않는다.**
|
||||
대신 **StatefulSet 의 롤링 업데이트가 사고를 절반에서 멈춰줬다.**
|
||||
|
||||
---
|
||||
|
||||
## 1. 전제 — 먼저 백업한다
|
||||
|
||||
D-1 에서 확인한 절차 그대로.
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- pg_dump -U keycloak -d keycloak \
|
||||
--clean --if-exists > /tmp/pre-upgrade.sql
|
||||
```
|
||||
|
||||
```
|
||||
백업: 396333 bytes
|
||||
현재 이미지: quay.io/keycloak/keycloak:26.7.0
|
||||
총 마이그레이션 수: 210
|
||||
현재 세션: 4
|
||||
```
|
||||
|
||||
### 개념 — `databasechangelog`
|
||||
|
||||
Keycloak 은 **Liquibase** 로 스키마를 관리한다. 적용한 변경 하나하나를
|
||||
`databasechangelog` 테이블에 기록한다.
|
||||
|
||||
| 컬럼 | 뜻 |
|
||||
|---|---|
|
||||
| `id` / `author` / `filename` | 변경을 식별 |
|
||||
| **`md5sum`** | **그 변경 정의의 체크섬** |
|
||||
| `orderexecuted` | 적용 순서 |
|
||||
|
||||
**210개가 쌓여 있다.** 이것이 "이 DB 는 어느 버전까지 올라갔는가"의 기록이다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 롤백을 시도했다 — 26.7.0 → 26.0
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab set image statefulset/keycloak keycloak=quay.io/keycloak/keycloak:26.0
|
||||
```
|
||||
|
||||
```
|
||||
+20초 keycloak-0:Running(1/1) keycloak-1:Running(0/1)
|
||||
+80초 keycloak-0:Running(1/1) keycloak-1:Error(0/1)
|
||||
+140초 keycloak-0:Running(1/1) keycloak-1:CrashLoopBackOff(0/1)
|
||||
```
|
||||
|
||||
```
|
||||
ERROR: Failed to start server in (production) mode
|
||||
ERROR: liquibase.exception.ValidationFailedException: Validation Failed:
|
||||
1 changesets check sum
|
||||
```
|
||||
|
||||
### 왜 실패하는가 — 체크섬 불일치
|
||||
|
||||
```
|
||||
26.7.0 이 적용한 변경 → databasechangelog 에 md5sum 기록
|
||||
26.0 이 기동하며 검증 → 자기가 아는 그 변경의 md5sum 과 비교
|
||||
└─ 다르다 → ValidationFailedException
|
||||
```
|
||||
|
||||
**"모르는 변경이 있다" 가 아니라 "아는 변경인데 정의가 다르다" 이다.**
|
||||
같은 changeset 이 버전 사이에 수정된 것이며, **더 엄격한 실패**다.
|
||||
|
||||
> **Liquibase 는 안전을 위해 기동 자체를 거부한다.**
|
||||
> 스키마를 반쯤 아는 상태로 서비스하느니 안 뜨는 쪽을 고른 설계다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 그런데 서비스는 살아 있었다
|
||||
|
||||
```
|
||||
https://auth.hyeonworks.com/realms/master HTTP 200
|
||||
ready 주소: [10.42.1.140] ← 한 파드만
|
||||
statefulset desired/ready/updated: 2 / 1 / 1
|
||||
```
|
||||
|
||||
**StatefulSet 의 롤링 업데이트가 한 번에 하나씩 바꾸기 때문**이다.
|
||||
|
||||
```
|
||||
keycloak-1 을 26.0 으로 → 기동 실패 → Ready 가 안 됨
|
||||
└─ StatefulSet 은 keycloak-0 을 건드리지 않는다
|
||||
└─ keycloak-0 (26.7.0) 이 계속 서비스한다
|
||||
```
|
||||
|
||||
**A-8 에서 "무중단은 replica ≥ 2 와 readiness 의 조합" 이라고 썼는데,
|
||||
여기서는 그 조합이 잘못된 배포를 절반에서 멈춰줬다.**
|
||||
|
||||
| replica 1 이었다면 | |
|
||||
|---|---|
|
||||
| 유일한 파드가 CrashLoopBackOff | **전면 장애** |
|
||||
| 되돌리려면 사람이 개입 | 그동안 계속 다운 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 앞으로 되돌리기
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab set image statefulset/keycloak keycloak=quay.io/keycloak/keycloak:26.7.0
|
||||
```
|
||||
|
||||
```
|
||||
partitioned roll out complete: 2 new pods have been updated...
|
||||
keycloak-0 1/1 Running
|
||||
keycloak-1 1/1 Running 28s
|
||||
|
||||
realms|clients|migrations|sessions = 2|15|210|4
|
||||
외부 진입점 HTTP 200
|
||||
```
|
||||
|
||||
**정상 복구.** 마이그레이션 수도 세션도 그대로다 — **실패한 기동은 스키마를
|
||||
건드리지 못했다.** Liquibase 가 검증 단계에서 멈췄기 때문이다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 그래서 업그레이드 계획은 어떻게 세워야 하는가
|
||||
|
||||
```
|
||||
✘ "문제가 생기면 이미지 태그를 되돌린다"
|
||||
└─ 스키마가 이미 바뀌었으면 옛 버전이 안 뜬다
|
||||
|
||||
✔ "문제가 생기면 백업에서 DB 를 되돌리고 이미지도 되돌린다"
|
||||
└─ D-1 에서 확인한 절차가 여기서 필요하다
|
||||
```
|
||||
|
||||
| 단계 | |
|
||||
|---|---|
|
||||
| 1 | **백업** (D-1) — 이것이 유일한 되돌리기 수단이다 |
|
||||
| 2 | 이미지 태그 변경 |
|
||||
| 3 | **첫 파드만 관찰** — StatefulSet 이 멈춰준다 |
|
||||
| 4 | 실패하면 **이미지를 되돌린다** (스키마가 안 바뀌었으면 이것으로 충분) |
|
||||
| 5 | 스키마가 이미 바뀌었으면 **DB 도 복구**해야 한다 |
|
||||
|
||||
**4와 5를 가르는 것이 "Liquibase 가 검증에서 멈췄는가, 이미 적용했는가" 다.**
|
||||
이번에는 검증에서 멈춰 4로 끝났다.
|
||||
|
||||
---
|
||||
|
||||
## 6. 이 실험이 확인한 것과 못 한 것
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| ✔ 롤백이 안 된다는 것 | 체크섬 불일치로 기동 거부 |
|
||||
| ✔ 실패가 안전하게 격리된다 | StatefulSet + readiness |
|
||||
| ✔ 실패한 기동은 스키마를 안 건드린다 | 마이그레이션 210 그대로 |
|
||||
| ✘ **정방향 업그레이드** | **26.7.0 보다 새 이미지가 없어 시험하지 못했다** |
|
||||
| ✘ 마이그레이션 중 장애 | 스키마 변경 도중 죽으면? |
|
||||
| ✘ 대규모 마이그레이션 시간 | 데이터가 작아 순식간이다 |
|
||||
|
||||
> **정방향을 시험하지 못한 것을 감춰서는 안 된다.**
|
||||
> 다만 **역방향이 더 위험한 방향**이고, 그것이 실패한다는 사실이
|
||||
> "롤백 계획" 을 무효로 만든다는 점에서 실무적으로 더 중요한 결과다.
|
||||
>
|
||||
> 새 버전이 나오면 같은 절차(백업 → 태그 변경 → 첫 파드 관찰)로 반복한다.
|
||||
|
||||
---
|
||||
|
||||
## 7. 재현 절차 (명령어)
|
||||
|
||||
```bash
|
||||
# 1. 백업 먼저 (D-1)
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- pg_dump -U keycloak -d keycloak \
|
||||
--clean --if-exists > pre-upgrade.sql
|
||||
|
||||
# 2. 현재 마이그레이션 수를 기록
|
||||
kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
|
||||
"select count(*) from databasechangelog"
|
||||
|
||||
# 3. 버전 변경
|
||||
kubectl -n keycloak-lab set image statefulset/keycloak keycloak=quay.io/keycloak/keycloak:<tag>
|
||||
|
||||
# 4. ★ 첫 파드만 본다. 실패하면 StatefulSet 이 멈춘다
|
||||
kubectl -n keycloak-lab get pods -w
|
||||
kubectl -n keycloak-lab logs keycloak-1 | grep -iE "liquibase|changeset|validation"
|
||||
|
||||
# 5. 서비스가 살아 있는지 (남은 파드가 받는다)
|
||||
kubectl -n keycloak-lab get endpoints keycloak -o jsonpath='{.subsets[*].addresses[*].ip}'
|
||||
|
||||
# 6. 되돌리기 — 스키마가 안 바뀌었으면 이미지만으로 충분
|
||||
kubectl -n keycloak-lab set image statefulset/keycloak keycloak=quay.io/keycloak/keycloak:26.7.0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 다음에 남기는 것
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **D-3** 비밀 관리 | 업그레이드 시 Secret 도 같이 검토된다 |
|
||||
| 운영 | **롤백 = 백업 복구**다. 태그만 되돌리는 계획은 반쪽이다 |
|
||||
| 운영 | **replica ≥ 2** 가 잘못된 배포를 절반에서 멈춘다 |
|
||||
| 미검증 | 정방향 업그레이드, 마이그레이션 중 장애, 대규모 소요 시간 |
|
||||
@@ -0,0 +1,219 @@
|
||||
# D-3 — Secret 은 정말 감춰지는가
|
||||
|
||||
브랜치 `feature/keycloak-d3-secret-management` ·
|
||||
증거 [`docs/evidence/d3-secret-management/`](evidence/d3-secret-management/) ·
|
||||
2026-09-04 17:15–17:25 KST
|
||||
|
||||
---
|
||||
|
||||
## 0. 결론부터
|
||||
|
||||
| 경로 | 감춰지는가 |
|
||||
|---|---|
|
||||
| `kubectl get secret -o jsonpath \| base64 -d` | **★ 한 줄로 읽힌다** |
|
||||
| `kubectl describe secret` | 값을 숨긴다 — **그래서 안전하다고 착각한다** |
|
||||
| **저장소(at rest)** | **★ 암호화 꺼져 있음.** 저장 파일에 평문이 있다 |
|
||||
| **파드 안** | **★ 평범한 환경변수다** |
|
||||
| RBAC 기본값 | **막는다** — `default` 서비스계정은 못 읽는다 |
|
||||
|
||||
**"Secret 이니까 안전하다" 는 네 가지 중 하나(RBAC)만 맞다.**
|
||||
|
||||
---
|
||||
|
||||
## 1. 한 줄로 읽힌다
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab get secret keycloak-lab-secrets \
|
||||
-o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d
|
||||
```
|
||||
|
||||
```
|
||||
keycloak-lab-secrets/POSTGRES_PASSWORD = lab-postgres-change-me
|
||||
keycloak-lab-secrets/KC_BOOTSTRAP_ADMIN_PASSWORD = lab-admin-change-me
|
||||
bff-secrets/KEYCLOAK_CLIENT_SECRET = bff-lab-secret
|
||||
oauth2-proxy-secrets/COOKIE_SECRET_A = lab-cookie-secret-aaaaaaaaaaaaaa
|
||||
```
|
||||
|
||||
**실험대의 모든 비밀이 명령 네 줄로 나온다.**
|
||||
|
||||
### `describe` 는 감춘다 — 그것이 함정이다
|
||||
|
||||
```
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
KEYCLOAK_CLIENT_SECRET: 14 bytes
|
||||
```
|
||||
|
||||
**바이트 수만 보여준다.** 이것만 보면 "가려져 있구나" 싶다.
|
||||
**`get -o jsonpath` 한 번이면 값이 나온다.**
|
||||
|
||||
### 개념 — base64 는 인코딩이지 암호화가 아니다
|
||||
|
||||
| | 목적 | 되돌리기 |
|
||||
|---|---|---|
|
||||
| **인코딩** (base64) | 바이너리를 텍스트로 안전하게 옮기기 | **키 없이 누구나** |
|
||||
| 암호화 | 키 없이는 못 읽게 하기 | 키가 있어야 |
|
||||
|
||||
**Secret 이 base64 를 쓰는 이유는 감추려는 것이 아니라
|
||||
YAML 에 임의 바이트를 담기 위해서다.**
|
||||
|
||||
---
|
||||
|
||||
## 2. 저장소에는 평문으로 있다
|
||||
|
||||
```bash
|
||||
ssh kc-lab-1 'sudo k3s secrets-encrypt status'
|
||||
```
|
||||
|
||||
```
|
||||
Encryption Status: Disabled, no configuration file found
|
||||
```
|
||||
|
||||
**k3s 의 저장소 암호화가 꺼져 있다.** 기본값이다.
|
||||
|
||||
```
|
||||
/var/lib/rancher/k3s/server/db/state.db 13MB
|
||||
/var/lib/rancher/k3s/server/db/state.db-wal 10MB
|
||||
```
|
||||
|
||||
```bash
|
||||
ssh kc-lab-1 'sudo grep -c "lab-postgres-change-me" /var/lib/rancher/k3s/server/db/state.db'
|
||||
```
|
||||
|
||||
```
|
||||
state.db 안의 평문 일치: 2
|
||||
```
|
||||
|
||||
**저장 파일 안에 비밀번호가 그대로 있다.**
|
||||
|
||||
| 그래서 무엇이 위험한가 | |
|
||||
|---|---|
|
||||
| 노드 디스크를 얻으면 | **전 클러스터의 비밀** |
|
||||
| 노드 백업/스냅샷 | 같은 것을 복사한다 |
|
||||
| A-4 에서 본 `local-path` PVC | **같은 디스크에 있다** |
|
||||
|
||||
> **D-1 에서 "덤프를 같은 장애 도메인에 두면 백업이 아니다" 라고 썼는데,
|
||||
> 여기서는 "노드 디스크 하나가 모든 비밀" 이다.**
|
||||
> 백업을 잘 챙겨도 그 백업 안에 비밀이 평문으로 들어간다.
|
||||
|
||||
**k3s 는 `--secrets-encryption` 플래그로 켤 수 있다.** 지금은 안 켜져 있다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 파드 안에서는 환경변수다
|
||||
|
||||
```bash
|
||||
kubectl -n keycloak-lab exec <bff-pod> -- sh -c 'env | grep -iE "secret|password"'
|
||||
```
|
||||
|
||||
```
|
||||
KEYCLOAK_CLIENT_SECRET=bff-lab-secret
|
||||
BFF_DB_PASSWORD=lab-postgres-change-me
|
||||
```
|
||||
|
||||
**`env` 한 번이면 나온다.**
|
||||
|
||||
| 새는 경로 | |
|
||||
|---|---|
|
||||
| `kubectl exec` 권한이 있는 사람 | 바로 본다 |
|
||||
| 같은 파드의 다른 프로세스 | `/proc/<pid>/environ` |
|
||||
| **크래시 덤프 · 오류 리포트** | 환경변수를 함께 담는 도구가 많다 |
|
||||
| 자식 프로세스 | 상속된다 |
|
||||
|
||||
**볼륨으로 마운트하면 이 중 몇 가지가 줄어든다** — 파일 권한으로 제한할 수
|
||||
있고 환경변수 덤프에 안 들어간다.
|
||||
|
||||
```yaml
|
||||
volumeMounts:
|
||||
- name: secrets
|
||||
mountPath: /etc/secrets
|
||||
readOnly: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. RBAC 은 실제로 막는다
|
||||
|
||||
```bash
|
||||
kubectl auth can-i get secrets -n keycloak-lab \
|
||||
--as=system:serviceaccount:keycloak-lab:default
|
||||
```
|
||||
|
||||
```
|
||||
default SA: no
|
||||
```
|
||||
|
||||
**기본 서비스계정은 Secret 을 못 읽는다.** 쿠버네티스의 기본값이 제한적이다.
|
||||
|
||||
> **네 가지 중 유일하게 제 역할을 하는 것이 RBAC 다.**
|
||||
> 그러므로 "누가 `get secrets` 를 할 수 있는가" 가 실질적인 방어선이며,
|
||||
> **관리자 권한을 가진 사람에게는 아무 방어가 없다.**
|
||||
|
||||
A-0 의 관측 스택에서 `nodes/proxy` 서브리소스를 따로 줘야 했던 것처럼,
|
||||
**Secret 접근도 리소스 단위로 나눌 수 있다.**
|
||||
|
||||
---
|
||||
|
||||
## 5. 그래서 무엇을 해야 하는가
|
||||
|
||||
```
|
||||
지금: 매니페스트에 stringData 평문 → git 에 커밋되면 끝
|
||||
k3s 저장소 암호화 꺼짐
|
||||
파드 환경변수
|
||||
```
|
||||
|
||||
| 단계 | 얻는 것 |
|
||||
|---|---|
|
||||
| ① 매니페스트에서 값을 빼고 **`.example` 만 커밋** | git 유출을 막는다 |
|
||||
| ② **k3s `--secrets-encryption`** 활성화 | 노드 디스크 유출을 막는다 |
|
||||
| ③ 환경변수 대신 **볼륨 마운트** | 프로세스·덤프 유출을 줄인다 |
|
||||
| ④ **SealedSecret / 외부 KMS** | 매니페스트에 암호문만 남는다 |
|
||||
| ⑤ **RBAC 최소화** | 유일하게 이미 동작하는 방어선을 좁힌다 |
|
||||
|
||||
**이 실험대는 ①~④ 중 아무것도 안 하고 있다.** 실험 목적으로는 의도적이지만,
|
||||
**그 사실을 기록해두지 않으면 그대로 운영에 옮겨간다.**
|
||||
|
||||
### 이 실험대의 비밀들은 이미 문서에 있다
|
||||
|
||||
`lab-postgres-change-me`, `bff-lab-secret` 같은 값이 **이 저장소의 매니페스트와
|
||||
문서에 그대로 적혀 있다.** 실험대 전용이며 외부에서 접근할 수 없는 값이지만,
|
||||
**"실험대니까 괜찮다" 가 습관이 되면 위험하다.** 이름에 `change-me` 를 넣은 것이
|
||||
그 최소한의 표시다.
|
||||
|
||||
---
|
||||
|
||||
## 6. 재현 절차 (명령어)
|
||||
|
||||
```bash
|
||||
# 1. 한 줄로 읽힌다
|
||||
kubectl -n keycloak-lab get secret keycloak-lab-secrets \
|
||||
-o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d
|
||||
|
||||
# 2. describe 는 감춘다 — 대조
|
||||
kubectl -n keycloak-lab describe secret bff-secrets
|
||||
|
||||
# 3. 저장소 암호화 여부
|
||||
ssh kc-lab-1 'sudo k3s secrets-encrypt status'
|
||||
|
||||
# 4. 저장 파일에 평문이 있는가
|
||||
ssh kc-lab-1 'sudo grep -c "lab-postgres-change-me" /var/lib/rancher/k3s/server/db/state.db'
|
||||
|
||||
# 5. 파드 안에서는 환경변수
|
||||
kubectl -n keycloak-lab exec <pod> -- sh -c 'env | grep -i secret'
|
||||
|
||||
# 6. 누가 읽을 수 있는가
|
||||
kubectl auth can-i get secrets -n keycloak-lab \
|
||||
--as=system:serviceaccount:keycloak-lab:default
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 다음에 남기는 것
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **D-4** 인증서 갱신 | 인증서 개인키도 같은 문제다 |
|
||||
| **B-6** 암호화 key | **key 를 Secret 에 두면 이 실험의 결론이 그대로 적용된다** |
|
||||
| 운영 | **RBAC 이 유일하게 동작하는 방어선이다** |
|
||||
Reference in New Issue
Block a user