Quiz: ServiceAccounts and Tokens

쿠버네티스 1.24 부터 ServiceAccount 를 만들어도 Secret 이 자동 생성되지 않는 이유는?

• 만료 없는 장기 토큰 대신 수명이 정해진 토큰을 쓰도록 바뀌었기 때문
• SA 마다 Secret 을 만들면 etcd 용량이 크게 늘기 때문
• RBAC 바인딩이 생기면 토큰이 자동으로 발급되도록 바뀌었기 때문
• Secret 리소스 자체가 v1.24 에서 폐기됐기 때문

토큰에 audience 를 지정하는 목적은?

• 서명 페이로드에서 불필요한 클레임을 빼 토큰 길이를 줄이려고
• 그 대상에서만 유효하게 만들어 다른 곳에서의 재사용을 막으려고
• expirationSeconds 대신 만료 시간을 늘리려고
• aud 값에 맞는 ClusterRole 을 자동으로 붙여 주려고

automountServiceAccountToken: false 를 설정하는 가장 큰 이유는?

• NetworkPolicy 가 토큰 마운트 여부를 보고 이그레스를 판정해서
• projected 볼륨 마운트가 줄어 파드 기동 속도가 빨라져서
• API 를 호출하지 않는 워크로드에서 탈취 시 쓸 수 있는 자격증명을 없애려고
• ServiceAccount 지정 자체를 생략할 수 있게 되어서

파드에 ServiceAccount 를 지정하지 않으면 어떻게 되는가?

• system:anonymous 신원으로 API 를 호출하게 된다
• 네임스페이스의 default 어카운트를 쓰게 되어 여러 파드가 신원을 공유한다
• cluster-admin 권한을 가진 어카운트가 자동으로 붙는다
• admission 단계에서 거부되어 파드가 아예 기동하지 않는다

kubernetes.io/service-account-token 타입 Secret 을 손으로 만드는 방식의 가장 큰 위험은?

• projected 볼륨이 아니라서 파드에 마운트할 수 없다
• 토큰에 aud 가 없어 RBAC 인가가 적용되지 않는다
• 토큰이 갱신될 때마다 etcd 에 새 리비전이 쌓인다
• 만료가 없어 유출 시 무기한 유효하고 폐기를 사람이 책임져야 한다

TokenRequest 로 받은 토큰의 페이로드에서 주체를 확인하려면 어떤 클레임을 봐야 하는가?

• iss
• aud
• jti
• sub

파드에 마운트된 토큰이 만료되면 애플리케이션은 어떻게 해야 하는가?

• 새 토큰을 받으려면 파드를 삭제하고 다시 띄워야 한다
• kubelet 이 갱신하므로 토큰 파일을 다시 읽으면 된다
• TokenRequest 로 새 토큰을 직접 받아 교체해야 한다
• projected 토큰에는 만료가 없으므로 아무것도 하지 않는다