Spring Cloud Vault : invalid token
영구적인 Role Id가 생성하는 temporary token
Apr 22, 2026
신규 개발중인 Spring Boot 서버가 시작 직후에는 Vault를 정상적으로 읽다가, 하루에 한 번은 아래와 같은 오류를 내는 경우가 있었습니다.
* invalid token * permission denied org.springframework.vault.VaultException: Status 403 Forbidden [secret]: 2 errors occurred:
환경변수로 주입된 role-id와 secret-id가 만료되지도 않았는데, Spring Boot는 왜 403에러를 발생시키고 있는 걸까요?
문제상황
프로젝트는 application-prod.yaml에서 Vault AppRole 인증을 사용하고 있습니다.
- role-id 사용
- secret-id 새 배포주기마다
처음에는 role-id와 secret-id가 만료되지 않는데 왜 몇 시간 뒤에 인증 오류가 나는지 의문이 생겼습니다만, Vault AppRole에서 실제 secret 조회에 사용되는 것은 role-id/secret-id 자체가 아니라, 그 값으로 로그인한 뒤 발급받는 client token라는 사실을 알게 됐습니다.
즉 구조는 다음과 같습니다.
- 애플리케이션이 role-id와 secret-id로 Vault에 로그인
- Vault가 별도의 client token 발급
- 이후 secret 조회는 이 client token으로 수행
- 이 토큰이 만료되면 Vault 접근 실패
운영에서 확인한 AppRole 설정
실제 vault read role를 실행하면 아래와 같은 정보를 알 수 있는데..
- secret_id_ttl
- secret_id_num_uses
- token_ttl
- token_max_ttl
- token_period
이 값을 해석하면 다음과 같습니다.
- secret-id는 만료 기한
- secret-id는 사용 횟수
- 토큰 생성 시 ttl
- 토큰 연장 가능한 ttl(refresh 개념)
- periodic token인지 아닌지
결론적으로, 문제의 직접 원인은 secret-id가 아니라 token_ttl이었습니다.
왜 서버 시작 직후는 괜찮고 실제 배포후에 알게 됐을까요?
Hashicorp Vault는 그동안의 팀 내에서 Secret이 관리되지 않는 측면을 개선하기 위해, 제안되어 도입 됐습니다.
매일 코드를 수정하고 배포하는 주기 내에서 dev stage에서는.. 주로 local에서 실행한 걸 fe와 연결하는 과정에 있었고, 다른 팀들도 이와 크게 다르진 않았습니다.
그렇기 때문에 spring cloud vault의 lifecycle 옵션을 사용해서 token을 계속 갱신한다고 하더라도.. max ttl이 24h 때문에 갱신 자체가 24시간을 넘길 수는 없었습니다.
이걸 해결하려면 periodic token을 사용해야 하는데, 이건 영구적으로 secret id를 쓰는 것과 비슷하게 영구적으로 token을 발급받아 사용하는 개념입니다.
라이브 서비스 개념으로 본다면,
- 일반 renewable token
- 장점: Vault의 기본 TTL/max TTL 모델에 잘 맞고, 장기 고정 토큰을 피할 수 있음
- 단점: 결국 재인증 지점이 오고, 그 순간 AppRole login 경로, network, policy, secret-id 상태에 장애가 있으면 런타임 중단 가능
- periodic token
- 장점: 서비스가 살아 있는 동안 renew만 안정적으로 되면 계속 유지 가능
- 단점: 장기 생존 토큰이 되므로 보안 정책을 더 엄격히 봐야 하고, renew loop 자체의 안정성이 매우 중요함
계속 떠 있는 서버라면, 일반 renewable token은 언젠가 re-login이 강제되는 구조라 운영상 불안정 포인트가 남게 됩니다. 여기서 개념을 햇갈리면 안되는데, "renewable token"이라는 성질 자체라기보다, "non-periodic token이라 max TTL 뒤에 re-login이 강제되는 모델"이라는 점 입니다.
periodic token도 renew는 합니다. 차이는 renew의 목적이 다릅니다.
- 일반 renewable token의 renew 남은 수명을 늘리되 결국 상한에 걸림
- periodic token의 renew 서비스 생존 신호처럼 TTL을 period로 재설정 상한 없이 유지 가능 단, explicit_max_ttl이 있으면 예외
팀적으로 내린 결론만 본다면, 외부 노출이 없는 내부 서버의 경우는 periodic token을 사용하고 외부 노출이 있는 api 서버라면 renewable token을 사용하는 것에 대한 검토였습니다.
++
위 사용 사례에 대한 추가 반영 후 … dev stage에서 추세를 조금 더 확인하고 있습니다.
Share article