Skip to content

CI CD 환경 구축

Jump to bottom
min9805 edited this page Aug 22, 2024 · 10 revisions

image

CI/CD 과정은 총 7 단계로 이루어져 있다.

(현재 레포지터리 기준)

  1. User 가 Master(Main) Branch 에 Pull Request 발생시킨다.
  2. Github 는 Pull Request 를 기준으로 Github Actions 를 실행시킨다.
  3. Github Actions 내부에서 CI 과정이 진행되며, Build 결과 파일 (Jar) 이 생성된다.
  4. Github Actions 는 S3 에 해당 파일을 업로드한다.
  5. Github Actions 가 CodeDeploy 에 Deployment 를 생성한다.
  6. CodeDeploy 는 S3 로 부터 빌드 파일을 가져온다.
  7. CodeDeploy 가 Ec2 에 해당 빌드 파일을 전달하며 스크립트를 실행시킨다.

Github Actions, AWS 를 사용한 전형적인 CI/CD 과정이다. 하지만 대부분의 참고 글에서도 옳지 못한 부분이 존재해 정정하고자 한다.

aws-credentials

      - name: AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

대부분의 글에서 위와 같이 AWS 의 Access Key, Secret Access Key 를 사용해 Github Actions 자체에 로그인을 시키는 것을 확인할 수 있다.

문제점

  1. 가장 우선적으로 Access Key 는 개인에게 종속되며 하나의 키를 가진다.

그 뜻은 Github Actions 가 실행될 때마다 해당 Access Key 의 이름으로 로그가 발생한다. 개인의 Access Key 가 공용적으로 사용되는 것 자체가 문제라고 할 수 있다. 이것만을 해결하기 위해 Github Actions 용 IAM User 를 생성하는 것도 옳은 방법은 아니다.

  1. Access Key 를 인터넷에 공유한다는 자체가 문제이다.

1번보다 근본적인 문제는 Access Key 를 인터넷에 올린다는 것 자체가 문제이다. 아무리 Github Secret 으로 암호화 되어있다고 하지만, Github 라는 공간에 (암호화를 해도) Key 를 올린다는 행위 자체가 옳지 않다고 볼 수 있다.

해결책

AWS 의 IAM 을 잘 이해하고 있다면 위 문제에 충분히 공감할 수 있다고 생각한다. IAM 을 따른다면 옳은 해결책은 Github Actions 에 Role 을 부여하는 것이다.

Security best practices in IAM

AWS 의 공식 문서에서도 Application에서는 IAM User가 아닌 IAM Role을 사용하길 권고함을 확인할 수 있다.

1. External Identity Provider 생성

Create an OpenID Connect (OIDC) identity provider in IAM 는 외부 자격 공급자(external identity provider - IdP)로부터 AWS 계정에 접근할 수 있도록 설정해줘야합니다. Provider URL에서 Assume을 할 수 있도록 Audience에 sts.amazoeaws.com을 지정해준다.

image

2. IAM Role 생성

GitHub Action에서 사용할 IAM Role을 생성한다.  Trust Relationships에는 앞서서 생성해준 Identity Providers에서 생성한 IdP의 arn을 추가해주고, Role을 사용할 Condition으로 Assume role을 할 수 있도록 sts.amazonaws.com과 어떤 조직의 Repository에서 사용할지를 명시해준다. 여기서는 실제 해당 Repository 의 Master 브랜치에 적용시킨 모습이다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<account-id>:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:softeerbootcamp4th/Team1-Strawberry-BE:ref:refs/heads/master"
                }
            }
        }
    ]
}

3. GitHub Action에서 Role 적용

      - name: AWS credential
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_NAME }}
          role-session-name: {{ secrets.AWS_ROLE_SESSION_NAME }}
          aws-region: ${{ secrets.AWS_DEFAULT_REGION }}

앞서 Access Key 를 직접 사용했던 credential 부분을 Role 을 주입받아 사용할 수 있다.

  • role-to-assume : ROLE 의 ARN
  • role-session-name : 임시 보안 자격 증명을 발급받을 때 사용되는 세션의 이름
    • 해당 Role 을 여러 개의 세션이 동시에 사용할 수 있으며, 이들을 session-name 으로 구분한다.
    • AWS CloudTrail 같은 로그 서비스에서 session-name 을 통해 추적할 수 있다.
  • aws-region : Role 의 Region

결론

Application 에서 Access Key 를 직접 사용하지 않고 Role 을 사용하는 것은 AWS 권고 사항이다. 실제 Github Actions 에서 Role 을 사용 시 다음의 장점들이 있다.

  • 임시 보안 자격 증명 발급으로 보안 향상
  • 언제든지 접근 권한 회수 가능하기에 강력한 권한 제어

특히 임시 보안 자격 증명 발급이기에 임시적인 시간만 역할을 가지고 이후 역할을 반납하기에 보안적으로 우수하다.

따라서 특히 Application 에서는 Role 을 사용하는게 옳다!

Clone this wiki locally