OpenStack 앱 크리덴셜 — 발급 시점 역할 고정

Terraform 으로 floating IP 를 만들려는데 계속 막혔습니다.

OpenStack 기반 클라우드라 사람이 콘솔에서 클릭하는 대신 코드로 만들어야 했고, 그러면 Terraform 이 쓸 인증 수단이 따로 필요합니다. 여기서 쓰는 게 애플리케이션 크리덴셜(application credential)입니다. 사용자 비밀번호를 그대로 주는 대신, 그 사용자를 대신해 API 를 호출할 수 있는 키를 따로 발급하는 방식입니다.

create_floatingip is disallowed by policy (PolicyNotAuthorized)

역할을 추가하고 토큰까지 다시 받아도 그대로였지만 웹 콘솔에서는 같은 작업이 됩니다. 이 “콘솔은 되고 API 는 막힌다” 가 결정적 단서였습니다.

AWS 키와 다른 모델 — 키에 저장된 역할 목록

AWS 액세스 키는 신원만 담고 요청마다 그때의 정책을 평가하기 때문에, 정책을 바꾸면 기존 키도 바로 새 권한으로 동작합니다.

OpenStack 의 애플리케이션 크리덴셜은 이쪽과 다르게 발급하는 순간의 역할 목록을 키 안에 그대로 저장합니다. 그래서 발급 후에 프로젝트에서 역할을 추가해도 그 키는 여전히 옛날 역할 목록으로 판정됩니다. 역할을 더해도, 토큰을 새로 받아도 소용없습니다 — 토큰은 그 키를 기반으로 나오기 때문입니다.

콘솔은 앱 크리덴셜이 아니라 라이브 세션으로 돌아가니 현재 역할이 그대로 반영되고, 키만 발급 당시 상태에 묶여 있어서 콘솔에서만 됐던 것이었습니다.

키에 어떤 역할이 저장돼 있는지는 이렇게 확인합니다.

GET /identity/v3/users/<user-id>/application_credentials
→ 키에 박힌 roles 목록이 옛날 그대로

발급 시점에 복사돼 들어간 값이라, 프로젝트에서 역할을 추가해도 이 목록은 안 바뀝니다.

해결 — 무중단 키 재발급

역할을 반영하려면 키를 다시 발급해야 하고, 앱 크리덴셜은 프로젝트당 개수 제한(예: 2개)이 있어서 무중단으로 하려면 두 번째 키를 먼저 만들고 바꿔치웁니다.

1. 새 역할이 반영된 상태에서 두 번째 키 발급
2. 설정(.envrc 등)의 자격증명을 새 키로 교체
3. 동작 확인 후 옛 키 삭제

문서의 권한 표와 실제 정책의 불일치

문서엔 프로젝트 Member 역할이면 모든 리소스를 다룰 수 있다고 돼 있었지만, 실제로 Member 는 floating IP 를 못 만들었습니다. 문서의 권한 표를 그대로 믿지 말고 안 되면 실제 정책(policy.yaml)이 요구하는 역할을 확인하는 게 빨랐습니다.

자격증명의 평가 시점 — 요청 시점 vs 발급 시점

클라우드마다 자격증명의 평가 시점이 다른데, AWS 키가 요청이 올 때마다 그 시점의 정책으로 판정하는 반면, OpenStack 앱 크리덴셜은 발급 시점의 역할 목록을 그대로 들고 갑니다. 권한을 바꿨는데도 키가 안 따라오면 그 키가 재발급이 필요한 종류인지부터 확인합니다. “콘솔은 되는데 API 만 막힌다” 가 그 신호고, 키에 저장된 역할 목록을 직접 조회해 보면 바로 갈립니다.