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>
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
---
|
|
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로 거부한다**
|
|
다섯 번째 규칙을 채택한 결정이다.
|
|
|