21장 OIDC로 장기 access key를 pipeline에서 없앤다

CI secret에 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY를 넣으면 유출·회전·퇴사자·복제 repository 문제가 따라온다. OIDC에서는 CI provider가 job identity를 signed token으로 발급하고, AWS STS가 IAM role의 trust condition과 비교한 뒤 짧은 session credential을 돌려준다.

GitHub 또는 GitLab job이 AWS STS의 trust 조건을 거쳐 단기 IAM role을 얻는 과정

두 policy를 구분한다.

trust policy: 누가 이 role을 맡을 수 있는가. provider, audience, repository/project, branch/environment를 제한한다.
permission policy: role을 맡은 뒤 무엇을 할 수 있는가. ECR repository, EKS cluster, 필요한 action을 제한한다.

GitHub trust의 개념 예시는 다음과 같다. account·organization·repository는 실제 값으로 바꾼다.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:WITHAI/flownote:environment:production"
      }
    }
  }]
}

wildcard로 모든 repository·branch를 믿지 않는다. reusable workflow를 중앙 통제한다면 AWS가 지원하는 claim과 GitHub token claim 변경 사항을 공식 문서에서 재확인한다. token payload를 log에 통째로 출력하지 않는다.

Git에서 EKS까지: 21장 OIDC로 장기 access key를 pipeline에서 없앤다

21장 OIDC로 장기 access key를 pipeline에서 없앤다