개발하자

도커 컨테이너의 awsecr에 대한 테라폼 배포

Cuire 2022. 11. 17. 17:56
반응형

도커 컨테이너의 awsecr에 대한 테라폼 배포

저는 테라폼 배포의 일환으로 도커 이미지를 awscr에 배포하는 데 문제가 있으며 최선의 장기 전략을 생각해 보려고 합니다.

지금 나는 s3와 dynamodb에 테라폼 원격 백엔드가 있고 그것을 나의 마스터 계정이라고 부르자. 그런 다음 개발/테스트 등의 환경을 별도의 계정으로 관리합니다. 테라폼 배포는 현재 내 로컬 시스템(mac)에서 실행되고 있으며 aWS 'master' 계정과 해당 자격 증명을 사용하여 대상 배포 계정에서 역할을 가정하여 다음과 같이 리소스를 생성합니다.

provider "aws" { // tell terraform which SDK it needs to load
  alias  = "target"
  region = var.region
  assume_role {

  role_arn = "arn:aws:iam::${var.deployment_account}:role/${var.provider_env_deployment_role_name}"
  }
}

나는 Fargate 배포를 통해 여러 ecs 서비스를 만들고 있다. 컨테이너 이미지는 GitHub Actions에 의해 별도의 저장소에 구축되고 GitHub 패키지로 저장됩니다. 이러한 패키지 이름과 버전은 ECR 및 서비스를 생성한 후에 배포되고 있으며(아마도 이상적인 것일 수 있습니다) 여기서 문제가 발생합니다.

이 프로세스는 GitHub 패키지에서 이미지를 가져와 재태그를 지정하고 null_resource local-exec의 여러 실행을 사용하여 ECR에 업로드하는 것입니다. 단독으로 잘 작동하지만 테라폼 프로세스의 일부로 문제가 있습니다. 그 이유는 다른 리소스가 위의 공급자를 사용하여 권한을 얻지만 null_resource가 공급자를 받아들이지 않기 때문에 이러한 방식으로 권한을 얻을 수 없기 때문이라고 생각합니다. 그래서 나는 aws creds 값을 셸에 전달해 왔다. 이것이 정말로 안전한지 확신할 수 없지만 그것은 또한 작동하지 않기 때문에 현재 무익하다. 다음 오류가 발생합니다.

Error saving credentials: error storing credentials - err: exit status 1, out: `error storing credentials - err: exit status 1, out: `The specified item already exists in the keychain.``

GitHub 작업을 통해 구축으로 마이그레이션할 때 Terraform을 통해 인프라 구축을 실제 애플리케이션 구축과 분리하고 GitHub 암호를 사용하여 자격 증명 값을 재설정한 후 스크립트를 실행할 수 있다고 생각합니다.

아니면, 열쇠고리 같은 것이 그냥 사라지고 내 과정이 잘 될 수도 있지 않을까? 안전한가요?

이 시나리오에는 문제가 없지만 모든 사용 사례에 대해 일반적인 접근 방식은 아닙니다.

나는 곧 도커 컨테이너와 함께 여러 개의 AWS 람다 함수를 배치하기 시작할 것이다. 이전에 해본 적은 없지만 다음과 같은 프로세스가 될 것으로 보입니다. ECR 생성, 컨테이너 배포, 람다 함수 배포. 이것은 컨테이너 배포가 테라폼 배포에 필수적이어야 한다는 것을 의미하며, 이는 로컬 실행과 관련된 문제로 되돌아갑니다.

배포를 여러 개의 파일로 분할하는 것을 의미하는 것을 발견했지만, 이는 우아하지 않고 잠재적으로 취약한 것으로 보입니다.

어쩌면 간단한 해결책이 있을지도 모르지만, 제가 이것을 어디로 가려고 하는지를 고려할 때, 저의 최선의 접근법은 무엇인가요?



이것이 완전한 답이 아니라는 것을 알지만, 당신은 환경 변수에서 당신의 AWS 크레딧을 끌어내야 한다. 다른 계정에 대한 자격 증명이 필요한지 잘 모르겠지만, 필요한 경우 작업 진행 중에 자격 증명을 교환하십시오. 참조. 테라포름은 이것들을 픽업해서 자동으로 AWS 접속에 사용해야 한다.



케빈 벅스가 제안한 대로...

나의 주된 문제는 Mac에서 배포하는 것과 키 체인의 사용과 관련된 것이었다. 이것이 중요한 경로가 아니었기 때문에 나는 그것을 돌아 GitHub Action을 설정했다.

액션은 내 '마스터' aws 계정 자격 증명을 위해 GitHub 비밀에서 환경 변수를 로드했습니다.

AWS_ACCESS_KEY_ID: ${{ secrets.NK_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.NK_AWS_SECRET_ACCESS_KEY }}

나는 또한 같은 방식으로 TF_VAR 접두사를 사용하여 대상 계정 자격 증명을 환경 변수에 로드했다.

TF_VAR_DEVELOP_AWS_ACCESS_KEY_ID: ${{ secrets.DEVELOP_AWS_ACCESS_KEY_ID }}
TF_VAR_DEVELOP_AWS_SECRET_ACCESS_KEY: ${{ secrets.DEVELOP_AWS_SECRET_ACCESS_KEY }}

그런 다음 환경 변수에서 자동으로 채워질 테라폼 변수를 선언합니다.

variable "DEVELOP_AWS_ACCESS_KEY_ID" {
  description = "access key for the dev account"
  type = string
}
variable "DEVELOP_AWS_SECRET_ACCESS_KEY" {
  description = "secret access key for the dev account"
  type = string
}

로컬 Exec에서 셸 스크립트를 실행하면 다음과 같이 됩니다.

resource "null_resource" "image-upload-to-importcsv-ecr" {

   provisioner "local-exec" {
      command = "./ecr-push.sh ${var.DEVELOP_AWS_ACCESS_KEY_ID} ${var.DEVELOP_AWS_SECRET_ACCESS_KEY} "
   }
}

그런 다음 스크립트 내에서 이러한 인수를 사용하여 자격 증명을 설정할 수 있습니다(예:

AWS_ACCESS=$1
AWS_SECRET=$1
.....
export AWS_ACCESS_KEY_ID=${AWS_ACCESS}
export AWS_SECRET_ACCESS_KEY=${AWS_SECRET}

이제 스크립트는 무엇이든 할 수 있는 자격 증명을 가지고 있습니다.



하드 코딩된 액세스 키/비밀 액세스 키 대신 Github/AWS의 OIDC 임시 자격 증명을 통해 역할을 맡을 수 있는 기능을 사용할 것을 제안합니다.

사용자는 배포할 다른 계정에 대해 인증 및 인증되는 초기 역할을 하나만 정의할 수 있습니다.

이러한 기능은 역할 자격 증명이 한 시간 동안만 유효하며 이 자격 증명을 회전해야 하는 작업 오버헤드가 없다고 가정합니다.


반응형