Service Accounts

결론부터

서비스 계정은 사람의 password와 browser session을 빌리지 않고 client 자체의 credential로 짧은 access token을 받는다.

배치 작업이나 백엔드 서비스가 API를 호출할 때 사용자 로그인을 흉내 내면 password 보관, MFA 우회, 퇴사자 계정 의존 문제가 생긴다. Keycloak에서는 confidential client의 service account와 client_credentials grant로 별도 machine identity를 만든다.

이 장에서 처음 나오는 말4개

client credentials grant

client가 자기 credential을 token endpoint에 제시해 자기 권한의 access token을 받는 OAuth grant.

service account

client credentials token의 subject가 되는 client 전용 사용자 모델.

client role scope

service account에 부여한 역할 가운데 실제 token에 포함할 수 있는 역할의 경계.

machine identity

사람이 아니라 서비스·작업·자동화 주체를 식별하는 계정.

이 장에서 답할 질문

• 사용자 로그인과 service account 인증은 무엇이 다른가?
• service account에 역할을 부여해도 token에 없을 수 있는 이유는 무엇인가?
• client secret과 access token은 어떻게 제한하고 교체하는가?

전용 client를 만든다

Client authentication과 Service accounts roles를 켜고 Standard Flow, Implicit Flow, Direct Access Grants는 끈다. 작업 하나가 맡은 API와 권한이 다르면 client도 분리한다. 사람의 계정이나 admin-cli를 자동화에 재사용하지 않는다.

Keycloak service account 문서는 token endpoint에 grant_type=client_credentials, client ID와 credential을 보내는 흐름을 설명한다. 이 grant에는 browser redirect, 사용자 password, SSO session이 없으며 보통 refresh token도 발급하지 않는다.

worker -- client_id + client_secret --> Keycloak token endpoint
worker <-- short-lived access token ----- Keycloak
worker -- Bearer access token ----------> API

두 권한 경계를 모두 줄인다

token 역할은 service account에 부여된 역할과 client가 scope로 허용한 역할의 교집합이다. Full Scope Allowed를 끄고 필요한 app-user만 양쪽에 둔다. API는 이어서 서명, 고정 issuer, 자기 audience, 만료와 필요한 역할을 모두 검증한다.

경계	이 실습의 값	빠졌을 때
service account 역할	app-user, api-admin 없음	권한 자체가 없음
client role scope	app-user, api-admin 없음	부여됐어도 token에 포함되지 않음
audience mapper	lab-api	API의 audience 검증에서 401
API 역할 검사	/user: app-user, /admin: api-admin	인증됐어도 권한 부족이면 403

실제 token과 API 결과를 검증한다

cd labs/keycloak
./internal/verify/verify-d18.sh

진단은 d18-worker client를 멱등하게 만들고 오답 secret이 token endpoint에서 거부되는지 확인한다. 정상 access token은 RS256 서명·issuer·lab-api audience·만료를 검증했고 subject는 service-account-d18-worker, 역할은 app-user만이었다. 같은 token으로 무토큰 /user는 401, /user는 200, /admin은 403이었다. refresh token은 없었다.

credential과 token을 운영한다

• client secret은 저장소에 커밋하지 않고 secret manager나 제한된 파일로 주입한다.
• 교체 시 새 credential 배포와 이전 credential 폐기 순서를 정하고, token 수명만큼 겹침을 고려한다.
• access token은 로그·URL·오류 본문에 남기지 않고 API별 audience와 짧은 수명을 사용한다.
• 가능하면 플랫폼이 발급하는 workload identity와 key rotation을 검토한다. static secret은 유출 시 client가 된다.
• client별 token 발급 실패, 비정상 발급량과 API 401/403을 관찰하되 token 원문은 수집하지 않는다.

요약

• 서비스 계정은 사람의 로그인과 session 없이 client credentials로 자기 access token을 받는다.
• 최종 역할은 service account 역할과 client role scope의 교집합이며 API 검증이 마지막 경계다.
• client secret과 token은 최소 권한·짧은 수명·안전한 저장·교체 절차를 함께 운영한다.