docs: A-2 — losing the database takes every node down while up stays 1

Both pods go NotReady, the Service endpoint list empties and the front door returns 503, so adding Keycloak replicas buys nothing against database loss. The node holding the session in cache fails too, because a refresh writes LAST_SESSION_REFRESH. Recovery was automatic in about fifteen seconds with no restart, which is what readiness rather than liveness buys. The observability finding matters as much: up stayed at 1 through a total outage, so alerting on it would have caught nothing. kube-state-metrics is missing and pod readiness is therefore not recorded as a metric. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs: A-1 — sessions survive a JGroups partition but logout invalidation does not
2026-09-04 11:57:55 +09:00 · 2026-09-04 11:52:49 +09:00 · 2026-09-04 11:16:59 +09:00 · 2026-09-04 10:50:23 +09:00 · 2026-09-04 10:24:21 +09:00 · 2026-09-04 10:14:45 +09:00
120 changed files with 12616 additions and 734 deletions
@@ -10,8 +10,6 @@ POSTGRES_PASSWORD=change-me-postgres-password
 TOKEN_MEDIATING_CLIENT_SECRET=change-me-token-mediating-client-secret
 BFF_CLIENT_SECRET=change-me-bff-client-secret
 EDGE_PROXY_CLIENT_SECRET=change-me-edge-proxy-client-secret
 OAUTH2_PROXY_COOKIE_SECRET=generate-a-base64-encoded-32-byte-secret
 INTERNAL_AUTH_TOKEN=generate-a-long-random-edge-to-backend-token
 MOCK_GOOGLE_BROKER_CLIENT_SECRET=change-me-mock-google-broker-client-secret
 ADMIN_USER_PASSWORD=change-me-admin-user-password
 REGULAR_USER_PASSWORD=change-me-regular-user-password
@@ -4,10 +4,15 @@
 *.iml
 backend/target/
 **/node_modules/
 frontend/dist/
 build/
 e2e/node_modules/
 google-e2e/node_modules/
 frontend/node_modules/
 frontend/dist/
 bff/target
 token-mediator/target
 # lab cloud-init contains a console password; keep the filled copy local
 deploy/lab/cloud-init/kc-lab.yaml
 deploy/lab/cloud-init/kc-lab-*.yaml
@@ -0,0 +1,22 @@
 [    1289ms] [WARNING] <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> @ https://app2.hyeonworks.com/login:0
 [    1417ms] [VERBOSE] [DOM] Input elements should have autocomplete attributes (suggested: "username"): (More info: https://goo.gl/9p2vKq) %o @ https://app2.hyeonworks.com/login:0
 [    9024ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    9130ms] [WARNING] <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> @ https://app2.hyeonworks.com/:0
 [    9456ms] [WARNING] Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.
 Arguments: 
 [0] _isAMomentObject: true, _isUTC: false, _useUTC: false, _l: undefined, _i: Thu, 27 Aug 2026 13:03:49, _f: undefined, _strict: undefined, _locale: [object Object]
 Error
    at a.createFromInputFallback (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:3)
    at an (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:25647)
    at un (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:29355)
    at aa (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:29221)
    at on (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:28938)
    at sa (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:29715)
    at A (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:624:29748)
    at a (https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:621:89)
    at f (https://app2.hyeonworks.com/public/build/3719.c065b2e146c4c8347d51.js:1:4635)
    at u (https://app2.hyeonworks.com/public/build/322.177b4bb01c5d74f9b28f.js:2473:47448) @ https://app2.hyeonworks.com/public/build/6029.0549a3fcb50e73c4b256.js:620
 [    9605ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   10620ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   11527ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   13875ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
@@ -0,0 +1,7 @@
 [     144ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [     153ms] [WARNING] <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> @ https://app2.hyeonworks.com/explore:0
 [    1077ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    2101ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    2922ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    7323ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    9370ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
@@ -0,0 +1,8 @@
 [     271ms] [WARNING] <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> @ https://app2.hyeonworks.com/explore?schemaVersion=1&orgId=1&panes=%7B%22a%22%3A%7B%22datasource%22%3A%22PBFA97CFB590B2093%22%2C%22queries%22%3A%5B%7B%22refId%22%3A%22A%22%2C%22expr%22%3A%22vendor_statistics_approximate_entries_unique%7Bcache%3D%5C%22sessions%5C%22%7D%22%2C%22range%22%3Atrue%2C%22instant%22%3Afalse%2C%22editorMode%22%3A%22code%22%2C%22legendFormat%22%3A%22%7B%7Bpod%7D%7D%20on%20%7B%7Bnode%7D%7D%22%2C%22datasource%22%3A%7B%22type%22%3A%22prometheus%22%2C%22uid%22%3A%22PBFA97CFB590B2093%22%7D%7D%5D%2C%22range%22%3A%7B%22from%22%3A%22now-15m%22%2C%22to%22%3A%22now%22%7D%7D%7D:0
 [     346ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    1512ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    2433ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    6941ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   13188ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   21578ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   25998ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
@@ -0,0 +1,7 @@
 [     766ms] [WARNING] An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. @ https://auth.hyeonworks.com/realms/master/protocol/openid-connect/3p-cookies/step1.html:0
 [     781ms] [WARNING] An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. @ https://auth.hyeonworks.com/realms/master/protocol/openid-connect/3p-cookies/step2.html:0
 [   17929ms] [WARNING] An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. @ https://auth.hyeonworks.com/realms/master/protocol/openid-connect/3p-cookies/step1.html:0
 [   17949ms] [WARNING] An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. @ https://auth.hyeonworks.com/realms/master/protocol/openid-connect/3p-cookies/step2.html:0
 [   17981ms] [WARNING] An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. @ https://auth.hyeonworks.com/realms/master/protocol/openid-connect/login-status-iframe.html:0
 [   18447ms] [WARNING] For accessibility reasons an aria-label should be specified on nav groups if a title isn't @ https://auth.hyeonworks.com/resources/9v5yc/admin/keycloak.v2/assets/main-BbID33M6.js:7
 [   18462ms] [WARNING] For accessibility reasons an aria-label should be specified on nav groups if a title isn't @ https://auth.hyeonworks.com/resources/9v5yc/admin/keycloak.v2/assets/main-BbID33M6.js:7
@@ -0,0 +1,2 @@
 [      75ms] [ERROR] Failed to load resource: the server responded with a status of 404 (Not Found) @ https://hyeonworks.com/questions:0
 [     100ms] [ERROR] Failed to load resource: the server responded with a status of 404 (Not Found) @ https://hyeonworks.com/favicon.ico:0
@@ -0,0 +1 @@
 [     149ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1 @@
 [     103ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1 @@
 [      95ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1 @@
 [     132ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1 @@
 [     239ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1 @@
 [     105ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1 @@
 [     108ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0
@@ -0,0 +1,41 @@
 [     344ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [     869ms] [WARNING] <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> @ https://app2.hyeonworks.com/explore?schemaVersion=1&panes=%7B%22cf1%22%3A%7B%22datasource%22%3A%22PBFA97CFB590B2093%22%2C%22queries%22%3A%5B%7B%22refId%22%3A%22A%22%2C%22expr%22%3A%22vendor_cluster_size%22%2C%22range%22%3Atrue%2C%22instant%22%3Afalse%2C%22editorMode%22%3A%22code%22%2C%22legendFormat%22%3A%22%7B%7Bpod%7D%7D+on+%7B%7Bnode%7D%7D%22%2C%22datasource%22%3A%7B%22type%22%3A%22prometheus%22%2C%22uid%22%3A%22PBFA97CFB590B2093%22%7D%7D%5D%2C%22range%22%3A%7B%22from%22%3A%22now-45m%22%2C%22to%22%3A%22now%22%7D%7D%7D&orgId=1:0
 [    1014ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    2039ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    4085ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    7289ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   15556ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   26818ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   32659ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   35930ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   53849ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   61722ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   79450ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   84571ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   87233ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   92665ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  113244ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  119181ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  137390ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  157071ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  166091ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  182011ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  188613ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  206228ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  218561ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  229607ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  235818ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  237158ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  252095ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  261118ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  273809ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  280227ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  292650ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  306477ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  309957ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  311984ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  325683ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  344586ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  357576ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  359294ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [  364740ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
@@ -0,0 +1,16 @@
 [     615ms] [WARNING] <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> @ https://app2.hyeonworks.com/explore?schemaVersion=1&panes=%7B%22te0%22%3A%7B%22datasource%22%3A%22PBFA97CFB590B2093%22%2C%22queries%22%3A%5B%7B%22refId%22%3A%22A%22%2C%22expr%22%3A%22up%7Bjob%3D%5C%22keycloak%5C%22%7D%22%2C%22range%22%3Atrue%2C%22instant%22%3Afalse%2C%22editorMode%22%3A%22code%22%2C%22legendFormat%22%3A%22up+%E2%80%94+%7B%7Bpod%7D%7D%22%2C%22datasource%22%3A%7B%22type%22%3A%22prometheus%22%2C%22uid%22%3A%22PBFA97CFB590B2093%22%7D%7D%5D%2C%22range%22%3A%7B%22from%22%3A%22now-20m%22%2C%22to%22%3A%22now%22%7D%7D%7D&orgId=1:0
 [     929ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    2566ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    5541ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [    7990ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   12402ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   17640ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   20285ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   28277ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   34341ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   34985ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   50081ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   65649ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   75046ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   75890ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
 [   96067ms] [ERROR] WebSocket connection to 'wss://app2.hyeonworks.com/api/live/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 @ https://app2.hyeonworks.com/public/build/1518.a3f1f690c084a37f01c7.js:362
@@ -0,0 +1,2 @@
 - main [ref=e7]:
  - status "Loading" [ref=e10]
@@ -0,0 +1 @@
 - main [ref=f3e7]
@@ -0,0 +1,2 @@
 - main [ref=f6e7]:
  - status "Loading" [ref=f6e10]
@@ -0,0 +1,104 @@
 - generic [ref=f9e4]:
  - link "Skip to main content" [ref=f9e5] [cursor=pointer]:
    - /url: "#pageContent"
  - banner [ref=f9e7]:
    - generic [ref=f9e8]:
      - link [ref=f9e10] [cursor=pointer]:
        - /url: /
        - img "Grafana" [ref=f9e11]
      - generic [ref=f9e14]:
        - button "Search or jump to..." [ref=f9e18] [cursor=pointer]
        - generic [ref=f9e19]: ctrl+k
      - generic [ref=f9e23]:
        - button "New" [ref=f9e24] [cursor=pointer]
        - button "Help" [ref=f9e30] [cursor=pointer]
        - button "News" [ref=f9e33] [cursor=pointer]
        - button "Profile" [ref=f9e36] [cursor=pointer]:
          - img "User avatar" [ref=f9e37]
    - generic [ref=f9e38]:
      - button "Open menu" [ref=f9e40] [cursor=pointer]
      - navigation "Breadcrumbs" [ref=f9e43]:
        - list [ref=f9e44]:
          - listitem [ref=f9e45]:
            - link "Home" [ref=f9e46] [cursor=pointer]:
              - /url: /
          - listitem [ref=f9e50]:
            - link "Explore" [ref=f9e51] [cursor=pointer]:
              - /url: /explore
          - listitem [ref=f9e55]:
            - generic "Prometheus" [ref=f9e56]
      - generic [ref=f9e57]:
        - button "Show more items" [ref=f9e60] [cursor=pointer]
        - button "Toggle top search bar" [ref=f9e64] [cursor=pointer]
  - main [ref=f9e70]:
    - generic [ref=f9e72]:
      - heading "Explore" [level=1] [ref=f9e73]
      - generic [ref=f9e78]:
        - navigation "Explore toolbar" [ref=f9e80]:
          - navigation "Search links" [ref=f9e82]:
            - generic [ref=f9e83]:
              - button "Content outline" [expanded] [ref=f9e85] [cursor=pointer]:
                - generic [ref=f9e88]: Outline
              - generic [ref=f9e93] [cursor=pointer]:
                - img "Prometheus logo" [ref=f9e95]
                - textbox "Select a data source" [ref=f9e96]:
                  - /placeholder: ""
          - button "Show more items" [ref=f9e102] [cursor=pointer]
        - generic [ref=f9e106]:
          - generic [ref=f9e110]:
            - button "Collapse outline" [expanded] [ref=f9e112] [cursor=pointer]:
              - img "arrow-from-right" [ref=f9e113]
            - button "Queries" [ref=f9e116] [cursor=pointer]:
              - img "arrow" [ref=f9e117]
          - generic [ref=f9e124]:
            - generic [ref=f9e126]:
              - generic "Query editor row" [ref=f9e129]:
                - generic [ref=f9e130]:
                  - generic [ref=f9e132]:
                    - generic [ref=f9e133]:
                      - button "Collapse query row" [expanded] [ref=f9e134] [cursor=pointer]
                      - generic [ref=f9e137]:
                        - button "Query editor row title A" [ref=f9e138] [cursor=pointer]:
                          - generic [ref=f9e139]: A
                        - emphasis [ref=f9e140]: (Prometheus)
                    - generic [ref=f9e141]:
                      - button "Show data source help" [ref=f9e143] [cursor=pointer]
                      - button "Duplicate query" [ref=f9e147] [cursor=pointer]
                      - button "Hide response" [ref=f9e151] [cursor=pointer]
                      - button "Remove query" [ref=f9e155] [cursor=pointer]
                      - button "Drag and drop to reorder" [ref=f9e158]:
                        - img "Drag and drop to reorder" [ref=f9e159]
                  - generic [ref=f9e162]:
                    - generic [ref=f9e163]:
                      - button "Kick start your query" [ref=f9e164] [cursor=pointer]
                      - generic [ref=f9e167]:
                        - generic [ref=f9e168] [cursor=pointer]: Explain
                        - generic [ref=f9e169]:
                          - checkbox "Explain Toggle switch" [ref=f9e170]
                          - generic "Toggle switch" [ref=f9e171] [cursor=pointer]
                      - radiogroup [ref=f9e176]:
                        - generic [ref=f9e177]:
                          - radio "Builder" [ref=f9e178] [cursor=pointer]
                          - generic [ref=f9e179] [cursor=pointer]: Builder
                        - generic [ref=f9e180]:
                          - radio "Code" [checked] [ref=f9e181] [cursor=pointer]
                          - generic [ref=f9e182] [cursor=pointer]: Code
                    - generic [ref=f9e184]:
                      - generic [ref=f9e186]:
                        - button "Loading metrics..." [disabled] [ref=f9e187] [cursor=pointer]
                        - generic [ref=f9e190]: Loading editor
                      - 'button "Options Legend: {{pod}} on {{node}} Format: Time series Step: auto Type: Range Exemplars: false" [ref=f9e198] [cursor=pointer]':
                        - generic [ref=f9e202]:
                          - heading "Options" [level=6] [ref=f9e203]
                          - generic [ref=f9e204]:
                            - generic [ref=f9e205]: "Legend: {{pod}} on {{node}}"
                            - generic [ref=f9e206]: "Format: Time series"
                            - generic [ref=f9e207]: "Step: auto"
                            - generic [ref=f9e208]: "Type: Range"
                            - generic [ref=f9e209]: "Exemplars: false"
              - generic [ref=f9e210]:
                - button "Add query" [ref=f9e211] [cursor=pointer]
                - button "Query history" [ref=f9e215] [cursor=pointer]
                - button "Query inspector" [ref=f9e219] [cursor=pointer]
            - generic:
              - main
@@ -0,0 +1,4 @@
 - main [ref=f12e3]:
  - generic [ref=f12e4]:
    - progressbar "Contents" [ref=f12e5]
    - paragraph [ref=f12e8]: Loading the Administration Console
@@ -0,0 +1,4 @@
 - generic [active] [ref=f15e1]:
  - progressbar "Loading" [ref=f15e4]
  - generic:
    - list
@@ -0,0 +1 @@
 - generic [active] [ref=f18e1]: Not Found
@@ -0,0 +1,151 @@
 - generic [active] [ref=e1]:
  - generic [ref=e4]:
    - link "Skip to main content" [ref=e5] [cursor=pointer]:
      - /url: "#pageContent"
    - banner [ref=e7]:
      - generic [ref=e8]:
        - link [ref=e10] [cursor=pointer]:
          - /url: /
          - img "Grafana" [ref=e11]
        - generic [ref=e14]:
          - button "Search or jump to..." [ref=e18] [cursor=pointer]
          - generic [ref=e19]: ctrl+k
        - generic [ref=e23]:
          - button "New" [ref=e24] [cursor=pointer]
          - button "Help" [ref=e30] [cursor=pointer]
          - button "News" [ref=e33] [cursor=pointer]
          - button "Profile" [ref=e36] [cursor=pointer]:
            - img "User avatar" [ref=e37]
      - generic [ref=e38]:
        - button "Open menu" [ref=e40] [cursor=pointer]
        - navigation "Breadcrumbs" [ref=e43]:
          - list [ref=e44]:
            - listitem [ref=e45]:
              - link "Home" [ref=e46] [cursor=pointer]:
                - /url: /
            - listitem [ref=e50]:
              - link "Explore" [ref=e51] [cursor=pointer]:
                - /url: /explore
            - listitem [ref=e55]:
              - generic "Prometheus" [ref=e56]
        - generic [ref=e57]:
          - generic [ref=e60]:
            - button "Copy shortened URL" [ref=e61] [cursor=pointer]
            - button "Open copy link options" [ref=e64] [cursor=pointer]
          - button "Toggle top search bar" [ref=e68] [cursor=pointer]
    - main [ref=e74]:
      - generic [ref=e76]:
        - heading "Explore" [level=1] [ref=e77]
        - generic [ref=e82]:
          - navigation "Explore toolbar" [ref=e84]:
            - navigation "Search links" [ref=e86]:
              - generic [ref=e87]:
                - button "Content outline" [expanded] [ref=e89] [cursor=pointer]:
                  - generic [ref=e92]: Outline
                - generic [ref=e97] [cursor=pointer]:
                  - img "Prometheus logo" [ref=e99]
                  - textbox "Select a data source" [ref=e100]:
                    - /placeholder: ""
            - generic [ref=e104]:
              - button "Split the pane" [ref=e106] [cursor=pointer]:
                - generic [ref=e109]: Split
              - button "Add" [ref=e111] [cursor=pointer]
              - generic [ref=e116]:
                - 'button "Time range selected: Last 45 minutes" [ref=e117] [cursor=pointer]'
                - button "Zoom out time range" [ref=e122] [cursor=pointer]
              - generic [ref=e126]:
                - button "Run query" [ref=e127] [cursor=pointer]
                - button "Auto refresh turned off. Choose refresh time interval" [ref=e131] [cursor=pointer]
          - generic [ref=e135]:
            - generic [ref=e139]:
              - button "Collapse outline" [expanded] [ref=e141] [cursor=pointer]:
                - img "arrow-from-right" [ref=e142]
              - button "Queries" [ref=e145] [cursor=pointer]:
                - img "arrow" [ref=e146]
              - button "Graph" [ref=e150] [cursor=pointer]:
                - img "graph-bar" [ref=e151]
            - generic [ref=e158]:
              - generic [ref=e160]:
                - generic "Query editor row" [ref=e163]:
                  - generic [ref=e164]:
                    - generic [ref=e166]:
                      - generic [ref=e167]:
                        - button "Collapse query row" [expanded] [ref=e168] [cursor=pointer]
                        - generic [ref=e171]:
                          - button "Query editor row title A" [ref=e172] [cursor=pointer]:
                            - generic [ref=e173]: A
                          - emphasis [ref=e174]: (Prometheus)
                      - generic [ref=e175]:
                        - button "Show data source help" [ref=e177] [cursor=pointer]
                        - button "Duplicate query" [ref=e181] [cursor=pointer]
                        - button "Hide response" [ref=e185] [cursor=pointer]
                        - button "Remove query" [ref=e189] [cursor=pointer]
                        - button "Drag and drop to reorder" [ref=e192]:
                          - img "Drag and drop to reorder" [ref=e193]
                    - generic [ref=e196]:
                      - generic [ref=e197]:
                        - button "Kick start your query" [ref=e198] [cursor=pointer]
                        - generic [ref=e201]:
                          - generic [ref=e202] [cursor=pointer]: Explain
                          - generic [ref=e203]:
                            - checkbox "Explain Toggle switch" [ref=e204]
                            - generic "Toggle switch" [ref=e205] [cursor=pointer]
                        - radiogroup [ref=e210]:
                          - generic [ref=e211]:
                            - radio "Builder" [ref=e212] [cursor=pointer]
                            - generic [ref=e213] [cursor=pointer]: Builder
                          - generic [ref=e214]:
                            - radio "Code" [checked] [ref=e215] [cursor=pointer]
                            - generic [ref=e216] [cursor=pointer]: Code
                      - generic [ref=e218]:
                        - generic [ref=e220]:
                          - button "Metrics browser" [ref=e221] [cursor=pointer]
                          - code [ref=e228]:
                            - generic [ref=e229]:
                              - generic [ref=e234]: vendor_cluster_size
                              - textbox "Editor content;Press Alt+F1 for Accessibility Options." [ref=e239]: vendor_cluster_size
                        - 'button "Options Legend: {{pod}} on {{node}} Format: Time series Step: auto Type: Range Exemplars: false" [ref=e245] [cursor=pointer]':
                          - generic [ref=e249]:
                            - heading "Options" [level=6] [ref=e250]
                            - generic [ref=e251]:
                              - generic [ref=e252]: "Legend: {{pod}} on {{node}}"
                              - generic [ref=e253]: "Format: Time series"
                              - generic [ref=e254]: "Step: auto"
                              - generic [ref=e255]: "Type: Range"
                              - generic [ref=e256]: "Exemplars: false"
                - generic [ref=e257]:
                  - button "Add query" [ref=e258] [cursor=pointer]
                  - button "Query history" [ref=e262] [cursor=pointer]
                  - button "Query inspector" [ref=e266] [cursor=pointer]
              - main [ref=e270]:
                - region [ref=e272]:
                  - generic [ref=e273]:
                    - heading "Graph" [level=2] [ref=e275]
                    - radiogroup [ref=e278]:
                      - generic [ref=e279]:
                        - radio "Lines" [checked] [ref=e280] [cursor=pointer]
                        - generic [ref=e281] [cursor=pointer]: Lines
                      - generic [ref=e282]:
                        - radio "Bars" [ref=e283] [cursor=pointer]
                        - generic [ref=e284] [cursor=pointer]: Bars
                      - generic [ref=e285]:
                        - radio "Points" [ref=e286] [cursor=pointer]
                        - generic [ref=e287] [cursor=pointer]: Points
                      - generic [ref=e288]:
                        - radio "Stacked lines" [ref=e289] [cursor=pointer]
                        - generic [ref=e290] [cursor=pointer]: Stacked lines
                      - generic [ref=e291]:
                        - radio "Stacked bars" [ref=e292] [cursor=pointer]
                        - generic [ref=e293] [cursor=pointer]: Stacked bars
                  - list [ref=e302]:
                    - listitem [ref=e303]:
                      - button "keycloak-0 on kc-lab-2" [ref=e307] [cursor=pointer]
                    - listitem [ref=e308]:
                      - button "keycloak-0 on kc-lab-2" [ref=e312] [cursor=pointer]
                    - listitem [ref=e313]:
                      - button "keycloak-1 on kc-lab-1" [ref=e317] [cursor=pointer]
  - generic [ref=e322]:
    - alert
    - alert
    - complementary
    - complementary
@@ -0,0 +1,145 @@
 - generic [active] [ref=f3e1]:
  - generic [ref=f3e4]:
    - link "Skip to main content" [ref=f3e5] [cursor=pointer]:
      - /url: "#pageContent"
    - banner [ref=f3e7]:
      - generic [ref=f3e8]:
        - link [ref=f3e10] [cursor=pointer]:
          - /url: /
          - img "Grafana" [ref=f3e11]
        - generic [ref=f3e14]:
          - button "Search or jump to..." [ref=f3e18] [cursor=pointer]
          - generic [ref=f3e19]: ctrl+k
        - generic [ref=f3e23]:
          - button "New" [ref=f3e24] [cursor=pointer]
          - button "Help" [ref=f3e30] [cursor=pointer]
          - button "News" [ref=f3e33] [cursor=pointer]
          - button "Profile" [ref=f3e36] [cursor=pointer]:
            - img "User avatar" [ref=f3e37]
      - generic [ref=f3e38]:
        - button "Open menu" [ref=f3e40] [cursor=pointer]
        - navigation "Breadcrumbs" [ref=f3e43]:
          - list [ref=f3e44]:
            - listitem [ref=f3e45]:
              - link "Home" [ref=f3e46] [cursor=pointer]:
                - /url: /
            - listitem [ref=f3e50]:
              - link "Explore" [ref=f3e51] [cursor=pointer]:
                - /url: /explore
            - listitem [ref=f3e55]:
              - generic "Prometheus" [ref=f3e56]
        - generic [ref=f3e57]:
          - generic [ref=f3e60]:
            - button "Copy shortened URL" [ref=f3e61] [cursor=pointer]
            - button "Open copy link options" [ref=f3e64] [cursor=pointer]
          - button "Toggle top search bar" [ref=f3e68] [cursor=pointer]
    - main [ref=f3e74]:
      - generic [ref=f3e76]:
        - heading "Explore" [level=1] [ref=f3e77]
        - generic [ref=f3e82]:
          - navigation "Explore toolbar" [ref=f3e84]:
            - navigation "Search links" [ref=f3e86]:
              - generic [ref=f3e87]:
                - button "Content outline" [expanded] [ref=f3e89] [cursor=pointer]:
                  - generic [ref=f3e92]: Outline
                - generic [ref=f3e97] [cursor=pointer]:
                  - img "Prometheus logo" [ref=f3e99]
                  - textbox "Select a data source" [ref=f3e100]:
                    - /placeholder: ""
            - generic [ref=f3e104]:
              - button "Split the pane" [ref=f3e106] [cursor=pointer]:
                - generic [ref=f3e109]: Split
              - button "Add" [ref=f3e111] [cursor=pointer]
              - generic [ref=f3e116]:
                - 'button "Time range selected: Last 20 minutes" [ref=f3e117] [cursor=pointer]'
                - button "Zoom out time range" [ref=f3e122] [cursor=pointer]
              - generic [ref=f3e126]:
                - button "Run query" [ref=f3e127] [cursor=pointer]
                - button "Auto refresh turned off. Choose refresh time interval" [ref=f3e131] [cursor=pointer]
          - generic [ref=f3e135]:
            - generic [ref=f3e139]:
              - button "Collapse outline" [expanded] [ref=f3e141] [cursor=pointer]:
                - img "arrow-from-right" [ref=f3e142]
              - button "Queries" [ref=f3e145] [cursor=pointer]:
                - img "arrow" [ref=f3e146]
              - button "Graph" [ref=f3e150] [cursor=pointer]:
                - img "graph-bar" [ref=f3e151]
            - generic [ref=f3e158]:
              - generic [ref=f3e160]:
                - generic "Query editor row" [ref=f3e163]:
                  - generic [ref=f3e164]:
                    - generic [ref=f3e166]:
                      - generic [ref=f3e167]:
                        - button "Collapse query row" [expanded] [ref=f3e168] [cursor=pointer]
                        - generic [ref=f3e171]:
                          - button "Query editor row title A" [ref=f3e172] [cursor=pointer]:
                            - generic [ref=f3e173]: A
                          - emphasis [ref=f3e174]: (Prometheus)
                      - generic [ref=f3e175]:
                        - button "Show data source help" [ref=f3e177] [cursor=pointer]
                        - button "Duplicate query" [ref=f3e181] [cursor=pointer]
                        - button "Hide response" [ref=f3e185] [cursor=pointer]
                        - button "Remove query" [ref=f3e189] [cursor=pointer]
                        - button "Drag and drop to reorder" [ref=f3e192]:
                          - img "Drag and drop to reorder" [ref=f3e193]
                    - generic [ref=f3e196]:
                      - generic [ref=f3e197]:
                        - button "Kick start your query" [ref=f3e198] [cursor=pointer]
                        - generic [ref=f3e201]:
                          - generic [ref=f3e202] [cursor=pointer]: Explain
                          - generic [ref=f3e203]:
                            - checkbox "Explain Toggle switch" [ref=f3e204]
                            - generic "Toggle switch" [ref=f3e205] [cursor=pointer]
                        - radiogroup [ref=f3e210]:
                          - generic [ref=f3e211]:
                            - radio "Builder" [ref=f3e212] [cursor=pointer]
                            - generic [ref=f3e213] [cursor=pointer]: Builder
                          - generic [ref=f3e214]:
                            - radio "Code" [checked] [ref=f3e215] [cursor=pointer]
                            - generic [ref=f3e216] [cursor=pointer]: Code
                      - generic [ref=f3e218]:
                        - generic [ref=f3e220]:
                          - button "Loading metrics..." [disabled] [ref=f3e221] [cursor=pointer]
                          - code [ref=f3e228]:
                            - generic [ref=f3e229]:
                              - generic [ref=f3e234]: "up{job=\"keycloak\"}"
                              - textbox "Editor content;Press Alt+F1 for Accessibility Options." [ref=f3e239]: "up{job=\"keycloak\"}"
                        - 'button "Options Legend: up — {{pod}} Format: Time series Step: auto Type: Range Exemplars: false" [ref=f3e245] [cursor=pointer]':
                          - generic [ref=f3e249]:
                            - heading "Options" [level=6] [ref=f3e250]
                            - generic [ref=f3e251]:
                              - generic [ref=f3e252]: "Legend: up — {{pod}}"
                              - generic [ref=f3e253]: "Format: Time series"
                              - generic [ref=f3e254]: "Step: auto"
                              - generic [ref=f3e255]: "Type: Range"
                              - generic [ref=f3e256]: "Exemplars: false"
                - generic [ref=f3e257]:
                  - button "Add query" [ref=f3e258] [cursor=pointer]
                  - button "Query history" [ref=f3e262] [cursor=pointer]
                  - button "Query inspector" [ref=f3e266] [cursor=pointer]
              - main [ref=f3e270]:
                - region [ref=f3e272]:
                  - generic [ref=f3e273]:
                    - heading "Graph" [level=2] [ref=f3e275]
                    - radiogroup [ref=f3e278]:
                      - generic [ref=f3e279]:
                        - radio "Lines" [checked] [ref=f3e280] [cursor=pointer]
                        - generic [ref=f3e281] [cursor=pointer]: Lines
                      - generic [ref=f3e282]:
                        - radio "Bars" [ref=f3e283] [cursor=pointer]
                        - generic [ref=f3e284] [cursor=pointer]: Bars
                      - generic [ref=f3e285]:
                        - radio "Points" [ref=f3e286] [cursor=pointer]
                        - generic [ref=f3e287] [cursor=pointer]: Points
                      - generic [ref=f3e288]:
                        - radio "Stacked lines" [ref=f3e289] [cursor=pointer]
                        - generic [ref=f3e290] [cursor=pointer]: Stacked lines
                      - generic [ref=f3e291]:
                        - radio "Stacked bars" [ref=f3e292] [cursor=pointer]
                        - generic [ref=f3e293] [cursor=pointer]: Stacked bars
                  - generic [ref=f3e294]: Loading plugin panel...
  - generic [ref=f3e299]:
    - alert
    - alert
    - complementary
    - complementary
@@ -15,6 +15,11 @@ Keycloak을 중심으로 네 가지 브라우저 인증 통합 패턴을 같은
 - AP3: Backend-for-Frontend (BFF)
 - AP4: Edge forward-auth
 세션 저장소·refresh token 경쟁·장애 복구는 네 패턴을 가로지르는 별도 축으로
 `develop-keycloak-session-store` 브랜치에서 진행합니다. 계획과 진행 상황은
 [`docs/session-store-lab-roadmap.md`](docs/session-store-lab-roadmap.md)에
 있습니다.
 현재 `develop`의 공통 baseline은 Keycloak, PostgreSQL, Spring Boot API,
 nginx를 Docker Compose로 실행하는 토대입니다. 패턴별 구현은 이 baseline
 위에서 별도 브랜치로 진행합니다.
@@ -103,22 +108,3 @@ Keycloak을 잠시 중지하고 export한 뒤 자동으로 다시 올립니다.
 runtime export에는 실제 client secret과 credential hash가 포함될 수 있어
 gitignored `build/keycloak-export/`에 권한 `0600`으로만 저장됩니다.
 ## AP4: oauth2-proxy Edge Forward Auth
 `develop-keycloak-pattern4`는 oauth2-proxy와 Nginx `auth_request`가
 인증을 edge에서 강제하는 패턴입니다.
 ```bash
 ./scripts/verify-pattern4.sh
 ```
 첫 feature에서는 oauth2-proxy를 `http://localhost:4180`에 직접 노출해
 OIDC redirect/PKCE/callback과 forwarded-user를 분리 확인합니다. 두 번째
 feature부터 `http://localhost:8088` Nginx가 단일 진입점이며, 내부
 `auth_request`는 브라우저 요청을 login 302로, API 요청을 JSON 401로
 구분합니다. 최종 feature에서는 backend와 oauth2-proxy의 호스트 노출을
 제거하고 Nginx 헤더 덮어쓰기와 내부 토큰 검증으로 spoofing을 막습니다.
 자세한 내용은
 [`docs/ap4-edge-forward-auth.md`](docs/ap4-edge-forward-auth.md)를
 참고하세요.
@@ -1,6 +1,8 @@
 package com.example.keycloakpattern;
 import java.util.Collections;
 import java.util.LinkedHashMap;
 import java.util.List;
 import java.util.Map;
 import org.springframework.security.core.annotation.AuthenticationPrincipal;
@@ -9,6 +11,8 @@ import org.springframework.web.bind.annotation.GetMapping;
 import org.springframework.web.bind.annotation.RequestMapping;
 import org.springframework.web.bind.annotation.RestController;
 import jakarta.servlet.http.HttpServletRequest;
@RestController
@RequestMapping("/api")
 public class ApiController {
@@ -18,6 +22,38 @@ public class ApiController {
        return Map.of("status", "ok", "service", "keycloak-pattern-api");
    }
    /**
     * Reflects what actually reached the application after the proxy chain.
     *
     * <p>The reverse proxy contract is defined in {@code docs/reverse-proxy-headers.md}
     * for a single nginx hop. The lab runs {@code nginx -> Traefik -> pod}, so this
     * endpoint exists to measure the two-hop result instead of assuming it.
     *
     * <p>{@code scheme}, {@code secure} and {@code requestUrl} are the values Keycloak
     * uses to build the {@code iss} claim and redirect URLs. If forwarded headers are
     * lost or rewritten, the mismatch shows up here first.
     */
    @GetMapping("/echo")
    public Map<String, Object> echo(HttpServletRequest request) {
        Map<String, List<String>> headers = new LinkedHashMap<>();
        for (String name : Collections.list(request.getHeaderNames())) {
            headers.put(name.toLowerCase(), Collections.list(request.getHeaders(name)));
        }
        Map<String, Object> response = new LinkedHashMap<>();
        response.put("headers", headers);
        response.put("remoteAddr", request.getRemoteAddr());
        // Pod IP. Identifies which replica answered, which is what makes the
        // host nginx upstream distribution and the sticky-session switch observable.
        response.put("localAddr", request.getLocalAddr());
        response.put("scheme", request.getScheme());
        response.put("secure", request.isSecure());
        response.put("serverName", request.getServerName());
        response.put("serverPort", request.getServerPort());
        response.put("requestUrl", request.getRequestURL().toString());
        return response;
    }
    @GetMapping("/me")
    public Map<String, Object> currentUser(@AuthenticationPrincipal Jwt jwt) {
        Map<String, Object> response = new LinkedHashMap<>();
@@ -1,59 +0,0 @@
 package com.example.keycloakpattern;
 import java.nio.charset.StandardCharsets;
 import java.security.MessageDigest;
 import java.util.LinkedHashMap;
 import java.util.Map;
 import jakarta.servlet.http.HttpServletRequest;
 import org.springframework.http.ResponseEntity;
 import org.springframework.beans.factory.annotation.Value;
 import org.springframework.web.bind.annotation.GetMapping;
 import org.springframework.web.bind.annotation.RestController;
@RestController
 public class EdgeIdentityController {
    private final byte[] internalAuthToken;
    EdgeIdentityController(@Value("${edge.internal-auth-token}") String internalAuthToken) {
        if (!hasText(internalAuthToken)) {
            throw new IllegalStateException("edge.internal-auth-token must be configured");
        }
        this.internalAuthToken = internalAuthToken.getBytes(StandardCharsets.UTF_8);
    }
    @GetMapping("/edge/me")
    ResponseEntity<Map<String, Object>> currentUser(HttpServletRequest request) {
        String authRequestUser = request.getHeader("X-Auth-Request-User");
        if (!hasText(authRequestUser) || !hasValidInternalToken(request)) {
            return ResponseEntity.status(401).body(Map.of(
                "error",
                "trusted edge authentication is required"
            ));
        }
        Map<String, Object> response = new LinkedHashMap<>();
        response.put("pattern", "AP4-edge-forward-auth");
        response.put("user", authRequestUser);
        response.put("email", request.getHeader("X-Auth-Request-Email"));
        response.put("identityHeader", "X-Auth-Request-User");
        return ResponseEntity.ok(response);
    }
    private boolean hasValidInternalToken(HttpServletRequest request) {
        String suppliedToken = request.getHeader("X-Internal-Auth-Token");
        if (!hasText(suppliedToken)) {
            return false;
        }
        return MessageDigest.isEqual(
            internalAuthToken,
            suppliedToken.getBytes(StandardCharsets.UTF_8)
        );
    }
    private static boolean hasText(String value) {
        return value != null && !value.isBlank();
    }
 }
@@ -17,12 +17,8 @@ public class SecurityConfig {
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(authorize -> authorize
-                .requestMatchers(
+                .requestMatchers("/actuator/health", "/actuator/health/**", "/api/public",
-                    "/actuator/health",
+                    "/api/echo")
                    "/actuator/health/**",
                    "/api/public",
                    "/edge/**"
                )
                .permitAll()
                .anyRequest()
                .authenticated())
@@ -1,12 +1,19 @@
 server:
  port: ${SERVER_PORT:8081}
-
+  # Spring ignores X-Forwarded-* unless this is set, so scheme/secure/requestUrl
-edge:
+  # report the raw connection by default. Keycloak has the same opt-in as
-  internal-auth-token: ${EDGE_INTERNAL_AUTH_TOKEN:}
+  # KC_PROXY_HEADERS. Flipping this to "native" is what the two-hop measurement
  # compares against.
  forward-headers-strategy: ${SERVER_FORWARD_HEADERS_STRATEGY:none}
 spring:
  application:
    name: keycloak-pattern-api
  jackson:
    serialization:
      # /api/echo is read by humans and captured as evidence screenshots, so the
      # response is indented rather than relying on a browser's JSON viewer.
      indent-output: true
  security:
    oauth2:
      resourceserver:
@@ -11,7 +11,7 @@ import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMock
 import org.springframework.boot.test.context.SpringBootTest;
 import org.springframework.test.web.servlet.MockMvc;
-@SpringBootTest(properties = "edge.internal-auth-token=test-internal-edge-token")
+@SpringBootTest
@AutoConfigureMockMvc
 class ApiSecurityTest {
@@ -25,6 +25,18 @@ class ApiSecurityTest {
            .andExpect(jsonPath("$.status").value("ok"));
    }
    @Test
    void echoEndpointReflectsForwardedHeadersWithoutAuthentication() throws Exception {
        mockMvc.perform(get("/api/echo")
                .header("X-Forwarded-Proto", "https")
                .header("X-Forwarded-Host", "app1.example.test"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.headers['x-forwarded-proto'][0]").value("https"))
            .andExpect(jsonPath("$.headers['x-forwarded-host'][0]").value("app1.example.test"))
            .andExpect(jsonPath("$.requestUrl").exists())
            .andExpect(jsonPath("$.remoteAddr").exists());
    }
    @Test
    void protectedEndpointRejectsAnonymousRequests() throws Exception {
        mockMvc.perform(get("/api/me"))
@@ -40,36 +52,4 @@ class ApiSecurityTest {
            .andExpect(jsonPath("$.subject").value("test-subject"))
            .andExpect(jsonPath("$.username").value("regular-user"));
    }
    @Test
    void edgeEndpointRejectsMissingTrustedHeaders() throws Exception {
        mockMvc.perform(get("/edge/me"))
            .andExpect(status().isUnauthorized());
    }
    @Test
    void edgeEndpointRejectsForgedIdentityWithoutInternalToken() throws Exception {
        mockMvc.perform(get("/edge/me")
                .header("X-Auth-Request-User", "spoofed-admin"))
            .andExpect(status().isUnauthorized());
    }
    @Test
    void edgeEndpointRejectsWrongInternalToken() throws Exception {
        mockMvc.perform(get("/edge/me")
                .header("X-Auth-Request-User", "spoofed-admin")
                .header("X-Internal-Auth-Token", "wrong-token"))
            .andExpect(status().isUnauthorized());
    }
    @Test
    void edgeEndpointAcceptsIdentityFromTrustedEdge() throws Exception {
        mockMvc.perform(get("/edge/me")
                .header("X-Auth-Request-User", "regular-user")
                .header("X-Auth-Request-Email", "regular-user@example.test")
                .header("X-Internal-Auth-Token", "test-internal-edge-token"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.user").value("regular-user"))
            .andExpect(jsonPath("$.identityHeader").value("X-Auth-Request-User"));
    }
 }
@@ -0,0 +1,136 @@
 # Session store lab
 세션 저장소·refresh token 경쟁·장애 복구를 검증하는 2노드 k3s 실험대.
 네 인증 패턴(AP1~AP4)을 가로지르는 공통층이므로 별도 축으로 관리한다.
 이 문서는 **절차**만 담는다.
 | 문서 | 내용 |
 |---|---|
 | [`docs/session-store-lab-roadmap.md`](../../docs/session-store-lab-roadmap.md) | 이 축의 계획과 진행 상황 |
 | [`docs/session-lab-concepts.md`](../../docs/session-lab-concepts.md) | 등장 개념 전체 |
 | [`docs/session-lab-operations.md`](../../docs/session-lab-operations.md) | 관측 도구 · 자주 쓰는 명령 · 훈련 |
 | [`docs/two-hop-proxy-header-contract.md`](../../docs/two-hop-proxy-header-contract.md) | 첫 실험 결과 |
 ## 토폴로지
 ```
  브라우저 / SSH  (tailnet)
        │  https://{auth,app1,app2}.hyeonworks.com → 100.83.212.4
        ▼
  lab host  ── nginx :443  TLS 종료 · X-Forwarded-* 주입
        │      nginx :80   301 → https
        │
        │  virbr0  192.168.122.0/24 (libvirt NAT)
        ├──▶ kc-lab-1  .11  k3s server  Traefik :80
        └──▶ kc-lab-2  .12  k3s agent   Traefik :80
                            └──▶ Pod
 ```
 `nginx → Traefik` **2홉**이 운영 구조와 같다는 점이 이 배치의 핵심이다.
 L7 프록시가 두 겹인 이유는 역할이 다르기 때문이다 — nginx는 바깥세상과의
 접점(TLS·인증서·헤더)을, Traefik은 클러스터 내부의 동적 라우팅을 맡는다.
 ## 구성 요소
 | 경로 | 역할 |
 |---|---|
 | `cloud-init/kc-lab.yaml.example` | 게스트 부트스트랩 템플릿 |
 | `host/nginx-keycloak-lab.conf` | lab host의 `sites-available/keycloak-lab` |
 | `k8s/echo.yaml` | 2홉 헤더 계약 측정용 워크로드 |
 | `scripts/rebuild-seed.sh` | cloud-init 시드 ISO 재생성 + 풀 업로드 |
 | `scripts/build-and-import.sh` | 이미지 빌드 → 각 노드 containerd 반입 |
 | `scripts/measure-proxy-headers.sh` | 헤더 계약 실측 |
 | `scripts/verify-lab.sh` | 인프라 상태 점검 |
 ## 상태 점검
 ```bash
 ./deploy/lab/scripts/verify-lab.sh      # lab host 에서
 ```
 **`404`가 성공 신호다.** TLS가 종료되고 Traefik까지 도달했으나 매칭되는
 Ingress 규칙이 없다는 뜻이다. `502`나 연결 거부면 체인이 끊긴 것이다.
 ## 첫 실험 — 2홉 헤더 계약
 [`docs/reverse-proxy-headers.md`](../../docs/reverse-proxy-headers.md)의 계약은
 nginx **1홉**을 가정하고 쓰였다. 실제 배치는 2홉이므로, nginx가 세팅한
 `X-Forwarded-*`를 Traefik이 그대로 넘기는지 덮어쓰는지 **측정해서 확인한다.**
 이 결론이 뒤의 모든 실험에 깔린다. Keycloak의 `iss` 클레임, redirect URL,
 쿠키 도메인 검증이 전부 이 헤더에 의존하기 때문이다.
 ```bash
 # 워크스테이션: 이미지 빌드 후 두 노드에 반입
 ./deploy/lab/scripts/build-and-import.sh
 # lab host: 배포
 kubectl apply -f deploy/lab/k8s/echo.yaml
 kubectl -n header-lab rollout status deployment/echo
 # 어디서든: 실측
 ./deploy/lab/scripts/measure-proxy-headers.sh
 ```
 관측 대상은 넷이다.
 1. `X-Forwarded-For` — Traefik이 **덧붙이는가 덮어쓰는가**
 2. `X-Forwarded-Proto` / `-Host` / `-Port` — 그대로 전달되는가
 3. **위조 내성** — 클라이언트가 직접 넣은 `X-Forwarded-*`가 앱까지 도달하는가
 4. `scheme` / `secure` / `requestUrl` — Keycloak이 URL을 만들 때 쓰는 값
 3번이 신뢰 경계의 핵심이다. 이 헤더들은 누구나 위조할 수 있는 평범한 HTTP
 헤더이므로, 신뢰 경계에 선 프록시가 **반드시 덮어써야** 한다.
 ## 이미지 배포 경로
 k3s는 containerd를 쓰고 이 실험대에는 레지스트리가 없다.
 ```
 워크스테이션  docker build → docker save
      │ ssh (lab host 경유)
      ▼
 게스트        sudo k3s ctr images import
 매니페스트    imagePullPolicy: Never
 ```
 **두 노드 모두에 반입해야 한다.** 스케줄러가 어느 노드에 배치할지 모른다.
 Keycloak·PostgreSQL·Redis는 공식 이미지를 그대로 당겨오므로 이 경로가
 필요한 것은 자체 빌드 이미지뿐이다.
 **lab host에 Docker를 설치하지 않는다.** k3s의 containerd와 이미지 저장소가
 갈려서 `docker build`한 이미지를 k3s가 보지 못하게 된다.
 ## 게스트 재생성
 파괴적 실험 후 초기화하는 경로다.
 ```bash
 virsh destroy kc-lab-1
 virsh undefine kc-lab-1                       # --remove-all-storage 는 시드 ISO 까지 지운다
 virsh vol-delete --pool default kc-lab-1.qcow2
 ./deploy/lab/scripts/rebuild-seed.sh 1        # user-data 를 고쳤을 때만
 virt-install --name kc-lab-1 --memory 3584 --vcpus 2 \
  --disk size=20,backing_store=/var/lib/libvirt/images/base.qcow2 \
  --disk vol=default/seed-kc-lab-1.iso,device=disk,bus=virtio,readonly=on \
  --network network=default,mac=52:54:00:aa:bb:11 \
  --import --os-variant debian12 --noautoconsole
 ```
 시드는 **virtio 디스크**로 붙인다. `virt-install --cloud-init`은 시드를 SATA
 CD-ROM으로 붙이는데, Debian `genericcloud` 이미지는 크기를 줄이려고 물리
 하드웨어 드라이버를 제외해서 **AHCI 장치를 보지 못한다.** 그러면 cloud-init이
 데이터소스를 찾지 못하고 아무 오류도 남기지 않은 채 종료한다. 증상은
 hostname이 `localhost`로 남고 SSH가 `Permission denied (publickey)`로 거부되는
 것뿐이다.
 게스트에 들어갈 수 없을 때는 화면을 직접 뜬다.
 ```bash
 virsh screenshot kc-lab-1 /tmp/kc1.ppm    # 확장자와 무관하게 PNG 로 저장된다
 ```
 `localhost login:`이면 cloud-init 미실행, `kc-lab-1 login:`이면 실행된 것이다.
@@ -0,0 +1,37 @@
 #cloud-config
 # Template for both lab guests. scripts/rebuild-seed.sh substitutes __NODE__
 # and bakes this into a CIDATA seed image.
 #
 # Copy to kc-lab.yaml and fill the two placeholders. The real file is ignored by
 # git because plain_text_passwd is a credential, however disposable.
 #
 # Indentation is spaces only. YAML forbids tabs, and cloud-init fails silently
 # on a parse error: the guest boots as "localhost" with no user and no way in.
 hostname: kc-lab-__NODE__
 fqdn: kc-lab-__NODE__
 manage_etc_hosts: true
 users:
  - name: donghyeon
    groups: [sudo]
    shell: /bin/bash
    # NOPASSWD is required: the k3s installer and the fault-injection scripts
    # run non-interactively and would block on a password prompt.
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    # Console-only escape hatch. Without it, a cloud-init failure leaves a guest
    # that cannot be logged into at all, so its own failure log is unreadable.
    # ssh_pwauth stays false, so this never widens SSH exposure.
    lock_passwd: false
    plain_text_passwd: CHANGE_ME
    ssh_authorized_keys:
      # Lab host key: needed because automation runs from the lab host, where
      # agent forwarding is not available.
      - CHANGE_ME_LAB_HOST_PUBLIC_KEY
      # Workstation key: lets ProxyJump reach the guest directly.
      - CHANGE_ME_WORKSTATION_PUBLIC_KEY
 ssh_pwauth: false
 package_update: true
 packages:
  - curl
  - nftables
@@ -0,0 +1,56 @@
 # Lab entry point. Deployed on the lab host as
 #   /etc/nginx/sites-available/keycloak-lab
 # and symlinked from sites-enabled/.
 #
 # Arch does not ship the Debian sites-available convention, so nginx.conf needs
 #   include /etc/nginx/sites-enabled/*;
 # inside its http { } block before this file has any effect.
 #
 # This is the outer of two L7 hops. It terminates TLS and hands plain HTTP to
 # the Traefik instance running on each k3s node.
 upstream k3s_traefik {
    # Sticky-session switch. Keycloak recommends affinity on AUTH_SESSION_ID;
    # ip_hash is the cheap stand-in for a single-browser lab. Leaving it off is
    # the interesting case: Infinispan still routes correctly, only slower.
    # ip_hash;
    server 192.168.122.11:80;
    server 192.168.122.12:80;
 }
 server {
    listen 80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
 }
 server {
    listen 443 ssl default_server;
    http2 on;
    server_name _;
    # fullchain.pem, never cert.pem: omitting the intermediates passes on
    # desktop browsers and fails on mobile and curl.
    ssl_certificate     /etc/letsencrypt/live/auth.hyeonworks.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.hyeonworks.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    location / {
        proxy_pass http://k3s_traefik;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port  443;
        # $remote_addr, not $proxy_add_x_forwarded_for. This is the trust
        # boundary: a client-supplied X-Forwarded-For must be discarded, not
        # extended, or nothing downstream can rely on the value.
        proxy_set_header X-Forwarded-For   $remote_addr;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
 }
@@ -0,0 +1,46 @@
 # Experiment A-1 — cut the JGroups transport (TCP 7800) while leaving discovery alone.
 #
 # The point is to separate two things that are easy to conflate:
 #
 #   discovery   how the nodes FIND each other   -> PostgreSQL JGROUPS_PING table
 #   transport   how they actually TALK          -> TCP 7800
 #
 # Blocking only the transport produces a state that cannot happen on a single
 # node: both members stay registered in the database, so each believes the other
 # exists, yet no message gets through.
 #
 #   kubectl apply -f deploy/lab/k8s/a1-block-jgroups-transport.yaml
 #   kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
 #
 # NetworkPolicy is an ALLOWLIST, not a firewall with deny rules. There is no way
 # to write "deny 7800". The moment a pod is selected by a policy carrying
 # policyTypes: [Ingress], every inbound port is denied unless a rule permits it.
 # So 7800 is blocked by *omission*: 8080 and 9000 are listed, 7800 is not.
 #
 # That makes the two allow rules load-bearing — get them wrong and the experiment
 # measures a dead Keycloak instead of a partitioned cluster:
 #
 #   8080  the HTTP endpoint. Traefik, the other pod's REST calls, and the probe
 #         traffic all arrive here.
 #   9000  the management port: /health/started, /health/ready, /health/live and
 #         /metrics. Losing it means the kubelet fails the readiness probe and
 #         kills the pod — the cluster would break for the wrong reason.
 #
 # Both rules deliberately omit `from:`, which allows those ports from any source.
 # Narrowing the source is not the subject here; the 2-hop experiment already
 # established how to do that by label when it matters.
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
  name: a1-block-jgroups-transport
  namespace: keycloak-lab
 spec:
  podSelector:
    matchLabels:
      app: keycloak
  policyTypes: [Ingress]
  ingress:
    - ports:
        - { port: 8080, protocol: TCP }   # HTTP — must stay open
        - { port: 9000, protocol: TCP }   # health + metrics — must stay open
    # 7800 is absent on purpose. That is the whole experiment.
@@ -0,0 +1,62 @@
 # Restrict who may reach the echo pods.
 #
 # Traefik is configured to trust X-Forwarded-* from the whole pod CIDR, and the
 # app's Tomcat valve trusts every private range by default. Both are IP-range
 # decisions, so any pod in the cluster can forge those headers by talking to the
 # Service directly and bypassing Traefik entirely. Measured, not hypothetical:
 #
 #   kubectl -n header-lab run t --rm -i --restart=Never --image=curlimages/curl -- \
 #     curl -s http://echo:8081/api/echo -H 'X-Forwarded-Host: evil.example.com'
 #   → serverName evil.example.com, remoteAddr 1.2.3.4
 #
 # A NetworkPolicy closes that path. It selects by label rather than IP, so it
 # survives pod restarts and rescheduling — unlike the trustedIPs list, which
 # could not name Traefik because its IP changes.
 #
 # "Trusting forwarded headers" and "guaranteeing a proxy sits in front" are a
 # pair. Doing only the first leaves this hole.
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
  name: echo-allow-traefik-only
  namespace: header-lab
 spec:
  podSelector:
    matchLabels:
      app: echo
  policyTypes:
    - Ingress
  ingress:
    # The proxy itself. namespaceSelector and podSelector in one list item are
    # ANDed, so this is "traefik pods in kube-system" and nothing else.
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              app.kubernetes.io/name: traefik
      ports:
        - protocol: TCP
          port: 8081
    # kubelet readiness/liveness probes originate from the node, not from a pod,
    # so they need their own rule. Without it the probes fail and the pods are
    # restarted in a loop.
    #
    # The probe's source address is the node's flannel bridge (cni0), which
    # holds the first address of that node's /24:
    #   kc-lab-1  10.42.0.1     kc-lab-2  10.42.1.1
    # Listing them as /32 keeps this rule from re-admitting arbitrary pods,
    # which a broader 10.42.0.0/16 block would do and would undo the policy.
    #
    # Adding a node means adding its gateway here. Verify with:
    #   kubectl get nodes -o jsonpath='{range .items[*]}{.spec.podCIDR}{"\n"}{end}'
    - from:
        - ipBlock:
            cidr: 10.42.0.1/32
        - ipBlock:
            cidr: 10.42.1.1/32
      ports:
        - protocol: TCP
          port: 8081
@@ -0,0 +1,113 @@
 # Header echo workload for the two-hop proxy contract measurement.
 #
 #   browser -> host nginx (TLS termination) -> Traefik -> this pod
 #
 # The image is built from backend/ and imported straight into each node's
 # containerd, so imagePullPolicy must stay Never. See scripts/build-and-import.sh.
 apiVersion: v1
 kind: Namespace
 metadata:
  name: header-lab
 ---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: echo
  namespace: header-lab
 spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      # One replica per node so the sticky-session switch on the host nginx
      # upstream has something observable to route between.
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: echo
      containers:
        - name: echo
          image: keycloak-pattern-api:lab
          imagePullPolicy: Never
          ports:
            - containerPort: 8081
              name: http
          env:
            - name: SERVER_PORT
              value: "8081"
            # "none" makes the app report the raw connection, so scheme/secure/
            # requestUrl show what arrives without any forwarded-header handling.
            # Set to "native" and redeploy to see the same request interpreted
            # with X-Forwarded-* honoured. Keycloak's KC_PROXY_HEADERS is the
            # same opt-in, which is why measuring both sides matters here.
            - name: SERVER_FORWARD_HEADERS_STRATEGY
              value: "native"
            # The JVM sizes its heap from the container limit, not the host.
            - name: JAVA_TOOL_OPTIONS
              value: "-XX:MaxRAMPercentage=70"
            # /api/echo is permitAll, so the JWT decoder is never exercised.
            # These stay pointed at the future Keycloak service name.
            - name: SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI
              value: "https://auth.hyeonworks.com/realms/keycloak-patterns"
            - name: SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI
              value: "https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs"
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: http
            initialDelaySeconds: 15
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: http
            initialDelaySeconds: 45
            periodSeconds: 15
          resources:
            requests:
              memory: 320Mi
              cpu: 100m
            limits:
              memory: 512Mi
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: echo
  namespace: header-lab
 spec:
  selector:
    app: echo
  ports:
    - port: 8081
      targetPort: http
      name: http
 ---
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
  name: echo
  namespace: header-lab
 spec:
  # k3s ships Traefik as the default ingress controller. Keeping it is what
  # makes this lab a faithful two-hop replica.
  ingressClassName: traefik
  rules:
    - host: app1.hyeonworks.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: echo
                port:
                  number: 8081
@@ -0,0 +1,277 @@
 # Keycloak multi-node cluster with PostgreSQL.
 #
 # Goal of this manifest: two Keycloak pods on two different nodes must discover
 # each other and form one Infinispan cluster. Keycloak 26 discovers peers through
 # the database (jdbc-ping) rather than multicast, writing to a JGROUPS_PING table,
 # but the cluster traffic itself runs over TCP 7800 between the pods. Those are
 # two separate mechanisms, which is why "registered in the DB but not clustered"
 # is a real failure mode — and one that a single node cannot reproduce.
 #
 #   kubectl apply -f deploy/lab/k8s/keycloak-cluster.yaml
 #   kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=600s
 #
 # Secrets are plain here. Proper secret handling is roadmap item 11; keeping it
 # visible for now is deliberate so the gap is obvious rather than forgotten.
 apiVersion: v1
 kind: Namespace
 metadata:
  name: keycloak-lab
 ---
 apiVersion: v1
 kind: Secret
 metadata:
  name: keycloak-lab-secrets
  namespace: keycloak-lab
 type: Opaque
 stringData:
  POSTGRES_PASSWORD: lab-postgres-change-me
  KC_BOOTSTRAP_ADMIN_PASSWORD: lab-admin-change-me
 ---
 # PostgreSQL. local-path binds the volume to whichever node the pod lands on, so
 # the database is effectively pinned to one node. That is not a flaw here: it is
 # what makes "the database node dies" a meaningful experiment later.
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
  name: postgres-data
  namespace: keycloak-lab
 spec:
  accessModes: [ReadWriteOnce]
  storageClassName: local-path
  resources:
    requests:
      storage: 5Gi
 ---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: postgres
  namespace: keycloak-lab
 spec:
  replicas: 1
  strategy:
    type: Recreate          # RWO volume cannot be mounted by two pods at once
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
              name: postgres
          env:
            - name: POSTGRES_DB
              value: keycloak
            - name: POSTGRES_USER
              value: keycloak
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: keycloak-lab-secrets
                  key: POSTGRES_PASSWORD
            # The image refuses to initialise into a non-empty mount, and
            # local-path volumes are clean, but this keeps the data one level
            # down so a lost+found or similar never blocks initdb.
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
          readinessProbe:
            exec:
              command: ["sh", "-c", "pg_isready -U keycloak -d keycloak"]
            initialDelaySeconds: 10
            periodSeconds: 5
          resources:
            requests:
              memory: 192Mi
              cpu: 50m
            limits:
              memory: 512Mi
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: postgres-data
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: postgres
  namespace: keycloak-lab
 spec:
  selector:
    app: postgres
  ports:
    - port: 5432
      targetPort: postgres
 ---
 # Keycloak. A StatefulSet rather than a Deployment so each pod keeps a stable
 # name (keycloak-0, keycloak-1); cluster membership is far easier to read in
 # logs and in the JGROUPS_PING table when the identities do not churn.
 apiVersion: apps/v1
 kind: StatefulSet
 metadata:
  name: keycloak
  namespace: keycloak-lab
 spec:
  serviceName: keycloak-headless
  replicas: 2
  podManagementPolicy: Parallel   # both pods start together, so they race to
                                  # register — which is the interesting case
  selector:
    matchLabels:
      app: keycloak
  template:
    metadata:
      labels:
        app: keycloak
    spec:
      # One pod per node. Two pods on one node would share a kernel and make the
      # 7800 blocking experiment meaningless.
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: keycloak
      containers:
        - name: keycloak
          image: quay.io/keycloak/keycloak:26.7.0
          # "start", not "start-dev". Dev mode forces cache=local and there is
          # no cluster to form at all.
          args: ["start"]
          ports:
            - containerPort: 8080
              name: http
            - containerPort: 9000
              name: management
            - containerPort: 7800
              name: jgroups
          env:
            - name: KC_DB
              value: postgres
            - name: KC_DB_URL
              value: jdbc:postgresql://postgres:5432/keycloak
            - name: KC_DB_USERNAME
              value: keycloak
            - name: KC_DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: keycloak-lab-secrets
                  key: POSTGRES_PASSWORD
            # Settings confirmed by the two-hop header measurement.
            # KC_HOSTNAME carries the full external URL, which pins scheme and
            # host for issuer and redirect URLs regardless of headers.
            # KC_PROXY_HEADERS is the separate opt-in that lets the forwarded
            # client address through — the same kind of switch as Spring's
            # forward-headers-strategy. See docs/two-hop-proxy-header-contract.md.
            - name: KC_HOSTNAME
              value: https://auth.hyeonworks.com
            - name: KC_HOSTNAME_STRICT
              value: "true"
            - name: KC_PROXY_HEADERS
              value: xforwarded
            - name: KC_HTTP_ENABLED
              value: "true"
            - name: KC_HEALTH_ENABLED
              value: "true"
            - name: KC_METRICS_ENABLED
              value: "true"
            # Without an explicit cap the JVM sizes its heap from the container
            # limit and this lab has roughly 3.8GB of guest headroom in total.
            - name: JAVA_OPTS_KC_HEAP
              value: "-Xms256m -Xmx512m"
            - name: KC_BOOTSTRAP_ADMIN_USERNAME
              value: admin
            - name: KC_BOOTSTRAP_ADMIN_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: keycloak-lab-secrets
                  key: KC_BOOTSTRAP_ADMIN_PASSWORD
          # Keycloak serves health and metrics on the management port (9000),
          # not on 8080, since version 25.
          startupProbe:
            httpGet:
              path: /health/started
              port: management
            periodSeconds: 10
            failureThreshold: 60      # first boot runs an implicit build
          readinessProbe:
            httpGet:
              path: /health/ready
              port: management
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health/live
              port: management
            periodSeconds: 30
          resources:
            requests:
              memory: 640Mi
              cpu: 100m
            limits:
              memory: 900Mi
 ---
 # Headless service. Not required for jdbc-ping discovery, which goes through the
 # database, but it gives each pod a stable DNS name for direct inspection.
 apiVersion: v1
 kind: Service
 metadata:
  name: keycloak-headless
  namespace: keycloak-lab
 spec:
  clusterIP: None
  selector:
    app: keycloak
  ports:
    - port: 8080
      targetPort: http
      name: http
    - port: 9000
      targetPort: management
      name: management
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: keycloak
  namespace: keycloak-lab
 spec:
  selector:
    app: keycloak
  ports:
    - port: 8080
      targetPort: http
      name: http
 ---
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
  name: keycloak
  namespace: keycloak-lab
 spec:
  ingressClassName: traefik
  rules:
    - host: auth.hyeonworks.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: keycloak
                port:
                  number: 8080
@@ -0,0 +1,373 @@
 # Prometheus + node-exporter + Grafana.
 #
 # Purpose: during a fault-injection experiment, know *which signal moved first*.
 # Without a metrics store the only record is whatever scrolled past in a terminal,
 # and "the cluster recovered in about a minute" is not a measurement.
 #
 #   kubectl apply -f deploy/lab/k8s/observability.yaml
 #   kubectl -n observability rollout status deployment/prometheus --timeout=300s
 #
 # Placement decision — Prometheus and Grafana are pinned to the control-plane
 # node (kc-lab-1). An observability stack must not share a failure domain with
 # the thing it observes. With only two nodes that cannot be fully avoided, so the
 # rule here is: the node that gets killed in experiments is the *agent*
 # (kc-lab-2, holding keycloak-0 and postgres), and everything needed to watch
 # that happen lives on the server node.
 apiVersion: v1
 kind: Namespace
 metadata:
  name: observability
 ---
 # Prometheus discovers scrape targets by querying the Kubernetes API, so it
 # needs read access to nodes, services, endpoints and pods. Without this the
 # kubernetes_sd_configs below silently return no targets.
 apiVersion: v1
 kind: ServiceAccount
 metadata:
  name: prometheus
  namespace: observability
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
  name: prometheus
 rules:
  - apiGroups: [""]
    # nodes/proxy is required in addition to nodes/metrics: the kubelet job
    # reaches each node through the API server's proxy subresource
    # (/api/v1/nodes/<name>/proxy/metrics). Without it every kubelet target
    # fails with 403 Forbidden while the other jobs stay green — a partial
    # failure that is easy to miss unless the target list is checked.
    resources: [nodes, nodes/metrics, nodes/proxy, services, endpoints, pods]
    verbs: [get, list, watch]
  - nonResourceURLs: ["/metrics"]
    verbs: [get]
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
  name: prometheus
 roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
 subjects:
  - kind: ServiceAccount
    name: prometheus
    namespace: observability
 ---
 apiVersion: v1
 kind: ConfigMap
 metadata:
  name: prometheus-config
  namespace: observability
 data:
  prometheus.yml: |
    global:
      # 15s is short for production but right here: a node loss should show up
      # within a couple of samples, not a minute later.
      scrape_interval: 15s
      evaluation_interval: 15s
    scrape_configs:
      # Prometheus scraping itself. Useful as a control: if this target is down,
      # the problem is Prometheus, not the thing being measured.
      - job_name: prometheus
        static_configs:
          - targets: ['localhost:9090']
      # Keycloak. Metrics live on the management port 9000, not 8080 — the same
      # split that the health probes use. KC_METRICS_ENABLED=true is already set
      # on the StatefulSet.
      #
      # Discovery is by endpoints rather than a static list because pod IPs
      # change on every restart; that was observed directly when the lab was
      # power-cycled and every pod came back with a new address.
      - job_name: keycloak
        kubernetes_sd_configs:
          - role: endpoints
            namespaces:
              names: [keycloak-lab]
        relabel_configs:
          - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
            action: keep
            regex: keycloak-headless;management
          - source_labels: [__meta_kubernetes_pod_name]
            target_label: pod
          - source_labels: [__meta_kubernetes_pod_node_name]
            target_label: node
      # node-exporter, one per node via DaemonSet. This is what answers
      # "did the machine die or did the process die".
      - job_name: node-exporter
        kubernetes_sd_configs:
          - role: endpoints
            namespaces:
              names: [observability]
        relabel_configs:
          - source_labels: [__meta_kubernetes_service_name]
            action: keep
            regex: node-exporter
          - source_labels: [__meta_kubernetes_pod_node_name]
            target_label: node
      # The kubelet's own metrics, reached through the API server proxy so no
      # extra port needs opening.
      - job_name: kubelet
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
          insecure_skip_verify: true
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
          - role: node
        relabel_configs:
          - action: labelmap
            regex: __meta_kubernetes_node_label_(.+)
          - target_label: __address__
            replacement: kubernetes.default.svc:443
          - source_labels: [__meta_kubernetes_node_name]
            regex: (.+)
            target_label: __metrics_path__
            replacement: /api/v1/nodes/${1}/proxy/metrics
 ---
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
  name: prometheus-data
  namespace: observability
 spec:
  accessModes: [ReadWriteOnce]
  storageClassName: local-path
  resources:
    requests:
      storage: 5Gi
 ---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: prometheus
  namespace: observability
 spec:
  replicas: 1
  strategy:
    type: Recreate            # RWO volume; two pods cannot mount it at once
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      # See the placement note at the top of this file.
      nodeSelector:
        node-role.kubernetes.io/control-plane: "true"
      securityContext:
        fsGroup: 65534        # the image runs as nobody and must own the volume
      containers:
        - name: prometheus
          image: prom/prometheus:v3.1.0
          args:
            - --config.file=/etc/prometheus/prometheus.yml
            - --storage.tsdb.path=/prometheus
            # 7 days is far more than an experiment needs and keeps the volume
            # small enough that it never becomes the reason a node fills up.
            - --storage.tsdb.retention.time=7d
            - --web.enable-lifecycle
          ports:
            - containerPort: 9090
              name: http
          volumeMounts:
            - name: config
              mountPath: /etc/prometheus
            - name: data
              mountPath: /prometheus
          readinessProbe:
            httpGet: { path: /-/ready, port: http }
            initialDelaySeconds: 10
          livenessProbe:
            httpGet: { path: /-/healthy, port: http }
            initialDelaySeconds: 30
          resources:
            requests: { memory: 256Mi, cpu: 50m }
            limits:   { memory: 640Mi }
      volumes:
        - name: config
          configMap:
            name: prometheus-config
        - name: data
          persistentVolumeClaim:
            claimName: prometheus-data
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: prometheus
  namespace: observability
 spec:
  selector:
    app: prometheus
  ports:
    - port: 9090
      targetPort: http
 ---
 # node-exporter. A DaemonSet so every node reports, including one that is about
 # to be killed — the last samples before it goes silent are the interesting part.
 apiVersion: apps/v1
 kind: DaemonSet
 metadata:
  name: node-exporter
  namespace: observability
 spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      # Host namespaces: the point is to measure the machine, not the container.
      hostNetwork: true
      hostPID: true
      tolerations:
        - operator: Exists      # must also run on tainted nodes
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.8.2
          args:
            - --path.procfs=/host/proc
            - --path.sysfs=/host/sys
            - --path.rootfs=/host/root
            - --collector.filesystem.mount-points-exclude=^/(dev|proc|sys|var/lib/docker/.+|var/lib/kubelet/.+)($|/)
          ports:
            - containerPort: 9100
              name: metrics
              hostPort: 9100
          volumeMounts:
            - { name: proc,   mountPath: /host/proc, readOnly: true }
            - { name: sys,    mountPath: /host/sys,  readOnly: true }
            - { name: rootfs, mountPath: /host/root, readOnly: true, mountPropagation: HostToContainer }
          resources:
            requests: { memory: 32Mi, cpu: 20m }
            limits:   { memory: 96Mi }
      volumes:
        - { name: proc,   hostPath: { path: /proc } }
        - { name: sys,    hostPath: { path: /sys } }
        - { name: rootfs, hostPath: { path: / } }
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: node-exporter
  namespace: observability
 spec:
  clusterIP: None             # headless: Prometheus wants each pod, not a VIP
  selector:
    app: node-exporter
  ports:
    - port: 9100
      targetPort: metrics
      name: metrics
 ---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: grafana
  namespace: observability
 spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      nodeSelector:
        node-role.kubernetes.io/control-plane: "true"
      containers:
        - name: grafana
          image: grafana/grafana:11.4.0
          ports:
            - containerPort: 3000
              name: http
          env:
            - name: GF_SECURITY_ADMIN_USER
              value: admin
            - name: GF_SECURITY_ADMIN_PASSWORD
              value: lab-grafana-change-me
            # Grafana builds absolute URLs for redirects and asset paths. Behind
            # the nginx -> Traefik chain it must be told the external address,
            # for exactly the reason Keycloak needs KC_HOSTNAME. Without it,
            # login redirects come back as http://<pod-ip>:3000.
            - name: GF_SERVER_ROOT_URL
              value: https://app2.hyeonworks.com
          volumeMounts:
            - name: datasources
              mountPath: /etc/grafana/provisioning/datasources
          readinessProbe:
            httpGet: { path: /api/health, port: http }
            initialDelaySeconds: 15
          resources:
            requests: { memory: 128Mi, cpu: 50m }
            limits:   { memory: 320Mi }
      volumes:
        - name: datasources
          configMap:
            name: grafana-datasources
 ---
 # Provisioning the datasource as a file means Grafana comes up already wired to
 # Prometheus. Clicking through the UI would leave the configuration only in
 # Grafana's own database, which is emptyDir here and disappears on restart.
 apiVersion: v1
 kind: ConfigMap
 metadata:
  name: grafana-datasources
  namespace: observability
 data:
  prometheus.yaml: |
    apiVersion: 1
    datasources:
      - name: Prometheus
        type: prometheus
        access: proxy
        url: http://prometheus.observability.svc:9090
        isDefault: true
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: grafana
  namespace: observability
 spec:
  selector:
    app: grafana
  ports:
    - port: 3000
      targetPort: http
 ---
 # Grafana is published on app2.hyeonworks.com because that name is already in
 # the wildcard-free certificate (auth / app1 / app2) and is otherwise unused.
 # It moves when app2 is needed for the SSO experiment.
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
  name: grafana
  namespace: observability
 spec:
  ingressClassName: traefik
  rules:
    - host: app2.hyeonworks.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: grafana
                port:
                  number: 3000
@@ -0,0 +1,43 @@
 # Make Traefik trust the X-Forwarded-* headers that the host nginx sets.
 #
 # Without this, Traefik rewrites every forwarded header from its own connection,
 # which is plain HTTP on port 80. The application then sees scheme=http even
 # though the browser connected over TLS. See docs/two-hop-proxy-header-contract.md.
 #
 # k3s installs Traefik through its bundled HelmChart, so values are overridden
 # with a HelmChartConfig rather than by editing the deployment. k3s reconciles
 # the chart and recreates the Traefik pod.
 #
 #   kubectl apply -f deploy/lab/k8s/traefik-forwarded-headers.yaml
 #   kubectl -n kube-system rollout status deploy/traefik --timeout=180s
 apiVersion: helm.cattle.io/v1
 kind: HelmChartConfig
 metadata:
  name: traefik
  namespace: kube-system
 spec:
  valuesContent: |-
    ports:
      web:
        forwardedHeaders:
          # Requests arriving from these sources keep their existing
          # X-Forwarded-* values instead of having them rewritten.
          #
          # 10.42.0.0/16 is the pod CIDR. It is required because the traefik
          # Service uses externalTrafficPolicy: Cluster, so svclb SNATs the
          # traffic and Traefik sees a pod-network address rather than the
          # host nginx address.
          #
          # The node/host range is deliberately absent. Because svclb SNATs,
          # the host nginx address never reaches Traefik — measured, not assumed.
          # Trusting a range that cannot appear only widens the surface.
          #
          # Trusting the whole pod CIDR still means any pod in the cluster could
          # forge these headers, which is why echo-network-policy.yaml restricts
          # who may reach the application at all.
          trustedIPs:
            - 10.42.0.0/16
      websecure:
        forwardedHeaders:
          trustedIPs:
            - 10.42.0.0/16
@@ -0,0 +1,42 @@
 #!/usr/bin/env bash
 # Build the API image on this workstation and import it into each lab node's
 # containerd.
 #
 # k3s does not run Docker and the lab has no registry, so images are shipped as
 # a stream: docker save -> ssh through the lab host -> k3s ctr images import.
 # Every node needs its own copy because the scheduler may place the pod anywhere.
 #
 #   ./deploy/lab/scripts/build-and-import.sh
 #   IMAGE=keycloak-pattern-api:lab NODES="kc-lab-1" ./deploy/lab/scripts/build-and-import.sh
 set -euo pipefail
 IMAGE="${IMAGE:-keycloak-pattern-api:lab}"
 NODES="${NODES:-kc-lab-1 kc-lab-2}"
 LAB_HOST="${LAB_HOST:-test-server}"
 CONTEXT="${CONTEXT:-backend}"
 repo_root="$(git rev-parse --show-toplevel)"
 cd "$repo_root"
 echo "==> building ${IMAGE} from ${CONTEXT}/"
 docker build -t "$IMAGE" "$CONTEXT"
 for node in $NODES; do
  echo "==> importing into ${node}"
  # Nested ssh: the workstation cannot reach the guests directly because they
  # sit behind the lab host's libvirt NAT. The lab host's ~/.ssh/config holds
  # the kc-lab-* aliases.
  docker save "$IMAGE" \
    | ssh "$LAB_HOST" "ssh ${node} 'sudo k3s ctr images import -'"
 done
 echo "==> verifying"
 for node in $NODES; do
  printf '  %-10s ' "$node"
  ssh "$LAB_HOST" "ssh ${node} 'sudo k3s ctr images ls -q'" \
    | grep -c "$IMAGE" \
    | xargs -I{} echo "{} match(es)"
 done
 echo
 echo "next: kubectl rollout restart -n header-lab deployment/echo"
@@ -0,0 +1,55 @@
 #!/usr/bin/env bash
 # Experiment 0c — where does a session entry actually live?
 #
 # Experiment 0b showed keycloak-1's session cache never moved when keycloak-0
 # handled a login. That leaves two explanations:
 #
 #   (a) a DISTRIBUTED cache with owners=1 — entries are spread across nodes by
 #       consistent hashing, and this one happened to land on keycloak-0;
 #   (b) a LOCAL cache — each node only ever caches what it handled itself.
 #
 # They are distinguished by driving logins at the OTHER node. Under (a) the
 # entries would keep landing on both nodes regardless of who was asked. Under
 # (b) the count rises only on the node that received the request.
 set -uo pipefail
 NS="${NS:-keycloak-lab}"
 N="${N:-5}"
 K0_IP=$(kubectl -n "$NS" get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1_IP=$(kubectl -n "$NS" get pod keycloak-1 -o jsonpath='{.status.podIP}')
 ADMIN_PW=$(kubectl -n "$NS" get secret keycloak-lab-secrets \
             -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d)
 echo "수집 시각: $(date '+%Y-%m-%d %H:%M:%S %Z')"
 echo "  keycloak-0 = $K0_IP  ($(kubectl -n "$NS" get pod keycloak-0 -o jsonpath='{.spec.nodeName}'))"
 echo "  keycloak-1 = $K1_IP  ($(kubectl -n "$NS" get pod keycloak-1 -o jsonpath='{.spec.nodeName}'))"
 echo
 kubectl -n "$NS" run kc-own --rm -i --restart=Never \
  --image=curlimages/curl:8.11.1 --quiet --command -- sh -c "
 O=/tmp/o; : > \$O
 ent() {
  curl -s --retry 3 --max-time 20 http://\$1:9000/metrics \
    | grep -E '^vendor_statistics_approximate_entries_unique.cache=.sessions' \
    | awk '{print \$NF}'
 }
 login() { i=0; while [ \$i -lt $N ]; do
  curl -s -o /dev/null -X POST http://\$1:8080/realms/master/protocol/openid-connect/token \
    -d grant_type=password -d client_id=admin-cli \
    -d username=admin -d 'password=$ADMIN_PW'
  i=\$((i+1)); done; sleep 5; }
 {
  printf '%-32s %12s %12s\n' '단계' 'k0 entries' 'k1 entries'
  printf '%-32s %12s %12s\n' '시작' \"\$(ent $K0_IP)\" \"\$(ent $K1_IP)\"
  login $K1_IP
  printf '%-32s %12s %12s\n' 'keycloak-1 에 로그인 ${N}회' \"\$(ent $K0_IP)\" \"\$(ent $K1_IP)\"
  login $K0_IP
  printf '%-32s %12s %12s\n' 'keycloak-0 에 로그인 ${N}회' \"\$(ent $K0_IP)\" \"\$(ent $K1_IP)\"
 } >> \$O
 cat \$O
 " 2>&1 | grep -v '^pod .* deleted$'
 echo
 echo "=== 대조: PostgreSQL 에는 몇 건인가 ==="
 kubectl -n "$NS" exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
  "select count(*) from offline_user_session where offline_flag='0'" 2>/dev/null | sed 's/^/  online 세션 /'
@@ -0,0 +1,83 @@
 #!/usr/bin/env bash
 # Experiment 0b — does the Infinispan cache itself replicate, or do both nodes
 # merely agree because they read the same database?
 #
 # Experiment 0 proved the two nodes give the same answers. That alone does NOT
 # prove Infinispan replicated anything: with persistent-user-sessions (the
 # Keycloak 26 default) the session is written to PostgreSQL, so two nodes reading
 # one database would agree even with the cache disabled entirely.
 #
 # This script separates the two by measuring the cache counters on BOTH nodes
 # around a single login. If the write on keycloak-0 shows up as cache activity
 # on keycloak-1, the replication is real and not a database artifact.
 set -uo pipefail
 NS="${NS:-keycloak-lab}"
 K0_IP=$(kubectl -n "$NS" get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1_IP=$(kubectl -n "$NS" get pod keycloak-1 -o jsonpath='{.status.podIP}')
 ADMIN_PW=$(kubectl -n "$NS" get secret keycloak-lab-secrets \
             -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d)
 echo "수집 시각: $(date '+%Y-%m-%d %H:%M:%S %Z')"
 echo
 # 파드 출력을 스트리밍으로 받으면 조각이 유실된다. 실제로 첫 시도에서
 # keycloak-1 의 스냅샷과 그 다음 마커가 통째로 사라져 델타가 0 으로 보였다.
 # 파드 안에서 파일로 모았다가 마지막에 한 번만 내보낸다.
 kubectl -n "$NS" run kc-delta --rm -i --restart=Never \
  --image=curlimages/curl:8.11.1 --quiet --command -- sh -c "
 set -u
 K0='http://$K0_IP'; K1='http://$K1_IP'
 O=/tmp/o.txt; : > \$O
 snap() {
  curl -s --retry 3 --retry-connrefused --max-time 20 \$1:9000/metrics \
    | grep -E '^vendor_(statistics_(stores|hits|misses|approximate_entries_unique)|rpc_manager_replication_count)\{cache=\"(sessions|clientSessions)\"' \
    | sed 's/,cache_manager=\"keycloak\"//; s/,node=\"[^\"]*\"//' >> \$O
 }
 echo '###BEFORE_K0' >> \$O; snap \$K0
 echo '###BEFORE_K1' >> \$O; snap \$K1
 echo '###LOGIN' >> \$O
 curl -s -o /dev/null -w 'http_code=%{http_code}\n' -X POST \
  \"\$K0:8080/realms/master/protocol/openid-connect/token\" \
  -d grant_type=password -d client_id=admin-cli \
  -d username=admin -d 'password=$ADMIN_PW' >> \$O
 sleep 5
 echo '###AFTER_K0' >> \$O; snap \$K0
 echo '###AFTER_K1' >> \$O; snap \$K1
 echo '###END' >> \$O
 cat \$O
 " 2>&1 | grep -v '^pod .* deleted$' > /tmp/cache-delta.txt
 python3 - /tmp/cache-delta.txt <<'PY'
 import re, sys
 raw = open(sys.argv[1]).read()
 blocks, cur = {}, None
 for line in raw.splitlines():
    if line.startswith('###'):
        cur = line[3:]; blocks[cur] = {}
    elif cur and '{' in line:
        m = re.match(r'(\S+?)\{cache="(\w+)"\}\s+(\S+)', line)
        if m:
            blocks[cur][(m.group(1), m.group(2))] = float(m.group(3))
 print('=== 로그인은 keycloak-0 에만 보냈다 ===')
 code = [l for l in raw.splitlines() if l.startswith('http_code=')]
 print('  로그인 응답: ' + (code[0] if code else '없음'))
 for n in ('BEFORE_K0','BEFORE_K1','AFTER_K0','AFTER_K1'):
    if not blocks.get(n):
        print(f'  !! {n} 스냅샷이 비었다 — 델타를 신뢰할 수 없다')
 print()
 hdr = f"  {'계수기':<42} {'캐시':<15} {'전':>8} {'후':>8} {'증가':>7}"
 for node in ('K0', 'K1'):
    who = 'keycloak-0 (로그인을 받은 노드)' if node == 'K0' else 'keycloak-1 (아무 요청도 받지 않은 노드)'
    print(f'=== {who} ===')
    print(hdr)
    b, a = blocks.get(f'BEFORE_{node}', {}), blocks.get(f'AFTER_{node}', {})
    for k in sorted(set(b) | set(a)):
        before, after = b.get(k[0:2], 0.0), a.get(k[0:2], 0.0)
        d = after - before
        mark = '  ←' if d else ''
        name = k[0].replace('vendor_statistics_', '').replace('vendor_rpc_manager_', 'rpc.')
        print(f"  {name:<42} {k[1]:<15} {before:>8.0f} {after:>8.0f} {d:>+7.0f}{mark}")
    print()
 PY
@@ -0,0 +1,108 @@
 #!/usr/bin/env bash
 # Experiment 0d — capture the actual SQL that the OTHER node runs.
 #
 # Experiments 0b/0c showed that session entries never appear in keycloak-1's
 # memory, yet keycloak-1 can use a session keycloak-0 created. The conclusion
 # "keycloak-1 reads it from PostgreSQL" was an inference, not an observation.
 #
 # This script turns on statement logging in PostgreSQL for a few seconds, sends
 # ONE refresh request to keycloak-1 for a session born on keycloak-0, and greps
 # the database log for that session id. If the inference is right, the SQL is
 # there, issued from keycloak-1's pod IP.
 #
 # It also checks whether serving that request makes keycloak-1 cache the session
 # — which sharpens "each node caches what it handled" from "what it logged in"
 # to "what it touched".
 set -uo pipefail
 NS="${NS:-keycloak-lab}"
 PSQL="kubectl -n $NS exec deploy/postgres -- psql -U keycloak -d keycloak -tAc"
 K0_IP=$(kubectl -n "$NS" get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1_IP=$(kubectl -n "$NS" get pod keycloak-1 -o jsonpath='{.status.podIP}')
 ADMIN_PW=$(kubectl -n "$NS" get secret keycloak-lab-secrets \
             -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d)
 echo "수집 시각: $(date '+%Y-%m-%d %H:%M:%S %Z')"
 echo "  keycloak-0 = $K0_IP   (세션을 만드는 노드)"
 echo "  keycloak-1 = $K1_IP   (읽기만 하는 노드)"
 echo
 # %h 를 넣어야 어느 파드가 보낸 질의인지 로그에서 구분된다.
 echo "=== PostgreSQL 문장 로깅을 켠다 ==="
 $PSQL "alter system set log_statement='all'"      >/dev/null 2>&1
 $PSQL "alter system set log_line_prefix='%m [%p] %h '" >/dev/null 2>&1
 $PSQL "select pg_reload_conf()"                   >/dev/null 2>&1
 echo "  log_statement    = $($PSQL 'show log_statement' 2>/dev/null)"
 echo "  log_line_prefix  = $($PSQL 'show log_line_prefix' 2>/dev/null)"
 echo
 # 로그 커서를 잡아둔다. 이 줄 수 이후만 본다.
 LOG_BEFORE=$(kubectl -n "$NS" logs deploy/postgres --tail=-1 2>/dev/null | wc -l)
 RESULT=$(kubectl -n "$NS" run kc-readpath --rm -i --restart=Never \
  --image=curlimages/curl:8.11.1 --quiet --command -- sh -c "
 O=/tmp/o; : > \$O
 TOKEN_EP='/realms/master/protocol/openid-connect/token'
 jget() { sed -n \"s/.*\\\"\$1\\\":\\\"\\([^\\\"]*\\)\\\".*/\\1/p\"; }
 ent() {
  curl -s --retry 3 --max-time 20 http://\$1:9000/metrics \
    | grep -E '^vendor_statistics_approximate_entries_unique.cache=.sessions' | awk '{print \$NF}'
 }
 # keycloak-0 에서 로그인한다
 L=\$(curl -s -X POST \"http://$K0_IP:8080\$TOKEN_EP\" -d grant_type=password \
     -d client_id=admin-cli -d username=admin -d 'password=$ADMIN_PW')
 SID=\$(echo \"\$L\" | jget access_token | cut -d. -f2 | sed 's/\$/==/' | base64 -d 2>/dev/null | jget sid)
 RT=\$(echo \"\$L\" | jget refresh_token)
 echo \"SID=\$SID\" >> \$O
 echo \"K1_ENTRIES_BEFORE=\$(ent $K1_IP)\" >> \$O
 sleep 2
 # 반대편 노드에 refresh 를 딱 한 번 보낸다
 # 인용을 한 겹 더 쌓으면 curl 이 URL 을 통째로 못 읽는다. 실제로 000 이 나왔다.
 CODE=\$(curl -s -o /dev/null -w '%{http_code}' -X POST \
  \"http://$K1_IP:8080\$TOKEN_EP\" \
  -d grant_type=refresh_token -d client_id=admin-cli -d \"refresh_token=\$RT\")
 echo \"REFRESH_ON_K1=\$CODE\" >> \$O
 sleep 3
 echo \"K1_ENTRIES_AFTER=\$(ent $K1_IP)\" >> \$O
 cat \$O
 " 2>&1 | grep -v '^pod .* deleted$')
 echo "=== 요청 ==="
 echo "$RESULT" | sed 's/^/  /'
 SID=$(echo "$RESULT" | sed -n 's/^SID=//p')
 echo
 echo "=== PostgreSQL 문장 로깅을 끈다 ==="
 $PSQL "alter system reset log_statement"     >/dev/null 2>&1
 $PSQL "alter system reset log_line_prefix"   >/dev/null 2>&1
 $PSQL "select pg_reload_conf()"              >/dev/null 2>&1
 echo "  log_statement = $($PSQL 'show log_statement' 2>/dev/null)"
 echo
 echo "=== keycloak-1 이 실제로 보낸 SQL 문장 ==="
 echo "  (파라미터가 \$1 로 묶여 있어, sid 는 바로 아래 DETAIL 줄에 있다)"
 echo
 kubectl -n "$NS" logs deploy/postgres --tail=-1 2>/dev/null \
  | tail -n +$((LOG_BEFORE + 1)) \
  | grep -F "$K1_IP" | grep -E "LOG:  execute" \
  | sed 's/.*execute [^:]*: //' | sed 's/^/  /' | head -12
 echo
 echo "=== 그 sid 를 언급한 SQL — 누가 보냈는가 ==="
 echo "  찾는 sid: $SID"
 echo
 kubectl -n "$NS" logs deploy/postgres --tail=-1 2>/dev/null \
  | tail -n +$((LOG_BEFORE + 1)) \
  | grep -F "$SID" \
  | sed -e "s/$K0_IP/[keycloak-0]/g" -e "s/$K1_IP/[keycloak-1]/g" \
  | cut -c1-220 \
  | head -20
 echo
 echo "=== 요약: 파드별 질의 건수 ==="
 kubectl -n "$NS" logs deploy/postgres --tail=-1 2>/dev/null \
  | tail -n +$((LOG_BEFORE + 1)) \
  | grep -F "$SID" \
  | grep -oE "^[0-9-]+ [0-9:.]+ [A-Z]+ \[[0-9]+\] [0-9.]+" \
  | awk '{print $NF}' | sort | uniq -c \
  | sed -e "s/$K0_IP/[keycloak-0]/" -e "s/$K1_IP/[keycloak-1]/" -e 's/^/  /'
@@ -0,0 +1,207 @@
 #!/usr/bin/env bash
 # Experiment 0 — is a session created on one Keycloak node usable on the other?
 #
 # Forming a cluster is not the same as sharing session state. The Infinispan log
 # says "cluster view (2)", but that only proves the members found each other.
 #
 # Design notes, learned the hard way:
 #
 #  * Every probe has a CONTROL. A result from the far node means nothing unless
 #    the same call against the issuing node is also measured. The first version
 #    of this script reported "403 on keycloak-1" as if it were a replication
 #    failure; the issuing node returned 403 too, and the cause was a missing
 #    openid scope. Measure both, always.
 #
 #  * Sessions are tracked by SID, not by count. Both the test login and the
 #    admin API calls create sessions for the same user, so counts are noisy.
 #    A specific session id either appears in a node's answer or it does not.
 #
 #  * The probe is the REFRESH TOKEN grant, not userinfo. userinfo only validates
 #    a signature and can succeed on a node that knows nothing about the session.
 #    Refreshing requires the node to find the session, check it is alive, and
 #    write back a new refresh time — it actually touches the session store.
 #
 # Talks to pod IPs directly: going through nginx/Traefik would hide which node
 # handled each request, which is the entire question.
 #
 #   ./deploy/lab/scripts/experiment-session-replication.sh
 set -uo pipefail
 NS="${NS:-keycloak-lab}"
 OUT="${OUT:-/tmp/session-replication}"
 mkdir -p "$OUT"
 PSQL="kubectl -n $NS exec deploy/postgres -- psql -U keycloak -d keycloak -tAc"
 echo "수집 시각: $(date '+%Y-%m-%d %H:%M:%S %Z')"
 echo
 K0_IP=$(kubectl -n "$NS" get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1_IP=$(kubectl -n "$NS" get pod keycloak-1 -o jsonpath='{.status.podIP}')
 K0_NODE=$(kubectl -n "$NS" get pod keycloak-0 -o jsonpath='{.spec.nodeName}')
 K1_NODE=$(kubectl -n "$NS" get pod keycloak-1 -o jsonpath='{.spec.nodeName}')
 ADMIN_PW=$(kubectl -n "$NS" get secret keycloak-lab-secrets \
             -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d)
 echo "=== 대상 ==="
 printf '  keycloak-0  %-14s %s\n' "$K0_IP" "$K0_NODE"
 printf '  keycloak-1  %-14s %s\n' "$K1_IP" "$K1_NODE"
 echo
 echo "=== [0] 실험 전 DB 세션 ==="
 $PSQL "select offline_flag, count(*) from offline_user_session group by offline_flag" 2>/dev/null \
  | sed 's/^/  offline_flag=/' || echo "  (없음)"
 echo
 # 파드 하나 안에서 전 단계를 실행한다. 단계마다 파드를 새로 띄우면 토큰을
 # 단계 사이로 넘길 수 없다.
 kubectl -n "$NS" run kc-probe --rm -i --restart=Never \
  --image=curlimages/curl:8.11.1 --quiet --command -- sh -c "
 set -u
 K0='http://$K0_IP:8080'; K1='http://$K1_IP:8080'
 TOKEN_EP='/realms/master/protocol/openid-connect/token'
 jget() { sed -n \"s/.*\\\"\$1\\\":\\\"\\([^\\\"]*\\)\\\".*/\\1/p\"; }
 # ── [1] keycloak-0 에서 로그인. 이 노드가 세션의 출생지다 ──────────────────
 LOGIN=\$(curl -s -X POST \"\$K0\$TOKEN_EP\" \
  -d grant_type=password -d client_id=admin-cli \
  -d username=admin -d 'password=$ADMIN_PW')
 echo '###STEP1_LOGIN'; echo \"\$LOGIN\"
 AT=\$(echo \"\$LOGIN\" | jget access_token)
 RT=\$(echo \"\$LOGIN\" | jget refresh_token)
 # ── [2] 관리 API 조회용 토큰. 세션 오염을 피하려고 따로 하나만 더 만든다 ──
 ADMTOK=\$(curl -s -X POST \"\$K0\$TOKEN_EP\" \
  -d grant_type=password -d client_id=admin-cli \
  -d username=admin -d 'password=$ADMIN_PW' | jget access_token)
 CID=\$(curl -s -H \"Authorization: Bearer \$ADMTOK\" \
  \"\$K0/admin/realms/master/clients?clientId=admin-cli\" | jget id | head -1)
 # ── [3] 두 노드에 같은 질문을 한다: admin-cli 의 세션 목록 ────────────────
 echo '###STEP3_SESSIONS_K0'
 curl -s -H \"Authorization: Bearer \$ADMTOK\" \
  \"\$K0/admin/realms/master/clients/\$CID/user-sessions?max=100\"
 echo
 echo '###STEP3_SESSIONS_K1'
 curl -s -H \"Authorization: Bearer \$ADMTOK\" \
  \"\$K1/admin/realms/master/clients/\$CID/user-sessions?max=100\"
 echo
 # ── [4] 대조군: keycloak-0 이 발급한 refresh token 을 keycloak-0 에 쓴다 ──
 #      먼저 반대편에 써야 하므로 여기서는 쓰지 않고, 순서를 [5] 뒤로 미룬다.
 #      refresh token 은 회전(rotation)되므로 한 번 쓰면 옛 것이 무효가 된다.
 #      따라서 '반대편 먼저'가 유일하게 의미 있는 순서다.
 # ── [5] 시험군: keycloak-0 이 발급한 refresh token 을 keycloak-1 에 쓴다 ──
 echo '###STEP5_REFRESH_ON_K1'
 curl -s -w '\nhttp_code=%{http_code}\n' -X POST \"\$K1\$TOKEN_EP\" \
  -d grant_type=refresh_token -d client_id=admin-cli -d \"refresh_token=\$RT\"
 RT2=\$(curl -s -X POST \"\$K1\$TOKEN_EP\" \
  -d grant_type=refresh_token -d client_id=admin-cli -d \"refresh_token=\$RT\" \
  | jget refresh_token)
 # ── [6] 무효화가 반대 방향으로도 전파되는가 ───────────────────────────────
 #      keycloak-1 에서 로그아웃시키고, keycloak-0 에서 갱신을 시도한다.
 echo '###STEP6_LOGOUT_VIA_K1'
 curl -s -o /dev/null -w 'http_code=%{http_code}\n' -X POST \"\$K1/realms/master/protocol/openid-connect/logout\" \
  -d client_id=admin-cli -d \"refresh_token=\$RT2\"
 echo '###STEP7_REFRESH_ON_K0_AFTER_LOGOUT'
 curl -s -w '\nhttp_code=%{http_code}\n' -X POST \"\$K0\$TOKEN_EP\" \
  -d grant_type=refresh_token -d client_id=admin-cli -d \"refresh_token=\$RT2\"
 echo '###END'
 " > "$OUT/raw.txt" 2>&1
 sed -i '/^pod .* deleted$/d' "$OUT/raw.txt"
 python3 - "$OUT/raw.txt" <<'PY' | tee "$OUT/report.txt"
 import base64, json, sys
 raw = open(sys.argv[1]).read()
 blocks, cur = {}, None
 for line in raw.splitlines():
    if line.startswith('###'):
        cur = line[3:]; blocks[cur] = []
    elif cur is not None:
        blocks[cur].append(line)
 get = lambda k: '\n'.join(blocks.get(k, [])).strip()
 def j(s):
    try:    return json.JSONDecoder().raw_decode(s.strip())[0]
    except Exception: return None
 def claims(tok):
    p = tok.split('.')[1]; p += '=' * (-len(p) % 4)
    return json.loads(base64.urlsafe_b64decode(p))
 login = j(get('STEP1_LOGIN'))
 if not login or 'access_token' not in login:
    print('로그인 실패:', get('STEP1_LOGIN')[:300]); sys.exit(1)
 ac = claims(login['access_token'])
 rc = claims(login['refresh_token'])
 SID = ac['sid']
 print('=== [1] keycloak-0 에서 로그인 ===')
 print(f"  sid          {SID}")
 print(f"  sub          {ac.get('sub')}")
 print(f"  iss          {ac.get('iss')}")
 print(f"  access 수명  {ac['exp']-ac['iat']}초")
 print(f"  refresh 수명 {rc['exp']-rc['iat']}초   typ={rc.get('typ')}")
 print(f"  refresh jti  {rc.get('jti')}")
 print()
 print('=== [3] 같은 sid 가 두 노드 모두에서 보이는가 ===')
 for step, who in (('STEP3_SESSIONS_K0', 'keycloak-0 (발급 노드)'),
                  ('STEP3_SESSIONS_K1', 'keycloak-1 (반대편)')):
    d = j(get(step))
    if d is None:
        print(f'  {who:24} 파싱 실패: {get(step)[:120]}'); continue
    ids = [s.get('id') for s in d]
    mark = '보임 ✔' if SID in ids else '없음 ✘'
    print(f'  {who:24} 세션 {len(ids)}개 중 대상 sid → {mark}')
    for s in d:
        if s.get('id') == SID:
            print(f"      ipAddress={s.get('ipAddress')}  start={s.get('start')}  lastAccess={s.get('lastAccess')}")
 def show(step, title, expect):
    print(); print(f'=== {title} ===')
    body = get(step)
    code = [l for l in body.splitlines() if l.startswith('http_code=')]
    code = code[0].split('=')[1] if code else '?'
    d = j(body)
    ok = '기대대로' if code == expect else f'기대({expect})와 다름'
    print(f'  HTTP {code}   ← {ok}')
    if d and 'access_token' in d:
        c = claims(d['access_token'])
        same = '동일 ✔' if c.get('sid') == SID else f"다름 ✘ ({c.get('sid')})"
        print(f'  새 토큰의 sid → {same}')
    elif d:
        print(f"  error             {d.get('error')}")
        print(f"  error_description {d.get('error_description')}")
 show('STEP5_REFRESH_ON_K1',
     '[5] keycloak-0 이 발급한 refresh token 을 keycloak-1 에 사용', '200')
 print(); print('=== [6] keycloak-1 을 통해 로그아웃 ===')
 print('  ' + get('STEP6_LOGOUT_VIA_K1').strip())
 show('STEP7_REFRESH_ON_K0_AFTER_LOGOUT',
     '[7] 로그아웃 후 keycloak-0 에서 갱신 시도 (무효화 전파)', '400')
 open('/tmp/session-replication/sid.txt','w').write(SID)
 PY
 SID=$(cat /tmp/session-replication/sid.txt 2>/dev/null)
 echo
 echo "=== [8] PostgreSQL 에서 그 sid 를 직접 확인 ==="
 echo "  대상 sid: $SID"
 $PSQL "select user_session_id, offline_flag, created_on, last_session_refresh
       from offline_user_session where user_session_id='$SID'" 2>/dev/null \
  | sed 's/^/  /' | grep -q . \
  && $PSQL "select user_session_id||' | flag='||offline_flag||' | created='||created_on||' | refresh='||last_session_refresh
            from offline_user_session where user_session_id='$SID'" 2>/dev/null | sed 's/^/  /' \
  || echo "  행 없음 — 로그아웃으로 삭제되었다"
 echo
 echo "  전체 세션 수: $($PSQL 'select count(*) from offline_user_session' 2>/dev/null)"
@@ -0,0 +1,42 @@
 #!/usr/bin/env bash
 # Measure what the nginx -> Traefik chain actually delivers to the application.
 #
 # docs/reverse-proxy-headers.md documents a single-hop nginx contract. The lab
 # runs two hops, so the forwarded headers are measured rather than assumed.
 # Run from anywhere that can resolve the lab hostnames.
 #
 #   ./deploy/lab/scripts/measure-proxy-headers.sh
 set -euo pipefail
 HOST="${HOST:-app1.hyeonworks.com}"
 URL="https://${HOST}/api/echo"
 jqf() {
  if command -v jq >/dev/null 2>&1; then jq "$@"; else python3 -m json.tool; fi
 }
 echo "=== 1. baseline: what the app sees for a normal request ==="
 curl -s "$URL" | jqf '{
  scheme, secure, serverName, serverPort, requestUrl, remoteAddr,
  forwarded: .headers | with_entries(select(.key | startswith("x-forwarded") or . == "x-real-ip" or . == "forwarded"))
 }' 2>/dev/null || curl -s "$URL"
 echo
 echo "=== 2. spoof test: client sends its own X-Forwarded-* ==="
 echo "    a trusted boundary must overwrite these, not append to them"
 curl -s "$URL" \
  -H 'X-Forwarded-For: 1.2.3.4' \
  -H 'X-Forwarded-Proto: http' \
  -H 'X-Forwarded-Host: evil.example.com' \
  -H 'X-Real-IP: 1.2.3.4' \
  | jqf '.headers | with_entries(select(.key | startswith("x-forwarded") or . == "x-real-ip"))' 2>/dev/null
 echo
 echo "=== 3. which pod answered (host nginx upstream distribution) ==="
 for _ in 1 2 3 4; do
  curl -s "$URL" | jqf -r '.headers["x-forwarded-server"] // "n/a"' 2>/dev/null
 done
 echo
 echo "=== 4. plain HTTP is redirected, not proxied ==="
 curl -s -o /dev/null -w '  http  -> %{http_code} %{redirect_url}\n' "http://${HOST}/api/echo"
@@ -0,0 +1,47 @@
 #!/usr/bin/env bash
 # Rebuild a guest's cloud-init seed image and publish it into the libvirt pool.
 # Run on the lab host.
 #
 #   ./rebuild-seed.sh 1
 #
 # The same content lives in three places: the source YAML, the ISO, and the
 # uploaded pool volume. Editing the YAML alone changes nothing, which is why
 # this is a script and not a set of remembered commands.
 #
 # A rebuilt seed only takes effect on a freshly created VM. cloud-init runs its
 # per-instance modules once per instance-id, so an existing guest ignores it.
 set -euo pipefail
 N="${1:?usage: rebuild-seed.sh <1|2>}"
 CLOUD_DIR="${CLOUD_DIR:-$HOME/workspace/cloud}"
 POOL="${POOL:-default}"
 export LIBVIRT_DEFAULT_URI="${LIBVIRT_DEFAULT_URI:-qemu:///system}"
 cd "$CLOUD_DIR"
 src="kc-lab-${N}.yaml"
 iso="seed-kc-lab-${N}.iso"
 meta="meta-kc-lab-${N}"
 [ -f "$src" ] || { echo "missing $CLOUD_DIR/$src" >&2; exit 1; }
 # A fresh instance-id makes cloud-init treat the guest as new and re-run the
 # per-instance modules.
 printf 'instance-id: kc-lab-%s-%s\nlocal-hostname: kc-lab-%s\n' \
  "$N" "$(date +%s)" "$N" > "$meta"
 # NoCloud looks for a volume labelled cidata holding files named exactly
 # user-data and meta-data. -graft-points renames them inside the image so no
 # staging directory is needed.
 xorrisofs -quiet -output "$iso" -volid CIDATA -joliet -rock -graft-points \
  "/user-data=${src}" "/meta-data=${meta}"
 size="$(stat -c%s "$iso")"
 virsh vol-delete --pool "$POOL" "$iso" >/dev/null 2>&1 || true
 virsh vol-create-as "$POOL" "$iso" "$size" --format raw >/dev/null
 virsh vol-upload --pool "$POOL" "$iso" "$iso"
 echo "$iso published to pool '$POOL' ($size bytes)"
 echo "attach it as a virtio disk, not a SATA cdrom:"
 echo "  --disk vol=${POOL}/${iso},device=disk,bus=virtio,readonly=on"
 echo "Debian genericcloud images carry no AHCI driver, so a SATA cdrom is invisible"
 echo "to the guest and cloud-init fails with no error anywhere."
@@ -0,0 +1,47 @@
 #!/usr/bin/env bash
 # Confirm the lab infrastructure is intact. Run on the lab host.
 #
 # A 404 from the HTTPS entry point is the success signal: TLS terminated and the
 # request reached Traefik, which simply had no matching ingress rule. A 502 or a
 # refused connection means the chain is broken somewhere.
 set -uo pipefail
 export LIBVIRT_DEFAULT_URI="${LIBVIRT_DEFAULT_URI:-qemu:///system}"
 HOSTS="${HOSTS:-auth.hyeonworks.com app1.hyeonworks.com app2.hyeonworks.com}"
 NODE_IPS="${NODE_IPS:-192.168.122.11 192.168.122.12}"
 fail=0
 check() { # description, expected, actual
  if [ "$2" = "$3" ]; then printf '  ok    %-34s %s\n' "$1" "$3"
  else printf '  FAIL  %-34s got %s, want %s\n' "$1" "$3" "$2"; fail=1; fi
 }
 echo "== guests =="
 for name in kc-lab-1 kc-lab-2; do
  check "$name" running "$(virsh domstate "$name" 2>/dev/null || echo absent)"
 done
 echo "== k3s =="
 ready="$(kubectl get nodes --no-headers 2>/dev/null | grep -c ' Ready ')"
 check "nodes Ready" 2 "$ready"
 lb="$(kubectl -n kube-system get svc traefik \
      -o jsonpath='{.status.loadBalancer.ingress[*].ip}' 2>/dev/null | wc -w)"
 check "traefik node IPs" 2 "$lb"
 echo "== host nginx =="
 check "service" active "$(systemctl is-active nginx)"
 check "cert renew timer" active "$(systemctl is-active certbot-renew.timer)"
 for ip in $NODE_IPS; do
  check "traefik $ip" 404 "$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "http://${ip}/")"
 done
 echo "== public entry point =="
 for h in $HOSTS; do
  check "https://$h" 404 "$(curl -s -o /dev/null -w '%{http_code}' --max-time 8 "https://${h}/")"
  check "tls verify $h" 0 "$(curl -s -o /dev/null -w '%{ssl_verify_result}' --max-time 8 "https://${h}/")"
 done
 check "http redirect" 301 "$(curl -s -o /dev/null -w '%{http_code}' --max-time 8 "http://${HOSTS%% *}/")"
 echo
 [ "$fail" -eq 0 ] && echo "lab is healthy" || echo "lab has failures"
 exit "$fail"
@@ -71,9 +71,8 @@ services:
      SERVER_PORT: "8081"
      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI: http://localhost:8080/realms/keycloak-patterns
      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI: http://keycloak:8080/realms/keycloak-patterns/protocol/openid-connect/certs
-      EDGE_INTERNAL_AUTH_TOKEN: ${INTERNAL_AUTH_TOKEN:?set INTERNAL_AUTH_TOKEN in .env}
+    ports:
-    expose:
+      - "127.0.0.1:8081:8081"
      - "8081"
    depends_on:
      keycloak:
        condition: service_healthy
@@ -89,68 +88,13 @@ services:
      - keycloak-net
    restart: unless-stopped
  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.2
    command:
      - --http-address=0.0.0.0:4180
      - --provider=keycloak-oidc
      - --oidc-issuer-url=http://localhost:8080/realms/keycloak-patterns
      - --skip-oidc-discovery=true
      - --login-url=http://localhost:8080/realms/keycloak-patterns/protocol/openid-connect/auth
      - --redeem-url=http://keycloak:8080/realms/keycloak-patterns/protocol/openid-connect/token
      - --oidc-jwks-url=http://keycloak:8080/realms/keycloak-patterns/protocol/openid-connect/certs
      - --profile-url=http://keycloak:8080/realms/keycloak-patterns/protocol/openid-connect/userinfo
      - --validate-url=http://keycloak:8080/realms/keycloak-patterns/protocol/openid-connect/userinfo
      - --redirect-url=http://localhost:8088/oauth2/callback
      - --upstream=http://app:8081
      - --email-domain=*
      - --scope=openid profile email
      - --code-challenge-method=S256
      - --reverse-proxy=true
      - --trusted-proxy-ip=172.30.40.10/32
      - --cookie-name=AP4_SESSION
      - --cookie-secure=false
      - --cookie-samesite=lax
      - --cookie-expire=1h
      - --session-cookie-minimal=true
      - --skip-provider-button=true
      - --set-xauthrequest=true
      - --pass-user-headers=true
      - --whitelist-domain=localhost:8088
      - --whitelist-domain=localhost:8080
    environment:
      OAUTH2_PROXY_CLIENT_ID: edge-proxy
      OAUTH2_PROXY_CLIENT_SECRET: ${EDGE_PROXY_CLIENT_SECRET:?set EDGE_PROXY_CLIENT_SECRET in .env}
      OAUTH2_PROXY_COOKIE_SECRET: ${OAUTH2_PROXY_COOKIE_SECRET:?set OAUTH2_PROXY_COOKIE_SECRET in .env}
    expose:
      - "4180"
    depends_on:
      keycloak:
        condition: service_healthy
      app:
        condition: service_healthy
    healthcheck:
      test:
        - CMD
        - /bin/oauth2-proxy
        - --version
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 5s
    networks:
      - keycloak-net
    restart: unless-stopped
  nginx:
    build:
      context: ./frontend
    environment:
      INTERNAL_AUTH_TOKEN: ${INTERNAL_AUTH_TOKEN:?set INTERNAL_AUTH_TOKEN in .env}
    ports:
      - "127.0.0.1:${NGINX_PORT:-8088}:80"
    depends_on:
-      oauth2-proxy:
+      app:
        condition: service_healthy
    healthcheck:
      test:
@@ -160,8 +104,7 @@ services:
      timeout: 5s
      retries: 12
    networks:
-      keycloak-net:
+      - keycloak-net
        ipv4_address: 172.30.40.10
    restart: unless-stopped
 volumes:
@@ -171,6 +114,3 @@ volumes:
 networks:
  keycloak-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.40.0/24
@@ -1,70 +0,0 @@
 # AP4 · oauth2-proxy Edge Forward Auth
 ## 첫 단계: oauth2-proxy 자체 OIDC 흐름
 `feature/keycloak-oauth2-proxy-oidc-flow`에서는 oauth2-proxy를
 `http://localhost:4180`에 직접 노출해 구성 요소를 분리해서 확인합니다.
 1. `/edge/me` 미인증 요청이 Keycloak로 redirect됩니다.
 2. oauth2-proxy는 confidential `edge-proxy` client와 PKCE S256을 사용합니다.
 3. callback에서 code/token 교환과 ID/access token 검증은 서버끼리
   수행합니다.
 4. 브라우저에는 HttpOnly `AP4_SESSION` cookie만 남습니다.
 5. oauth2-proxy가 backend 요청에 `X-Forwarded-User`를 붙여 200을 받습니다.
 Keycloak이 발급하는 issuer는 브라우저 기준
 `http://localhost:8080/realms/keycloak-patterns`입니다. 컨테이너 내부의
 `localhost`는 oauth2-proxy 자신이므로 discovery endpoint에 도달할 수
 없습니다. 그래서 이 로컬 Compose 구성은 issuer 검증값은 외부 URL로
 유지하되, login URL은 브라우저용 외부 주소, token/JWKS/userinfo는
 `http://keycloak:8080` 내부 주소로 각각 명시합니다.
 HTTP 로컬 시연이라 `cookie-secure=false`를 사용합니다. 운영 HTTPS에서는
 반드시 secure cookie로 되돌려야 합니다.
 ## 다음 단계의 보안 전제
 이 첫 feature의 backend는 전달된 사용자 헤더를 신뢰하며 8081도
 loopback에 publish되어 있습니다. 따라서 로컬에서 직접
 `X-Forwarded-User: spoofed-admin`을 보내면 우회가 재현됩니다. 이후
 Nginx `auth_request` 통합을 거쳐 최종 feature에서 backend no-publish와
 내부 shared-secret 검증을 함께 적용합니다.
 ## 두 번째 단계: Nginx `auth_request`
 `feature/keycloak-nginx-auth-request-integration`부터 외부 진입점은
 `http://localhost:8088` Nginx 하나입니다. oauth2-proxy의 4180 포트는
 Compose 네트워크에만 expose됩니다.
 - Nginx의 정확 일치 `location = /oauth2/auth`는 `internal`이라 외부에서
  직접 호출할 수 없습니다.
 - 인증 서브리퀘스트에는 본문을 보내지 않고 `Content-Length`도
  비웁니다.
 - 일반 브라우저 요청의 401은 `/oauth2/start` 302로 변환합니다.
 - API 요청 `/api/edge`는 redirect하지 않고 JSON 401을 반환합니다.
 - 인증 성공 시 oauth2-proxy의 `X-Auth-Request-User`와 email만 backend로
  전달합니다.
 Nginx 컨테이너 IP를 전용 Compose subnet에서 고정하고 oauth2-proxy의
 trusted proxy를 그 단일 IP로 제한합니다. 다만 이 단계에서는 backend
 8081이 로컬 호스트에 열려 있어 신뢰 헤더를 직접 위조할 수 있습니다.
 그 재현 조건은 마지막 feature에서 제거합니다.
 ## 마지막 단계: 신뢰 경계와 헤더 스푸핑 방어
 `feature/keycloak-header-spoofing-defense`에서는 신뢰 경계를 실제
 네트워크와 application 양쪽에서 강제합니다.
 1. backend 8081과 oauth2-proxy 4180은 host에 publish하지 않습니다.
   브라우저가 접근 가능한 application 포트는 Nginx 8088뿐입니다.
 2. Nginx는 client가 보낸 `X-Auth-Request-User`, email, 내부 토큰을
   그대로 전달하지 않고 oauth2-proxy 결과와 server-side 토큰으로
   항상 덮어씁니다.
 3. backend는 `X-Auth-Request-User`와 `X-Internal-Auth-Token`이 모두
   유효할 때만 edge identity를 받아들이며 token은 constant-time으로
   비교합니다.
 shared token은 방어 심층화 수단입니다. 운영에서는 Secret Manager나
 orchestrator secret으로 주입하고 주기적으로 교체해야 합니다. 서비스
 간 mTLS 또는 service mesh identity를 사용할 수 있다면 단순 shared
 token보다 강한 workload identity로 대체하는 편이 좋습니다.
@@ -1,26 +0,0 @@
 # AP4 edge forward-auth with Google federation
 Google federation은 AP4의 edge contract를 바꾸지 않는다.
 ```text
 Browser -> nginx -> oauth2-proxy -> Keycloak -> Google
 Browser <- AP4_SESSION <- oauth2-proxy <- Keycloak
 nginx -> trusted identity headers -> upstream app
 ```
 oauth2-proxy가 신뢰하는 issuer는 Google이 아니라 Keycloak이다. Google ID
 token은 Keycloak broker 경계 안에서 검증되고, oauth2-proxy는 Keycloak
 authorization code/token과 session cookie만 다룬다. upstream 앱도
 broker 여부와 무관하게 동일한 trusted headers를 받는다.
 `verify-edge-google-federation.sh`는 mock Google 로그인, confidential
 server-side token 교환(브라우저에 token 요청 없음), 미검증 broker email 거부,
 Keycloak email verification 완료 후 HttpOnly edge cookie와 brokered
 subject/email header를 실제 컨테이너와 브라우저로 검증한다. minimal session의
 `X-Auth-Request-User`는 표시용 username이 아니라 Keycloak의 안정적인 local
 subject UUID이며, 화면 이름이 필요하면 별도 허용 header를 명시한다.
 brokered token/claims가 client-side session cookie의 4KB 한계를 넘지 않도록
 oauth2-proxy에는 `session-cookie-minimal=true`를 적용한다. AP4 upstream은
 token forwarding이 아니라 trusted identity headers만 사용하므로 cookie에
 access/refresh/ID token을 보관할 필요가 없다.
@@ -1,20 +0,0 @@
 # AP4 edge forward-auth: local identity profile
 nginx의 `auth_request`가 oauth2-proxy `/oauth2/auth`를 호출하고, 미인증
 브라우저만 Keycloak로 redirect한다. oauth2-proxy는 confidential
 `edge-proxy` client로 code를 교환하며 browser에는 HttpOnly session cookie만
 남긴다.
 Google이 없어도 이 경계는 완전히 동작한다. 사용자는 Keycloak local
 credential로 로그인하고 upstream 애플리케이션은 OAuth/OIDC를 몰라도 된다.
 보안 경계:
 - backend와 oauth2-proxy 포트를 host에 publish하지 않는다.
 - 외부에서 받은 identity header를 nginx가 제거·덮어쓴다.
 - backend는 trusted nginx가 주입하는 별도 internal token도 확인한다.
 - 브라우저가 직접 호출한 `/oauth2/auth`는 공개하지 않는다.
 `verify-edge-no-google-profile.sh`는 Compose와 nginx 계약을 검사하고,
 `verify-pattern4.sh`는 실제 local-user 브라우저 흐름과 spoofing 방어를
 검증한다.
@@ -0,0 +1,13 @@
 === [기준선 1] 클러스터 뷰 — 양쪽 파드의 마지막 ISPN000094 ===
  keycloak-0: [keycloak-1-48749(v=16.0.12)|5] (2) [keycloak-1-48749(v=16.0.12), keycloak-0-30843(v=16.0.12)]
  keycloak-1: [keycloak-1-48749(v=16.0.12)|5] (2) [keycloak-1-48749(v=16.0.12), keycloak-0-30843(v=16.0.12)]
 === [기준선 2] JGROUPS_PING — 디스커버리 등록 ===
       name       |       ip        | coord |               coordinated_by                
 ------------------+-----------------+-------+---------------------------------------------
 keycloak-0-30843 | 10.42.1.43:7800 | f     | uuid://00000000-0000-0000-0000-000000000007
 keycloak-1-48749 | 10.42.0.35:7800 | t     | uuid://00000000-0000-0000-0000-000000000007
 (2 rows)
 === [기준선 3] 기존 NetworkPolicy ===
 No resources found in keycloak-lab namespace.
@@ -0,0 +1,17 @@
 === [대조군] 차단 전 — keycloak-0 로그인 → keycloak-1 에서 refresh ===
  sid                    tAWs2gCPr6SOcD4jDR9-_CzB
  keycloak-1 에서 refresh: 200
 === [기준선 4] JGroups 지표 — 양쪽 노드 ===
 --- K0 (10.42.1.43) ---
 vendor_jgroups_stats_bytes_sent_total 31476.0
 vendor_jgroups_merge3_get_num_merge_events 0.0
 vendor_jgroups_merge3_get_views 0.0
 vendor_jgroups_fd_sock2_get_num_suspected_members 0.0
 vendor_jgroups_nakack2_get_xmit_table_missing_messages 0.0
 --- K1 (10.42.0.35) ---
 vendor_jgroups_merge3_get_views 0.0
 vendor_jgroups_stats_bytes_sent_total 126765.0
 vendor_jgroups_nakack2_get_xmit_table_missing_messages 0.0
 vendor_jgroups_fd_sock2_get_num_suspected_members 0.0
 vendor_jgroups_merge3_get_num_merge_events 0.0
@@ -0,0 +1,8 @@
 === 차단 적용 ===
 networkpolicy.networking.k8s.io/a1-block-jgroups-transport created
 a1-block-jgroups-transport   map[app:keycloak]
 적용 시각: 11:38:08
 === FD_SOCK2 가 상대를 의심하기까지 기다린다 (15초 간격, 최대 3분) ===
  +15초  suspected(k0 k1) = 
  → 변화 감지
@@ -0,0 +1,26 @@
 차단 경과: 11:38:51 (적용 11:38:08)
 === [차단 후 1] JGroups 지표 ===
 --- keycloak-0 ---
 vendor_jgroups_stats_bytes_sent_total 32857.0
 vendor_jgroups_merge3_get_num_merge_events 0.0
 vendor_jgroups_merge3_get_views 0.0
 vendor_jgroups_fd_sock2_get_num_suspected_members 0.0
 vendor_jgroups_nakack2_get_xmit_table_missing_messages 0.0
 --- keycloak-1 ---
 vendor_jgroups_merge3_get_views 0.0
 vendor_jgroups_stats_bytes_sent_total 129103.0
 vendor_jgroups_nakack2_get_xmit_table_missing_messages 0.0
 vendor_jgroups_fd_sock2_get_num_suspected_members 0.0
 vendor_jgroups_merge3_get_num_merge_events 0.0
 === [차단 후 2] 클러스터 뷰 — 갈라졌는가 ===
  keycloak-0: 
  keycloak-1: 
 === [차단 후 3] JGROUPS_PING — 디스커버리는 살아 있는가 ===
       name       |       ip        | coord 
 ------------------+-----------------+-------
 keycloak-0-30843 | 10.42.1.43:7800 | f
 keycloak-1-48749 | 10.42.0.35:7800 | t
 (2 rows)
@@ -0,0 +1,16 @@
 === [문제 확정] NetworkPolicy 적용 후에도 기존 연결이 conntrack 에 살아 있다 ===
 --- kc-lab-1 ---
  tcp      6 86398 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=40023 dport=7800 src=10.42.1.43 dst=10.42.0.35 sport=7800 dport=40023 [ASSURED] mark=0 use=1
  tcp      6 79982 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=50477 dport=57800 src=10.42.1.43 dst=10.42.0.35 sport=57800 dport=50477 [ASSURED] mark=0 use=1
 --- kc-lab-2 ---
  tcp      6 86398 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=40023 dport=7800 src=10.42.1.43 dst=10.42.0.35 sport=7800 dport=40023 [ASSURED] mark=0 use=1
  tcp      6 33 SYN_SENT src=10.42.1.58 dst=10.42.0.35 sport=34824 dport=7800 [UNREPLIED] src=10.42.0.35 dst=10.42.1.58 sport=7800 dport=34824 mark=0 use=1
  tcp      6 79982 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=50477 dport=57800 src=10.42.1.43 dst=10.42.0.35 sport=57800 dport=50477 [ASSURED] mark=0 use=1
 === [조치] 7800 흐름의 conntrack 항목을 지운다 → 다음 패킷이 정책을 다시 탄다 ===
  kc-lab-1: tcp      6 86398 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=40023 dport=7800 src=10.42.1.43 dst=10.42.0.35 sport=7800 dport=40023 [ASSURED] mark=0 use=1 conntrack v1.4.7 (conntrack-tools): 0 flow entries have been deleted.
  kc-lab-2: tcp      6 33 SYN_SENT src=10.42.1.58 dst=10.42.0.35 sport=34824 dport=7800 [UNREPLIED] src=10.42.0.35 dst=10.42.1.58 sport=7800 dport=34824 mark=0 use=1 conntrack v1.4.7 (conntrack-tools): 0 flow entries have been deleted.
 === 삭제 후 7800 conntrack ===
  kc-lab-1: 2 건
  kc-lab-2: 2 건
@@ -0,0 +1,13 @@
 관찰 시작: 11:42:03
  +20초  suspected(k0 k1) = []
  +40초  suspected(k0 k1) = []
  +60초  suspected(k0 k1) = [0.0 0.0 0.0 0.0 ]
  +80초  suspected(k0 k1) = []
  +100초  suspected(k0 k1) = []
  +120초  suspected(k0 k1) = []
  +140초  suspected(k0 k1) = [0.0 ]
  +160초  suspected(k0 k1) = [0.0 0.0 0.0 0.0 ]
 === 클러스터 뷰 변화 (최근 8분) ===
 --- keycloak-0 ---
 --- keycloak-1 ---
@@ -0,0 +1,16 @@
 === vendor_cluster_size — 지난 25분 (차단 11:38:08, conntrack 삭제 11:41) ===
  keycloak-0:
    11:20=2  11:21=2  11:22=2  11:23=2  11:24=2  11:25=2  11:26=2  11:27=2  11:28=2  11:29=2  11:30=2  11:31=2  11:32=2  11:33=2  11:34=2  11:35=2  11:36=2  11:37=2  11:38=2  11:39=2  11:40=2  11:41=2  11:42=2  11:43=2  11:44=2  11:45=2
  keycloak-1:
    11:20=2  11:21=2  11:22=2  11:23=2  11:24=2  11:25=2  11:26=2  11:27=2  11:28=2  11:29=2  11:30=2  11:31=2  11:32=2  11:33=2  11:34=2  11:35=2  11:36=2  11:37=2  11:38=2  11:39=2  11:40=2  11:41=2  11:42=2  11:43=2  11:44=2  11:45=2
 === 현재 값 ===
  keycloak-1   = 2 멤버
  keycloak-0   = 2 멤버
 === 7800 소켓 상태 (파드 내부) ===
  keycloak-0  2
  keycloak-1  2
 === conntrack ===
  kc-lab-1  1 건
  kc-lab-2  1 건
@@ -0,0 +1,9 @@
 === 정책이 걸린 상태에서 keycloak-0 을 재시작한다 → 재연결이 막힌다 ===
 재시작 시각: 11:46:07
 pod "keycloak-0" deleted from keycloak-lab namespace
 keycloak-0   false   10.42.1.67   2026-09-04T02:44:23Z
 === cluster_size 추이 ===
  keycloak-0: 11:45:27=1  11:45:57=1  11:46:27=1  11:46:57=1  11:47:27=1
  keycloak-0: 11:40:57=2  11:41:27=2  11:41:57=2  11:42:27=2  11:42:57=2  11:43:27=2  11:43:57=2
  keycloak-1: 11:40:57=2  11:41:27=2  11:41:57=2  11:42:27=2  11:42:57=2  11:43:27=2  11:43:57=2  11:44:27=1  11:44:57=1  11:45:27=1  11:45:57=1  11:46:27=1  11:46:57=1  11:47:27=1
@@ -0,0 +1,16 @@
 === keycloak-0 헬스 상태 ===
  keycloak-0 = 10.42.1.67   keycloak-1 = 10.42.0.35
  PodReadyToStartContainers=True 
  Initialized=True 
  Ready=False ContainersNotReady
  ContainersReady=False ContainersNotReady
  PodScheduled=True 
 === ★ 본 시험 — 분단 상태에서 교차 노드 세션이 되는가 ===
  [1] keycloak-0 로그인          sid=nShl5TaBrZnKStDqaspjgmJB
  [2] keycloak-1 에서 refresh     HTTP 200
  [3] keycloak-1 에서 로그아웃    HTTP 204
  [4] keycloak-0 에서 재갱신 시도 HTTP 200
      (400 이면 무효화가 전파된 것)
 === DB 세션 수 ===
@@ -0,0 +1,33 @@
 === 그 sid 가 DB 에 남아 있는가 ===
 user_session_id | offline_flag | last_session_refresh 
 -----------------+--------------+----------------------
 (0 rows)
 === 전체 온라인 세션 수 ===
  1
 === 노드별 세션 캐시 엔트리 (Prometheus) ===
  keycloak-1   kc-lab-1   = 0
  keycloak-0   kc-lab-2   = 1
 === keycloak-0 이 Ready 가 아닌 이유 — 헬스 응답 ===
 {
    "status": "DOWN",
    "checks": [
        {
            "name": "Graceful Shutdown",
            "status": "UP"
        },
        {
            "name": "Keycloak cluster health check",
            "status": "DOWN",
            "data": {
                "Failing since": "2026-09-04 02:45:14,251"
            }
        },
        {
            "name": "Keycloak database connections async health check",
            "status": "UP"
        },
        {
            "name": "Keycloak Initialized",
@@ -0,0 +1,25 @@
 === 양쪽 노드의 readiness — 둘 다 DOWN 이면 전면 장애다 ===
 Traceback (most recent call last):
  File "<string>", line 3, in <module>
    d=json.load(sys.stdin)
  File "/usr/lib/python3.14/json/__init__.py", line 298, in load
    return loads(fp.read(),
        cls=cls, object_hook=object_hook,
        parse_float=parse_float, parse_int=parse_int,
        parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.14/json/__init__.py", line 352, in loads
    return _default_decoder.decode(s)
           ~~~~~~~~~~~~~~~~~~~~~~~^^^
  File "/usr/lib/python3.14/json/decoder.py", line 348, in decode
    raise JSONDecodeError("Extra data", s, end)
 json.decoder.JSONDecodeError: Extra data: line 21 column 2 (char 446)
 === 파드 Ready 상태 ===
 keycloak-0                  false   0
 keycloak-1                  true    0
 === ★ Service 엔드포인트 — 트래픽을 받는 파드가 남아 있는가 ===
  ready 주소: [10.42.0.35]  notReady : [10.42.1.67]
 === ★ 외부 진입점으로 실제 로그인이 되는가 (nginx→Traefik→Service) ===
  https://auth.hyeonworks.com/realms/master  HTTP 200
  토큰 발급                                   HTTP 200
@@ -0,0 +1,24 @@
 === 차단 해제 ===
 해제 시각: 11:49:58
 networkpolicy.networking.k8s.io "a1-block-jgroups-transport" deleted from keycloak-lab namespace
 === 자동으로 다시 붙는가 (30초 간격, 최대 4분) ===
  +30초  keycloak-0=1 keycloak-1=1   | Ready 파드 2 개
  +60초  keycloak-0=1 keycloak-1=1   | Ready 파드 2 개
  +90초  keycloak-0=2 keycloak-1=2   | Ready 파드 3 개
  → 클러스터 재형성
 === 복구 로그 ===
  keycloak-0: [keycloak-0-26403(v=16.0.12)|0] (1) [keycloak-0-26403(v=16.0.12)]
  keycloak-1: [keycloak-1-48749(v=16.0.12)|6] (1) [keycloak-1-48749(v=16.0.12)]
 === MERGE3 가 합쳤는가 ===
  merge_events keycloak-1   = 1
  merge_events keycloak-0   = 1
 === JGROUPS_PING — 코디네이터가 하나로 돌아왔는가 ===
       name       |       ip        | coord 
 ------------------+-----------------+-------
 keycloak-0-26403 | 10.42.1.67:7800 | t
 keycloak-1-48749 | 10.42.0.35:7800 | f
 (2 rows)
@@ -0,0 +1,26 @@
 # A-1 — JGroups 트랜스포트(7800) 차단 증거
 2026-09-04 11:38–11:52 KST · Keycloak 26.7.0 / Infinispan 16.0.12
 해설: [`docs/experiment-a1-jgroups-transport-block.md`](../../experiment-a1-jgroups-transport-block.md)
 | 파일 | 무엇을 보여주는가 |
 |---|---|
 | `01-baseline-cluster.txt` | 차단 전 — 양쪽이 뷰 ID 5·멤버 2로 일치, `JGROUPS_PING` 코디네이터 1명 |
 | `02-control-before-block.txt` | **대조군** — 차단 전 교차 노드 refresh `200`, JGroups 지표 전부 0 |
 | `03-block-applied.txt` | NetworkPolicy 적용. **빈 측정값을 "변화 감지"로 오판한 기록** |
 | `04-after-block-state.txt` | 차단 43초 후 — 지표 무변화, `JGROUPS_PING` 그대로 |
 | `05-conntrack-problem.txt` | **핵심 문제** — `ESTABLISHED [ASSURED]` 로 기존 연결이 살아 있음. FD_SOCK2 의 **57800** 포트도 함께 드러남 |
 | `06-partition-observed.txt` | 임시 curl 파드 폴링의 실패 — 빈 값·개수 불일치 |
 | `07-cluster-size.txt` | **`vendor_cluster_size` 가 25분 내내 2** — 분단이 일어나지 않았다는 결정적 증거 |
 | `08-restart-forced-partition.txt` | 재연결 강제 후 `2 → 1` |
 | `09-cross-node-under-partition.txt` | **본 시험** — 교차 refresh `200`(예측 적중), **로그아웃 후 재갱신 `200`(예측 빗나감)** |
 | `10-logout-not-propagated.txt` | 기제 확정 — **DB 행 0건인데 keycloak-0 캐시에 1건**, 헬스체크 `cluster health: DOWN` |
 | `11-service-impact.txt` | **분단 노드가 Service 에서 빠짐.** `ready=[10.42.0.35] notReady=[10.42.1.67]`, 외부 로그인 `200` |
 | `12-recovery.txt` | 90초 만에 자동 재형성, `merge3_get_num_merge_events = 1`, 코디네이터 재선출 |
 | `a1-cluster-size-partition-recovery.png` | Grafana — `vendor_cluster_size` 가 `2 → 1 → 2` 로 움직이는 전 구간 |
 ## 핵심 세 줄
 1. **NetworkPolicy 만으로는 이미 붙어 있는 클러스터를 못 끊는다.** conntrack 의 ESTABLISHED 가 먼저 통과시킨다.
 2. **세션 공유는 분단을 견딘다(200).** 통념이 틀렸고 A-0 모델이 맞다.
 3. **로그아웃 무효화는 7800 을 탄다.** DB 행이 지워져도 반대편은 낡은 캐시로 200 을 준다 — A-0 의 인과 해석을 정정한다.
@@ -0,0 +1,14 @@
 === A-2 기준선 — 클러스터가 정상으로 돌아왔는가 ===
 keycloak-0                  true   10.42.1.67   kc-lab-2
 keycloak-1                  true   10.42.0.35   kc-lab-1
 postgres-7b474b88c8-sn9ff   true   10.42.1.24   kc-lab-2
  cluster_size keycloak-1   = 2
  cluster_size keycloak-0   = 2
 === 노드별 세션 캐시 (실험 설계에 필요) ===
  keycloak-1   kc-lab-1   = 0 건
  keycloak-0   kc-lab-2   = 0 건
 === DB 온라인 세션 ===
  2
@@ -0,0 +1,10 @@
 pod/a2-probe condition met
  keycloak-0=10.42.1.67  keycloak-1=10.42.0.35
 === [준비] 양쪽 노드에 세션을 하나씩 만든다 ===
  keycloak-0 에서 로그인  sid=EAXV5HcG2J1BZ3vnwONf64AQ  토큰길이=613
  keycloak-1 에서 로그인  sid=McyTj5lj3n_JqApCXeuAHExc  토큰길이=613
 === [확인] 세션이 각자 노드에만 캐시되었는가 ===
  keycloak-1   = 0 건
  keycloak-0   = 1 건
@@ -0,0 +1,16 @@
 === [1] 토큰을 새로 발급 (access 수명 60초) ===
  발급 완료 sid=RKXQGAgkuLtouFMVPTFmp_0_
 === [2] PostgreSQL 정지 ===
  정지 시각: 11:56:04
 deployment.apps/postgres scaled
 pod/postgres-7b474b88c8-sn9ff condition met
  삭제 완료: 11:56:04
 === [3] 네 경로를 즉시 시험 ===
  ④ 이미 발급된 access token 으로 관리 API   HTTP 000000{"error":"HTTP 401 Unauthorized"}401
  ① 캐시를 가진 노드(keycloak-0)에서 refresh  HTTP 500
  ② 캐시가 없는 노드(keycloak-1)에서 refresh  HTTP 500
  ③ 새 로그인                                 HTTP 500
  --- 오류 본문 (새 로그인) ---
 {"error":"unknown_error","error_description":"For more on this error consult the server log."}
@@ -0,0 +1,29 @@
 === 파드 Ready 상태 — DB 가 없으면 어떻게 되는가 ===
 keycloak-0   false   0
 keycloak-1   false   0
 === Service 엔드포인트 ===
 Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
 Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
  notReady: [10.42.0.35 10.42.1.67]
 === health/ready 상세 ===
  전체: DOWN
    Graceful Shutdown                                    UP
    Keycloak cluster health check                        UP
    Keycloak database connections async health check     DOWN
    Keycloak Initialized                                 UP
 === ④ 다시 — 서명 검증만 필요한 경로는 살아 있는가 ===
  JWKS 엔드포인트(realm 공개키)  HTTP 200
  realm 메타데이터(.well-known)  HTTP 200
  관리 API(세션 조회 필요)       HTTP 500
 === 외부 진입점 ===
  https://auth.hyeonworks.com/realms/master   HTTP 503
 === Keycloak 로그 — 실제 오류 ===
 	at io.agroal.pool.ConnectionPool$CreateConnectionTask.call(ConnectionPool.java:664)
 	at io.agroal.pool.ConnectionPool$CreateConnectionTask.call(ConnectionPool.java:645)
 Caused by: java.net.ConnectException: Connection refused
 	at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:219)
 	at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:365)
@@ -0,0 +1,21 @@
 === ★ up 지표는 무엇을 말하는가 (프로세스는 살아 있다) ===
  up{pod=keycloak-1} = 1   ← 1 인데 서비스는 503 이다
  up{pod=keycloak-0} = 1   ← 1 인데 서비스는 503 이다
 === 복구 — PostgreSQL 재기동 ===
  재기동 시각: 11:57:09
 deployment.apps/postgres scaled
 Waiting for deployment "postgres" rollout to finish: 0 out of 1 new replicas have been updated...
 Waiting for deployment "postgres" rollout to finish: 0 of 1 updated replicas are available...
 deployment "postgres" successfully rolled out
 === Keycloak 이 스스로 회복하는가 (재시작 없이) ===
  +15초  keycloak-0                  true keycloak-1                  true  | 외부 HTTP 200
  → 서비스 복귀
 === 재시작 횟수 — 파드가 죽었다 살아난 것인가, 그대로 회복한 것인가 ===
 keycloak-0                  0
 keycloak-1                  0
 === 정지 전 세션이 살아남았는가 ===
  online 세션 5
@@ -0,0 +1,19 @@
 # A-2 — PostgreSQL 정지 증거
 2026-09-04 11:56–11:58 KST · Keycloak 26.7.0
 해설: [`docs/experiment-a2-database-loss.md`](../../experiment-a2-database-loss.md)
 | 파일 | 무엇을 보여주는가 |
 |---|---|
 | `01-baseline.txt` | 정지 전 — 양쪽 Ready, `cluster_size=2` |
 | `02-setup-sessions.txt` | 양쪽 노드에 세션 하나씩. 캐시는 각자 노드에만 |
 | `03-four-paths.txt` | **네 경로 전부 `500`.** 캐시를 가진 노드도 실패 — refresh 는 쓰기다 |
 | `04-health-and-service.txt` | **전면 장애 증거** — Ready 파드 0개, `ready 주소=[]`, 외부 **503**, `database connections: DOWN`. JWKS·.well-known 은 `200` |
 | `05-recovery.txt` | **`up=1` 인 채로 503.** DB 복귀 15초 후 재시작 0회로 자동 회복, 세션 5건 생존 |
 | `a2-up-stayed-1-during-outage.png` | Grafana — `up{job="keycloak"}` 이 전면 장애 내내 **1에 평평** |
 ## 핵심 세 줄
 1. **DB 는 단일 장애점이다.** Keycloak 을 몇 대로 늘려도 같이 죽는다 — Ready 파드 0개, 외부 503.
 2. **캐시는 읽기를 대신할 뿐 쓰기를 못 한다.** refresh 는 `UPDATE LAST_SESSION_REFRESH` 를 하므로 캐시가 있어도 실패한다.
 3. **`up` 은 이 장애를 못 잡는다.** 알림은 readiness 와 외부 응답 코드에 걸어야 한다.
@@ -0,0 +1,56 @@
 수집 시각: 2026-09-03 17:24:54 KST
 대상: Keycloak 26.7.0 × 2 + PostgreSQL 16, k3s 2노드
 === [1] 파드 배치 ===
  keycloak-0                   1/1    10.42.1.18   kc-lab-2
  keycloak-1                   1/1    10.42.0.16   kc-lab-1
  postgres-7b474b88c8-bw7b8    1/1    10.42.1.19   kc-lab-2
 === [2] 클러스터 뷰 로그 (Infinispan) ===
 -- keycloak-0 --
    2026-09-03 08:18:23,359 INFO  [org.infinispan.CLUSTER] (executor-thread-1) ISPN000094: Received new cluster view for channel ISPN: [keycloak-1-26938(v=16.0.12)|1] (2) [keycloak-1-26938(v=16.0.12), keycloak-0-49501(v=16.0.12)]
    2026-09-03 08:18:23,433 INFO  [org.infinispan.CLUSTER] (executor-thread-1) ISPN000079: Channel `ISPN` local address is `keycloak-0-49501`, physical addresses are `[10.42.1.18:7800]`
 -- keycloak-1 --
    2026-09-03 08:18:23,269 INFO  [org.infinispan.CLUSTER] (jgroups-5,keycloak-1-26938(v=16.0.12)) ISPN000094: Received new cluster view for channel ISPN: [keycloak-1-26938(v=16.0.12)|1] (2) [keycloak-1-26938(v=16.0.12), keycloak-0-49501(v=16.0.12)]
    2026-09-03 08:18:23,282 INFO  [org.infinispan.CLUSTER] (jgroups-5,keycloak-1-26938(v=16.0.12)) ISPN100000: Node keycloak-0-49501 joined the cluster
    2026-09-03 08:18:23,286 INFO  [org.infinispan.CLUSTER] (jgroups-5,keycloak-1-26938(v=16.0.12)) ISPN100000: Node keycloak-0-49501 joined the cluster
 === [3] JGROUPS_PING 테이블 구조 ===
                         Table "public.jgroups_ping"
       Column     |          Type          | Collation | Nullable | Default 
  ----------------+------------------------+-----------+----------+---------
   address        | character varying(200) |           | not null | 
   name           | character varying(200) |           |          | 
   cluster_name   | character varying(200) |           | not null | 
   ip             | character varying(200) |           | not null | 
   coord          | boolean                |           |          | 
   last_update    | bigint                 |           |          | 
   coordinated_by | character varying(200) |           |          | 
  Indexes:
      "constraint_jgroups_ping" PRIMARY KEY, btree (address)
 === [4] JGROUPS_PING 등록 내역 ===
         name       | cluster_name |       ip        | coord 
  ------------------+--------------+-----------------+-------
   keycloak-0-49501 | ISPN         | 10.42.1.18:7800 | f
   keycloak-1-26938 | ISPN         | 10.42.0.16:7800 | t
  (2 rows)
 === [5] 외부 접근 — OIDC discovery ===
  issuer                     https://auth.hyeonworks.com/realms/master
  authorization_endpoint     https://auth.hyeonworks.com/realms/master/protocol/openid-connect/auth
  token_endpoint             https://auth.hyeonworks.com/realms/master/protocol/openid-connect/token
  end_session_endpoint       https://auth.hyeonworks.com/realms/master/protocol/openid-connect/logout
  jwks_uri                   https://auth.hyeonworks.com/realms/master/protocol/openid-connect/certs
  ★ 전부 https. 첫 실험에서 확정한 KC_HOSTNAME + KC_PROXY_HEADERS 조합이 작동한다.
 === [6] 자원 사용 ===
  keycloak-0                  8m    594Mi   
  keycloak-1                  9m    593Mi   
  postgres-7b474b88c8-bw7b8   3m    67Mi    
  --- 노드 ---
  kc-lab-1   2248Mi (65%)
  kc-lab-2   1447Mi (58%)
@@ -0,0 +1,62 @@
 # 증거 — Keycloak 멀티노드 클러스터 형성
 `docs/keycloak-multinode-cluster.md`의 근거 자료.
 **정상적으로 클러스터가 형성된 상태**에서 수집했으며, 이후 고장을 주입한
 뒤 이것과 대조한다.
 수집 시각: 2026-09-03 17:24 KST
 | 파일 | 내용 |
 |---|---|
 | `01-cluster-formed.txt` | 파드 배치·클러스터 뷰 로그·JGROUPS_PING·OIDC discovery·자원 |
 ## 이 상태에서 확인된 것
 **클러스터 뷰가 멤버 2를 보고한다**
 ```
 ISPN000094: Received new cluster view for channel ISPN:
  [keycloak-1-26938|1] (2) [keycloak-1-26938, keycloak-0-49501]
 ISPN100000: Node keycloak-0-49501 joined the cluster
 ISPN000079: physical addresses are [10.42.1.18:7800]
 ```
 **디스커버리와 통신 경로가 한 테이블에 다 보인다**
 ```
       name       | cluster_name |       ip        | coord
 ------------------+--------------+-----------------+-------
 keycloak-0-49501 | ISPN         | 10.42.1.18:7800 | f
 keycloak-1-26938 | ISPN         | 10.42.0.16:7800 | t
 ```
 `name`/`cluster_name`은 **DB 디스커버리**의 결과이고, `ip`의 `:7800`은
 **실제 통신 경로**다. 7800을 막으면 이 표는 그대로 채워지면서 클러스터 뷰만
 깨질 것으로 예상한다 — 다음 실험의 가설이다.
 `coord = t` 인 `keycloak-1`이 코디네이터다.
 **배치** — 서로 다른 노드에 하나씩. PostgreSQL은 `kc-lab-2`에 있으므로
 **그 노드를 죽이면 Keycloak 하나와 DB가 동시에 사라진다.**
 ```
 keycloak-0   10.42.1.18   kc-lab-2
 keycloak-1   10.42.0.16   kc-lab-1
 postgres     10.42.1.19   kc-lab-2
 ```
 **issuer가 https로 발급된다** — 첫 실험(2홉 헤더 계약)의 결론이 적용된 결과다.
 ## 재수집
 ```bash
 kubectl -n keycloak-lab get pods -o wide
 kubectl -n keycloak-lab logs keycloak-0 | grep -E 'ISPN000094|ISPN000079|ISPN100000'
 PG=$(kubectl -n keycloak-lab get pod -l app=postgres -o name | head -1)
 kubectl -n keycloak-lab exec "$PG" -- \
  psql -U keycloak -d keycloak -c "SELECT name, cluster_name, ip, coord FROM jgroups_ping ORDER BY name;"
 curl -s https://auth.hyeonworks.com/realms/master/.well-known/openid-configuration | python3 -m json.tool
 kubectl -n keycloak-lab top pods
 ```
@@ -0,0 +1,52 @@
 ===================================================================
 실험 0 — 한 노드에서 만든 세션이 다른 노드에서 쓰이는가
 ===================================================================
 ### 사전 확인: 클러스터가 2 멤버로 형성되었는가
 2026-09-04 00:52:09,294 INFO  [org.infinispan.CLUSTER] (executor-thread-1) ISPN000094: Received new cluster view for channel ISPN: [keycloak-1-48749(v=16.0.12)|5] (2) [keycloak-1-48749(v=16.0.12), keycloak-0-30843(v=16.0.12)]
       name       |       ip        | coord 
 ------------------+-----------------+-------
 keycloak-1-48749 | 10.42.0.35:7800 | t
 keycloak-0-30843 | 10.42.1.43:7800 | f
 (2 rows)
 수집 시각: 2026-09-04 09:54:29 KST
 === 대상 ===
  keycloak-0  10.42.1.43     kc-lab-2
  keycloak-1  10.42.0.35     kc-lab-1
 === [0] 실험 전 DB 세션 ===
 === [1] keycloak-0 에서 로그인 ===
  sid          jiv3rVZi1VeaO07oVJkL_MYW
  sub          None
  iss          https://auth.hyeonworks.com/realms/master
  access 수명  60초
  refresh 수명 1800초   typ=Refresh
  refresh jti  7669cc49-4778-851f-3c49-65f76964ae8e
 === [3] 같은 sid 가 두 노드 모두에서 보이는가 ===
  keycloak-0 (발급 노드)       세션 2개 중 대상 sid → 보임 ✔
      ipAddress=10.42.1.44  start=1788483164000  lastAccess=1788483164000
  keycloak-1 (반대편)         세션 2개 중 대상 sid → 보임 ✔
      ipAddress=10.42.1.44  start=1788483164000  lastAccess=1788483164000
 === [5] keycloak-0 이 발급한 refresh token 을 keycloak-1 에 사용 ===
  HTTP 200   ← 기대대로
  새 토큰의 sid → 동일 ✔
 === [6] keycloak-1 을 통해 로그아웃 ===
  http_code=204
 === [7] 로그아웃 후 keycloak-0 에서 갱신 시도 (무효화 전파) ===
  HTTP 400   ← 기대대로
  error             invalid_grant
  error_description Session not active
 === [8] PostgreSQL 에서 그 sid 를 직접 확인 ===
  대상 sid: jiv3rVZi1VeaO07oVJkL_MYW
  행 없음 — 로그아웃으로 삭제되었다
  전체 세션 수: 1
@@ -0,0 +1,35 @@
 ===================================================================
 실험 0b — Infinispan 이 복제한 것인가, DB 를 같이 본 것인가
 ===================================================================
 수집 시각: 2026-09-04 09:54:41 KST
 === 로그인은 keycloak-0 에만 보냈다 ===
  로그인 응답: http_code=200
 === keycloak-0 (로그인을 받은 노드) ===
  계수기                                        캐시                     전        후      증가
  rpc.replication_count                      clientSessions         1        1      +0
  rpc.replication_count                      sessions               1        1      +0
  approximate_entries_unique                 clientSessions         1        2      +1  ←
  approximate_entries_unique                 sessions               1        2      +1  ←
  hits                                       clientSessions         2        2      +0
  hits                                       sessions               2        2      +0
  misses                                     clientSessions         2        3      +1  ←
  misses                                     sessions               3        4      +1  ←
  stores                                     clientSessions         2        3      +1  ←
  stores                                     sessions               2        3      +1  ←
 === keycloak-1 (아무 요청도 받지 않은 노드) ===
  계수기                                        캐시                     전        후      증가
  rpc.replication_count                      clientSessions         7        7      +0
  rpc.replication_count                      sessions               7        7      +0
  approximate_entries_unique                 clientSessions         0        0      +0
  approximate_entries_unique                 sessions               0        0      +0
  hits                                       clientSessions         4        4      +0
  hits                                       sessions               4        4      +0
  misses                                     clientSessions         0        0      +0
  misses                                     sessions               0        0      +0
  stores                                     clientSessions         1        1      +0
  stores                                     sessions               1        1      +0
@@ -0,0 +1,15 @@
 ===================================================================
 실험 0c — 세션 엔트리는 어느 노드에 있는가 (로컬 캐시인가 분산인가)
 ===================================================================
 수집 시각: 2026-09-04 09:54:54 KST
  keycloak-0 = 10.42.1.43  (kc-lab-2)
  keycloak-1 = 10.42.0.35  (kc-lab-1)
 단계                             k0 entries   k1 entries
 시작                                    2.0          0.0
 keycloak-1 에 로그인 5회             2.0          5.0
 keycloak-0 에 로그인 5회             7.0          5.0
 === 대조: PostgreSQL 에는 몇 건인가 ===
  online 세션 12
@@ -0,0 +1,56 @@
 ===================================================================
 실험 0d — 반대편 노드가 정말 DB 에서 읽는가 (SQL 을 직접 잡는다)
 ===================================================================
 수집 시각: 2026-09-04 10:14:17 KST
  keycloak-0 = 10.42.1.43   (세션을 만드는 노드)
  keycloak-1 = 10.42.0.35   (읽기만 하는 노드)
 === PostgreSQL 문장 로깅을 켠다 ===
  log_statement    = all
  log_line_prefix  = %m [%p] %h 
 === 요청 ===
  SID=jSt9GEPVQLJsO-1CeJjVgltg
  K1_ENTRIES_BEFORE=5.0
  REFRESH_ON_K1=200
  K1_ENTRIES_AFTER=5.0
 === PostgreSQL 문장 로깅을 끈다 ===
  log_statement = none
 === keycloak-1 이 실제로 보낸 SQL 문장 ===
  (파라미터가 $1 로 묶여 있어, sid 는 바로 아래 DETAIL 줄에 있다)
  select puse1_0.OFFLINE_FLAG,puse1_0.USER_SESSION_ID,puse1_0.BROKER_SESSION_ID,puse1_0.CREATED_ON,puse1_0.DATA,puse1_0.LAST_SESSION_REFRESH,puse1_0.REALM_ID,puse1_0.REMEMBER_ME,puse1_0.USER_ID,puse1_0.VERSION from OFFLINE_USER_SESSION puse1_0 where (puse1_0.OFFLINE_FLAG,puse1_0.USER_SESSION_ID) in (($1,$2))
  select puse1_0.VERSION from OFFLINE_USER_SESSION puse1_0 where puse1_0.USER_SESSION_ID=$1 and puse1_0.OFFLINE_FLAG=$2 for no key update of puse1_0 skip locked
  select pcse1_0.CLIENT_ID,pcse1_0.CLIENT_STORAGE_PROVIDER,pcse1_0.EXTERNAL_CLIENT_ID,pcse1_0.OFFLINE_FLAG,pcse1_0.USER_SESSION_ID,pcse1_0.DATA,pcse1_0.REALM_ID,pcse1_0.TIMESTAMP,pcse1_0.VERSION from OFFLINE_CLIENT_SESSION pcse1_0 where (pcse1_0.CLIENT_ID,pcse1_0.CLIENT_STORAGE_PROVIDER,pcse1_0.EXTERNAL_CLIENT_ID,pcse1_0.OFFLINE_FLAG,pcse1_0.USER_SESSION_ID) in (($1,$2,$3,$4,$5))
  select pcse1_0.VERSION from OFFLINE_CLIENT_SESSION pcse1_0 where pcse1_0.USER_SESSION_ID=$1 and pcse1_0.OFFLINE_FLAG=$2 and pcse1_0.CLIENT_ID=$3 and pcse1_0.EXTERNAL_CLIENT_ID=$4 and pcse1_0.CLIENT_STORAGE_PROVIDER=$5 for no key update of pcse1_0 skip locked
  update OFFLINE_CLIENT_SESSION set TIMESTAMP=$1,VERSION=$2 where CLIENT_ID=$3 and CLIENT_STORAGE_PROVIDER=$4 and EXTERNAL_CLIENT_ID=$5 and OFFLINE_FLAG=$6 and USER_SESSION_ID=$7 and VERSION=$8
  update OFFLINE_USER_SESSION set LAST_SESSION_REFRESH=$1,VERSION=$2 where OFFLINE_FLAG=$3 and USER_SESSION_ID=$4 and VERSION=$5
  SET LOCAL synchronous_commit TO OFF
  COMMIT
  DELETE from JGROUPS_PING WHERE address=$1
  INSERT INTO JGROUPS_PING (address, name, cluster_name, ip, coord, last_update, coordinated_by) values ($1, $2, $3, $4, $5, $6, $7)
  COMMIT
  DELETE from JGROUPS_PING WHERE address=$1
 === 그 sid 를 언급한 SQL — 누가 보냈는가 ===
  찾는 sid: jSt9GEPVQLJsO-1CeJjVgltg
 2026-09-04 01:12:32.851 UTC [81407] [keycloak-0] DETAIL:  parameters: $1 = '0', $2 = 'jSt9GEPVQLJsO-1CeJjVgltg'
 2026-09-04 01:12:32.852 UTC [81407] [keycloak-0] DETAIL:  parameters: $1 = '131a9912-b578-4b9c-b16a-97518704077e', $2 = 'local', $3 = 'local', $4 = '0', $5 = 'jSt9GEPVQLJsO-1CeJjVgltg'
 2026-09-04 01:12:32.860 UTC [81407] [keycloak-0] DETAIL:  parameters: $1 = '0', $2 = 'jSt9GEPVQLJsO-1CeJjVgltg'
 2026-09-04 01:12:32.862 UTC [81407] [keycloak-0] DETAIL:  parameters: $1 = '131a9912-b578-4b9c-b16a-97518704077e', $2 = 'local', $3 = 'local', $4 = '0', $5 = 'jSt9GEPVQLJsO-1CeJjVgltg'
 2026-09-04 01:12:32.863 UTC [81407] [keycloak-0] DETAIL:  parameters: $1 = NULL, $2 = '1788484352', $3 = '{"ipAddress":"10.42.1.50","authMethod":"openid-connect","rememberMe":false,"started":0,"notes":{"KC_DEVICE_NOTE":"
 2026-09-04 01:12:32.864 UTC [81407] [keycloak-0] DETAIL:  parameters: $1 = '{"authMethod":"openid-connect","notes":{"clientId":"131a9912-b578-4b9c-b16a-97518704077e","userSessionStartedAt":"1788484352","iss":"https://aut
 2026-09-04 01:12:34.934 UTC [81376] [keycloak-1] DETAIL:  parameters: $1 = '0', $2 = 'jSt9GEPVQLJsO-1CeJjVgltg'
 2026-09-04 01:12:34.936 UTC [81376] [keycloak-1] DETAIL:  parameters: $1 = 'jSt9GEPVQLJsO-1CeJjVgltg', $2 = '0'
 2026-09-04 01:12:34.937 UTC [81376] [keycloak-1] DETAIL:  parameters: $1 = '131a9912-b578-4b9c-b16a-97518704077e', $2 = 'local', $3 = 'local', $4 = '0', $5 = 'jSt9GEPVQLJsO-1CeJjVgltg'
 2026-09-04 01:12:34.938 UTC [81376] [keycloak-1] DETAIL:  parameters: $1 = 'jSt9GEPVQLJsO-1CeJjVgltg', $2 = '0', $3 = '131a9912-b578-4b9c-b16a-97518704077e', $4 = 'local', $5 = 'local'
 2026-09-04 01:12:34.944 UTC [81376] [keycloak-1] DETAIL:  parameters: $1 = '1788484354', $2 = '1', $3 = '131a9912-b578-4b9c-b16a-97518704077e', $4 = 'local', $5 = 'local', $6 = '0', $7 = 'jSt9GEPVQLJsO-1CeJjVgltg', $8 = 
 2026-09-04 01:12:34.946 UTC [81376] [keycloak-1] DETAIL:  parameters: $1 = '1788484354', $2 = '1', $3 = '0', $4 = 'jSt9GEPVQLJsO-1CeJjVgltg', $5 = '0'
 === 요약: 파드별 질의 건수 ===
        6 [keycloak-1]
        6 [keycloak-0]
@@ -0,0 +1,26 @@
 # 실험 0 — 세션 복제 증거
 수집: 2026-09-04 09:54 KST · Keycloak 26 / Infinispan 16.0.12 / PostgreSQL 16
 해설: [`docs/experiment-00-session-replication.md`](../../experiment-00-session-replication.md)
 | 파일 | 무엇을 보여주는가 |
 |---|---|
 | `01-cross-node-session.txt` | 클러스터 2멤버 확인 → keycloak-0 로그인 → 같은 sid 가 양쪽에서 보임 → **keycloak-1 이 refresh 성공(200)** → keycloak-1 로그아웃 → **keycloak-0 갱신 실패(400)** → DB 행 삭제 확인 |
 | `02-cache-delta.txt` | 로그인 하나를 사이에 둔 양쪽 노드의 캐시 계수기. **keycloak-1 은 전부 +0** |
 | `03-cache-ownership.txt` | 로그인을 반대편에 몰아준 결과. **요청을 받은 노드에서만 엔트리가 는다.** 캐시 합 7+5 = DB 12 |
 | `session-cache-entries-per-pod.png` | 위 사실의 시계열. 파란 선(keycloak-1)이 0에 붙어 있는 동안 초록 선(keycloak-0)만 14까지 오른다 |
 | `keycloak-admin-sessions.png` | 관리 콘솔의 Sessions 화면. 브라우저는 nginx→Traefik 을 거쳐 두 파드 중 하나에 닿지만 **어느 파드가 만든 세션이든 전부 보인다** |
 ## 핵심 한 줄
 클러스터는 형성되지만 **세션 엔트리는 노드를 건너가지 않는다.**
 두 노드가 같은 답을 하는 이유는 Infinispan 복제가 아니라 **같은 PostgreSQL** 이다.
 | 파일 | 무엇을 보여주는가 |
 |---|---|
 | `04-read-path-sql.txt` | PostgreSQL 문장 로깅으로 잡은 **keycloak-1 이 실제로 날린 SQL**. `SELECT ... FROM OFFLINE_USER_SESSION` 로 남의 세션을 읽고 `UPDATE ... where VERSION=$5` 로 쓴다. 같은 트랜잭션에 `SET LOCAL synchronous_commit TO OFF` 가 들어 있다 |
 ## 추론이 관측이 된 지점
 0b·0c 는 "keycloak-1 메모리에 없는데 쓸 수 있으니 DB 에서 읽었을 것"이라는
 **추론**이었다. 0d 에서 그 SQL 을 파드 IP 와 함께 직접 잡았다.
@@ -0,0 +1,34 @@
 수집 시각: 2026-09-03 15:01:30 KST
 대상: https://app1.hyeonworks.com/api/echo
 === [1] 호스트 nginx 가 주입하는 헤더 ===
 3:	server 192.168.122.11:80;
 4:	server 192.168.122.12:80;
 8:	listen 80 default_server;
 14:	listen 443 ssl default_server;
 26:		proxy_set_header Host			$host;
 27:		proxy_set_header X-Forwarded-Host	$host;
 28:		proxy_set_header X-Forwarded-Proto	http;
 29:		proxy_set_header X-Forwarded-Port	80;
 30:		proxy_set_header X-Forwarded-For	$remote_addr;
 31:		proxy_set_header X-Real-IP		$remote_addr;
 === [2] Traefik entryPoint 인자 (forwardedHeaders 부재 확인) ===
 ["--entryPoints.metrics.address=:9100/tcp"
 "--entryPoints.traefik.address=:8080/tcp"
 "--entryPoints.web.address=:8000/tcp"
 "--entryPoints.websecure.address=:8443/tcp"
 "--metrics.prometheus.entrypoint=metrics"
 "--entryPoints.websecure.http.tls=true"
  → forwardedHeaders.trustedIPs 인자가 없음 = 기본값(신뢰 안 함)
 === [3] Traefik 파드 수와 위치 ===
 traefik-59b7647586-ftwf8   10.42.0.8   kc-lab-1
 === [4] traefik Service externalTrafficPolicy ===
 Cluster
  → Cluster = svclb 가 SNAT 하여 클라이언트 IP 소실
 === [5] 앱 파드의 스위치 상태 ===
 SERVER_PORT=8081
 SERVER_FORWARD_HEADERS_STRATEGY=none
@@ -0,0 +1,87 @@
 수집 시각: 2026-09-03 15:02:27 KST
 === [A] 정상 경로 — 브라우저와 같은 요청 ===
 명령: curl -s https://app1.hyeonworks.com/api/echo
  x-forwarded-proto    http
  x-forwarded-port     80
  x-forwarded-for      10.42.0.1
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            10.42.0.1
  x-forwarded-server   traefik-59b7647586-ftwf8
  --- 앱이 해석한 값        
  scheme               http
  secure               False
  serverName           app1.hyeonworks.com
  serverPort           80
  remoteAddr           10.42.0.8
  localAddr            10.42.1.3
  requestUrl           http://app1.hyeonworks.com/api/echo
 === [B] 대조 실험 1 — nginx 우회, 헤더 없이 Traefik 직접 ===
 명령: curl http://192.168.122.11/api/echo -H 'Host: app1.hyeonworks.com'   (test-server 에서)
  x-forwarded-proto    http
  x-forwarded-port     80
  x-forwarded-for      10.42.0.1
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            10.42.0.1
  x-forwarded-server   traefik-59b7647586-ftwf8
  --- 앱이 해석한 값        
  scheme               http
  secure               False
  serverName           app1.hyeonworks.com
  serverPort           80
  remoteAddr           10.42.0.8
  localAddr            10.42.0.9
  requestUrl           http://app1.hyeonworks.com/api/echo
 === [C] 대조 실험 2 — nginx 우회, 올바른 헤더를 명시해서 ===
 명령: 위와 동일 + -H 'X-Forwarded-Proto: https' -H 'X-Forwarded-Port: 443' -H 'X-Forwarded-For: 203.0.113.7'
  x-forwarded-proto    http
  x-forwarded-port     80
  x-forwarded-for      10.42.0.1
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            10.42.0.1
  x-forwarded-server   traefik-59b7647586-ftwf8
  --- 앱이 해석한 값        
  scheme               http
  secure               False
  serverName           app1.hyeonworks.com
  serverPort           80
  remoteAddr           10.42.0.8
  localAddr            10.42.1.3
  requestUrl           http://app1.hyeonworks.com/api/echo
  ★ [C] 에서 https/443/203.0.113.7 을 명시했음에도 http/80/10.42.0.1 이 도달했다.
    → Traefik 이 들어온 X-Forwarded-* 를 신뢰하지 않고 재작성한다는 독립적 증거.
 === [D] 위조 테스트 — 클라이언트가 직접 헤더 주입 ===
 명령: curl https://app1.hyeonworks.com/api/echo -H 'X-Forwarded-Host: evil.example.com' -H 'X-Forwarded-For: 1.2.3.4'
  x-forwarded-proto    http
  x-forwarded-port     80
  x-forwarded-for      10.42.1.0
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            10.42.1.0
  x-forwarded-server   traefik-59b7647586-ftwf8
  --- 앱이 해석한 값        
  scheme               http
  secure               False
  serverName           app1.hyeonworks.com
  serverPort           80
  remoteAddr           10.42.0.8
  localAddr            10.42.0.9
  requestUrl           http://app1.hyeonworks.com/api/echo
  ★ evil.example.com 과 1.2.3.4 가 도달하지 않았다 = 신뢰 경계는 작동.
 === [E] 파드 분배 8회 ===
  pod 10.42.1.3 | traefik traefik-59b7647586-ftwf8
  pod 10.42.0.9 | traefik traefik-59b7647586-ftwf8
  pod 10.42.1.3 | traefik traefik-59b7647586-ftwf8
  pod 10.42.0.9 | traefik traefik-59b7647586-ftwf8
  pod 10.42.1.3 | traefik traefik-59b7647586-ftwf8
  pod 10.42.0.9 | traefik traefik-59b7647586-ftwf8
  pod 10.42.1.3 | traefik traefik-59b7647586-ftwf8
  pod 10.42.0.9 | traefik traefik-59b7647586-ftwf8
 === [F] HTTP → HTTPS 리다이렉트 ===
  status=301  location=https://app1.hyeonworks.com/api/echo
@@ -0,0 +1,55 @@
 수집 시각: 2026-09-03 15:32:04 KST
 단계: A(nginx) + B(Traefik) + C(앱) 모두 적용 후
 === [1] nginx 가 보내는 값 ===
 28:		proxy_set_header X-Forwarded-Proto	https;
 29:		proxy_set_header X-Forwarded-Port	443;
 30:		proxy_set_header X-Forwarded-For	$remote_addr;
 31:		proxy_set_header X-Real-IP		$remote_addr;
 === [2] Traefik entryPoint 인자 ===
 "--entryPoints.web.forwardedHeaders.trustedIPs=10.42.0.0/16
 "--entryPoints.websecure.forwardedHeaders.trustedIPs=10.42.0.0/16
 === [3] 앱 스위치 ===
 SERVER_FORWARD_HEADERS_STRATEGY=native
 === [4] 최종 측정 ===
  x-forwarded-proto    https
  x-forwarded-port     443
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            100.123.124.30
  x-forwarded-server   traefik-697889c85-g7xpp
  --- 앱이 해석한 값        
  scheme               https
  secure               True
  serverName           app1.hyeonworks.com
  serverPort           443
  remoteAddr           100.123.124.30
  localAddr            10.42.0.10
  requestUrl           https://app1.hyeonworks.com/api/echo
 === [5] 위조 테스트 — 클라이언트가 http/evil/1.2.3.4 를 주입 ===
  x-forwarded-proto    https
  x-forwarded-port     443
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            100.123.124.30
  x-forwarded-server   traefik-697889c85-g7xpp
  --- 앱이 해석한 값        
  scheme               https
  secure               True
  serverName           app1.hyeonworks.com
  serverPort           443
  remoteAddr           100.123.124.30
  localAddr            10.42.1.6
  requestUrl           https://app1.hyeonworks.com/api/echo
  ★ 주입값이 하나도 반영되지 않았다. nginx 의 $remote_addr 덮어쓰기가 방어한다.
 === [6] 파드 분배 6회 ===
  pod 10.42.0.10 | remoteAddr 100.123.124.30 | scheme https
  pod 10.42.1.6 | remoteAddr 100.123.124.30 | scheme https
  pod 10.42.0.10 | remoteAddr 100.123.124.30 | scheme https
  pod 10.42.1.6 | remoteAddr 100.123.124.30 | scheme https
  pod 10.42.0.10 | remoteAddr 100.123.124.30 | scheme https
  pod 10.42.1.6 | remoteAddr 100.123.124.30 | scheme https
@@ -0,0 +1,48 @@
 수집 시각: 2026-09-03 16:16:48 KST
 주제: 프록시 우회 경로 차단 (NetworkPolicy)
 === [1] 차단 전 — 클러스터 안에서 앱에 직접 요청 ===
 명령: kubectl run ... -- curl http://echo:8081/api/echo \
        -H 'X-Forwarded-Proto: https' -H 'X-Forwarded-Host: evil.example.com' -H 'X-Forwarded-For: 1.2.3.4'
  scheme       https
  secure       True
  serverName   evil.example.com      ← 위조 성공
  remoteAddr   1.2.3.4               ← 위조 성공
  requestUrl   https://evil.example.com/api/echo
  ★ Traefik 을 거치지 않으면 헤더 위조가 그대로 통한다.
    trustedIPs 와 internalProxies 가 둘 다 '대역'을 믿기 때문.
 === [2] 적용한 것 ===
  deploy/lab/k8s/traefik-forwarded-headers.yaml  — 192.168.122.0/24 제거
    "--entryPoints.web.forwardedHeaders.trustedIPs=10.42.0.0/16"
    "--entryPoints.websecure.forwardedHeaders.trustedIPs=10.42.0.0/16"
  deploy/lab/k8s/echo-network-policy.yaml        — Traefik 파드에서만 8081 허용
 [{"from":[{"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"kube-system"}},"podSelector":{"matchLabels":{"app.kubernetes.io/name":"traefik"}}}],"ports":[{"port":8081,"protocol":"TCP"}]},{"from":[{"ipBlock":{"cidr":"10.42.0.1/32"}},{"ipBlock":{"cidr":"10.42.1.1/32"}}],"ports":[{"port":8081,"protocol":"TCP"}]}]
 === [3] 차단 후 — 정상 경로 (계속 동작해야 함) ===
  x-forwarded-proto    https
  x-forwarded-port     443
  x-forwarded-host     app1.hyeonworks.com
  x-real-ip            100.123.124.30
  x-forwarded-server   traefik-5d6fcf895-wpfhr
  --- 앱이 해석한 값        
  scheme               https
  secure               True
  serverName           app1.hyeonworks.com
  serverPort           443
  remoteAddr           100.123.124.30
  localAddr            10.42.0.14
  requestUrl           https://app1.hyeonworks.com/api/echo
 === [4] 차단 후 — 우회 시도 ===
  HTTP 000 / curl exit 7
  HTTP 000 / curl exit 7
  ★ curl exit 7 = Failed to connect. 연결 자체가 성립하지 않는다.
 === [5] 파드 건강 상태 (probe 가 차단되지 않았는지) ===
  echo-54dbd94986-8jmdb 1/1 Running restarts=0
  echo-54dbd94986-lfltk 1/1 Running restarts=0
@@ -0,0 +1,199 @@
 # 증거 — 2홉 프록시 헤더 계약 (수정 전 상태)
 `docs/two-hop-proxy-header-contract.md`의 진단을 뒷받침하는 원자료.
 **모두 수정 전 상태에서 수집**했으며, 수정 후 재수집하여 대조한다.
 수집 시각: 2026-09-03 15:01~15:03 KST
 | 파일 | 내용 |
 |---|---|
 | `01-environment.txt` | 수정 전 세 계층의 설정 스냅샷 |
 | `02-measurements.txt` | 수정 전 측정 · 대조 실험 · 위조 테스트 · 분배 |
 | `stage-a-nginx-fixed.png` | A 단계 브라우저 화면 |
 | `stage-b-traefik-trusts.png` | B 단계 브라우저 화면 |
 | `stage-c-resolved.png` | C 단계 브라우저 화면 |
 | `04-after-fix.txt` | 수정 후 측정 · 위조 테스트 · 분배 |
 ---
 ## 확인된 문제는 둘이다
 최초 진단은 "Traefik이 덮어쓴다" 하나였으나, 증거 수집 과정에서
 **독립된 원인이 두 개**임이 드러났다.
 ### 문제 1 — nginx가 애초에 틀린 값을 보낸다
 `01-environment.txt`
 ```
 26:  proxy_set_header Host              $host;
 27:  proxy_set_header X-Forwarded-Host  $host;
 28:  proxy_set_header X-Forwarded-Proto http;     ← https 여야 한다
 29:  proxy_set_header X-Forwarded-Port  80;       ← 443 이어야 한다
 30:  proxy_set_header X-Forwarded-For   $remote_addr;
 31:  proxy_set_header X-Real-IP         $remote_addr;
 ```
 `listen 443 ssl` 서버 블록 안인데 `X-Forwarded-Proto`가 `http`다.
 TLS를 종료하는 서버가 "원래 요청은 평문이었다"고 알리고 있다.
 HTTP 전용으로 먼저 세운 뒤 TLS를 얹는 과정에서 **이 두 줄을 함께 바꾸지
 않아 남은 값**이다. 설정 자체는 문법 오류가 없으므로 `nginx -t`도 통과하고,
 **아무 경고 없이 잘못된 값이 전파된다.**
 ### 문제 2 — Traefik이 올바른 값이 와도 덮어쓴다
 `02-measurements.txt`의 **대조 실험 [C]** 가 이를 독립적으로 증명한다.
 nginx를 우회해 Traefik에 직접 요청하면서 올바른 헤더를 명시했다.
 ```
 보낸 것 :  X-Forwarded-Proto: https
           X-Forwarded-Port:  443
           X-Forwarded-For:   203.0.113.7
 도달한 것: x-forwarded-proto  http
           x-forwarded-port   80
           x-forwarded-for    10.42.0.1
 ```
 **세 값 모두 재작성됐다.** Traefik entryPoint에
 `forwardedHeaders.trustedIPs`가 설정되지 않아 들어온 헤더를 신뢰하지 않는다.
 `01-environment.txt`의 Traefik 인자 목록에 `forwardedHeaders` 관련 항목이
 하나도 없는 것이 그 근거다.
 **문제 1만 고쳐서는 해결되지 않는다.** 두 원인이 직렬로 걸려 있다.
 ---
 ## 브라우저 증거
 스크린샷은 모두 **브라우저가 `/api/echo` 응답을 렌더링한 실제 화면**이다.
 앱이 정렬된 JSON을 내보내도록 `spring.jackson.serialization.indent-output`을
 켜두었으므로 브라우저의 JSON 뷰어 설정과 무관하게 동일하게 읽힌다.
 세 장은 **같은 요청을 세 가지 설정 상태에서** 찍은 것이다.
 | 파일 | 켜진 스위치 | 화면에서 확인할 것 |
 |---|---|---|
 | `stage-a-nginx-fixed.png` | nginx 만 | `x-forwarded-proto: http` — Traefik 이 덮어씀 |
 | `stage-b-traefik-trusts.png` | nginx + Traefik | **헤더는 `https`인데 `scheme: http`** |
 | `stage-c-resolved.png` | 셋 다 | `scheme: https`, `secure: true` |
 **`stage-b`가 가장 중요한 한 장이다.** `x-forwarded-proto: https`가 앱에
 도착해 있는데도 `scheme: http`, `secure: false`, `requestUrl: http://...`다.
 **헤더가 도착하는 것과 앱이 그것을 읽는 것은 다른 문제**임을 한 화면이
 보여준다.
 ## 정상으로 확인된 것
 증거 수집에서 **문제가 아니라고 확인된 항목**도 함께 남긴다.
 | 항목 | 결과 |
 |---|---|
 | TLS 종료 | 정상. 실인증서, `isSecureContext=true` |
 | `X-Forwarded-Host` | 유지됨 — Traefik이 이것만은 덮어쓰지 않는다 |
 | 위조 차단 | 클라이언트가 넣은 `evil.example.com`, `1.2.3.4`가 앱에 도달하지 않음 |
 | 파드 분배 | 8회 요청이 두 파드에 정확히 번갈아 도달 |
 | HTTP 리다이렉트 | `301 → https://app1.hyeonworks.com/api/echo` |
 **위조가 차단되는 것은 nginx가 막아서가 아니라 Traefik이 전부 덮어쓰기
 때문**이다. 문제 2를 고치면 이 방어가 nginx의 `$remote_addr` 덮어쓰기로
 옮겨간다. 수정 후 재측정에서 **위조가 여전히 막히는지 반드시 확인**해야 한다.
 ---
 ## 재수집 방법
 ```bash
 # 터미널 증거
 ./deploy/lab/scripts/measure-proxy-headers.sh
 # 개별 확인
 curl -s https://app1.hyeonworks.com/api/echo | python3 -m json.tool
 # 대조 실험 (test-server 에서, nginx 우회)
 curl -s http://192.168.122.11/api/echo \
  -H 'Host: app1.hyeonworks.com' \
  -H 'X-Forwarded-Proto: https' -H 'X-Forwarded-Port: 443' \
  -H 'X-Forwarded-For: 203.0.113.7' | python3 -m json.tool
 ```
 ---
 ## 수정 후 (2026-09-03 15:32 KST)
 세 스위치를 순서대로 켜며 각 단계를 측정했다. 상세 절차는
 `docs/two-hop-proxy-header-contract.md` 9~11절.
 | 파일 | 단계 |
 |---|---|
 | `stage-a-nginx-fixed.png` | A — nginx 만 고침 |
 | `stage-b-traefik-trusts.png` | B — Traefik `trustedIPs` 추가 |
 | `stage-c-resolved.png` | C — 앱 `strategy=native` |
 | `04-after-fix.txt` | 최종 측정 · 위조 테스트 · 분배 |
 스크린샷은 브라우저가 `/api/echo` 응답을 렌더링한 **실제 화면**이다.
 ### 단계별 결과
 | 항목 | 최초 | A | B | C |
 |---|---|---|---|---|
 | `x-forwarded-proto` | `http` | **`http`** | `https` | `https` |
 | `x-real-ip` | `10.42.1.0` | `10.42.1.0` | `100.123.124.30` | `100.123.124.30` |
 | `scheme` (앱 해석) | `http` | `http` | **`http`** | **`https`** |
 | `requestUrl` | `http://…` | `http://…` | `http://…` | **`https://…`** |
 **A 이후 아무 변화가 없는 것**이 Traefik 덮어쓰기의 증거이고,
 **B 이후 헤더는 살아났으나 앱 해석은 그대로인 것**이 2번과 3번 스위치가
 다른 일을 한다는 증거다.
 ### 위조 차단 재확인
 `04-after-fix.txt` [5]. 클라이언트가 `X-Forwarded-Proto: http`,
 `X-Forwarded-Host: evil.example.com`, `X-Forwarded-For: 1.2.3.4`를 주입했으나
 **하나도 반영되지 않았다.**
 **방어 주체가 바뀌었다.** 수정 전에는 Traefik이 전부 덮어써서 막았고,
 수정 후에는 nginx의 `$remote_addr`가 막는다. 그래서 nginx에서
 `$proxy_add_x_forwarded_for`(덧붙이기)로 바꾸면 안 된다.
 ### 겪은 함정
 `kubectl rollout status`가 완료를 알려도 **helm-controller의 Job이 차트를
 업그레이드하는 동안 구 Traefik 파드가 함께 살아 있다.** 이 시점에 측정하면
 옛 파드가 응답해 "고쳤는데 안 바뀌었다"고 오해하게 된다. `x-forwarded-server`
 값의 파드 이름으로 어느 파드가 응답했는지 확인해야 한다.
 ---
 ## 프록시 우회 차단 (2026-09-03 16:16 KST)
 `05-networkpolicy.txt`
 헤더 신뢰를 켠 뒤 남아 있던 구멍을 실증하고 막았다.
 **차단 전** — 클러스터 안에서 Traefik을 우회해 앱에 직접 요청하면
 `serverName: evil.example.com`, `remoteAddr: 1.2.3.4`로 **위조가 성립했다.**
 **적용한 것**
 | 파일 | 변경 |
 |---|---|
 | `traefik-forwarded-headers.yaml` | `192.168.122.0/24` 제거 (SNAT 때문에 도달 불가한 대역) |
 | `echo-network-policy.yaml` | Traefik 파드에서만 8081 허용 (라벨 기준) |
 **차단 후**
 ```
 정상 경로   scheme=https, remoteAddr=100.123.124.30    동작
 우회 시도   HTTP 000 / curl exit 7                      연결 거부
 파드 상태   1/1 Running, restarts=0                     probe 정상
 ```
 `exit 7`은 curl의 "Failed to connect"다. HTTP 403이 아니라
 **TCP 연결 자체가 성립하지 않았다**는 뜻이다.
 `restarts=0`이 중요하다. NetworkPolicy에서 kubelet probe 경로를 빠뜨리면
 probe가 실패해 파드가 재시작 루프에 빠진다. 노드의 cni0 주소
 (`10.42.0.1`, `10.42.1.1`)를 `/32`로 허용해 이를 피했다.
@@ -0,0 +1,636 @@
 # 실험 0 — 한 노드에서 만든 세션이 다른 노드에서 쓰이는가
 로드맵 A-0. 이후 모든 장애 실험의 기준선이다.
 > **맥락이 안 잡히면 먼저 읽을 것** —
 > [`docs/session-lab-prerequisites.md`](session-lab-prerequisites.md).
 > 왜 세션이 문제가 되는지, Keycloak이 세션을 어디에 두는지, 그래서 이 실험이
 > 무엇을 가르려는 것인지를 바닥부터 세워둔 문서다.
 - 실행 스크립트 — [`deploy/lab/scripts/experiment-session-replication.sh`](../deploy/lab/scripts/experiment-session-replication.sh),
  [`experiment-cache-replication-delta.sh`](../deploy/lab/scripts/experiment-cache-replication-delta.sh),
  [`experiment-cache-ownership.sh`](../deploy/lab/scripts/experiment-cache-ownership.sh),
  [`experiment-session-read-path.sh`](../deploy/lab/scripts/experiment-session-read-path.sh)
 - 증거 — [`docs/evidence/session-replication/`](evidence/session-replication/)
 - 수집 시각 — 2026-09-04 09:54 KST, Keycloak 26 / Infinispan 16.0.12 / PostgreSQL 16
 ---
 ## 0. 결론부터
 | 물음 | 답 |
 |---|---|
 | 한 노드에서 만든 세션을 다른 노드가 쓸 수 있는가 | **그렇다** |
 | 로그아웃이 반대 방향으로 전파되는가 | **그렇다** |
 | **그 공유는 Infinispan 복제 덕분인가** | **아니다** |
 | 그럼 무엇이 공유하는가 | **PostgreSQL** — 반대편 노드가 날린 SQL을 직접 잡았다 |
 **클러스터가 형성됐다는 것과 세션이 복제된다는 것은 다른 얘기였다.**
 로그에는 `(2) [keycloak-0, keycloak-1]`이 찍히고 `JGROUPS_PING`에도 둘 다
 등록되어 있지만, **세션 엔트리는 노드 사이를 건너가지 않는다.**
 각 노드는 **자기가 처리한 로그인만** 캐시한다. 두 노드가 같은 답을 내놓는
 이유는 복제가 아니라 **같은 데이터베이스를 보기 때문**이다.
 ---
 ## 1. 왜 이 실험이 첫 번째인가
 앞선 작업에서 Keycloak 2노드 클러스터를 세우고 `ISPN000094`로 멤버 2개를
 확인했다. 거기서 멈추면 **"클러스터가 떴다"까지만 아는 것**이고, 그 위에서
 장애를 주입해봐야 무엇이 무엇 때문에 깨졌는지 해석할 수 없다.
 기준선이 없으면 이런 잘못된 추론을 하게 된다.
 > 7800을 막았더니 세션이 깨졌다 → 역시 세션은 7800으로 복제되는구나
 실제로는 7800으로 세션이 오가지 않는다는 것을 **먼저** 알아야, 7800을 막았을
 때 깨지는 것이 무엇인지 정확히 말할 수 있다.
 ---
 ## 2. 실험 설계에서 배운 것 세 가지
 측정값보다 **어떻게 측정할지**에서 더 많이 틀렸다. 세 번 고쳤다.
 ### 2-1. 대조군 없는 측정은 해석할 수 없다
 첫 판본은 이렇게 보고했다.
 ```
 === [4] keycloak-0 이 발급한 토큰을 keycloak-1 이 받는가 ===
  http_code=403
 ```
 **403을 "복제 실패"로 읽을 뻔했다.** 발급 노드에도 같은 요청을 보내보니
 ```
 --- userinfo, scope 없음 ---
  k0(발급노드) 403
  k1(반대편)   403
 --- 403 본문 ---
 WWW-Authenticate: Bearer realm="master", error="insufficient_scope",
                  error_description="Missing openid scope"
 ```
 **양쪽 다 403이었다.** 원인은 복제가 아니라 요청에 `openid` scope가 없다는
 것이었다. 오히려 **두 노드가 똑같이 답했다는 사실 자체가 일치의 증거**였다.
 > **원칙** — 반대편 노드의 응답은 발급 노드의 응답과 나란히 놓기 전까지
 > 아무 의미가 없다. 시험군만 재는 측정은 측정이 아니다.
 ### 2-2. 개수가 아니라 식별자로 추적한다
 `client-session-stats`가 `active=2`를 돌려줬다. 그런데 스크립트 자체가
 로그인을 두 번 하고(시험용 + 관리 API 호출용) 있었다. **개수는 실험 도구가
 만든 잡음에 그대로 오염된다.**
 바꾼 방식: 토큰의 `sid`를 뽑아, 각 노드의 세션 목록에 **그 sid가 있는지**를
 본다. 개수가 몇이든 상관없다.
 ```
  keycloak-0 (발급 노드)       세션 2개 중 대상 sid → 보임 ✔
  keycloak-1 (반대편)         세션 2개 중 대상 sid → 보임 ✔
 ```
 ### 2-3. 세션 저장소를 실제로 건드리는 탐침을 골라야 한다
 | 탐침 | 하는 일 | 적합한가 |
 |---|---|---|
 | `userinfo` | 서명 검증 + scope 확인 | **아니다.** 세션을 몰라도 통과할 수 있다 |
 | **`refresh_token` 그랜트** | 세션을 찾고, 살아있는지 보고, 갱신 시각을 쓴다 | **그렇다** |
 refresh는 **읽고 쓴다.** 그래서 "저 노드가 이 세션을 정말로 아는가"에 답한다.
 여기에 더해 refresh token은 **회전(rotation)** 된다 — 한 번 쓰면 옛 것이
 무효가 된다. 따라서 **반대편 노드에 먼저 써야** 한다. 발급 노드에 먼저 쓰면
 시험군에 쓸 토큰이 사라진다. 대조군과 시험군의 순서가 강제된다.
 ---
 ## 3. 실험 0 — 교차 노드 세션 사용
 ### 실행
 ```bash
 kubectl -n keycloak-lab exec deploy/postgres -- \
  psql -U keycloak -d keycloak -c "delete from offline_user_session"
 kubectl -n keycloak-lab rollout restart statefulset/keycloak    # 캐시를 비운다
 ./deploy/lab/scripts/experiment-session-replication.sh
 ```
 nginx나 Traefik을 거치지 않고 **파드 IP로 직접** 말을 건다. 로드밸런서를
 거치면 어느 노드가 처리했는지가 감춰지는데, 그게 바로 이 실험의 질문이다.
 ### 결과 — [`01-cross-node-session.txt`](evidence/session-replication/01-cross-node-session.txt)
 ```
 ### 사전 확인: 클러스터가 2 멤버로 형성되었는가
 ISPN000094: Received new cluster view for channel ISPN:
  [keycloak-1-48749(v=16.0.12)|5] (2) [keycloak-1-48749, keycloak-0-30843]
       name       |       ip        | coord
 ------------------+-----------------+-------
 keycloak-1-48749 | 10.42.0.35:7800 | t
 keycloak-0-30843 | 10.42.1.43:7800 | f
 === 대상 ===
  keycloak-0  10.42.1.43     kc-lab-2
  keycloak-1  10.42.0.35     kc-lab-1
 === [1] keycloak-0 에서 로그인 ===
  sid          jiv3rVZi1VeaO07oVJkL_MYW
  iss          https://auth.hyeonworks.com/realms/master
  access 수명  60초
  refresh 수명 1800초   typ=Refresh
 === [3] 같은 sid 가 두 노드 모두에서 보이는가 ===
  keycloak-0 (발급 노드)       세션 2개 중 대상 sid → 보임 ✔
  keycloak-1 (반대편)         세션 2개 중 대상 sid → 보임 ✔
 === [5] keycloak-0 이 발급한 refresh token 을 keycloak-1 에 사용 ===
  HTTP 200   ← 기대대로
  새 토큰의 sid → 동일 ✔
 === [6] keycloak-1 을 통해 로그아웃 ===
  http_code=204
 === [7] 로그아웃 후 keycloak-0 에서 갱신 시도 (무효화 전파) ===
  HTTP 400   ← 기대대로
  error             invalid_grant
  error_description Session not active
 === [8] PostgreSQL 에서 그 sid 를 직접 확인 ===
  행 없음 — 로그아웃으로 삭제되었다
 ```
 **네 가지가 모두 기대대로다.**
 | | 확인된 것 |
 |---|---|
 | 조회 | 같은 sid가 양쪽에서 보인다 |
 | **쓰기** | keycloak-0의 refresh token을 keycloak-1이 받아 갱신했고, **sid가 유지된다** |
 | **역방향 무효화** | keycloak-1의 로그아웃이 keycloak-0의 갱신을 막았다 |
 | 영속 | 로그아웃과 함께 DB 행이 사라졌다 |
 **`sid`는 JWT 안에만 있는 값이 아니다.** PostgreSQL의
 `OFFLINE_USER_SESSION.user_session_id` 컬럼에 **문자 그대로** 들어 있다.
 ---
 ## 4. 실험 0b — 복제인가, 같은 DB를 본 것인가
 실험 0은 "두 노드가 같은 답을 한다"까지만 증명한다. **그것으로는 Infinispan이
 복제했다고 말할 수 없다.** `persistent-user-sessions`(Keycloak 26 기본값)에서는
 세션이 PostgreSQL에 기록되므로, **캐시를 아예 꺼도 두 노드는 같은 답을 한다.**
 가르는 방법: 로그인 한 번을 사이에 두고 **양쪽 노드의 캐시 계수기**를 잰다.
 ### 결과 — [`02-cache-delta.txt`](evidence/session-replication/02-cache-delta.txt)
 ```
 === 로그인은 keycloak-0 에만 보냈다 ===
  로그인 응답: http_code=200
 === keycloak-0 (로그인을 받은 노드) ===
  계수기                                        캐시                     전        후      증가
  approximate_entries_unique                 sessions               1        2      +1  ←
  stores                                     sessions               2        3      +1  ←
  misses                                     sessions               3        4      +1  ←
  rpc.replication_count                      sessions               1        1      +0
 === keycloak-1 (아무 요청도 받지 않은 노드) ===
  approximate_entries_unique                 sessions               0        0      +0
  stores                                     sessions               1        1      +0
  hits                                       sessions               4        4      +0
  rpc.replication_count                      sessions               7        7      +0
 ```
 **keycloak-1의 계수기가 하나도 움직이지 않았다.** 엔트리도 0, 저장도 0.
 그리고 keycloak-1의 `sessions` 캐시 엔트리는 **처음부터 끝까지 0**이다.
 keycloak-0이 세션을 9개 들고 있는 동안에도 0이었다.
 ---
 ## 5. 실험 0c — 엔트리는 어느 노드에 있는가
 0b의 결과에는 두 가지 설명이 가능하다.
 | | |
 |---|---|
 | (a) **분산 캐시 + owners=1** | 일관 해싱으로 흩어지는데 이번 건이 우연히 keycloak-0에 떨어졌다 |
 | (b) **로컬 캐시** | 각 노드는 자기가 처리한 것만 캐시한다 |
 **반대편 노드에 로그인을 몰아주면 갈린다.** (a)라면 어느 쪽에 요청하든 엔트리는
 양쪽에 흩어진다. (b)라면 **요청을 받은 노드에서만** 는다.
 ### 결과 — [`03-cache-ownership.txt`](evidence/session-replication/03-cache-ownership.txt)
 ```
 단계                             k0 entries   k1 entries
 시작                                    2.0          0.0
 keycloak-1 에 로그인 5회             2.0          5.0      ← k0 그대로, k1 만 +5
 keycloak-0 에 로그인 5회             7.0          5.0      ← k0 만 +5, k1 그대로
 === 대조: PostgreSQL 에는 몇 건인가 ===
  online 세션 12                                            ← 7 + 5 = 12, 정확히 일치
 ```
 **(b)다.** 그리고 **7 + 5 = 12**로 DB 총계와 정확히 맞는다 — 모든 세션이 DB에
 있고, 각각은 **자기를 만든 노드 한 곳에만** 캐시되어 있다.
 ### 그래프로 본 같은 사실
 ![세션 캐시 엔트리 수](evidence/session-replication/session-cache-entries-per-pod.png)
 `vendor_statistics_approximate_entries_unique{cache="sessions"}` — Grafana Explore.
 **파란 선(keycloak-1)이 0에 붙어 있는 동안 초록 선(keycloak-0)만 14까지
 올라간다.** 파란 선은 09:50, 즉 **keycloak-1에 직접 로그인을 보낸 순간에만**
 5로 뛴다. 중간의 절벽은 캐시를 비우려고 파드를 재시작한 지점이다.
 > 캐시 설정은 파일에서 읽을 수 없다. 파드의 `/opt/keycloak/conf/cache-ispn.xml`은
 > `<cache-container name="keycloak"><transport/></cache-container>` 뿐이고,
 > Keycloak 26은 캐시를 **코드에서** 만든다. 그래서 위 결론은 설정을 읽어서가
 > 아니라 **동작을 측정해서** 얻었다.
 ---
 ## 6. 실험 0d — 반대편 노드가 정말 DB에서 읽는가
 0b·0c까지는 **추론**이었다. "keycloak-1의 메모리에 없는데 쓸 수 있으니 DB에서
 읽었을 것이다" — 그럴듯하지만 **SQL을 본 적은 없다.**
 PostgreSQL의 문장 로깅을 몇 초만 켜고, keycloak-0에서 만든 세션에 대해
 **keycloak-1에 refresh를 딱 한 번** 보낸 뒤 로그를 뒤졌다.
 ```bash
 alter system set log_statement='all';
 alter system set log_line_prefix='%m [%p] %h ';   -- %h 로 파드 IP 를 남긴다
 select pg_reload_conf();
 ```
 ### 잡힌 트랜잭션 — [`04-read-path-sql.txt`](evidence/session-replication/04-read-path-sql.txt)
 ```
 01:12:34.934 pid=81376 | BEGIN
 01:12:34.934 pid=81376 | select ... from OFFLINE_USER_SESSION where (OFFLINE_FLAG,USER_SESSION_ID) in (($1,$2))
 01:12:34.936 pid=81376 | select VERSION from OFFLINE_USER_SESSION   ... for no key update skip locked
 01:12:34.937 pid=81376 | select ... from OFFLINE_CLIENT_SESSION where (...) in ((...))
 01:12:34.938 pid=81376 | select VERSION from OFFLINE_CLIENT_SESSION ... for no key update skip locked
 01:12:34.944 pid=81376 | update OFFLINE_CLIENT_SESSION set TIMESTAMP=$1,VERSION=$2 where ... and VERSION=$8
 01:12:34.946 pid=81376 | update OFFLINE_USER_SESSION   set LAST_SESSION_REFRESH=$1,VERSION=$2 where ... and VERSION=$5
 01:12:34.946 pid=81376 | SET LOCAL synchronous_commit TO OFF
 01:12:34.947 pid=81376 | COMMIT
 ```
 이 연결의 클라이언트 IP는 `10.42.0.35` — **keycloak-1의 파드 IP**다.
 sid 하나에 대해 keycloak-0이 6건(로그인), keycloak-1이 6건(갱신)을 날렸다.
 ```
 === 요약: 파드별 질의 건수 ===
        6 [keycloak-1]
        6 [keycloak-0]
 ```
 **추론이 관측이 되었다.** keycloak-1은 세션을 DB에서 읽고, DB에 쓴다.
 ### 여기서 딸려 나온 것 세 가지
 이 13밀리초짜리 트랜잭션 하나에 **원래 질문들의 답이 절반쯤 들어 있다.**
 #### (1) 낙관적 락 — `VERSION` 컬럼
 ```sql
 update OFFLINE_USER_SESSION
   set LAST_SESSION_REFRESH=$1, VERSION=$2
 where OFFLINE_FLAG=$3 and USER_SESSION_ID=$4 and VERSION=$5
                                              ─────────────
                                              읽을 때의 버전과 같을 때만 쓴다
 ```
 읽은 뒤 다른 노드가 먼저 고쳤다면 `VERSION`이 달라져 **`UPDATE`가 0행을
 갱신하고 실패한다.** 잠금을 오래 잡지 않고 충돌을 사후에 검출하는 방식이다.
 **리프레시 토큰 동시 갱신 경쟁(로드맵 B-5)이 여기서 갈린다.** 두 요청이
 같은 세션을 동시에 갱신하면 하나는 이 검사에서 진다.
 #### (2) `FOR NO KEY UPDATE ... SKIP LOCKED`
 ```sql
 select VERSION from OFFLINE_USER_SESSION
 where USER_SESSION_ID=$1 and OFFLINE_FLAG=$2
   for no key update of puse1_0 skip locked
       ──────────────         ────────────
       키가 아닌 컬럼만 잠근다  잠긴 행은 건너뛴다 (기다리지 않는다)
 ```
 | 절 | 뜻 |
 |---|---|
 | `FOR NO KEY UPDATE` | 행을 잠그되 **외래키 참조는 막지 않는다.** `FOR UPDATE`보다 약해 경합이 준다 |
 | **`SKIP LOCKED`** | 이미 잠긴 행을 **기다리지 않고 건너뛴다** |
 `SKIP LOCKED`가 핵심이다. 같은 세션에 동시 요청이 몰려도 **줄을 서지 않는다.**
 대기 대신 낙관적 락 실패로 처리한다 — 처리량을 위해 **지연 대신 재시도**를
 고른 설계다.
 #### (3) `SET LOCAL synchronous_commit TO OFF` — 내구성을 일부 포기한다
 **같은 트랜잭션 안에서**, `COMMIT` 직전에 나온다. pid로 경계를 확인했다.
 | | |
 |---|---|
 | 기본값 `on` | `COMMIT`이 **WAL이 디스크에 내려간 뒤** 돌아온다 |
 | **`off`** | **WAL 플러시를 기다리지 않고** 즉시 돌아온다 |
 **결과: PostgreSQL이 갑자기 죽으면 직전 수백 밀리초의 세션 갱신이 사라질 수
 있다.** 커밋했다고 응답해놓고 없어진다.
 Keycloak이 이걸 의도적으로 켠 이유는 명확하다 — `LAST_SESSION_REFRESH` 갱신은
 **초당 수백 번 일어나고, 몇백 밀리초쯤 잃어도 사용자가 다시 갱신하면 그만**이다.
 로그인·로그아웃 같은 것과 달리 잃어도 되는 쓰기다.
 > **DB 복구 실험(A-2)에서 그대로 관측될 지점이다.** PostgreSQL을 정상 종료가
 > 아니라 강제 종료시키면, 마지막 몇백 밀리초의 세션 갱신이 실제로 없어져야
 > 한다. 이건 버그가 아니라 **설계된 트레이드오프**다.
 ```bash
 kubectl -n keycloak-lab exec deploy/postgres -- \
  psql -U keycloak -d keycloak -c "show synchronous_commit"   # 전역 기본값은 on
 ```
 전역 설정은 `on`이고, **Keycloak이 세션 트랜잭션에만 `SET LOCAL`로 끈다.**
 `SET LOCAL`은 그 트랜잭션이 끝나면 되돌아간다.
 ### 덤: 캐시는 읽어도 채워지지 않는다
 ```
 K1_ENTRIES_BEFORE=5.0
 REFRESH_ON_K1=200
 K1_ENTRIES_AFTER=5.0      ← 갱신을 처리하고도 그대로
 ```
 **keycloak-1은 남의 세션을 DB에서 읽어 처리하고도 캐시에 담지 않았다.**
 0c에서 세운 모델 "각 노드는 자기가 처리한 것만 캐시한다"를 더 좁혀야 한다.
 > 캐시에 담기는 것은 **그 노드가 로그인시켜 만든 세션**뿐이다.
 > 남의 세션은 매번 DB에서 읽는다.
 로드밸런서가 세션을 만든 노드가 아닌 쪽으로 요청을 보내면 **매번 DB를 친다.**
 세션 어피니티(sticky session)가 정확성이 아니라 **성능** 문제인 이유가 이것이다.
 ### 덤 2: jdbc-ping 하트비트가 그대로 보인다
 ```
 01:12:37.551 pid=81369 | BEGIN
 01:12:37.551 pid=81369 | DELETE from JGROUPS_PING WHERE address=$1
 01:12:37.552 pid=81369 | INSERT INTO JGROUPS_PING (address, name, cluster_name, ip, coord, last_update, coordinated_by) values (...)
 01:12:37.553 pid=81369 | COMMIT
 ```
 **디스커버리는 별도 연결(pid=81369)에서 주기적으로 자기 행을 지우고 다시
 넣는다.** 세션 트래픽과 완전히 분리된 경로다 — 11층에서 말한 "디스커버리와
 트랜스포트는 다른 경로"가 로그에서 눈으로 확인된다.
 ---
 ## 7. 그래서 무엇이 세션을 공유하는가
 ```
    로그인 (keycloak-0)
         │
         ├──▶ PostgreSQL OFFLINE_USER_SESSION        ← 진실의 원천. 양쪽이 본다
         │
         └──▶ keycloak-0 로컬 캐시                   ← 자기 것만. 건너가지 않는다
    keycloak-1 이 그 세션을 물으면
         │
         └──▶ 자기 캐시에 없음 → PostgreSQL 에서 읽는다
 ```
 | 계층 | 역할 | 노드 간 공유 |
 |---|---|---|
 | **PostgreSQL** | 진실의 원천 | **여기서 일어난다** |
 | **Infinispan `sessions`** | 자기 노드가 처리한 세션의 룩어사이드 캐시 | **일어나지 않는다** |
 | **Infinispan 클러스터** | 무효화 메시지, `work` 캐시 등 | 형성은 되어 있다 |
 이건 **Keycloak 26의 의도된 설계**다. `persistent-user-sessions`가 기본이 되면서
 DB가 진실의 원천이 됐고, 세션 캐시는 **복제할 이유가 없어졌다.** 복제를 하면
 네트워크와 메모리를 쓰면서 DB와 캐시 두 벌을 정합하게 유지해야 한다.
 ---
 ## 8. 개념
 ### 8-1. `persistent-user-sessions`
 Keycloak 25에서 도입되고 **26에서 기본값**이 된 기능. 사용자 세션을
 Infinispan에만 두지 않고 **데이터베이스에 기록**한다.
 | | 켜져 있을 때 (기본) | 꺼져 있을 때 (volatile) |
 |---|---|---|
 | 진실의 원천 | **PostgreSQL** | Infinispan |
 | 전체 재시작 후 | **세션이 남는다** | 전부 사라진다 |
 | 노드 간 공유 | DB가 한다 | **복제가 해야 한다** |
 | 로그인당 비용 | DB 쓰기 | 네트워크 복제 |
 **이 실험의 결론은 전부 "켜져 있을 때"의 이야기다.** 끄면 다른 그림이 나오고,
 그 비교가 로드맵 A-2다.
 ```bash
 kubectl -n keycloak-lab exec keycloak-0 -- \
  /opt/keycloak/bin/kc.sh show-config 2>/dev/null | grep -i feature
 ```
 ### 8-2. 온라인 세션이 `OFFLINE_` 테이블에 들어간다
 **`USER_SESSION` 테이블은 존재하지 않는다.** 처음에 이걸 찾다가 없어서 당황했다.
 ```
 public | auth_session                  | table | keycloak
 public | jgroups_ping                  | table | keycloak
 public | offline_client_session        | table | keycloak
 public | offline_user_session          | table | keycloak
 public | revoked_token                 | table | keycloak
 public | root_auth_session             | table | keycloak
 ```
 `persistent-user-sessions`는 **기존 오프라인 세션 테이블을 재사용**하고
 `offline_flag` 컬럼으로 구분한다.
 | `offline_flag` | 의미 |
 |---|---|
 | **`'0'`** | **온라인 세션** (일반 로그인) |
 | `'1'` | 오프라인 세션 (`offline_access`) |
 기본키가 `(user_session_id, offline_flag)` 복합키인 이유다 — 같은 세션 id가
 온라인/오프라인 두 행으로 존재할 수 있다.
 ```sql
 select offline_flag, count(*) from offline_user_session group by offline_flag;
 select user_session_id, offline_flag, created_on, last_session_refresh
  from offline_user_session where user_session_id = '<sid>';
 ```
 **이름이 내용을 배신하는 스키마다.** 운영에서 "온라인 세션이 DB 어디 있냐"를
 찾을 때 이걸 모르면 한참 헤맨다.
 ### 8-3. `sid` — 토큰과 DB를 잇는 열쇠
 ```
 JWT access_token 의 sid   jiv3rVZi1VeaO07oVJkL_MYW
                          ↕ 같은 값
 DB user_session_id        jiv3rVZi1VeaO07oVJkL_MYW
                          ↕ 같은 값
 Admin API 세션 목록의 id  jiv3rVZi1VeaO07oVJkL_MYW
 ```
 세 곳에서 같은 문자열이다. **장애를 추적할 때 이 값 하나로 토큰·DB·관리 API를
 꿰뚫을 수 있다.** 백채널 로그아웃의 `sid` 클레임도 이것이다.
 ### 8-4. `openid` scope가 없으면 OIDC 토큰이 아니다
 `admin-cli`에 `scope` 없이 direct grant를 하면 나오는 클레임은 이렇다.
 ```
 --- access_token ---
  클레임: azp, exp, iat, iss, jti, scope, sid, typ
  typ = Bearer | sub = None | sid = OxikTqdHCJ7ESm2GPKI1oa6c
 ```
 **`sub`이 없다.** OIDC가 아니라 순수 OAuth2 액세스 토큰이기 때문이다.
 `sub`은 OIDC가 요구하는 클레임이고, `openid` scope가 있어야 붙는다.
 같은 이유로 `userinfo`가 403 `insufficient_scope`를 준다 — userinfo는 OIDC
 엔드포인트다. **두 현상은 하나의 원인**이다.
 ### 8-5. 룩어사이드(lookaside) 캐시
 ```
  읽기:  캐시 확인 → 없으면 DB → 캐시에 채움
  쓰기:  DB 에 쓰고 → 캐시에도 씀
 ```
 캐시가 **DB 앞에 서 있되 DB를 대체하지 않는** 구조. 캐시를 통째로 날려도
 정확성은 유지되고 느려지기만 한다. Keycloak 26의 세션 캐시가 이 모양이다.
 이 성질이 **노드 상실 실험(A-3)의 결과를 미리 결정한다** — 노드가 죽으면
 그 노드의 캐시는 사라지지만 세션은 DB에 있으므로 살아남아야 한다.
 ---
 ## 9. 다음 실험에 대한 예측
 기준선이 생겼으므로 **틀릴 수 있는 예측**을 세울 수 있다. 예측이 빗나가면
 그것이야말로 배울 거리다.
 | 실험 | 예측 | 근거 |
 |---|---|---|
 | **A-1** TCP 7800 차단 | **세션 공유는 안 깨진다.** 대신 무효화 전파와 `work` 캐시가 깨진다 | 세션은 7800으로 오가지 않는다 |
 | **A-2** DB 손실 | **즉시 전면 장애.** 캐시에 있는 세션도 못 쓴다 | DB가 진실의 원천 |
 | **A-2'** DB **강제** 종료 | 직전 수백 ms 의 세션 갱신이 **사라진다** | `synchronous_commit OFF` |
 | **B-5** 동시 갱신 경쟁 | 한쪽이 `VERSION` 검사에서 지고 재시도한다 | 낙관적 락 |
 | **A-3** 노드 상실 (kc-lab-2) | **세션은 살아남는다.** 죽은 노드의 캐시만 사라진다 | 룩어사이드 |
 | **A-4** volatile 비교 | 7800 차단이 **A-1과 정반대로** 치명적이 된다 | 그때는 캐시가 진실의 원천 |
 특히 A-1은 **직관과 어긋나는 예측**이다. "클러스터 포트를 막으면 세션이
 깨진다"가 상식이지만, 이 기준선이 맞다면 안 깨져야 한다.
 ---
 ## 10. 겪은 함정
 ### 10-1. kubectl 스트림에서 출력이 통째로 사라졌다
 `kubectl run --rm -i ... | grep` 로 받으면 **중간 조각이 유실됐다.**
 keycloak-1의 스냅샷과 그 다음 마커가 함께 없어져, 전값이 0으로 잡히면서
 **가짜 델타가 만들어졌다.**
 ```
 ###BEFORE_K1        ← 여기 있어야 할 지표 20줄과
 http_code=200          다음 마커 ###LOGIN 이 통째로 사라졌다
 ###AFTER_K0
 ```
 이때 리포트는 keycloak-1이 `+9`, `+7` 증가한 것처럼 보였다. **없는 복제가
 있는 것처럼 보이는, 가장 나쁜 종류의 오류다.**
 | 고친 방법 | |
 |---|---|
 | 파드 안에서 파일로 모으고 마지막에 `cat` 한 번 | 스트리밍 중 유실을 없앤다 |
 | 스냅샷이 비면 **경고를 출력**한다 | 조용히 0으로 계산되는 것을 막는다 |
 ```bash
 for n in ('BEFORE_K0','BEFORE_K1','AFTER_K0','AFTER_K1'):
    if not blocks.get(n):
        print(f'  !! {n} 스냅샷이 비었다 — 델타를 신뢰할 수 없다')
 ```
 **계측 코드는 자기가 실패했는지 스스로 말해야 한다.**
 ### 10-2. DB에서 직접 지우면 캐시는 남는다
 정리하려고 `delete from offline_user_session`을 실행했더니, **캐시 엔트리는
 그대로 남아** 캐시 합계(19)와 DB 총계(15)가 어긋났다.
 > 운영에서 세션 테이블을 직접 손대면 캐시와 DB가 갈라진다. 세션을 지울 때는
 > 관리 API(`logout-all`)를 쓰거나, DB를 건드렸다면 **파드를 재시작**해야 한다.
 이 실험의 최종 수치는 **파드 재시작 후** 다시 잰 것이다.
 ### 10-3. Keycloak 이미지에는 `curl`이 없다
 `kubectl exec keycloak-0 -- curl` 은 실패한다. 임시 `curlimages/curl` 파드를
 띄워 파드 네트워크 안에서 호출했다. 파드 IP는 클러스터 밖에서 닿지 않으므로
 이 방법이 사실상 유일하다.
 ### 10-4. 중첩 셸의 변수 치환
 `ssh host '... $VAR ...'` 안에 다시 `sh -c "..."` 를 넣으면 인용이 세 겹이 되어
 치환이 조용히 깨진다. 첫 시도에서 파드 IP가 빈 문자열이 되어 아무 출력도
 나오지 않았다.
 **스크립트 파일로 만들어 `scp` 로 옮기는 쪽이 옳다.** 재현도 되고 저장소에
 남는다. `deploy/lab/scripts/` 아래 세 스크립트가 그 결과다.
 ---
 ## 11. 재현
 ```bash
 # 1. 깨끗한 상태로 되돌린다 (DB 비우고 캐시 비우기)
 ssh test-server '
  kubectl -n keycloak-lab exec deploy/postgres -- \
    psql -U keycloak -d keycloak -c "delete from offline_user_session"
  kubectl -n keycloak-lab rollout restart statefulset/keycloak
  kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s'
 # 2. 세 실험을 순서대로
 ssh test-server '/tmp/experiment-session-replication.sh'      # 교차 노드 사용
 ssh test-server '/tmp/experiment-cache-replication-delta.sh'  # 복제인가 DB인가
 ssh test-server '/tmp/experiment-cache-ownership.sh'          # 엔트리 위치
 # 3. 그래프
 #    https://app2.hyeonworks.com/explore
 #    vendor_statistics_approximate_entries_unique{cache="sessions"}
 #    Legend: {{pod}} on {{node}}
 ```
 ### 확인용 명령 모음
 ```bash
 # 클러스터 멤버
 kubectl -n keycloak-lab logs keycloak-0 | grep ISPN000094 | tail -1
 kubectl -n keycloak-lab exec deploy/postgres -- \
  psql -U keycloak -d keycloak -c "select name, ip, coord from jgroups_ping"
 # DB 세션
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
  -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 # 노드별 캐시 엔트리 (파드 안에서)
 curl -s http://<pod-ip>:9000/metrics \
  | grep 'approximate_entries_unique{cache="sessions"'
 ```
@@ -0,0 +1,506 @@
 # A-1 — 노드 간 통신(TCP 7800)을 끊으면 무엇이 깨지는가
 브랜치 `feature/keycloak-a1-jgroups-transport-block` ·
 증거 [`docs/evidence/a1-jgroups-transport-block/`](evidence/a1-jgroups-transport-block/) ·
 2026-09-04 11:38–11:52 KST · Keycloak 26.7.0 / Infinispan 16.0.12
 맥락은 [`session-lab-prerequisites.md`](session-lab-prerequisites.md),
 기준선은 [`experiment-00-session-replication.md`](experiment-00-session-replication.md).
 ---
 ## 0. 결론부터
 | 예측 | 결과 |
 |---|---|
 | 세션 공유는 **안 깨진다** | **맞다.** 교차 노드 refresh 가 `200` |
 | 로그아웃 전파는 **안 깨진다** | **틀렸다.** `400` 이어야 할 것이 `200` |
 | — | **NetworkPolicy 만으로는 분단이 일어나지 않는다** (예상 못 함) |
 | — | **분단된 노드가 스스로 로드밸런서에서 빠진다** (예상 못 함) |
 **예측 하나가 빗나갔고, 예상하지 못한 것이 둘 나왔다.** 그중 하나는
 실험 방법 자체를 무효화할 뻔했다.
 ---
 ## 1. 왜 이 실험인가
 A-0 에서 **세션은 Infinispan 복제가 아니라 PostgreSQL 로 공유된다**는 것을
 측정했다. 그렇다면 통념과 정면으로 어긋난다.
 | | |
 |---|---|
 | **통념** (Keycloak 24 이전 자료) | 세션은 7800 으로 복제된다 → **막으면 세션 공유가 깨진다** |
 | **A-0 측정** | 세션은 DB 로 공유된다 → **막아도 안 깨진다** |
 둘 중 하나는 틀렸고, 이 실험이 판정한다.
 ---
 ## 2. 기준선
 ```
 === [기준선 1] 클러스터 뷰 ===
  keycloak-0: [keycloak-1-48749|5] (2) [keycloak-1-48749, keycloak-0-30843]
  keycloak-1: [keycloak-1-48749|5] (2) [keycloak-1-48749, keycloak-0-30843]
 === [기준선 2] JGROUPS_PING ===
 keycloak-0-30843 | 10.42.1.43:7800 | f
 keycloak-1-48749 | 10.42.0.35:7800 | t     ← 코디네이터는 하나
 === [기준선 4] JGroups 지표 (양쪽 동일) ===
  fd_sock2_get_num_suspected_members   0.0
  merge3_get_num_merge_events          0.0
  nakack2_get_xmit_table_missing       0.0
 ```
 **대조군** — 차단 전에 같은 절차를 그대로 한 번 돌린다.
 ```
 === [대조군] keycloak-0 로그인 → keycloak-1 에서 refresh ===
  sid                    tAWs2gCPr6SOcD4jDR9-_CzB
  keycloak-1 에서 refresh: 200
 ```
 A-0 에서 배운 규칙이다 — **시험군만 재는 측정은 측정이 아니다.**
 ---
 ## 3. 주입 — NetworkPolicy 로 7800 만 막는다
 ```bash
 kubectl apply -f deploy/lab/k8s/a1-block-jgroups-transport.yaml
 ```
 ```yaml
 spec:
  podSelector: { matchLabels: { app: keycloak } }
  policyTypes: [Ingress]
  ingress:
    - ports:
        - { port: 8080, protocol: TCP }   # HTTP        — 열어둔다
        - { port: 9000, protocol: TCP }   # health+metrics — 열어둔다
    # 7800 은 일부러 없다
 ```
 ### 개념 — NetworkPolicy 는 방화벽이 아니라 **허용 목록**이다
 **"7800 을 거부"라고 쓸 수 없다.** 파드가 `policyTypes: [Ingress]` 를 가진
 정책에 선택되는 순간 **모든 인바운드가 거부**되고, 규칙에 적힌 것만 통과한다.
 그래서 7800 은 **빠뜨림으로써** 막힌다.
 이 구조가 두 허용 규칙을 **결정적으로 만든다.** 잘못 쓰면 분단된 클러스터가
 아니라 **죽은 Keycloak 을 측정하게 된다.**
 | 포트 | 빼면 |
 |---|---|
 | 8080 | Traefik·상대 노드의 REST 호출이 전부 끊긴다 |
 | **9000** | **readiness 프로브가 실패해 kubelet 이 파드를 죽인다** — 엉뚱한 이유로 클러스터가 깨진다 |
 적용 직후 확인했다.
 ```
 파드 상태:  keycloak-0 ready=true restarts=0
            keycloak-1 ready=true restarts=0
 9000 도달:  10.42.1.43:9000 health=200 / 10.42.0.35:9000 health=200
 8080 도달:  10.42.1.43:8080 root=200   / 10.42.0.35:8080 root=200
 ```
 **주입이 의도한 것만 건드렸음을 먼저 확인한 뒤에 결과를 해석한다.**
 ---
 ## 4. 문제 ①  — **NetworkPolicy 만으로는 분단이 안 된다**
 가장 중요한 발견이며, 하마터면 **실험 전체를 무효로 만들 뻔했다.**
 차단 후 지표가 꿈쩍도 하지 않았다. 신규 연결은 분명히 막히는데.
 ```
 === 7800 신규 연결 ===
  10.42.1.43:7800  curl exit=7   (연결 실패)
  10.42.1.43:9000  curl exit=28  (연결됨, telnet 이라 대기 → 타임아웃)
 ```
 그런데 파드 내부 소켓을 보니
 ```
 === /proc/net/tcp6 · 7800 = 0x1E78 ===
 keycloak-0: ...2B012A0A:1E78  ...23002A0A:9C57  01   ← 01 = ESTABLISHED
 keycloak-1: ...23002A0A:9C57  ...2B012A0A:1E78  01
            (10.42.0.35:40023 → 10.42.1.43:7800)
 ```
 **기존 연결이 멀쩡히 살아 있다.**
 ### 왜 그런가 — conntrack
 ```
   패킷 도착
      │
      ├─▶ [ conntrack: ESTABLISHED/RELATED 이면 ACCEPT ]  ← 여기서 통과해버린다
      │
      └─▶ [ NetworkPolicy 규칙 평가 ]                     ← 여기까지 오지 않는다
 ```
 리눅스 방화벽은 성능을 위해 **이미 성립한 연결을 먼저 통과**시킨다.
 NetworkPolicy 는 그 뒤에 있으므로 **신규 연결(SYN)만** 걸러낸다.
 ```
 === conntrack 확인 ===
 tcp 6 86398 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=40023 dport=7800 ... [ASSURED]
 tcp 6 79982 ESTABLISHED src=10.42.0.35 dst=10.42.1.43 sport=50477 dport=57800 ... [ASSURED]
 tcp 6    33 SYN_SENT    src=10.42.1.58 dst=10.42.0.35 sport=34824 dport=7800 [UNREPLIED]
                        ─────────────────────────────────────────────────────────────
                        신규 연결은 응답을 못 받는다 = 정책이 동작하고는 있다
 ```
 > **운영적 함의 — NetworkPolicy 는 이미 붙어 있는 것을 떼어내지 못한다.**
 > 보안 사고 대응으로 "지금 당장 이 통신을 끊어라"에 NetworkPolicy 를 적용하면,
 > **새 연결만 막히고 진행 중인 연결은 계속된다.** 끊으려면 conntrack 을 지우거나
 > 파드를 재시작해야 한다.
 ### 덤 — **57800 포트도 있다**
 `sport=50477 dport=57800` — FD_SOCK2 는 **`bind_port + 50000`** 을 쓴다.
 7800 만 막고 57800 을 열어두면 장애 감지 채널이 남는다.
 이 실험의 허용 목록 방식은 **둘 다 자동으로 막았다** — 8080·9000 외 전부 거부이므로.
 ### 조치
 ```bash
 # 정확한 튜플로 지정해야 지워진다. --dport 만으로는 0건이었다
 sudo conntrack -D -p tcp -s 10.42.0.35 -d 10.42.1.43 --sport 40023 --dport 7800
 sudo conntrack -D -p tcp -s 10.42.1.43 -d 10.42.0.35 --sport 7800 --dport 40023   # 역방향
 ```
 **양쪽 노드에서, 양쪽 방향으로** 지워야 한다. 서버 쪽 노드에는 튜플이 뒤집혀
 기록되어 있다.
 그리고 **즉시 끊기지 않는다.**
 ```
 11:41  conntrack 삭제
 11:44  cluster_size 2 → 1        ← 약 3분 뒤
 ```
 TCP 는 상대가 사라졌음을 **재전송 타임아웃**으로 알아낸다. 소켓은 한동안
 `ESTABLISHED` 로 남아 있다.
 ---
 ## 5. 문제 ② — 계측 도구가 잘못됐다
 임시 curl 파드로 20초마다 지표를 긁었더니 이런 결과가 나왔다.
 ```
  +20초   suspected(k0 k1) = []
  +60초   suspected(k0 k1) = [0.0 0.0 0.0 0.0 ]
  +140초  suspected(k0 k1) = [0.0 ]
 ```
 **빈 값, 개수가 맞지 않는 값이 섞인다.** `kubectl run --rm` 은 매번 파드를
 만들고 지우므로 느리고 경합이 있다.
 게다가 첫 시도의 판정 조건이
 ```sh
 [ "$R" != "0.0 0.0 " ] && echo "→ 변화 감지" && break
 ```
 여서 **빈 문자열을 "변화"로 읽고 즉시 빠져나왔다.** A-0 에서 똑같은 실수를
 했는데 또 했다.
 > **임시 파드는 계측 도구가 아니다.** 15초마다 이미 긁고 있는 Prometheus 가
 > 그러라고 있는 것이다.
 ```bash
 kubectl -n observability port-forward svc/prometheus 19090:9090 &
 curl -s "http://localhost:19090/api/v1/query_range?query=vendor_cluster_size&start=$START&end=$END&step=60"
 ```
 그리고 이 과정에서 **`vendor_cluster_size`** 를 발견했다 — 멤버 수를 직접
 알려주는 지표다. 처음부터 이걸 봤어야 했다.
 ```bash
 curl -s "http://localhost:19090/api/v1/label/__name__/values" | grep -E "cluster|member|view"
 ```
 ---
 ## 6. 진짜 분단이 일어난 순간
 ```
 === vendor_cluster_size ===
 keycloak-1: 11:43:57=2  11:44:27=1  ...  11:51:28=2
 keycloak-0: 11:43:57=2  (파드 교체)  11:45:27=1  ...  11:51:28=2
 ```
 ![cluster_size 추이](evidence/a1-jgroups-transport-block/a1-cluster-size-partition-recovery.png)
 정책이 걸린 채 `keycloak-0` 이 재시작되자, 로그가 정확히 말해준다.
 ```
 GMS: JOIN(keycloak-0-26403) sent to keycloak-1-48749 timed out   ← 10회
 GMS: too many JOIN attempts (10): becoming singleton             ← 포기
 ISPN000094: new cluster view [keycloak-0-26403|0] (1) [keycloak-0-26403]
 ```
 `keycloak-1` 쪽도 혼자가 되었다.
 ```
 ISPN000094: [keycloak-1-48749|6] (1) [keycloak-1-48749]
 ```
 ### **DB 에는 둘 다 있는데 클러스터는 안 붙는다** — 예측한 그 상태
 ```
 === JGROUPS_PING ===
       name       |       ip        | coord
 ------------------+-----------------+-------
 keycloak-0-26403 | 10.42.1.67:7800 | t     ← 코디네이터
 keycloak-1-48749 | 10.42.0.35:7800 | t     ← 코디네이터
 ```
 **`coord = t` 가 둘.** 교과서적인 split brain 이며, **데이터베이스 한 줄로
 확인된다.** 디스커버리(DB)는 살아 있고 트랜스포트(7800)만 죽은 상태다.
 **단일 노드에서는 만들 수 없는 고장**이며, 이 실험대를 2 VM 으로 만든 이유다.
 ---
 ## 7. 본 시험 — 분단 상태에서 세션은 어떻게 되는가
 ```
  [1] keycloak-0 로그인          sid=nShl5TaBrZnKStDqaspjgmJB
  [2] keycloak-1 에서 refresh     HTTP 200      ← 예측대로
  [3] keycloak-1 에서 로그아웃    HTTP 204
  [4] keycloak-0 에서 재갱신 시도 HTTP 200      ← 400 이어야 했다
 ```
 ### [2] 세션 공유 — **예측이 맞았다**
 클러스터가 갈라졌는데도 **한쪽에서 만든 세션을 반대쪽이 갱신했다.**
 A-0 의 모델이 맞고, **통념이 틀렸다.** 세션은 7800 으로 다니지 않는다.
 ### [4] 로그아웃 전파 — **예측이 틀렸다**
 A-0 에서는 같은 절차가 `400 invalid_grant / Session not active` 였다.
 분단 상태에서는 `200` 이다. **로그아웃한 세션이 반대편에서 살아 있다.**
 기제를 확정했다.
 ```
 === 그 sid 가 DB 에 남아 있는가 ===
 user_session_id | offline_flag | last_session_refresh
 -----------------+--------------+----------------------
 (0 rows)                                            ← DB 행은 삭제되었다
 === 노드별 세션 캐시 엔트리 ===
  keycloak-1   kc-lab-1   = 0
  keycloak-0   kc-lab-2   = 1                       ← 캐시에는 남아 있다
 ```
 ```
   keycloak-1 로그아웃
        │
        ├──▶ PostgreSQL 행 삭제                     ✔ 되었다
        │
        └──▶ keycloak-0 에게 "캐시에서 지워라"       ✗ 7800 이 막혀 못 갔다
                                                        │
   keycloak-0 은 자기 캐시로 200 을 준다  ◀────────────┘
 ```
 ### **A-0 의 결론을 정정한다**
 A-0 에서 나는 이렇게 썼다.
 > 로그아웃과 함께 DB 행이 사라졌다 → 무효화가 DB 삭제로 전파된다
 **그 인과는 틀렸다.** DB 행 삭제는 일어나지만, **반대편 노드는 DB 를 다시
 읽지 않는다.** 자기 캐시에 있으면 그걸로 답한다.
 > **룩어사이드 캐시는 읽을 때 DB 와 대조하지 않는다.**
 > 캐시 무효화는 **클러스터 메시지(7800)를 타고** 간다.
 A-0 에서 400 이 나온 것은 DB 덕분이 아니라 **그때는 7800 이 살아 있어서**였다.
 두 실험을 붙여야 비로소 정확한 그림이 나온다.
 | | 세션 **조회** | 세션 **무효화** |
 |---|---|---|
 | 경로 | PostgreSQL | **클러스터 메시지 (7800)** |
 | 7800 차단 시 | 정상 | **전파되지 않음** |
 ---
 ## 8. 그런데 안전장치가 있었다 — 예상 못 한 발견
 `keycloak-0` 이 `Ready=false` 였다. 이유를 물었더니
 ```json
 { "status": "DOWN",
  "checks": [
    { "name": "Keycloak cluster health check", "status": "DOWN",
      "data": { "Failing since": "2026-09-04 02:45:14,251" } },
    { "name": "Keycloak database connections async health check", "status": "UP" }
  ] }
 ```
 **Keycloak 은 클러스터 분단을 readiness 로 신고한다.** 그리고 쿠버네티스가
 그 신고를 받아 처리했다.
 ```
 === Service 엔드포인트 ===
  ready 주소: [10.42.0.35]     ← keycloak-1 만 트래픽을 받는다
  notReady : [10.42.1.67]      ← keycloak-0 은 제외되었다
 === 외부 진입점 ===
  https://auth.hyeonworks.com/realms/master   HTTP 200
  토큰 발급                                    HTTP 200
 ```
 **분단된 노드가 스스로 로드밸런서에서 빠졌고, 서비스는 계속되었다.**
 ### 그래서 7절의 로그아웃 우회는 어떻게 봐야 하나
 | | |
 |---|---|
 | 내가 한 것 | Service 를 우회해 **파드 IP 로 직접** 호출 |
 | 실제 사용자 | nginx → Traefik → **Service** → Ready 인 파드만 |
 **정문으로 들어오면 낡은 캐시에 닿지 않는다.** readiness 게이트가 막는다.
 > 다만 이건 **비대칭이라서 살았다.** `keycloak-1` 은 원래 뷰에서 멤버가 하나
 > 줄어든 정상적인 사건이라 Ready 를 유지했고, `keycloak-0` 은 합류 자체를
 > 못 해 DOWN 이 되었다. **양쪽이 동시에 DOWN 이 되는 경로가 있다면 전면 장애다.**
 > A-5(비대칭 파티션)에서 이어서 본다.
 ---
 ## 9. 복구
 ```bash
 kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
 ```
 ```
  +30초   keycloak-0=1 keycloak-1=1
  +60초   keycloak-0=1 keycloak-1=1
  +90초   keycloak-0=2 keycloak-1=2   ← 재형성
 ```
 **90초 만에 자동으로 다시 붙었다. 사람 손이 필요 없었다.**
 ```
 === MERGE3 가 합쳤는가 ===
  merge_events keycloak-0 = 1
  merge_events keycloak-1 = 1
 ```
 **MERGE3 가 한 일이다.** split brain 을 감지해 뷰를 병합하는 프로토콜이며,
 지표가 `0 → 1` 로 올라간 것이 그 증거다.
 ```
 === JGROUPS_PING ===
 keycloak-0-26403 | 10.42.1.67:7800 | t
 keycloak-1-48749 | 10.42.0.35:7800 | f     ← 코디네이터가 하나로 돌아왔다
 ```
 **코디네이터가 keycloak-1 에서 keycloak-0 으로 넘어갔다.** 코디네이터는
 특권이 아니라 역할이며, 병합 시 재선출된다.
 ---
 ## 10. 개념 정리
 ### conntrack — 연결 추적
 리눅스 커널이 **진행 중인 연결을 기억**하는 표. 패킷마다 규칙을 다시 평가하지
 않기 위해 존재한다.
 | 상태 | 뜻 |
 |---|---|
 | `NEW` | 첫 패킷(SYN) |
 | **`ESTABLISHED`** | **양방향 통신이 성립함 — 규칙 평가를 건너뛴다** |
 | `[ASSURED]` | 충분히 오래된 연결. 표가 꽉 차도 안 지워진다 |
 | `SYN_SENT [UNREPLIED]` | 보냈는데 답이 없음 = **차단되고 있다** |
 ```bash
 sudo conntrack -L | grep 7800
 sudo conntrack -D -p tcp -s <src> -d <dst> --sport <sp> --dport <dp>
 ```
 ### FD_SOCK2 와 포트 규약
 | 프로토콜 | 포트 | 하는 일 |
 |---|---|---|
 | TCP (트랜스포트) | **7800** | 클러스터 메시지 |
 | **FD_SOCK2** | **57800** = 7800 + 50000 | 소켓으로 상대 생존 감시 |
 **방화벽 규칙을 손으로 쓸 때 57800 을 빠뜨리기 쉽다.**
 ### MERGE3
 split brain 이 생긴 뒤 **갈라진 뷰를 다시 합치는** JGroups 프로토콜.
 주기적으로 다른 코디네이터의 존재를 확인하고, 발견하면 병합을 개시한다.
 ```promql
 vendor_jgroups_merge3_get_num_merge_events
 ```
 ### readiness 프로브와 Service 엔드포인트
 ```
   readiness 실패 → 파드가 Service 의 notReadyAddresses 로 이동
                  → kube-proxy 가 그 파드로 라우팅하지 않음
                  → 살아 있지만 트래픽은 안 받음
 ```
 **liveness 와 다르다.** liveness 실패는 **재시작**, readiness 실패는
 **격리**다. 클러스터 분단처럼 "재시작해도 안 나아지는" 문제에는 readiness 가
 맞는 신호다.
 ---
 ## 11. 재현 절차 (명령어)
 ```bash
 # 0. 기준선
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
  -c "select name, ip, coord from jgroups_ping order by name"
 kubectl -n observability port-forward svc/prometheus 19090:9090 &
 curl -s "http://localhost:19090/api/v1/query?query=vendor_cluster_size"
 # 1. 차단
 kubectl apply -f deploy/lab/k8s/a1-block-jgroups-transport.yaml
 # 2. 주입이 의도한 것만 건드렸는지 확인 (8080/9000 은 살아 있어야 한다)
 kubectl -n keycloak-lab get pods -o wide | grep keycloak     # restarts=0 확인
 # 3. 기존 연결이 남아 있음을 확인 — 이걸 안 하면 실험이 무효다
 ssh kc-lab-1 'sudo conntrack -L | grep 7800'
 # 4. conntrack 삭제 (양쪽 노드, 양쪽 방향). 반영까지 약 3분
 ssh kc-lab-1 'sudo conntrack -D -p tcp -s <k1ip> -d <k0ip> --sport <sp> --dport 7800'
 ssh kc-lab-2 'sudo conntrack -D -p tcp -s <k0ip> -d <k1ip> --sport 7800 --dport <sp>'
 # 5. 분단 확인
 curl -s "http://localhost:19090/api/v1/query?query=vendor_cluster_size"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
  -c "select name, coord from jgroups_ping"        # coord=t 가 둘이면 split brain
 # 6. 복구
 kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
 curl -s "http://localhost:19090/api/v1/query?query=vendor_jgroups_merge3_get_num_merge_events"
 ```
 ---
 ## 12. 다음 실험에 남기는 것
 | 실험 | 이 실험이 준 것 |
 |---|---|
 | **A-5** 비대칭 파티션 | **양쪽이 동시에 NotReady 가 되는 경로가 있는가.** 여기서는 비대칭이라 살았다 |
 | **A-2** DB 정지 | 캐시가 DB 와 대조하지 않는다는 사실 → **캐시에 있는 세션은 DB 없이도 읽힐 수 있다** |
 | **A-7** volatile 비교 | 같은 주입에서 세션 공유가 **깨져야** 한다. 이 실험이 그 대조군 |
 | 전체 | **주입이 실제로 걸렸는지 먼저 확인한다.** NetworkPolicy 는 기존 연결을 못 끊는다 |
@@ -0,0 +1,308 @@
 # A-2 — PostgreSQL 이 죽으면 어떻게 되는가
 브랜치 `feature/keycloak-a2-database-loss` ·
 증거 [`docs/evidence/a2-database-loss/`](evidence/a2-database-loss/) ·
 2026-09-04 11:56–11:58 KST · Keycloak 26.7.0
 선행: [`A-0`](experiment-00-session-replication.md) ·
 [`A-1`](experiment-a1-jgroups-transport-block.md)
 ---
 ## 0. 결론부터
 | 예측 | 결과 |
 |---|---|
 | 즉시 전면 장애 | **맞다.** 외부 진입점 **503**, 양쪽 노드 NotReady |
 | 캐시에 있어도 못 쓴다 | **맞다.** 캐시를 가진 노드도 `500` |
 | — | **`up = 1` 인 채로 전면 장애가 났다** (관측의 함정) |
 | — | **DB 복귀 15초 만에 재시작 없이 자동 회복** |
 **A-1 과 정반대다.** A-1 은 한쪽만 빠지고 서비스가 계속됐지만,
 A-2 는 **살아남는 노드가 없다.**
 ---
 ## 1. 설계 — 네 경로를 구분해서 본다
 A-1 에서 **"룩어사이드 캐시는 읽을 때 DB 와 대조하지 않는다"** 를 확인했다.
 그렇다면 캐시를 가진 노드는 DB 없이도 버틸지 모른다. 그 가설을 가른다.
 | # | 경로 | 무엇을 보는가 |
 |---|---|---|
 | ① | **캐시를 가진 노드**에서 refresh | 캐시가 DB 를 대신할 수 있는가 |
 | ② | 캐시가 없는 노드에서 refresh | 완전한 DB 의존 |
 | ③ | 새 로그인 | 쓰기 경로 |
 | ④ | 이미 발급된 토큰으로 조회 | 서명만으로 되는 경로 |
 **access token 수명이 60초**이므로, 토큰 발급 → DB 정지 → 시험을 그 안에
 끝내야 한다.
 ### 계측 도구를 바꿨다
 A-1 에서 임시 curl 파드가 형편없는 계측 도구임을 확인했다. 여기서는
 **상주 탐침 파드**를 하나 띄우고 `exec` 로 단계를 이어간다. 토큰을 파드 안
 파일에 남겨 **DB 정지 전후로 같은 토큰**을 쓸 수 있다.
 ```bash
 kubectl -n keycloak-lab run a2-probe --image=curlimages/curl:8.11.1 \
  --restart=Never --command -- sleep 7200
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a2-probe --timeout=120s
 ```
 ---
 ## 2. 기준선
 ```
 keycloak-0   ready=true   10.42.1.67   kc-lab-2
 keycloak-1   ready=true   10.42.0.35   kc-lab-1
 postgres     ready=true   10.42.1.24   kc-lab-2
 cluster_size keycloak-0 = 2
 cluster_size keycloak-1 = 2
 ```
 세션을 양쪽에 하나씩 만들고, A-0 대로 **각자 자기 노드에만 캐시**되는 것을
 확인했다.
 ```
  keycloak-0 에서 로그인  sid=EAXV5HcG2J1BZ3vnwONf64AQ
  keycloak-1 에서 로그인  sid=McyTj5lj3n_JqApCXeuAHExc
  → 캐시  keycloak-0 = 1 건 / keycloak-1 = 0 건 (스크레이프 지연)
 ```
 ---
 ## 3. 주입
 ```bash
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
 kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 ```
 ```
 정지 시각: 11:56:04
 삭제 완료: 11:56:04     ← 즉시
 ```
 ---
 ## 4. 결과 — 네 경로
 ```
  ① 캐시를 가진 노드(keycloak-0)에서 refresh   HTTP 500
  ② 캐시가 없는 노드(keycloak-1)에서 refresh   HTTP 500
  ③ 새 로그인                                  HTTP 500
  ④ 관리 API (세션 조회 필요)                   HTTP 500
  --- 오류 본문 ---
  {"error":"unknown_error","error_description":"For more on this error consult the server log."}
 ```
 ### ① 이 500 인 것이 중요하다
 **캐시에 세션을 들고 있어도 refresh 는 실패한다.**
 A-1 에서는 로그아웃된 세션을 캐시로 `200` 을 줬다. 왜 여기서는 안 되는가.
 ```
   refresh 처리
     ├── 세션이 존재하는가        →  캐시로 답할 수 있다
     └── LAST_SESSION_REFRESH 갱신 →  DB 쓰기가 필요하다   ← 여기서 죽는다
 ```
 A-0 에서 잡은 SQL 그대로다.
 ```sql
 update OFFLINE_USER_SESSION set LAST_SESSION_REFRESH=$1, VERSION=$2 where ...
 ```
 > **캐시는 읽기를 대신할 뿐, 쓰기를 대신하지 못한다.**
 > refresh 는 이름과 달리 **쓰기 연산**이다.
 ### 로그가 말하는 원인
 ```
 Caused by: java.net.ConnectException: Connection refused
  at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect
  at io.agroal.pool.ConnectionPool$CreateConnectionTask.call
 ```
 `agroal` 은 Quarkus 의 커넥션 풀이다. 풀이 새 커넥션을 만들지 못한다.
 ---
 ## 5. 살아남은 것 — 상태가 필요 없는 경로
 ```
  JWKS 엔드포인트(realm 공개키)   HTTP 200
  realm 메타데이터(.well-known)   HTTP 200
  관리 API (세션 조회 필요)        HTTP 500
 ```
 **realm 공개키와 메타데이터는 메모리에 있으므로 DB 없이도 응답한다.**
 이론적으로는 **이미 JWKS 를 캐시한 리소스 서버는 토큰 검증을 계속할 수 있다**는
 뜻이다. 다만 이 실험대에는 독립 리소스 서버가 아직 없으므로 **여기까지가
 말할 수 있는 범위**다 — B층에서 확인한다.
 > **그런데 정문으로는 이것도 못 쓴다.** 아래 6절 때문이다.
 ---
 ## 6. 전면 장애 — 살아남는 노드가 없다
 ```
 === 파드 Ready ===
 keycloak-0   false   restarts=0
 keycloak-1   false   restarts=0
 === Service 엔드포인트 ===
  ready   : []                              ← 비었다
  notReady: [10.42.0.35 10.42.1.67]
 === 외부 진입점 ===
  https://auth.hyeonworks.com/realms/master   HTTP 503
 ```
 ```json
 { "status": "DOWN",
  "checks": [
    { "name": "Keycloak cluster health check",                    "status": "UP"   },
    { "name": "Keycloak database connections async health check", "status": "DOWN" },
    { "name": "Keycloak Initialized",                             "status": "UP"   } ] }
 ```
 **`cluster health` 는 UP 인데 `database connections` 가 DOWN 이라 전체가 DOWN 이다.**
 헬스체크는 **모든 항목이 UP 이어야 UP** 이다.
 ### A-1 과의 대비가 이 실험의 핵심이다
 | | A-1 (7800 차단) | **A-2 (DB 정지)** |
 |---|---|---|
 | Ready 인 파드 | keycloak-1 **1개 생존** | **0개** |
 | Service `ready` | `[10.42.0.35]` | **`[]`** |
 | 외부 응답 | **200** | **503** |
 | 성격 | 용량 저하 | **전면 장애** |
 **노드를 몇 대로 늘려도 DB 가 죽으면 전부 같이 죽는다.**
 Keycloak 의 대수는 DB 장애에 아무 도움이 되지 않는다.
 > 원래 질문 *"Redis 또는 DB가 뒤질 경우 어떻게 복구를 해야 되는지"* 에 대한
 > 첫 번째 답 — **복구 이전에, DB 이중화가 Keycloak 대수보다 우선한다.**
 ---
 ## 7. 관측의 함정 — `up = 1` 인 채로 전면 장애
 ```
  up{pod=keycloak-1} = 1
  up{pod=keycloak-0} = 1     ← 서비스는 503 인데
 ```
 ![up 은 움직이지 않았다](evidence/a2-database-loss/a2-up-stayed-1-during-outage.png)
 **전 구간 평평하다.** (11:44 의 짧은 골은 A-1 에서 파드를 교체한 자국이다.)
 `up` 은 **Prometheus 가 `/metrics` 를 긁는 데 성공했는가**만 말한다.
 프로세스는 멀쩡히 살아 메트릭을 내놓고 있었다. **기능은 전멸했는데.**
 | 지표 | 이 장애에서 |
 |---|---|
 | `up` | **1 — 아무것도 알려주지 않는다** |
 | 파드 `Ready` | **false — 여기서 드러난다** |
 | 외부 HTTP 코드 | **503 — 사용자가 겪는 것** |
 > **A-0 에서 나는 `up` 을 "가장 중요한 합성 지표"라고 썼다.**
 > 절반만 맞다. `up` 은 **대상이 사라진 것**을 잡지만 **대상이 살아서 못 쓰는 것**은
 > 못 잡는다. 후자가 운영에서 훨씬 흔하다.
 >
 > **알림은 `up` 이 아니라 readiness 와 외부 응답 코드에 걸어야 한다.**
 이 실험대에는 아직 `kube-state-metrics` 가 없어 파드 readiness 가 지표로
 남지 않는다. **관측 스택에 빠진 것을 이 실험이 찾아냈다** — 보완 항목이다.
 ---
 ## 8. 복구 — 자동이었다
 ```bash
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 ```
 ```
  재기동 시각: 11:57:09
  +15초  keycloak-0 true  keycloak-1 true  | 외부 HTTP 200
  → 서비스 복귀
  재시작 횟수:  keycloak-0 = 0,  keycloak-1 = 0
  정지 전 세션: online 세션 5 건 살아남음
 ```
 | | |
 |---|---|
 | 회복 시간 | **약 15초** (DB Ready 이후) |
 | 사람 개입 | **없음** |
 | Keycloak 재시작 | **불필요** — `restarts=0` |
 | 세션 | **살아남음** — DB 에 있으므로 |
 **커넥션 풀이 스스로 재연결하고 readiness 가 다시 UP 이 되면서 Service 에
 복귀했다.** `readiness` 를 쓴 설계의 이득이 여기서 나온다 — `liveness` 였다면
 파드가 재시작되어 캐시까지 날아갔을 것이다.
 ### 개념 — readiness 와 liveness 를 가르는 기준
 | | 실패하면 | 언제 쓰나 |
 |---|---|---|
 | **liveness** | **재시작** | 재시작하면 나아지는 문제 (교착, 메모리 누수) |
 | **readiness** | **트래픽에서 격리** | 재시작해도 안 나아지는 문제 (**의존 대상이 죽음**) |
 **DB 장애에 liveness 를 걸면 재앙이다.** 모든 파드가 무한 재시작하고,
 DB 가 돌아와도 CrashLoopBackOff 의 백오프 때문에 회복이 늦어진다.
 ---
 ## 9. 재현 절차 (명령어)
 ```bash
 # 0. 상주 탐침 (임시 파드는 계측에 부적합 — A-1 참조)
 kubectl -n keycloak-lab run a2-probe --image=curlimages/curl:8.11.1 \
  --restart=Never --command -- sleep 7200
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a2-probe --timeout=120s
 # 1. 토큰 발급 (access 60초 안에 시험을 끝내야 한다)
 kubectl -n keycloak-lab exec a2-probe -- sh -c \
  'curl -s -X POST http://<k0>:8080/realms/master/protocol/openid-connect/token \
     -d grant_type=password -d client_id=admin-cli \
     -d username=admin -d password=<pw> > /tmp/tok.json'
 # 2. DB 정지
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
 kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 # 3. 네 경로
 kubectl -n keycloak-lab exec a2-probe -- curl -s -o /dev/null -w '%{http_code}\n' ...
 # 4. 영향 범위
 kubectl -n keycloak-lab get endpoints keycloak \
  -o jsonpath='{.subsets[*].addresses[*].ip}'          # 비어 있으면 전면 장애
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 # 5. up 이 거짓말하는 것을 확인
 curl -s "http://localhost:19090/api/v1/query?query=up%7Bjob=%22keycloak%22%7D"
 # 6. 복구
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 ```
 ---
 ## 10. 다음 실험에 남기는 것
 | 실험 | 이 실험이 준 것 |
 |---|---|
 | **A-3** DB 강제 종료 | 정상 정지는 데이터를 안 잃었다. **강제 종료는?** (`synchronous_commit OFF`) |
 | **A-4** 노드 상실 | postgres 가 kc-lab-2 에 있으므로 그 노드를 죽이면 **A-2 가 함께 일어난다** |
 | **D-1** 백업·복구 | 여기서는 DB 가 되살아났다. **데이터가 사라졌다면?** |
 | 관측 스택 | **`kube-state-metrics` 가 없어 파드 readiness 가 지표로 안 남는다** — 보완 필요 |
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
DongHyeonkaandClaude Opus 5	4177fb6a48	docs: A-2 — losing the database takes every node down while up stays 1 Both pods go NotReady, the Service endpoint list empties and the front door returns 503, so adding Keycloak replicas buys nothing against database loss. The node holding the session in cache fails too, because a refresh writes LAST_SESSION_REFRESH. Recovery was automatic in about fifteen seconds with no restart, which is what readiness rather than liveness buys. The observability finding matters as much: up stayed at 1 through a total outage, so alerting on it would have caught nothing. kube-state-metrics is missing and pod readiness is therefore not recorded as a metric. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 11:57:55 +09:00
DongHyeonkaandClaude Opus 5	2a98ef1090	docs: A-1 — sessions survive a JGroups partition but logout invalidation does not Cutting TCP 7800 leaves cross-node refresh working (200), confirming sessions travel through PostgreSQL rather than the cluster transport. Logout is the opposite: the database row is deleted but the other node answers from its stale local cache, so the A-0 conclusion that invalidation rides the database is corrected here. Two things the plan did not anticipate: a NetworkPolicy cannot sever an established connection because conntrack accepts it before policy evaluation, and Keycloak reports the partition through its readiness probe so the split node removes itself from the Service. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 11:52:49 +09:00
DongHyeonkaandClaude Opus 5	9c3cde457e	docs: close nine gaps found by re-reading every open question in full Cross-checked each question's 남은 미지수, 다음 검증 and 제약 against the plan item by item. Adds B-0 (autoconfiguration actually chosen), B-6 (encryption key rotation) and B-7 (oauth2-proxy cookie secret rotation) as new experiments, plus lock-holder death, rotation-disabled comparison, partial-logout recovery, store latency and the Q4 design checklist. Restores the Redis persistence comparison and records the correct index URL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 11:16:59 +09:00
DongHyeonkaandClaude Opus 5	f1e8c35805	docs: plan all remaining experiments with architecture, injection points and predictions Twenty experiments across four layers, each with a topology diagram marking where the fault goes in, the metrics to watch, a falsifiable prediction written before the run, and a pass/fail rule. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 10:50:23 +09:00
DongHyeonkaandClaude Opus 5	1de6108157	docs: add the prerequisite knowledge this lab assumes Builds up from HTTP statelessness to why session storage location determines the operational response, so the measurements have context to land in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 10:24:21 +09:00
DongHyeonkaandClaude Opus 5	22d873eb4f	docs: capture the SQL the other node actually runs, and correct the replication claim PostgreSQL statement logging shows keycloak-1 reading and updating the session created on keycloak-0. The same transaction reveals optimistic locking via VERSION, SKIP LOCKED, and synchronous_commit turned off. Fixes the earlier concept note that credited Infinispan with cross-node propagation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 10:14:45 +09:00
DongHyeonkaandClaude Opus 5	e5ebaeb623	docs: prove sessions are shared by PostgreSQL, not Infinispan replication Experiment 0 with three probes: cross-node refresh/logout, cache counter deltas around a single login, and cache entry ownership. Each node caches only what it handled; cache totals sum exactly to the database count. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 09:58:10 +09:00
DongHyeonkaandClaude Opus 5	006da7d490	docs: record observability setup and add concept layers 10-13 Adds Kubernetes resources (StatefulSet, PVC, Secret, RBAC, placement), Keycloak clustering internals (Infinispan, JGroups), Prometheus concepts and virtualization operations. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 09:21:45 +09:00
DongHyeonkaandClaude Opus 5	d5cc2b55a9	fix: grant nodes/proxy so kubelet metrics can be scraped Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 09:14:51 +09:00
DongHyeonkaandClaude Opus 5	0bb0e0ac49	feat: add Prometheus, node-exporter and Grafana for fault-injection observability Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 09:13:41 +09:00
DongHyeonkaandClaude Opus 5	33878e8880	docs: record multi-node cluster setup, rationale and formation evidence Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 17:26:45 +09:00
DongHyeonkaandClaude Opus 5	6dce35ec83	feat: deploy Keycloak multi-node cluster with PostgreSQL Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 17:17:25 +09:00
DongHyeonkaandClaude Opus 5	001efd624a	docs: correct the memory analysis to distinguish host and guest headroom Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 17:02:11 +09:00
DongHyeonkaandClaude Opus 5	d6f8b9f8b3	docs: restructure roadmap into A/B/operations layers and add five operational items Adds backup rehearsal, version upgrade, observability, secret management and certificate renewal. Corrects the experiment order so the refresh-token contention test runs after the shared store exists. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:56:13 +09:00
DongHyeonkaandClaude Opus 5	df4d3b4345	docs: map published open questions to lab coverage and fix experiment order Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:44:12 +09:00
DongHyeonkaandClaude Opus 5	61ba5db259	docs: add lab operations guide with tooling, commands and drills Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:39:45 +09:00
DongHyeonkaandClaude Opus 5	bc784fcd6e	docs: surface the spoofing bypass finding in the roadmap Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:24:52 +09:00
DongHyeonkaandClaude Opus 5	ddcb1c08e6	docs: record the session store lab roadmap and progress Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:20:38 +09:00
DongHyeonkaandClaude Opus 5	e1ba9c5626	docs: record proxy-bypass closure with before and after evidence Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:17:24 +09:00
DongHyeonkaandClaude Opus 5	3af52bb66a	feat: narrow Traefik trusted range and restrict echo ingress to Traefik Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 16:15:28 +09:00
DongHyeonkaandClaude Opus 5	98874b0c6c	docs: retake staged evidence screenshots with indented output Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 15:52:47 +09:00
DongHyeonkaandClaude Opus 5	b708c8d503	feat: indent echo responses for readable evidence Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 15:48:57 +09:00
DongHyeonkaandClaude Opus 5	7737787937	docs: record the staged fix and post-fix evidence Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 15:33:40 +09:00
DongHyeonkaandClaude Opus 5	1c1b86e849	feat: let the app interpret forwarded headers Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 15:30:31 +09:00
DongHyeonkaandClaude Opus 5	2294c52095	feat: make Traefik trust forwarded headers from the host nginx Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 15:29:18 +09:00
DongHyeonkaandClaude Opus 5	69d4502757	docs: collect evidence for the two-hop header contract failure Control experiment isolates two independent causes: the nginx 443 block still emits X-Forwarded-Proto http, and Traefik rewrites forwarded headers regardless. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 15:04:38 +09:00
DongHyeonkaandClaude Opus 5	ae1f391598	docs: expand two-hop header contract with switch locations and per-pattern impact Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 14:57:08 +09:00
DongHyeonkaandClaude Opus 5	844d6f1d33	docs: measure and diagnose the two-hop proxy header contract Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 14:35:27 +09:00
DongHyeonkaandClaude Opus 5	a831792c5c	docs: map deploy/ assets and record why unapplied configs are kept Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 14:18:08 +09:00
DongHyeonkaandClaude Opus 5	bcfdeb93ee	docs: explain every setting used in the echo manifest Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 14:11:18 +09:00
DongHyeonkaandClaude Opus 5	deae8966b8	docs: record why Docker must not be installed on the lab host Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 13:53:36 +09:00
DongHyeonkaandClaude Opus 5	6c90468c5a	feat: report pod address from echo endpoint Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 13:44:29 +09:00
DongHyeonka	51bb055d61	feat: 2홉 구성 진행	2026-09-03 11:46:56 +09:00
DongHyeonka	c22b217fbd	chore: 메타데이터 gitignore	2026-09-02 14:44:06 +09:00
		`@@ -0,0 +1,2 @@`
							`[ 75ms] [ERROR] Failed to load resource: the server responded with a status of 404 (Not Found) @ https://hyeonworks.com/questions:0`
							`[ 100ms] [ERROR] Failed to load resource: the server responded with a status of 404 (Not Found) @ https://hyeonworks.com/favicon.ico:0`
		`@@ -0,0 +1 @@`
							`[ 149ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1 @@`
							`[ 103ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1 @@`
							`[ 95ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1 @@`
							`[ 132ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1 @@`
							`[ 239ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1 @@`
							`[ 105ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1 @@`
							`[ 108ms] [ERROR] Failed to load resource: the server responded with a status of 401 (Unauthorized) @ https://hyeonworks.com/api/v1/studio/session:0`
		`@@ -0,0 +1,2 @@`
							`- main [ref=e7]:`
							`- status "Loading" [ref=e10]`