DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
2.8 KiB
Plaintext
16 lines
2.8 KiB
Plaintext
## 3. Confirmed — raw allowlist 기본값은 없는 리소스를 가리키고, 그것이 의도다
|
|
|
|
`RedisSdkSettings.Raw.policyResource` 기본값은 `classpath:redis-sdk/raw-command-allowlist.yml`인데, 저장소에 그 파일은 **없다**(`159-...` §8.3b, `git ls-files` 매치 0. 이 leaf의 main resource는 `AutoConfiguration.imports`와 `redis-sdk/redis-command-policy.yml` 둘뿐).
|
|
|
|
이것은 결함이 아니라 이미 잡혀 있는 함정이다. `requireRawPolicyResource`가 그 사실과 과거 증상을 함께 적는다 — "`validate()` only checks that the setting is non-blank, and the default points at … a resource this module does not ship. So enabling the raw gateway passed configuration validation and then **failed at the first raw command, from inside a request, against a live connection.** The allowlist is the entire authorisation model for that gateway; not being able to read it is a startup failure." test `enabledRejectsAMissingRawAllowlistResource`와 `enabledAcceptsAReadableRawAllowlistResource`가 양쪽을 고정한다.
|
|
|
|
## 4. Confirmed — "하나의 상수, 두 독자"가 실제로 지켜진다
|
|
|
|
`RedisCorrectnessRoles`의 javadoc은 이 클래스가 존재하는 이유를 과거 장애로 설명한다 — `redisRequired` health contributor를 만들지 결정하는 조건과 readiness 그룹이 그 이름을 넣어도 되는지 결정하는 post-processor가 서로 어긋나자, Boot가 존재하지 않는 contributor를 named group에서 발견하고 **모든 Redis-off 배포가 startup에서 실패**했다("Included health contributor 'redisRequired' in group 'readiness' does not exist").
|
|
|
|
주장을 검증했다. `app-bootstrap`의 `RedisReadinessGroupPostProcessor`가 이 leaf의 상수를 **실제로 import해서 읽는다** — `:45`에서 `RedisCorrectnessRoles.anySelected(environment)`, `:54`에서 `RedisCorrectnessRoles.REQUIRED_HEALTH_CONTRIBUTOR`. 술어가 복제돼 있지 않다. 주장대로다.
|
|
|
|
두 contributor의 분리도 그 자체로 규칙이다 — `redisOptional`은 도달 불가일 때 `DOWN`이 아니라 커스텀 `DEGRADED`를 반환하고("a status the readiness group understands as failure would remove a healthy pod from service — shrinking capacity during the exact incident that needs it most"), `redisRequired`는 correctness 역할(session·idempotency·rate-limit·lease) 중 하나가 Redis를 선택했을 때만 존재하며 `DOWN`을 낸다. probe는 플래그가 아니라 실제 왕복이고("`isOpen()` on a driver connection reports what the client believes, which stays true for as long as it takes TCP to notice"), 실패 detail에는 예외 **클래스 이름만** 넣는다("a driver message can carry an endpoint, a username, or a key").
|
|
|
|
## 5. P2 — README readiness 표와 build.gradle 주석이 실제 소스와 어긋난다
|