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

OpenStack 은 오픈소스 클라우드 플랫폼이고, 애플리케이션 크리덴셜(application credential)은 사용자 대신 API 를 호출할 때 쓰는 인증 키입니다.

OpenStack 기반 클라우드에서 Terraform 으로 floating IP 를 만드는데 계속 막혔습니다.

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 만 막힌다” 가 그 신호인데, 콘솔은 라이브 세션이고 키는 발급 당시 상태에 묶여 있기 때문입니다.