docs(keycloak-session-store): import the session-storage lab as a new project
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>
This commit is contained in:
co-authored by
Claude Opus 5
parent
43bccd08a8
commit
b2963105a8
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
kind: REFERENCE
|
||||
slug: a-single-admission-point-must-count-its-bypasses
|
||||
title: 단일 admission point는 우회 경로를 세어야 성립한다
|
||||
topic: redis-command-admission
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: reference:a-single-admission-point-must-count-its-bypasses
|
||||
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
||||
---
|
||||
|
||||
# 단일 admission point는 우회 경로를 세어야 성립한다
|
||||
|
||||
## 목적
|
||||
|
||||
단일 승인 지점이라는 선언을 그 지점이 실제로 유일하다는 증거로 읽는 것을 막는다.
|
||||
|
||||
## 규칙
|
||||
|
||||
1. 선언은 두 가지를 함께 주장한다
|
||||
지나는 것이 전부 검사된다는 것과 모든 것이 지난다는 것이다. 코드가 보장하는 것은 대개 첫 번째뿐이다.
|
||||
|
||||
2. 하위 계층 타입을 직접 참조하는 곳을 센다
|
||||
승인 지점이 감싸고 있는 타입을 상위 코드가 직접 부르면 그것이 우회다.
|
||||
|
||||
3. 임포트 목록이 빠른 지표다
|
||||
어떤 패키지에서 무엇을 가져오는지 집계하면 우회 여부가 드러난다.
|
||||
|
||||
4. 우회가 있으면 선언을 좁히거나 경로를 막는다
|
||||
둘 중 하나를 하지 않으면 다음 사람이 같은 오해를 한다.
|
||||
|
||||
5. 컴파일 시점에 막을 수 있으면 그렇게 한다
|
||||
하위 타입을 패키지 밖에서 볼 수 없게 하면 우회 경로가 생기지 않는다.
|
||||
|
||||
## 적용 조건
|
||||
|
||||
단일 진입점이나 단일 승인 지점을 표방하는 모든 계층
|
||||
|
||||
정책과 실행이 분리된 구조
|
||||
|
||||
## 예외
|
||||
|
||||
성능이나 특수 목적으로 의도적으로 우회를 허용하는 경로가 있을 수 있다. 그 경우 어떤 검사가 생략되는지가 그 자리에 적혀 있어야 한다.
|
||||
|
||||
## 예시
|
||||
|
||||
명령 정책 가드가 자기를 모든 명령이 지나는 단일 승인 지점이라고 적는다. 의미 어댑터 다섯이 가드도 실행기도 타입 API 도 참조하지 않고 게이트웨이를 30 회 직접 부른다.
|
||||
|
||||
허가 출처 확인이 그 우회로 함께 건너뛰어진다. 가드는 애플리케이션이 허가 인터페이스를 직접 구현하는 경우까지 막도록 설계되어 있다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **의미 어댑터 다섯이 gateway를 직접 불러 admission 아홉 단계를 건너뛴다**
|
||||
이 규칙을 만든 사례다.
|
||||
- **명령 카탈로그와 admission 아홉 단계**
|
||||
우회되는 대상이다.
|
||||
- **중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다**
|
||||
같은 계열의 확인 규칙이다.
|
||||
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
---
|
||||
kind: REFERENCE
|
||||
slug: server-metadata-defines-the-command
|
||||
title: 서버 메타데이터가 명령의 정의이고 정책 파일은 허용 범위다
|
||||
topic: redis-command-admission
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: reference:server-metadata-defines-the-command
|
||||
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
||||
---
|
||||
|
||||
# 서버 메타데이터가 명령의 정의이고 정책 파일은 허용 범위다
|
||||
|
||||
## 목적
|
||||
|
||||
정책 파일이 명령의 정의 노릇을 해서, 서버가 실제로 하는 일과 어긋난 채 허용 판정이 내려지는 것을 막는다.
|
||||
|
||||
## 규칙
|
||||
|
||||
1. 정의는 서버에서 온다
|
||||
명령의 키 스펙과 플래그와 인자 구조는 서버 메타데이터가 정본이다.
|
||||
|
||||
2. 정책 파일은 그 위에서 범위만 정한다
|
||||
무엇이 허용되고 무엇이 위험한지를 적는다. 명령이 무엇인지를 다시 적지 않는다.
|
||||
|
||||
3. 두 쪽의 드리프트를 검사한다
|
||||
서버 버전이 올라가면 정의가 바뀔 수 있다. 정책 파일이 옛 정의 위에 서 있는지 확인하는 검사가 필요하다.
|
||||
|
||||
4. 그 검사를 실제로 돌린다
|
||||
게이트라고 부르는 것과 빌드에 있는 것은 다르다.
|
||||
|
||||
5. 분류되지 않은 명령은 거부한다
|
||||
카탈로그가 답하지 못하는 명령을 통과시키면 정책이 적용되지 않은 명령이 실행된다.
|
||||
|
||||
## 적용 조건
|
||||
|
||||
명령 단위로 허용 여부를 판정하는 모든 데이터 저장소 클라이언트
|
||||
|
||||
서버 버전에 따라 명령 정의가 달라지는 환경
|
||||
|
||||
## 예외
|
||||
|
||||
서버 메타데이터를 조회할 수 없는 구성에서는 정의를 고정할 수밖에 없다. 그 경우 고정한 버전을 명시하고, 다른 버전에 붙었을 때의 동작을 정해 둔다.
|
||||
|
||||
## 예시
|
||||
|
||||
명령 메타데이터 드리프트를 검사하는 코드가 있고 정책 파일 머리 주석이 그것을 빌드 게이트라고 부르지만, 그 검사를 실행하는 태스크도 CI 단계도 없다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **명령 카탈로그와 admission 아홉 단계**
|
||||
카탈로그가 승인에서 하는 역할이다.
|
||||
- **build gate라 불리는 catalog drift 검사가 어디에서도 실행되지 않는다**
|
||||
네 번째 규칙이 필요한 사례다.
|
||||
- **분류되지 않은 명령은 fail-closed로 거부한다**
|
||||
다섯 번째 규칙을 채택한 결정이다.
|
||||
|
||||
Reference in New Issue
Block a user