부트스트랩 on J2eff's Garage

맨 아래 거북이 — 제네시스 계정과 신뢰의 뿌리

Mon, 06 Jul 2026 11:00:00 +0900

6편에서 슬쩍 넘어간 게 있다. “씨앗 계정"이라 부르며 “하드코딩된 특별한 존재"라고만 하고 지나갔다. 이번 편은 그 씨앗의 정체를 밝히고, 거기서 시작된 질문을 끝까지 따라간다. 최초의 루트는 대체 누가 만드는가?

씨앗의 진짜 이름

씨앗은 아무 계정이 아니었다. 그건 제네시스 계정 — 모든 것이 거기서 파생되는 최초의 관리 계정이다. mincloud에서 그 번호를 000000000001로 못박았다. 지금까지 user/jeff 흉내를 내던 개발 자격증명을, 진짜 정체인 루트로 되돌린다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// 제네시스 '관리 계정'과 그 루트를 심는다 — 어떤 서명된 요청보다도
// 먼저 존재해야 하는 단 하나의 계정. AWS 가입 순간 루트가 존재하는 것과 같다.
func loadManagementRoot(store credstore.Store) string {
	account := cmp.Or(os.Getenv("MINCLOUD_MANAGEMENT_ACCOUNT_ID"), "000000000001")
	store.Put(accessKeyID, credstore.Credential{
		SecretAccessKey: secret,
		Identity: credstore.Identity{
			Account: account,
			UserID: account, // 루트의 UserId는 계정 ID
			ARN: "arn:aws:iam::" + account + ":root",
		},
	})
	return accessKeyID
}

이제 마스터 키로 신원을 물으면, 관리 계정의 루트가 돌아온다.

$ aws sts get-caller-identity --endpoint-url http://localhost:9900
{
 "UserId": "000000000001",
 "Account": "000000000001",
 "Arn": "arn:aws:iam::000000000001:root"
}

이게 AWS의 관리 계정(management account) 에 대응한다. 조직의 꼭대기 계정, 나머지 모든 계정이 그 아래에서 태어나는 뿌리다.

그런데 그 루트는 누가 만들었나

여기서 6편의 순환이 한 층 더 깊어진다. 계정을 만들려면 계정이 있어야 한다고 했다. 그래서 부트스트랩은 서명 밖에 있어야 한다고. 좋다. 그런데 그 최초의 관리 계정 루트 자신은 누가 만들었는가? 그것도 서명 밖에서 만들어져야 하는데, 그럼 그걸 만든 권한은 어디서 왔는가?

무한히 위로 올라갈 것 같지만, 그렇지 않다. 바닥은 다른 ‘키’가 아니다. 거북이 탑은 물리적·조직적 통제에서 끝난다.

mincloud의 경우, 제네시스 루트를 심는 건 loadManagementRoot다. 그럼 그걸 실행할 권한은? 바이너리를 실행할 수 있는 사람 — 이 박스를 통제하는 사람이다. 서명도 자격증명도 아니다. “기계에 손을 댈 수 있는가"가 최종 신뢰의 뿌리다.

AWS도 원리는 같다. IAM·계정 시스템 자체가 AWS가 운영하는 서버 위의 소프트웨어고, 그 최초 상태는 API가 아니라 인프라 프로비저닝으로 심긴다. 신뢰의 뿌리는 암호가 아니라 “데이터센터와 하드웨어를 물리적으로 소유·통제한다” 는 사실이다. 소프트웨어 위가 아니라 그 아래에서.

뿌리를 지키는 의식

그 최종 루트를 어떻게 안전하게 다루는가 — 여기가 진짜 정교하다. 원리는 은행이든 DNS든 CA든 똑같다.

HSM: 최상위 키가 탐침 방지 하드웨어 안에서 태어나 밖으로 나오지 않는다. 소프트웨어가 키를 ‘가지지’ 않는다.
에어갭: 루트 키는 네트워크에서 떼어 둔다.
M-of-N 분할 통제: 한 사람이 루트를 쓸 수 없다. n명 중 k명이 각자의 조각(스마트카드)을 모아야 작동한다.
키 세리머니: 최상위 키를 쓰는 건 다인원·기록·촬영·감사되는 의식이다.
거의 쓰지 않는다: 루트는 아래 계층에 위임하고 잠가둔다. 일상 작업엔 절대 나오지 않는다.

이게 추상이 아니다. DNSSEC 루트 키 세리머니나 CA 루트 키 세리머니를 찾아보면, 인류가 “위에 아무것도 없는 뿌리"를 만들고 지키는 방식이 문자 그대로 이렇다 — HSM, 다인원, 에어갭, 의식. (AWS 내부의 정확한 절차는 비공개지만, 이 산업 원리를 따른다.)

mincloud가 진짜 서비스가 된다면

지금 mincloud의 뿌리는 “로컬에서 바이너리를 실행하는 나"다. 이게 진짜 호스팅 클라우드가 되면, 그 뿌리는 사라지지 않고 옮겨간다 — “프로덕션 인프라와 시크릿 저장소를 통제하는 자"에게로.

그때 반드시 바뀌는 것들:

하드코딩 마스터 금지. 지금의 well-known 기본값(MINCLOUDTESTKEY0000A)은 로컬 편의일 뿐, 공개되면 백도어다. 프로덕션은 프로비저닝 때 유일한 루트를 생성해 시크릿 매니저(KMS/Vault)에 넣는다. mincloud엔 이미 그 주입구가 있다 —
```
MINCLOUD_ROOT_ACCESS_KEY_ID / MINCLOUD_ROOT_SECRET_ACCESS_KEY
```
이미지엔 절대 안 넣고, 배포 시 시크릿으로만 주입한다.
부트스트랩 문은 인터넷에 노출하지 않는다. 서명 없는 동작은 운영자 전용. 세상을 마주하는 건 서명된 API뿐이다.
시크릿 평문 저장 금지. 지금 DynamoDB에 시크릿이 평문으로 들어가는 건 mock이라 넘어가는 것이고, 진짜라면 해시/KMS 암호화다.

그리고 stakes가 오를수록 뿌리를 더 조인다. 작은 서비스면 “시크릿 매니저 + MFA + 감사"로 충분하고, 은행급이면 아까의 HSM+세리머니까지 간다. 요는, 진짜 서비스가 된다고 부트스트랩을 벗어나는 게 아니라, “누가 인프라를 통제하는가"를 더 형식화하고 강화할 뿐이라는 것이다.

다음: 이제 누가 계정을 만드는가

제네시스 루트가 섰다. 그럼 6편에서 아무나 열던 그 “계정 만드는 문"을 다시 볼 수 있다. 진짜 AWS에서 계정 생성은 아무 문이 아니다 — 관리 계정의 권한이다. 관리 계정이 서명해서, 그 아래 멤버 계정을 찍는다.

다음 편에서 그걸 만든다. 서명 없는 문은 이제 제네시스 하나에만 남기고, 나머지 계정은 관리 루트가 서명한 CreateAccount 로만 태어나게 한다. 그리고 그 문 앞에서, 이 시리즈에서 처음으로 “인증은 됐는데 권한이 없다” 는 대답을 만나게 된다.

최초의 계정은 어디서 오는가

Mon, 06 Jul 2026 10:00:00 +0900

5편까지 mincloud엔 계정이 딱 하나였다. 부팅할 때 심는 개발용 씨앗 자격증명. 그걸로 STS도 부르고 IAM 키도 발급했다. 그런데 그 씨앗을 안 쓰고 맨손으로 첫 키를 만들어 보려 하면, 벽에 부딪힌다.

$ aws iam create-access-key --user-name friend01 \
 --endpoint-url http://localhost:9910

Unable to locate credentials.

당연하다. create-access-key는 IAM 요청이고, IAM 요청은 SigV4로 서명해야 하고, 서명하려면 이미 자격증명이 있어야 한다. 키를 만들려면 키가 있어야 한다. 그럼 애초에 최초의 하나는 어떻게 존재하는가?

서명할 수 없는 문

답부터 말하면, 최초의 계정은 우리 API로 만들 수 없다. 만들면 안 된다.

CreateAccount 같은 걸 SigV4 API에 넣었다고 하자. 그 요청에 서명하려면 키가 필요하고, 그 키는 계정이 있어야 나오고, 계정은… 순환이다. 그래서 AWS도 가입(sign-up)을 SigV4 API로 만들지 않았다. 가입은 완전히 다른 평면이다.

서비스 평면 — sts, iam, ec2. SigV4로 인증한다. aws CLI가 여기랑 대화한다.
가입/콘솔 평면 — 인증이 아니라 다른 신뢰(이메일 확인·결제)로 계정과 루트를 계정 밖에서 찍어낸다. 여기엔 액세스키가 필요 없다 — 그걸 처음 만드는 곳이니까.

즉 부트스트랩은 서명의 바깥에 있어야 한다. mincloud도 똑같이 둘로 나눈다. 서비스 평면은 그대로 두고, 계정을 찍어내는 일은 서명하지 않는 별도의 문에 둔다. 그 문의 신뢰는 서명이 아니라 “이 배포에 손을 댈 수 있는가"다.

1
2
3
4
5
6
7
8
9


// admin 서브커맨드는 부트스트랩 평면이다. 서명하는 서비스 API가 아니라,
// 최초 자격증명을 '만드는' 쪽. 그래서 SigV4를 거치지 않는다.
func main() {
	if len(os.Args) > 1 && os.Args[1] == "admin" {
		runAdmin(os.Args[2:])
		return
	}
	runServer()
}

지금까지 쓰던 씨앗 자격증명은, 사실 “이미 가입돼 있는 계정 하나를 미리 박아둔 것"이었다. 이제 그 문을 진짜로 연다.

계정을 찍어내다

admin create-account는 새 계정을 만든다. 계정 ID, 루트 유저, 그리고 그 계정만의 루트 액세스키/시크릿을 발급해 credstore(5편의 DynamoDB)에 저장하고, 운영자에게 건넨다.

$ mincloud admin create-account
account created — hand the root credential to the account owner:
 Account: 340106438124
 Root AccessKeyId: AKIAE6L7MMXWPV4XWCNQ
 Root SecretKey: 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

(여기 값은 로컬에서 방금 만든 가짜다.) 이 문은 배포 안에서만 연다. 서명이 없으니 아무 데서나 두드리게 두면 안 되고, “박스에 접근할 수 있는 운영자” 가 신뢰의 경계다. 이게 AWS 콘솔 가입의 mincloud판이다 — 계정 밖 신뢰로 루트를 찍어내는 문.

받은 루트키로 STS에 물으면, 신원이 돌아온다.

$ aws sts get-caller-identity --endpoint-url http://localhost:9900
{
 "UserId": "340106438124",
 "Account": "340106438124",
 "Arn": "arn:aws:iam::340106438124:root"
}

Arn이 :root로 끝나고, UserId가 계정 ID와 똑같다. 이게 루트의 표식이다. (뒤에서 IAM 유저와 대조한다.)

12자리는 어디서 오나

여기서 멈칫할 수 있다. 저 340106438124라는 12자리는 그냥 랜덤으로 뽑은 숫자인가? 그러면 계정 ID와 액세스키가 아무 관계 없는 두 난수가 된다. 그런데 진짜 AWS는 그렇게 안 한다.

잘 알려진 사실인데(Tal Be’ery, Aidan Steele의 연구), AWS 계정 ID는 액세스키 ID 안에 인코딩돼 있다. AKIA… 키만 있으면 API 호출 없이 오프라인으로 계정을 복원할 수 있다.

1
2
3
4
5


import base64
def account_of(key):
 raw = base64.b32decode(key[4:]) # AKIA 뒤 16글자 → 10바이트
 z = int.from_bytes(raw[0:6], "big") # 앞 6바이트(48비트)
 return "{:012d}".format((z & 0x7fffffffff80) >> 7)

mincloud도 이 방식을 그대로 따랐다. create-account가 12자리를 정하면, 발급하는 액세스키가 그 계정을 base32 본문에 품도록 만든다. 그래서 우리가 만든 키를 진짜 공개 디코더에 넣어도 우리 계정이 나온다.

$ mincloud admin whoami AKIAE6L7MMXWPV4XWCNQ
AKIAE6L7MMXWPV4XWCNQ -> account 340106438124

$ python3 decode.py AKIAE6L7MMXWPV4XWCNQ
340106438124

계정이 “떠다니는 난수"가 아니라 키가 지니고 다니는 값이 된 것이다. 눈으로도 보인다. 같은 계정에서 발급한 두 키는 앞부분을 공유한다.

AKIAE6L7MMXW PV4XWCNQ ← 루트
AKIAE6L7MMXW D6RJRYGX ← 같은 계정의 다른 키
──────────── ────────
계정 인코딩 키별 랜덤

앞 열두 글자는 계정에서 파생돼 똑같고, 뒤는 키마다 다른 랜덤이다.

루트가 유저를 만든다

이제 계정이 여럿이 될 수 있으니, 격리가 진짜 문제가 된다. 방금 만든 루트로 자기 계정 안에 IAM 유저 alice를 발급해 보자.

$ aws iam create-access-key --user-name alice --endpoint-url http://localhost:9910
...AccessKeyId: AKIAE6L7MMXWD6RJRYGX...

$ aws sts get-caller-identity --endpoint-url http://localhost:9900 # alice 키로
{
 "UserId": "AIDAY7WVA4T7QWXELDV5",
 "Account": "340106438124",
 "Arn": "arn:aws:iam::340106438124:user/alice"
}

alice는 이 루트가 속한 계정(340106438124) 안의 유저다. 루트가 만든 키가 다른 계정으로 새지 않는다 — 자격증명마다 자기 계정을 품고 다니기 때문이다. alice의 키를 오프라인 디코드해도 같은 340106438124가 나온다.

그리고 루트와 IAM 유저는 겉모습으로 구별된다.

정체	ARN 끝	UserId
루트	`:root`	계정 ID와 동일
IAM 유저	`:user/<이름>`	`AIDA…` 로 시작

get-caller-identity가 돌려주는 이 한 줄이, “너가 루트냐 유저냐"를 그대로 말해 준다. 이 구분은 뒤에서 인가(authorization)를 다룰 때 핵심 열쇠가 된다 — 루트는 암묵적으로 다 되고, :user/…는 정책이 있어야 뭔가 할 수 있다.

두 평면, 그리고 남은 빚

정리하면, mincloud는 이제 두 개의 문을 가진다. 서명하는 서비스 평면과, 서명하지 않는 부트스트랩 평면. 후자는 서명이 없어야 한다는 게 핵심이다 — 서명을 붙이는 순간 최초의 계정을 만들 길이 다시 막힌다.

이건 은근히 미끄러운 규칙이다. AWS CLI는 커스텀 모델(aws configure add-model)로 새 명령을 붙일 수 있어서, 마음만 먹으면 aws mincloud create-account 같은 걸 만들 수도 있다. 하지만 이 문만은 거기 두면 안 된다. CLI 명령이 되는 순간 SigV4로 서명되고, chicken-and-egg가 부활한다. 부트스트랩은 끝까지 서명 바깥에 있어야 한다.

정직하게 남는 빚도 있다. 씨앗 계정은 여전히 하드코딩된 특별한 존재고, create-account는 지금 누구 손을 거쳐야 하는지(승인·쿼터)를 따지지 않는다. “박스에 접근하면 계정을 무한정 찍는다"는 건 데모니까 넘어가는 것이지, 진짜 가입 플로우는 그 앞에 결제와 검증이 있다.

그런데 여기까지 오는 동안, 클라이언트는 늘 aws CLI가 명령 하나를 던지는 식이었다. 다음 편에서는 훨씬 까다로운 손님을 부른다 — Terraform. plan → apply → destroy를 돌리는 이 손님은, 명령 하나로는 만족하지 않는다. mincloud의 반쪽짜리 IAM이 진짜 CRUD가 되어야 하는 순간이 거기서 온다.