쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

설정
문의하기
피드백
AWS Documentation
AWS 계정 생성
역할 자동 판매기 솔루션을 배포하여 최소 권한 IAM 역할 프로비저닝 - 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구모범 사례에픽문제 해결관련 리소스추가 정보

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

역할 자동 판매기 솔루션을 배포하여 최소 권한 IAM 역할 프로비저닝

PDF

작성자: Benjamin Morris(AWS), Aman Kaur Gandhi(AWS), Chad Moon(AWS), Nima Fotouhi(AWS)

요약

파이프라인에 대한 범위 AWS Identity and Access Management 초과(IAM) 역할 권한은 조직에 불필요한 위험을 초래할 수 있습니다. 개발자는 개발 중에 광범위한 권한을 부여하지만 코드 문제 해결 후 권한 범위를 축소하지 않는 경우가 있습니다. 이로 인해 강력한 역할이 비즈니스 요구 없이 존재하고 보안 엔지니어가 검토하지 않았을 수 있는 문제가 발생합니다.

이 패턴은이 문제에 대한 해결책인 역할 자동 판매기(RVM)를 제공합니다. RVM은 안전한 중앙 집중식 배포 모델을 사용하여 개발자의 노력을 최소화하면서 개별 GitHub 리포지토리의 파이프라인에 대한 최소 권한 IAM 역할을 프로비저닝하는 방법을 보여줍니다. RVM은 중앙 솔루션이므로 변경 사항을 승인하는 데 필요한 검토자로 보안 팀을 구성할 수 있습니다. 이 접근 방식을 통해 보안은 과도하게 권한이 부여된 파이프라인 역할 요청을 거부할 수 있습니다.

RVM은 Terraform 코드를 입력으로 받아 파이프라인 지원 IAM 역할을 출력으로 생성합니다. 필수 입력은 AWS 계정 ID, GitHub 리포지토리 이름 및 권한 정책입니다. RVM은 이러한 입력을 사용하여 역할의 신뢰 정책 및 권한 정책을 생성합니다. 결과 신뢰 정책은 지정된 GitHub 리포지토리가 역할을 수임하고 파이프라인 작업에 사용할 수 있도록 허용합니다.

RVM은 IAM 역할(부트스트랩 중에 구성됨)을 사용합니다. 이 역할에는 조직의 각 계정에서 role-provisioning-role 수임할 수 있는 권한이 있습니다. 역할은 AWS Control Tower Account Factory for Terraform(AFT) 또는 AWS CloudFormation StackSets를 통해 구성됩니다. role-provisioning-roles는 실제로 개발자를 위한 파이프라인 역할을 생성하는 역할입니다.

사전 조건 및 제한 사항

사전 조건 

  • 활성. AWS 계정

  • GitHub 작업을 통해 코드형 인프라(IaC)를 배포하는 데 사용되는 GitHub 조직입니다. (GitHub Enterprise/Premium/Ultimate는 필요하지 않습니다 .)

  • 다중 계정 AWS 환경. 이 환경은의 일부가 될 필요가 없습니다 AWS Organizations.

  • 모든에 IAM 역할을 배포하는 메커니즘입니다 AWS 계정 (예: AFT 또는 CloudFormation StackSets).

  • Terraform 버전 1.3 이상이 설치 및 구성되었습니다.

  • Terraform AWS Provider 버전 4 이상이 설치 및 구성되었습니다.

제한 사항

  • 이 패턴의 코드는 GitHub Actions 및 Terraform에 고유합니다. 그러나 패턴의 일반적인 개념은 다른 지속적 통합 및 전송(CI/CD) 프레임워크에서 재사용할 수 있습니다.

  • 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전 가용성은 AWS 리전별 서비스를 참조하세요. 특정 엔드포인트는 서비스 엔드포인트 및 할당량을 참조하고 서비스 링크를 선택합니다.

아키텍처

이 다이어그램은 이 패턴의 워크플로우를 보여줍니다.

GitHub 작업을 사용하여 IAM 역할 생성 및 배포를 자동화하는 워크플로입니다.

역할 자동 판매기의 일반적인 사용에 대한 워크플로는 다음 단계로 구성됩니다.

  1. 개발자는 새로 요청된 IAM 역할에 대한 Terraform 코드가 포함된 코드를 RVM GitHub 리포지토리로 푸시합니다. 이 작업은 RVM GitHub 작업 파이프라인을 트리거합니다.

  2. 파이프라인은 OpenID Connect(OIDC) 신뢰 정책을 사용하여 RVM 역할 수임 역할을 수임합니다.

  3. RVM 파이프라인이 실행되면 개발자의 새 IAM 역할을 프로비저닝하는 계정에서 RVM 워크플로 역할을 수임합니다. (RDM 워크플로 역할은 AFT 또는 CloudFormation StackSets.)

  4. RVM은 적절한 권한과 신뢰로 개발자의 IAM 역할을 생성하므로 다른 애플리케이션 파이프라인에서 역할을 수임할 수 있습니다.

  5. 앱 개발자는이 RVM 프로비저닝 역할을 수임하도록 앱 파이프라인을 구성할 수 있습니다.

생성된 역할에는 개발자가 요청한 권한과 ReadOnlyAccess 정책이 포함됩니다. 역할은 개발자가 지정한 리포지토리의 main브랜치에 대해 실행되는 파이프라인에서만 가능하다고 가정할 수 있습니다. 이 접근 방식은 역할을 사용하기 위해 브랜치 보호 및 검토가 필요할 수 있도록 하는 데 도움이 됩니다.

자동화 및 규모 조정

최소 권한 권한은 프로비저닝되는 각 역할에 대한 세부 정보에 주의를 기울여야 합니다. 이 모델은 이러한 역할을 생성하는 데 필요한 복잡성을 줄여 개발자가 추가 학습이나 노력 없이 필요한 역할을 생성할 수 있도록 합니다.

도구

AWS 서비스

  • AWS Identity and Access Management (IAM)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.

  • AWS Organizations는 여러를 생성하여 중앙에서 관리하는 조직 AWS 계정 으로 통합하는 데 도움이 되는 계정 관리 서비스입니다.

기타 도구

  • Git은 오픈 소스, 분산 버전 관리 시스템입니다. 여기에는 조직 계정을 생성하는 기능이 포함됩니다.

  • GitHub Actions는 GitHub 리포지토리와 긴밀하게 통합된 지속적 통합 및 지속적 전송(CI/CD) 플랫폼입니다. GitHub 작업을 사용하여 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있습니다.

  • Terraform은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.

코드 리포지토리

이 패턴의 코드는 GitHub role-vending-machine 리포지토리에서 사용할 수 있습니다.

모범 사례

  • 올바른 방법을 쉽고 어렵게 만들기 - 올바른 일을 쉽게 할 수 있습니다. 개발자가 RVM 프로비저닝 프로세스에 어려움을 겪고 있는 경우 다른 수단을 통해 역할을 생성하려고 할 수 있으며, 이는 RVM의 중앙 특성을 약화시킵니다. 보안 팀이 RVM을 안전하고 효과적으로 사용하는 방법에 대한 명확한 지침을 제공해야 합니다.

    또한 개발자가 잘못된 일을 하기 어렵게 만들어야 합니다. 서비스 제어 정책(SCPs) 또는 권한 경계를 사용하여 다른 역할을 생성할 수 있는 역할을 제한합니다. 이 접근 방식은 역할 생성을 RVM 및 기타 신뢰할 수 있는 소스로만 제한하는 데 도움이 될 수 있습니다.

  • 좋은 예제 제공 - 불가피하게 일부 개발자는 RVM 리포지토리의 기존 역할을 새 역할에 권한을 부여하기 위한 비공식 템플릿으로 조정합니다. 복사할 수 있는 최소 권한 예제가 있는 경우 개발자가 와일드카드가 많은 광범위한 권한을 요청할 위험을 줄일 수 있습니다. 와일드카드가 많은 권한이 높은 역할로 시작하는 경우 시간이 지남에 따라 해당 문제가 곱해질 수 있습니다.

  • 명명 규칙 및 조건 사용 - 개발자가 애플리케이션이 생성할 리소스 이름을 모두 알지 못하더라도 명명 규칙을 사용하여 역할 권한을 제한해야 합니다. 예를 들어 Amazon S3 버킷을 생성하는 경우 리소스 키의 값은 해당 이름과 일치하는 버킷 이외의 권한을 역할에 부여하지 arn:aws:s3:::myorg-myapp-dev-* 않는 것처럼 보일 수 있습니다. IAM 정책을 통해 명명 규칙을 적용하면 명명 규칙 준수를 개선할 수 있는 추가적인 이점이 있습니다. 일치하지 않는 리소스는 생성할 수 없으므로 이러한 개선이 발생합니다.

  • 풀 요청(PR) 검토 필요 - RVM 솔루션의 가치는 새 파이프라인 역할을 검토할 수 있는 중앙 위치를 생성한다는 것입니다. 그러나이 설계는 RVM에 안전한 고품질 코드가 커밋되도록 하는 데 도움이 되는 가드레일이 있는 경우에만 유용합니다. 코드(예: main)를 배포하는 데 사용되는 브랜치를 직접 푸시로부터 보호하고 이를 대상으로 하는 병합 요청에 대한 승인이 필요합니다.

  • 읽기 전용 역할 구성 - 기본적으로 RVM은 요청된 각 역할의 readonly 버전을 프로비저닝합니다. 이 역할은 파이프라인 워크플로와 같이 데이터를 쓰지 않는 CI/CD terraform plan 파이프라인에서 사용할 수 있습니다. 이 접근 방식은 읽기 전용 워크플로가 잘못 작동하는 경우 원치 않는 변경을 방지하는 데 도움이 됩니다.

    기본적으로 AWS 관리형 ReadOnlyAccess 정책은 읽기 전용 역할과 읽기-쓰기 역할 모두에 연결됩니다. 이 정책은 필요한 권한을 결정할 때 반복의 필요성을 줄이지만 일부 조직에서는 지나치게 허용적일 수 있습니다. 원하는 경우 Terraform 코드에서 정책을 제거할 수 있습니다.

  • 최소 권한 부여 - 최소 권한 원칙을 따르고 작업을 수행하는 데 필요한 최소 권한을 부여합니다. 자세한 내용은 IAM 설명서의 최소 권한 부여 및 보안 모범 사례를 참조하세요.

에픽

작업설명필요한 기술

샘플 리포지토리를 GitHub 조직에 복사합니다.

필요에 맞게 조정할 수 있도록이 패턴의 리포지토리를 GitHub 조직에 복제하거나이 리포지토리를 포크합니다.

  • 이 리포지토리를 복제하도록 선택한 경우 다음 명령을 사용할 수 있습니다. git clone https://github.com/aws-samples/role-vending-machine

  • 리포지토리를 GitHub 조직에 포크하도록 선택한 경우 다음 명령을 사용할 수 있습니다.

    gh repo fork aws-samples/role-vending-machine --org YOUR_ORGANIZATION_NAME

DevOps 엔지니어

RVM에 AWS 계정 대한를 결정합니다.

RVM에 AWS 계정 사용할 인프라 배포를 결정합니다. 관리 또는 루트 계정을 사용하지 마세요.

클라우드 아키텍트

(선택 사항) 조직의 파이프라인이 PRs 생성하도록 허용합니다.

참고

이 단계는 generate_providers_and_account_vars 워크플로가 PRs을 생성하도록 허용하려는 경우에만 필요합니다.

조직의 파이프라인이 PRs을 생성하도록 허용하려면 다음 단계를 사용합니다.

  1. https://github.com/organizations/YOUR_ORG/settings/actions로 이동합니다.

  2. GitHub 작업 허용을 선택하여 풀 요청을 생성하고 승인합니다.

자세한 내용은 GitHub 설명서의 리포지토리에 대한 GitHub 작업 설정 관리를 참조하세요. GitHub

DevOps 엔지니어

RVM 계정에 읽기 전용 권한을 부여합니다.

관리 계정에서 RVM 계정에 읽기 전용 권한을 부여하는 위임 정책을 생성합니다. 이렇게 generate_providers_and_account_vars.py 하면 스크립트가 실행될 때 RVM GitHub 워크플로가 AWS 조직의 계정 목록을 동적으로 가져올 수 있습니다.

다음 코드를 사용하고를 2단계에서 선택한 AWS 계정 ID<YOUR RVM Account ID>로 바꿉니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<YOUR RVM Account ID>:root"
      },
      "Action": [
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListRoots",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListDelegatedAdministrators"
      ],
      "Resource": "*"
    }
  ]
}
클라우드 관리자

샘플 리포지토리에서 기본값을 업데이트합니다.

특정 환경에서 작동하도록 RVM을 구성하려면 다음을 AWS 리전수행합니다.

  1. scripts/generate_providers_and_account_vars.py 및 기타 파일(예: bootstrap 폴더)을 작업하는 적절한 리전으로 업데이트합니다.

  2. AWS 계정 ID AWS 리전및 지정하려는 기타 변수로 .github/workflows/.env 파일을 업데이트합니다.

DevOps 엔지니어

환경 준비

작업설명필요한 기술

샘플 리포지토리를 GitHub 조직에 복사합니다.

필요에 맞게 조정할 수 있도록이 패턴의 리포지토리를 GitHub 조직에 복제하거나이 리포지토리를 포크합니다.

  • 이 리포지토리를 복제하도록 선택한 경우 다음 명령을 사용할 수 있습니다. git clone https://github.com/aws-samples/role-vending-machine

  • 리포지토리를 GitHub 조직에 포크하도록 선택한 경우 다음 명령을 사용할 수 있습니다.

    gh repo fork aws-samples/role-vending-machine --org YOUR_ORGANIZATION_NAME

DevOps 엔지니어

RVM에 AWS 계정 대한를 결정합니다.

RVM에 AWS 계정 사용할 인프라 배포를 결정합니다. 관리 또는 루트 계정을 사용하지 마세요.

클라우드 아키텍트

(선택 사항) 조직의 파이프라인이 PRs 생성하도록 허용합니다.

참고

이 단계는 generate_providers_and_account_vars 워크플로가 PRs을 생성하도록 허용하려는 경우에만 필요합니다.

조직의 파이프라인이 PRs을 생성하도록 허용하려면 다음 단계를 사용합니다.

  1. https://github.com/organizations/YOUR_ORG/settings/actions로 이동합니다.

  2. GitHub 작업 허용을 선택하여 풀 요청을 생성하고 승인합니다.

자세한 내용은 GitHub 설명서의 리포지토리에 대한 GitHub 작업 설정 관리를 참조하세요. GitHub

DevOps 엔지니어

RVM 계정에 읽기 전용 권한을 부여합니다.

관리 계정에서 RVM 계정에 읽기 전용 권한을 부여하는 위임 정책을 생성합니다. 이렇게 generate_providers_and_account_vars.py 하면 스크립트가 실행될 때 RVM GitHub 워크플로가 AWS 조직의 계정 목록을 동적으로 가져올 수 있습니다.

다음 코드를 사용하고를 2단계에서 선택한 AWS 계정 ID<YOUR RVM Account ID>로 바꿉니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<YOUR RVM Account ID>:root"
      },
      "Action": [
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListRoots",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListDelegatedAdministrators"
      ],
      "Resource": "*"
    }
  ]
}
클라우드 관리자

샘플 리포지토리에서 기본값을 업데이트합니다.

특정 환경에서 작동하도록 RVM을 구성하려면 다음을 AWS 리전수행합니다.

  1. scripts/generate_providers_and_account_vars.py 및 기타 파일(예: bootstrap 폴더)을 작업하는 적절한 리전으로 업데이트합니다.

  2. AWS 계정 ID AWS 리전및 지정하려는 기타 변수로 .github/workflows/.env 파일을 업데이트합니다.

DevOps 엔지니어
작업설명필요한 기술

RVM 리포지토리를 부트스트랩합니다.

이 단계는 RVM 파이프라인 자체에서 사용하는 OIDC 신뢰 및 IAM 역할을 생성하여 다른 역할의 운영 및 벤딩을 시작하는 데 필요합니다.

RVM 계정의 컨텍스트에서 scripts/bootstrap 디렉터리에서 terraform apply 명령을 수동으로 실행합니다. 변수 설명서에 따라 필요한 값을 입력합니다.

DevOps 엔지니어

인프라 초기화

작업설명필요한 기술

RVM 리포지토리를 부트스트랩합니다.

이 단계는 RVM 파이프라인 자체에서 사용하는 OIDC 신뢰 및 IAM 역할을 생성하여 다른 역할의 운영 및 벤딩을 시작하는 데 필요합니다.

RVM 계정의 컨텍스트에서 scripts/bootstrap 디렉터리에서 terraform apply 명령을 수동으로 실행합니다. 변수 설명서에 따라 필요한 값을 입력합니다.

DevOps 엔지니어
작업설명필요한 기술

모든 계정에 github-workflow-rvm 및 github-workflow-rvm-readonly 역할을 배포합니다.

AFT 또는 StackSets와 같은 조직의 관행에 맞는 배포 방법을 선택합니다. 이 방법을 사용하여 scripts/assumed_role/main.tf 파일의 두 IAM 역할(기본 이름 github-workflow-rvm 및 github-workflow-rvm-readonly)을 RVM이 파이프라인 역할을 생성할 수 있게 하려는 각 계정에 배포합니다.

이러한 IAM 역할에는 RVM 계정의 역할 수임 역할(또는 이에 readonly 상응하는 역할)이 이를 수임하도록 허용하는 신뢰 정책이 있습니다. 또한 역할에는와 일치하는 역할을 읽고 쓸 수 있도록 허용하는 IAM 권한 정책이 있습니다(readonly역할을 사용하지 않는 한). github-workflow-role-*

관리자

generate_providers_and_account_vars 워크플로를 실행합니다.

파이프라인 역할을 생성할 준비가 되도록 RVM을 구성하려면 다음을 수행합니다.

  1. generate_providers_and_account_vars workflow_dispatch를 사용하여 워크플로를 실행합니다.

  2. 워크플로가 생성하는 PR을 병합합니다.

워크플로가 완료되면 RVM은 다음을 수행할 준비가 된 것입니다.

  • 새 파이프라인 역할에 대한 요청을 수락합니다.

  • 요청에 따라 읽기 전용 또는 읽기-쓰기 역할을 생성합니다.

  • 지정된에 역할을 배포합니다 AWS 계정.

DevOps 엔지니어

작업 구성

작업설명필요한 기술

모든 계정에 github-workflow-rvm 및 github-workflow-rvm-readonly 역할을 배포합니다.

AFT 또는 StackSets와 같은 조직의 관행에 맞는 배포 방법을 선택합니다. 이 방법을 사용하여 scripts/assumed_role/main.tf 파일의 두 IAM 역할(기본 이름 github-workflow-rvm 및 github-workflow-rvm-readonly)을 RVM이 파이프라인 역할을 생성할 수 있게 하려는 각 계정에 배포합니다.

이러한 IAM 역할에는 RVM 계정의 역할 수임 역할(또는 이에 readonly 상응하는 역할)이 이를 수임하도록 허용하는 신뢰 정책이 있습니다. 또한 역할에는와 일치하는 역할을 읽고 쓸 수 있도록 허용하는 IAM 권한 정책이 있습니다(readonly역할을 사용하지 않는 한). github-workflow-role-*

관리자

generate_providers_and_account_vars 워크플로를 실행합니다.

파이프라인 역할을 생성할 준비가 되도록 RVM을 구성하려면 다음을 수행합니다.

  1. generate_providers_and_account_vars workflow_dispatch를 사용하여 워크플로를 실행합니다.

  2. 워크플로가 생성하는 PR을 병합합니다.

워크플로가 완료되면 RVM은 다음을 수행할 준비가 된 것입니다.

  • 새 파이프라인 역할에 대한 요청을 수락합니다.

  • 요청에 따라 읽기 전용 또는 읽기-쓰기 역할을 생성합니다.

  • 지정된에 역할을 배포합니다 AWS 계정.

DevOps 엔지니어

문제 해결

문제Solution

RVM을 사용하여 역할을 생성했지만 GitHub는 이를 수임할 수 없습니다.

GitHub 리포지토리의 이름이 github_workflow_roles 모듈에 제공된 이름과 일치하는지 확인합니다. 역할은 하나의 리포지토리만 수임할 수 있도록 범위가 지정됩니다.

마찬가지로 GitHub 파이프라인에 사용되는 브랜치가 github_workflow_roles 모듈에 제공된 브랜치의 이름과 일치하는지 확인합니다. 일반적으로 쓰기 권한이 있는 RVM 생성 역할은 main브랜치로 범위가 지정된 워크플로(즉,에서 소싱된 배포)에서만 사용할 수 있습니다main.

특정 리소스를 읽을 권한이 없기 때문에 읽기 전용 역할이 파이프라인을 실행하지 못하고 있습니다.

ReadOnlyAccess 정책은 광범위한 읽기 전용 권한을 제공하지만 정책에는 일부 읽기 작업(예: 특정 Security Hub 작업)이 없습니다.

github-workflow-roles 모듈의 inline_policy_readonly 파라미터를 사용하여 특정 작업 권한을 추가할 수 있습니다.

관련 리소스

추가 정보

GitHub 환경 사용

GitHub 환경은 역할 액세스를 위한 브랜치 기반 제한에 대한 대체 접근 방식입니다. GitHub 환경을 사용하려는 경우 IAM 신뢰 정책의 추가 조건에 대한 구문의 예는 다음과 같습니다. 이 구문은 GitHub 작업이 Production 환경에서 실행 중인 경우에만 역할을 사용할 수 있도록 지정합니다.

"StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production"
}

예제 구문은 다음 자리 표시자 값을 사용합니다.

  • octo-org는 GitHub 조직 이름입니다.

  • octo-repo는 리포지토리 이름입니다.

  • Production는 특정 GitHub 환경 이름입니다.

도움이 필요하십니까?

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.