IAM
키는 내가 누구인지를 증명하고, 무엇을 할 수 있는지는 버킷에 적힌 규칙이 정한다
질문은 S3를 닫다가 생겼다. 키도 없이 브라우저로 hello.txt가 그냥 열렸는데, 실제 AWS에서도 그럴까. 그런데 aws 명령을 칠 때는 AWS_ACCESS_KEY_ID를 넣었다. 키는 왜 넣었을까에서 시작했다.
처음 짐작은 「넣기 · 지우기는 키가 필요하고, 조회는 키 없이 된다」였다. 조회는 열어 두고 바꾸는 일만 막아 둔 거라고 생각했다. 그래서 키 없이 넣고 지워 봤다.
curl.exe -X PUT --data "bye" http://localhost:4566/my-bucket/bye.txt
curl.exe -X DELETE http://localhost:4566/my-bucket/bye.txt
둘 다 됐다. 넣은 bye.txt가 브라우저로 열렸고, 지우자 사라졌다. 짐작이 틀린 것처럼 보였는데, 대답한 것이 실제 AWS가 아니라 내 PC의 Floci라는 점을 다시 봤다. Floci의 README.md에는 이렇게 적혀 있다.
Credentials can be any non-empty values unless you explicitly enable stricter service-specific auth checks.
키 없이 된 건 S3가 원래 그래서가 아니라 Floci가 키를 검사하지 않아서였다. 문장 뒷부분대로 Floci에는 S3 검사를 켜는 설정(FLOCI_SERVICES_S3_ENFORCE_AUTH)이 있어서, 검사를 켠 Floci를 4570 포트에 하나 더 띄워 같은 일을 해 봤다.
| 키 없이 조회 | 키 없이 넣기 · 지우기 | |
|---|---|---|
| 4566 Floci (검사 꺼짐) | 됨 | 됨 |
| 4570 Floci (검사 켜짐) | 막힘 (403 AccessDenied) |
막힘 |
검사를 켜니 조회도 키 없이는 안 됐다. 그래서 첫 짐작을 고쳤다. 조회가 원래 열려 있는 게 아니라, 기본은 다 막혀 있다.
그러면 홈페이지처럼 키 없는 방문자도 봐야 하는 파일은 어떻게 여나. 두 번째 짐작은 「S3에 규칙을 적어 두면, S3 앞단이 요청마다 그걸 확인하고 주거나 막는다」였다. 버킷에 이 규칙을 적었다.
aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":"*","Action":"s3:GetObject","Resource":"arn:aws:s3:::my-bucket/*"}]}
| 칸 | 값 | 뜻 |
|---|---|---|
Effect |
Allow |
허용한다 |
Principal |
* |
누구에게나 (키가 없어도) |
Action |
s3:GetObject |
파일 가져오기를 |
Resource |
my-bucket/* |
my-bucket 안의 모든 파일에 대해 |
규칙을 적자 키 없는 조회는 열리고, 키 없는 쓰기는 그대로 막혔다. 짐작이 맞았다. 규칙에 가져오기만 적었으니 가져오기만 열린 것이다.
마지막으로 남은 것은 키였다. 검사를 켠 4570에서도 키를 넣은 aws s3 mb · cp · ls는 규칙을 적기 전부터 다 됐다. 세 번째 짐작은 「키가 규칙을 알려 준다」였다. 키 값을 조금씩 바꿔 같은 aws s3 ls를 보내 봤다.
| 키 ID | 비밀 키 | 결과 |
|---|---|---|
test |
test |
목록이 보인다 |
test |
wrong |
SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. |
other |
test |
InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records. |
test라는 단어 안에 「쓰기는 되고 읽기는 안 된다」 같은 규칙이 들어 있을 수는 없다. 에러가 확인한 것도 규칙이 아니라 키 ID가 기록에 있는지, 비밀 키로 만든 서명이 맞는지였다. 그래서 세 번째 짐작을 고쳤다. 키는 「나는 이 키의 주인이다」를 증명할 뿐이고, 무엇을 할 수 있는지는 따로 적힌 규칙이 정한다.
- 검사를 끈 Floci(4566). 키 없이 넣어도 들어간다. Floci가 키를 검사하지 않아서다
- 검사를 켠 Floci(4570). 적힌 규칙이 없으니 키 없는 조회도 막힌다. 기본은 다 막혀 있다
- 키를 넣은 AWS CLI로 버킷에 규칙을 적는다. 누구에게나 파일 가져오기(GetObject)를 허용한다
- S3 앞단이 요청마다 규칙을 확인한다. 조회는 규칙에 있어 열리고, 쓰기는 없어 그대로 막힌다
- 키는 규칙을 담지 않는다. 키 ID가 기록에 있는지, 서명이 맞는지로 누구인지만 확인한다
여기서 Claude가 준 것은 재료다. Floci
README.md의 문장, 검사를 켜는 설정 이름(FLOCI_SERVICES_S3_ENFORCE_AUTH), 버킷 규칙 JSON과 그 칸의 뜻, 그리고 키 값을 바꿔 보낸 세 결과(Claude가 먼저 쳐 본 것)다. 「Floci라서 된 것이다」, 「규칙은 S3에 적고 앞단이 확인한다」, 「키는 쓸 수 있는 사람인지만 확인한다」는 내가 냈다. 전부 Floci로 확인한 것이고, 실제 AWS에서는 아직 확인하지 않았다.
IAM에서 아직 안 본 것
- 나는
test키로 규칙을 하나도 적지 않았는데, 왜 버킷 만들기 · 올리기 · 목록 보기가 다 됐을까. 키를 가진 쪽의 규칙은 어디에 적나 — 이 섹션을 닫다가 생겼다 - 실제 AWS의 S3에서도 키 없는 조회가 기본으로 막혀 있나 — 위 결과는 전부 Floci다