이름이 같은 계정과 서로 다른 자격증명

한 줄 요약

권한 회수는 할 수 있는 일을 바꾸고, 서비스 계정 UID 변경은 옛 토큰이 가리키는 신원을 바꿉니다.
같은 이름으로 계정을 재생성해도 옛 토큰과 기존 RoleBinding이 같은 방식으로 처리되지는 않습니다.

왜 이게 필요했나

예시 상황입니다. reader 토큰이 노출됐다는 연락을 받았습니다. 운영자가 계정을 삭제하고
같은 이름으로 다시 만든 뒤 옛 토큰의 401을 보고 대응을 마쳤습니다. 그런데 새 토큰으로
조회하니 이전과 같은 데이터가 보입니다. 토큰 폐기에 실패한 것일까요?

성급히 결론 내리기 전에 무엇을 지우고 무엇을 남겼는지 확인해야 합니다. 계정은 새로
만들었지만 그 이름을 대상으로 하는 RoleBinding은 그대로일 수 있습니다. 새 신원에
다시 권한이 연결되는 현상을 이해해야 사고 대응의 종료 조건도 정확히 정할 수 있습니다.

어떻게 동작하나

같은 이름, 다른 UID

이번 실험은 기존 Pod와 RoleBinding을 남기고 SA만 재생성합니다. 원래 토큰의 sub는
system:serviceaccount:kcsa-identity:reader입니다. 새로 발급한 토큰도 sub는 같습니다.
그러나 두 토큰의 서비스 계정 UID는 다릅니다. 사람 눈에 보이는 이름만 비교하면
서로 다른 객체를 같은 객체로 착각할 수 있습니다.

탐침에서는 기존 토큰이 만료되기 전에 SA를 재생성했습니다. TokenReview의 인증 결과는
false가 됐고 API 조회는 401이 됐습니다. exp와 관측 시각을 함께 남겼기 때문에
단순히 오래 기다려 토큰이 만료된 결과와 구별할 수 있습니다. 기존 Pod UID도 함께
확인하여 Pod를 새로 만든 영향으로 설명하지 않도록 했습니다.

바인딩은 어떤 주체를 가리키는가

RoleBinding의 ServiceAccount 주체는 이름과 네임스페이스를 사용합니다. 이번 바인딩은
kcsa-identity의 reader를 가리킵니다. SA의 옛 UID를 보관해 그 객체만 영원히 허용하는
구조가 아닙니다. 다음처럼 결과가 달라지는 이유를 각 열에서 설명해 보세요.

| 상태 | 옛 토큰 | 새 토큰 | 바인딩 |
| --- | --- | --- | --- |
| 원래 계정, 최소 읽기 권한 | 자기 ConfigMap 200 | 아직 없음 | 원래 바인딩 존재 |
| Role의 rules를 비움 | 인증 true, 조회 403 | 아직 없음 | 그대로 존재 |
| Role 복원 후 SA 재생성 | 인증 false, 조회 401 | 발급하면 조회 200 | 같은 이름을 계속 가리킴 |
| 바인딩 제거 | 계속 401 | 인증 true, 조회 403 | 제거됨 |

이 표는 이번 개인 클러스터의 실제 관측을 학습용으로 정리한 것입니다. 새 토큰의 200은
옛 토큰이 되살아났다는 증거가 아닙니다. 새 UID를 가진 인증 결과와 이름 기반 인가가
결합된 결과입니다. 또한 바인딩 제거 후의 403은 새 토큰이 무효가 됐다는 뜻이 아닙니다.
인증은 여전히 true라는 별도 관측이 이 해석을 뒷받침합니다.

삭제할 때도 이름만 믿지 않는다

삭제 대상의 현재 UID를 읽고 기준선과 비교한 후 UID·resourceVersion 전제 조건으로
삭제를 요청합니다. 조사하는 동안 누군가 객체를 교체했다면 다른 객체를 지우는 대신
멈추고 재확인해야 합니다. 이번 도우미의 목적은 원래 계정과 바인딩만 바꾸는 것이며,
이름이 같다는 이유로 나중에 생긴 다른 객체까지 지우는 것이 아닙니다.

현장에서 만나는 모습

사고 대응에서는 먼저 노출된 자격증명, 사용 가능한 API, 연결된 워크로드, 다른 바인딩을
함께 조사합니다. SA 삭제는 그 계정을 사용하는 다른 작업에도 영향을 줄 수 있습니다.
이 실험의 삭제·재생성을 운영에 그대로 복사하지 마세요. 최소 권한 회수, 업무 중단 범위,
자격증명 재발급과 재배포, 재노출 원인 제거를 조율한 뒤 종료 조건을 확인해야 합니다.

다른 팀 요청을 함께 보내는 이유도 있습니다. 자기 요청의 거절만 확인하면 클러스터 전체를
망가뜨려도 성공처럼 보일 수 있습니다. 이번에는 다른 네임스페이스 reader의 인증 UID와
합성 ConfigMap UID, 정상 200 응답이 그대로인지 확인합니다. 이는 이 두 네임스페이스의
영향 범위 검증이지 플랫폼 전체 격리나 모든 사용자 업무의 무중단 증명은 아닙니다.

오프라인 JWT 검증과 온라인 검사도 구분합니다. 서명과 수명을 로컬에서 확인하는 서비스는
결합된 API 객체가 지금도 존재하는지 저절로 알 수 없습니다. 현재 결합 상태가 중요하다면
TokenReview 같은 온라인 검증이 필요합니다. 반대로 이번 단원의 클레임 디코딩은 오프라인
서명 검증 구현이 아니므로, 두 방식을 모두 구현해 비교했다고 보고해서는 안 됩니다.

삭제 대기 중인 객체의 유예 규칙과 이미 사라지거나 UID가 달라진 객체의 검사를 혼동하지
않습니다. 이번에는 실제 UID 변경과 API 결과를 함께 관측했습니다. 고정된 시간만 잔 뒤
성공으로 처리하는 방식은 신원 전환의 증거를 남기지 못합니다.

다음 실습에서 할 것

권한을 비웠다가 복원하고, 정확한 원래 SA를 동명 재생성한 뒤 새 토큰을 발급합니다.
마지막으로 원래 바인딩만 회수해 옛 401·새 403·다른 팀 200을 구별합니다. 관측마다
시각·UID·인증 결과·HTTP 상태를 남기고, 과거에 성공한 기록과 현재 상태를 나누어 해석하세요.
이전 단계의 파일을 지워 기록을 맞추지 말고 무엇이 언제 달라졌는지 설명하는 것이 과제입니다.

공식문서

• [RBAC의 RoleBinding과 ServiceAccount 주체](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
• [결합 객체 수명과 온라인 검증](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)