GitHub OIDC와 배포 자격 증명, 열쇠를 두지 않고 배포하기

방문객에게 현관 비밀번호를 알려 주는 것과 방문증을 발급하는 것은 달라요. 비밀번호는 한 번 알려 주면 회수할 수 없고 누구에게 옮겨 갔는지도 알 수 없어요. 방문증은 저녁이면 만료되고, 누구에게 발급했는지 기록이 남아요.

배포를 자동화할 때도 같은 선택을 해요. GitHub에서 실행되는 배포 작업이 AWS에 접근하려면 자신을 증명해야 하거든요. OIDC(OpenID Connect)는 이때 GitHub가 알려 주는 작업의 신원을 AWS가 확인하도록 연결해 주는 규약이에요. 오래 보관하는 키를 없애려면, 대신 어떤 신원을 믿을지 구체적으로 정해야 해요.

저장소에 넣어 둔 키의 문제

가장 흔한 방식은 AWS에서 액세스 키를 발급받아 저장소의 비밀 값 칸에 넣어 두는 것이에요. 동작은 잘 해요. 문제는 그 키에 수명이 없다는 데 있어요.

수명이 없다는 것은 세 가지를 뜻해요. 지우기 전까지 계속 유효하고, 어딘가로 복사되어도 알 수 없으며, 복사본이 몇 개인지도 셀 수 없어요. 사람이 주기적으로 교체하기로 정해도 그 약속은 대체로 지켜지지 않아요. 앞 시리즈에서 다룬 대로 이런 규칙은 기억에 맡기면 무너져요.

신뢰를 미리 등록해 두기

다른 방식은 키를 아예 두지 않는 것이에요. AWS 쪽에 그 발급처를 신뢰할 대상으로 미리 등록해 두고, 배포가 실행될 때마다 그 자리에서 짧게 사는 자격 증명을 받아 써요.

GitHub 문서는 이 방식을 이렇게 설명해요. 워크플로가 장기 AWS 키 대신 AWS의 보안 토큰 서비스에서 단기 자격 증명을 받게 하고, 토큰 발급 권한과 AWS 리소스 권한은 서로 다른 것이에요. 받아 온 자격 증명은 AWS의 임시 자격 증명이라 정해진 시간이 지나면 저절로 만료돼요. 유출돼도 그 시간이 지나면 쓸 수 없다는 뜻이에요.

여기서 실제로 중요한 것은 그다음이에요. 신뢰를 등록할 때 어느 저장소의 어느 흐름까지 허용할지 조건을 함께 적어요. 같은 문서가 이 조건으로 허용할 저장소와 브랜치, 환경을 제한하라고 권해요. 이 조건을 넓게 쓰면 무슨 일이 생기는지가 이 글에서 가장 중요한 대목이에요. 조건이 느슨하면 전혀 다른 저장소의 워크플로가 그 역할을 맡아 제 계정에서 작업할 수 있어요. 키를 없앴는데 문은 더 넓게 열어 둔 상태가 돼요.

켰다고 옛 키가 사라지지는 않는다

전환 작업에서 가장 자주 빠지는 단계가 이것이에요. 새 방식을 켜면 배포가 잘 되고, 잘 되니까 끝난 것처럼 보여요. 그런데 옛 키는 아무 데도 가지 않았어요. 저장소의 비밀 값 칸에 남아 있고, 실행 환경 변수에 남아 있을 수 있고, 다른 도구나 개인 계정에도 복사본이 있을 수 있어요.

예전 키가 남아 있으면 실제로 어느 자격 증명이 쓰이는지도 살펴봐야 해요. 사용하는 SDK와 배포 도구의 선택 순서에 따라 환경 변수의 고정 키가 먼저 선택될 수 있어요. 배포 성공만으로는 새 인증 경로를 거쳤다고 단정할 수 없는 거예요. AWS가 기록한 실행 주체까지 맞아야 전환을 확인할 수 있어요.

무엇을 하나	얻는 것	이것만으로는 안 되는 것
신뢰 등록과 조건 지정	키 없이 배포가 된다	조건이 넓으면 남의 저장소도 맡을 수 있다
역할에 권한 붙이기	필요한 작업만 허용된다	옛 키가 남아 있으면 그쪽이 쓰일 수 있다
옛 키 삭제	다른 경로가 닫힌다	어디에 복사됐는지는 따로 찾아야 한다

세 줄이 순서대로 하나의 작업처럼 보이지만 실제로는 각각 끝을 확인해야 하는 별개의 일이에요. 그리고 마지막 줄이 가장 오래 걸려요.

저는 무엇을 지웠나

제가 만드는 앱의 배포를 이 방식으로 옮기면서 가장 시간을 쓴 것은 켜는 일이 아니라 찾는 일이었어요. 켜는 데는 얼마 걸리지 않았고, 어디에 옛 키가 남아 있는지 확인하는 데 그보다 오래 걸렸어요.

찾다 보니 나온 것 가운데는 예전에 시험해 보려고 만들었다가 잊은 것도 있었어요. 그때는 곧 지울 생각이었는데, 앞 글에서 비용을 이야기하며 적은 것과 같은 이유로 지우는 일에는 마감이 없었어요. 다만 이쪽은 요금이 아니라 권한이 남아 있는 경우라 성격이 달라요. 쓰지 않는 자원은 돈이 나가고, 쓰지 않는 자격 증명은 아무 신호도 내지 않아요.

그래서 전환의 마지막 단계를 삭제가 아니라 확인으로 바꿨어요. 지웠다고 믿는 것과 목록을 다시 세어 본 것은 다른 상태였어요.