Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 DongHyeonkaandClaude Opus 5
|
b5528fae87 | ||
|
DongHyeonkaandClaude Opus 5
|
4864d837f1 | ||
|
DongHyeonkaandClaude Opus 5
|
027c24ee27 | ||
|
DongHyeonkaandClaude Opus 5
|
df140ab218 |
@@ -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,38 @@
|
||||
=== 현재 인증서 (외부 관측, sudo 불필요) ===
|
||||
subject=CN = auth.hyeonworks.com
|
||||
issuer=C = US, O = Let's Encrypt, CN = YE2
|
||||
notBefore=Sep 3 00:47:23 2026 GMT
|
||||
notAfter=Dec 2 00:47:22 2026 GMT
|
||||
X509v3 Subject Alternative Name:
|
||||
DNS:app1.hyeonworks.com, DNS:app2.hyeonworks.com, DNS:auth.hyeonworks.com
|
||||
|
||||
→ 세 호스트가 같은 인증서를 쓴다 (SAN 3개, 와일드카드 아님)
|
||||
|
||||
=== 체인 완결성 (fullchain vs cert 실수 확인) ===
|
||||
0 s:CN = auth.hyeonworks.com
|
||||
1 s:C = US, O = Let's Encrypt, CN = YE2
|
||||
2 s:C = US, O = ISRG, CN = Root YE
|
||||
3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X2
|
||||
Verify return code: 0 (ok)
|
||||
|
||||
→ 중간 인증서가 함께 제공된다. fullchain.pem 이 올바로 설정되어 있다.
|
||||
|
||||
=== 갱신 자동화 ===
|
||||
NEXT LEFT LAST PASSED UNIT
|
||||
Fri 2026-09-04 17:03:46 KST 1h 54min Fri 2026-09-04 03:19:39 KST 11h ago certbot-renew.timer
|
||||
타이머 enabled: enabled
|
||||
타이머 active: active
|
||||
|
||||
=== 남은 기간 ===
|
||||
만료: Dec 2 00:47:22 2026 GMT
|
||||
남은 일수: 88일
|
||||
Let's Encrypt 90일 발급 · 30일 남으면 갱신 → 실제 갱신까지 약 58일
|
||||
|
||||
=== 강제 갱신은 하지 못했다 ===
|
||||
$ sudo -n -l
|
||||
sudo: a password is required
|
||||
$ sudo -n systemctl reload nginx
|
||||
sudo: a password is required
|
||||
|
||||
→ test-server 의 sudo 는 비밀번호를 요구한다 (게스트 kc-lab-1/2 는 무암호).
|
||||
certbot renew --force-renewal 도 nginx reload 도 실행할 수 없다.
|
||||
@@ -0,0 +1,14 @@
|
||||
# D-4 — 인증서 갱신 증거
|
||||
|
||||
2026-09-04 17:25–17:35 KST
|
||||
해설: [`docs/experiment-d4-certificate-renewal.md`](../../experiment-d4-certificate-renewal.md)
|
||||
|
||||
| 파일 | 무엇을 보여주는가 |
|
||||
|---|---|
|
||||
| `01-certificate-state.txt` | SAN 3개(와일드카드 아님) · **체인 4단계, `Verify return code: 0`** · `certbot-renew.timer` enabled·active, 11시간 전 실행 · 88일 남음 · **`sudo: a password is required` 로 강제 갱신 불가** |
|
||||
|
||||
## 핵심 세 줄
|
||||
|
||||
1. **인증서가 이름 3개만 담는다.** B-7 에서 oauth2-proxy 를 올릴 호스트가 없어 Grafana 의 `app2` 를 빌려야 했던 실제 비용이 여기서 나왔다.
|
||||
2. **체인이 완전하다** — 단계가 4개이므로 `fullchain.pem` 을 쓰고 있다. 1개면 `cert.pem` 실수이며 캐시 없는 클라이언트에서만 깨진다.
|
||||
3. **강제 갱신은 못 했다.** 호스트 sudo 가 비밀번호를 요구한다. 타이머가 active 라는 것은 "갱신이 된다"의 확인이 아니다.
|
||||
@@ -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 이 유일하게 동작하는 방어선이다** |
|
||||
@@ -0,0 +1,182 @@
|
||||
# D-4 — 인증서 갱신
|
||||
|
||||
브랜치 `feature/keycloak-d4-certificate-renewal` ·
|
||||
증거 [`docs/evidence/d4-certificate-renewal/`](evidence/d4-certificate-renewal/) ·
|
||||
2026-09-04 17:25–17:35 KST
|
||||
|
||||
---
|
||||
|
||||
## 0. 결론부터
|
||||
|
||||
| 확인 | 결과 |
|
||||
|---|---|
|
||||
| 인증서 구성 | **SAN 3개** (`auth`/`app1`/`app2`), 와일드카드 아님 |
|
||||
| 체인 완결성 | **정상.** `Verify return code: 0 (ok)`, 4단계 |
|
||||
| 갱신 자동화 | **동작 중.** `certbot-renew.timer` enabled·active, 11시간 전 실행됨 |
|
||||
| 남은 기간 | **88일** (갱신까지 약 58일) |
|
||||
| **강제 갱신 실측** | **★ 못 했다.** `sudo: a password is required` |
|
||||
|
||||
**측정한 것과 못 한 것을 나눠 적는다.** 못 한 것을 안 한 것처럼 쓰면
|
||||
이 기록 전체의 신뢰가 깎인다.
|
||||
|
||||
---
|
||||
|
||||
## 1. 인증서 구성 — B-7 에서 실제로 걸린 제약
|
||||
|
||||
```
|
||||
X509v3 Subject Alternative Name:
|
||||
DNS:app1.hyeonworks.com, DNS:app2.hyeonworks.com, DNS:auth.hyeonworks.com
|
||||
```
|
||||
|
||||
**세 이름뿐이고 와일드카드가 아니다.**
|
||||
|
||||
> **이 제약이 B-7 에서 실제 비용을 만들었다.**
|
||||
> oauth2-proxy 를 올릴 호스트명이 없어 **Grafana 가 쓰던 `app2` 를 빌려야 했고**,
|
||||
> 그 때문에 관측 스택의 웹 UI 가 실험 동안 내려가 있었다.
|
||||
>
|
||||
> **"인증서에 이름을 몇 개 넣을 것인가" 는 TLS 설정이 아니라
|
||||
> 나중에 무엇을 배포할 수 있는가를 정하는 결정이다.**
|
||||
|
||||
| | 이 실험대 | 와일드카드였다면 |
|
||||
|---|---|---|
|
||||
| 새 호스트 추가 | **인증서 재발급 필요** | 바로 가능 |
|
||||
| DNS-01 검증 | 필요 | 필요 (와일드카드는 DNS-01 만 가능) |
|
||||
| 노출 | 이름 3개만 | **하위 전체가 한 키에 묶인다** |
|
||||
|
||||
---
|
||||
|
||||
## 2. 체인이 완전한가 — 흔한 실수 확인
|
||||
|
||||
```
|
||||
0 s:CN = auth.hyeonworks.com ← 리프
|
||||
1 s:C = US, O = Let's Encrypt, CN = YE2 ← 중간
|
||||
2 s:C = US, O = ISRG, CN = Root YE
|
||||
3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X2
|
||||
Verify return code: 0 (ok)
|
||||
```
|
||||
|
||||
**중간 인증서가 함께 제공된다.**
|
||||
|
||||
### 개념 — `fullchain.pem` vs `cert.pem`
|
||||
|
||||
certbot 은 두 파일을 만든다.
|
||||
|
||||
| 파일 | 내용 | nginx 에 넣으면 |
|
||||
|---|---|---|
|
||||
| `cert.pem` | **리프만** | **일부 클라이언트에서 검증 실패** |
|
||||
| **`fullchain.pem`** | 리프 + 중간 | 정상 |
|
||||
|
||||
**브라우저는 중간 인증서를 캐시하고 있어 `cert.pem` 으로도 대개 동작한다.**
|
||||
그래서 실수해도 개발 중에는 안 드러나고, **캐시가 없는 클라이언트
|
||||
(모바일 앱, curl, 다른 서버)에서만 깨진다.**
|
||||
|
||||
```bash
|
||||
openssl s_client -connect <host>:443 -servername <host> | grep -E "^ *[0-9] s:"
|
||||
```
|
||||
|
||||
**단계가 2개 이상이면 fullchain 이고, 1개면 cert.pem 을 쓴 것이다.**
|
||||
이 실험대는 4단계로 정상이다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 갱신 자동화는 동작한다
|
||||
|
||||
```
|
||||
NEXT LEFT LAST PASSED
|
||||
Fri 2026-09-04 17:03:46 KST 1h 54min Fri 2026-09-04 03:19:39 KST 11h ago
|
||||
타이머 enabled: enabled / active: active
|
||||
```
|
||||
|
||||
**하루 두 번 돌고, 11시간 전에 실제로 실행됐다.**
|
||||
|
||||
```
|
||||
만료: Dec 2 00:47:22 2026 GMT
|
||||
남은 일수: 88일
|
||||
```
|
||||
|
||||
**아직 갱신하지 않은 것이 정상이다** — Let's Encrypt 는 90일 발급이고
|
||||
certbot 은 **30일 남았을 때** 갱신한다. 지금 실행돼도 아무것도 안 한다.
|
||||
|
||||
> **타이머가 돌았다는 것과 갱신이 됐다는 것은 다르다.**
|
||||
> "타이머가 active 니까 괜찮다" 는 확인이 아니다. **실제 갱신은 58일 뒤**이며,
|
||||
> 그때 처음으로 절차가 시험된다.
|
||||
|
||||
---
|
||||
|
||||
## 4. ★ 못 한 것 — 강제 갱신과 무중단 확인
|
||||
|
||||
계획서의 D-4 는 이렇게 적혀 있었다.
|
||||
|
||||
```bash
|
||||
sudo certbot renew --force-renewal
|
||||
```
|
||||
|
||||
**실행할 수 없었다.**
|
||||
|
||||
```
|
||||
$ sudo -n -l
|
||||
sudo: a password is required
|
||||
$ sudo -n systemctl reload nginx
|
||||
sudo: a password is required
|
||||
```
|
||||
|
||||
**test-server 의 sudo 는 비밀번호를 요구한다.** 게스트(kc-lab-1/2)는 무암호라
|
||||
A층에서 `conntrack`·`tc` 를 자유롭게 썼는데, **호스트는 다르다.**
|
||||
|
||||
> **이 사실은 B-7 에서 처음 드러났다** — nginx 설정을 읽으려던 시도가 계속
|
||||
> 빈 결과였고, 그게 **sudo 의 조용한 실패**였다. 여기서 다시 확인된다.
|
||||
|
||||
### 그래서 답하지 못한 것
|
||||
|
||||
| 계획서의 항목 | 상태 |
|
||||
|---|---|
|
||||
| nginx reload 타이밍에 무중단인가 | **미측정** |
|
||||
| 갱신 중 진행 중이던 요청은 | **미측정** |
|
||||
| `certbot-renew.timer` 가 실제 갱신을 하는가 | **미측정** (58일 뒤에야 알 수 있다) |
|
||||
|
||||
### 이론적으로는 무엇을 기대하는가
|
||||
|
||||
```
|
||||
certbot renew → 새 인증서 파일 저장
|
||||
└─ deploy-hook: nginx -s reload
|
||||
└─ nginx 는 새 워커를 띄우고 옛 워커는 진행 중 요청을 끝낸 뒤 종료
|
||||
→ graceful. 진행 중 요청은 옛 인증서로 완결된다
|
||||
```
|
||||
|
||||
**nginx 의 reload 는 설계상 무중단**이지만, **확인하지 않았으므로 그렇게
|
||||
쓰면 안 된다.** 이 실험대에서 반복해 배운 것이 바로 그것이다 —
|
||||
A-1 의 NetworkPolicy, A-3 의 `--grace-period=0`, B-5 의 AOF 모두
|
||||
**"그럴 것이다" 가 틀렸던 사례**다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 재현 절차 (명령어)
|
||||
|
||||
```bash
|
||||
# 1. 인증서 내용 — 밖에서 볼 수 있다
|
||||
echo | openssl s_client -connect auth.hyeonworks.com:443 -servername auth.hyeonworks.com 2>/dev/null \
|
||||
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
|
||||
|
||||
# 2. 체인 완결성 — 단계가 1개면 cert.pem 을 쓴 것이다
|
||||
echo | openssl s_client -connect auth.hyeonworks.com:443 -servername auth.hyeonworks.com 2>/dev/null \
|
||||
| grep -E "^ *[0-9] s:|Verify return code"
|
||||
|
||||
# 3. 갱신 자동화
|
||||
systemctl list-timers certbot-renew.timer --no-pager
|
||||
systemctl is-enabled certbot-renew.timer
|
||||
|
||||
# 4. 강제 갱신 (sudo 필요 — 이 실험대에서는 불가)
|
||||
sudo certbot renew --force-renewal
|
||||
# 갱신 중 다른 창에서:
|
||||
# while true; do curl -s -o /dev/null -w '%{http_code} ' https://auth.hyeonworks.com/realms/master; sleep 1; done
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 남긴 것
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **강제 갱신 + 무중단 측정** | sudo 권한이 필요하다 |
|
||||
| **SAN 확장** | 새 호스트를 쓰려면 재발급 — B-7 에서 실제로 걸렸다 |
|
||||
| **D-3 과 연결** | 인증서 **개인키**도 같은 비밀 관리 문제다 |
|
||||
@@ -0,0 +1,77 @@
|
||||
# 실험 색인 — 23개 전부
|
||||
|
||||
각 실험은 **자기 브랜치**에 있고, 해설 문서와 증거 폴더가 한 벌이다.
|
||||
|
||||
| # | 실험 | 브랜치 | 한 줄 결과 |
|
||||
|---|---|---|---|
|
||||
| **A-0** | 세션 복제 확인 | `...multinode-cluster-jdbc-ping` | 세션 공유는 Infinispan 이 아니라 **PostgreSQL** 이 한다 |
|
||||
| **A-1** | TCP 7800 차단 | `...a1-jgroups-transport-block` | 세션은 견디지만 **로그아웃 무효화가 7800 을 탄다** |
|
||||
| **A-2** | DB 정상 정지 | `...a2-database-loss` | 전면 장애. **그런데 `up` 은 1이었다** |
|
||||
| **A-3** | DB 강제 종료 | `...a3-database-crash` | **153건 중 4건의 로그인이 사라졌다** |
|
||||
| **A-4** | 노드 전원 차단 | `...a4-node-loss` | **죽은 파드가 산 파드보다 건강해 보인다** |
|
||||
| **A-5** | 비대칭 파티션 | `...a5-asymmetric-partition` | 단방향은 자가 치유. 완전 분단도 **한쪽은 산다** |
|
||||
| **A-6** | 지연 주입 | `...a6-latency-injection` | **200ms → 22초** (왕복 × 풀 큐잉) |
|
||||
| **A-7** | volatile 비교 | `...a7-volatile-comparison` | **세 결과가 정반대로 뒤집힌다** |
|
||||
| **A-8** | 롤링 재시작 | `...a8-rolling-restart` | 무중단 + 세션 생존 |
|
||||
| **B-0** | 자동구성 확인 | `...b0-bff-redis-deploy` | 조회 키에 **session id 가 없다** |
|
||||
| **B-1** | Redis 세션 | `...b1-redis-session-store` | 세션만 옮겨지고 **토큰은 남는다** |
|
||||
| **B-2** | 다중 인스턴스 | `...b2-multi-instance-session` | 공유는 되지만 **평문·덮어쓰기·로그아웃 미정리** |
|
||||
| **B-3** | refresh 경쟁 | `...b3-refresh-token-contention` | 경쟁이 아니라 **세션이 파괴된다** |
|
||||
| **B-4** | Edge 인가 | `...b4-edge-authorization-scope` | nginx 는 **설정하지 않은 헤더를 덮어쓰지 않는다** |
|
||||
| **B-5** | Redis 상실 | `...b5-redis-loss-persistence` | **파드가 Ready 인 채로 계속 실패한다** |
|
||||
| **B-6** | key 회전 | `...b6-key-rotation` | 회전은 안전, **옛 키를 버리는 순간이 위험** |
|
||||
| **B-7** | cookie secret | `...b7-cookie-secret-rotation` | **겹침 구간이 없고 세션이 고아로 남는다** |
|
||||
| **C-1** | 다중 앱 SSO | `...c1-multi-app-sso` | **IdP 세션을 죽여도 아무도 로그아웃되지 않는다** |
|
||||
| **C-2** | 백채널 로그아웃 | `...c2-backchannel-logout` | **받는 쪽을 아무도 구현하지 않았다** |
|
||||
| **D-1** | 백업·복구 | `...d1-backup-restore` | **빈 데이터베이스가 `200` 을 냈다** |
|
||||
| **D-2** | 버전 업그레이드 | `...d2-version-upgrade` | **이미지를 되돌려도 스키마는 안 돌아온다** |
|
||||
| **D-3** | 비밀 관리 | `...d3-secret-management` | **RBAC 만 실제로 감춘다** |
|
||||
| **D-4** | 인증서 갱신 | `...d4-certificate-renewal` | 구성은 정상. **강제 갱신은 못 했다** |
|
||||
|
||||
## 문서 지도
|
||||
|
||||
| 문서 | 용도 |
|
||||
|---|---|
|
||||
| [`session-lab-prerequisites.md`](session-lab-prerequisites.md) | **먼저 읽을 것** — 왜 이런 걸 재는지 |
|
||||
| [`experiment-plan.md`](experiment-plan.md) | 23개의 구조도·주입 방법·예측 |
|
||||
| [`open-questions-coverage.md`](open-questions-coverage.md) | 공개 열린 질문 4개 대조 |
|
||||
| [`session-lab-concepts.md`](session-lab-concepts.md) | 등장 개념 전체 (13층) |
|
||||
|
||||
## 반복해서 배운 것 — 주입이 안 걸린 사례
|
||||
|
||||
**아홉 번 있었다. 전부 "아무 일도 없었다" 로 보였다.**
|
||||
|
||||
| 실험 | 안 걸린 주입 | 원인 |
|
||||
|---|---|---|
|
||||
| A-1 | NetworkPolicy 로 7800 차단 | conntrack `ESTABLISHED` 가 먼저 통과시킨다 |
|
||||
| A-3 | `delete --grace-period=0 --force` | 컨테이너 런타임이 SIGTERM → 정상 종료 |
|
||||
| A-3 | `kill -9 1` | 컨테이너 안에서 **PID 1 은 SIGKILL 을 무시**한다 |
|
||||
| A-5 | `iptables -I FORWARD 1` | kube-router 가 자기 체인을 위로 재삽입 |
|
||||
| A-5 | raw 테이블, 반대 노드 | **연결 방향이 뒤집혀 있었다** |
|
||||
| A-6 | `tc ... dev eth0` | 인터페이스가 `enp1s0` 이다 |
|
||||
| A-6 | `enp1s0` 에 파드 IP 필터 | VXLAN 캡슐화로 **안 보인다** |
|
||||
| B-2 | `spring.sql.init` 스키마 | PostgreSQL 에 없는 `blob` 타입 + `continue-on-error` |
|
||||
| B-7·D-4 | `sudo nginx -T` 등 | **호스트 sudo 가 비밀번호를 요구**한다 |
|
||||
|
||||
**그래서 실험마다 "주입 성공 신호" 를 먼저 정하게 됐다** —
|
||||
`cluster_size` 하락, `not properly shut down` 로그, iptables 패킷 카운터,
|
||||
`tc -s qdisc` 의 `Sent`.
|
||||
|
||||
## 예측이 빗나간 곳
|
||||
|
||||
| 실험 | 예측 | 실제 |
|
||||
|---|---|---|
|
||||
| A-1 | 로그아웃 전파는 안 깨진다 | **깨졌다** — 무효화는 7800 을 탄다 |
|
||||
| A-2 | `up` 이 잡아줄 것 | **1로 평평했다** |
|
||||
| A-6 | 낙관적 락 충돌이 는다 | **0건** — 로그인은 새 행을 만든다 |
|
||||
| B-4 | nginx 가 동명 헤더를 덮어쓴다 | **둘 다 도착했다** |
|
||||
| B-6 | JWKS 캐시가 유예를 준다 | **즉시 401** |
|
||||
|
||||
## 말할 수 있는 것과 없는 것
|
||||
|
||||
**말할 수 있다** — Keycloak 멀티노드에서 세션과 토큰이 어디에 저장되고
|
||||
각 저장소가 죽으면 무엇이 어떻게 실패하는지 **재현하고 복구했다.**
|
||||
버전에 따라 결론이 뒤집힌다는 것을 **같은 주입으로 양쪽 다 측정했다.**
|
||||
|
||||
**말하면 안 된다** — "운영해봤다", "대규모 트래픽을 다뤄봤다".
|
||||
규모·시간·다른 사람·실제 사용자·비용은 이 실험대에 없다.
|
||||
Reference in New Issue
Block a user