Github Actions CICD 파이프라인에 AWS Role 사용하기

매번 Github Actions로 돌리고 있는 CICD 파이프라인에서 쓰고 있는 Access Key과 Secret이 번거롭기도 하고 걱정도 되었는데 때마침 LG U+에 계시는 정영진 엔지니어님의 글(GitHub Action AWS에 IAM Role로 접근하기)을 읽고 한번 도입해봐야지 벼르던 차였다.

 

실제로 적용하는 것은 위의 블로그 글 만으로도 충분 했지만, 여기에 Github 공식문서를 참고 했다. 

 

 

Access Key를 사용하면 굉장히 직관적일 수 있고, 일반적이지만, Access Key를 직접 사용하는 방법은 보안상의 위험성이 있을 수 있다고 생각했다. 따라서 AWS Role을 사용하여 보안성을 높이고자 했다. 

 

위의 두 글에서 볼 수 있다시피, 가장 먼저 OpenID Connect (OIDC) ID 공급자를 생성하면서 과정을 시작한다. 

그렇다면 OIDC는 무엇인지 궁금해서 찾아봤다. 

 

OpenID Connect는 사용자 인증 및 권한 부여를 위한 프로토콜로서, 사용자가 로그인을 할 때 클라이언트가 사용자의 인증 정보를 요청하는 대신, 인증 서비스 제공자에게 리디렉션하여 로그인을 수행하기 위해서 사용된다. 이 때, 인증 서비스 제공자는 사용자의 로그인 정보를 확인하고, 사용자의 ID에 해당하는 JWT 형태의 ID Token을 발급한다. 이 ID Token에는 사용자의 신원 정보와 권한 정보가 포함되어 있으며, 클라이언트는 해당 ID Token을 검증하여 사용자의 인증을 수행하고, 필요한 사용자 정보를 추출, 이를 통해 클라이언트는 인증 서비스 제공자에서 사용자 정보를 가져와 자신의 애플리케이션에서 사용할 수 있다. 

 

Github에서 제공하는 그림으로 설명하자면 다음과 같다.

 

 

여기서 내가 이해한 원리는, Github Actions의 Jobs이 실행 될 때마다, GitHub OIDC Provider가, 토큰을 발행하고, 이 토큰을 AWS의 STS서비스가 받아 검증한 뒤, Role을 사용할 수 있는 짧은 유효기간을 가진 클라우드 임시 자격증명을 부여하게 된다는 것이었다. 

 

따라서 Github Actions의 workflow yaml 파일에서 다음과 같은 권한을 주는데, 이는 OIDC 에서 발급받은 ID Token을 사용할 수 있도록 Github Actions runner가 해당 토큰을 읽을 수 있는 권한을 부여하기 위해서 작성한다. (처음에 이 부분을 건너뛰고 그냥 지나쳐서 조금 시간을 썼다.)

permissions:
  contents: read
  id-token: write

 

위의 정영진 엔지니어님의 글에도 이미 하는 방법은 작성이 되어 있지만, 간단하게 요약해보자면, 

1. AWS IAM - Identity Provider - OpenID Connect 구성.
   • OIDC endpoint와 Audience 작성
2. 적절한 AWS 정책을 가진 역할(Role)을 생성.
3. Github Actions에 Role을 적용.

이렇게 간단하게 Github Actions에 access key를 직접 사용하는 대신, Role을 적용할 수 있다. 

 

이 방식의 장점은 크게 다음과 같다.

• AWS Role을 통해 AWS 리소스에 대한 안전한 액세스를 구현할 수 있다.
• IAM Role을 통해 최소 권한 부여가 가능해진다.
• Access Key Rotation에 따른 번거로운 작업이 줄어든다. 

 

매번 보안에 대해서 궁금하고 고민하고 있는데 좋은 글을 알게 되어서 적용해 볼 수 있었고 아주 작은 마음의 평화를 얻었다. 

이렇게 랜선으로 주니어에게 빛이 되어주시는 모든 분들께 감사하다는 말씀을 이 블로그 글을 빌어 드리고 싶다.