단기 자격 증명 및 Github 작업을 사용하여 AWS CDK 애플리케이션 구축

AWS에 애플리케이션을 배포할 수 있는 여러 가지 방법이 있습니다.AWS CloudFormation 또는 유사AWS CodePipeline 서비스를 직접 이용할 수 있습니다.AWS CloudFormation이 마음에 들지 않으면 AWS Elastic Beanstalk 등의 서비스를 사용할 수 있습니다.
선택의 여지가 많다.
이 블로그는 AWS CDK 애플리케이션을 배포할 때 가장 선호하는 방법GitHub Actions과 단기 IAM 자격 증명을 사용하여 가장 큰 보안 이점을 얻을 수 있음을 보여 줍니다.
잠수합시다.

You can find all the code presented in this blog post in this GitHub repository.

GitHub 작업을 사용한 일반적인 AWS CDK 배포

최근까지 GitHub 작업을 사용한 일반적인 AWS 배치는 아래의 약도와 유사하게 보일 수 있습니다.

기본 응용 프로그램을 배포하려면 장기 IAM 사용자 자격 증명GitHub repository/organization secrets에 저장해야 합니다.이런 설정이 확실히 작용했지만 우리 환경에 상대적으로 큰 안전 구멍을 남겼다.
이 경우 IAM 사용자를 멀리해야 하는 이유를 살펴보겠습니다.

AWS IAM 사용자의 문제

나보다 안전에 대해 더 잘 아는 사람들.나는 그들의 관점에 전적으로 동의한다.
어떤 안전 전문가에게 그들이 장기 또는 단기적으로 취소할 수 있는 증거를 더 받아들이기를 원하는지 물어보세요.나는 큰 돈을 걸고 싶다. 그들은 후자를 선택할 것이다.접근 키는 장수합니다!상상해 봐, 한 공격자가 이걸 잡았어.그들은 너의 인프라 시설을 파괴할 것이다.그다지 이상적이지 않다.
다행히도 최근에는 또 다른 선택이 생겼다.우리 이 화제를 한층 더 토론합시다.

다른 선택

AWS CDK 애플리케이션을 최대 시간 내에 배포할 때 IAM 사용자 설정에 거의 어려움을 겪었습니다.GitHubannounced support for OpenID Connect for GitHub actions 발표 이후 모든 것이 달라졌다.
현재, 우리는 AssumeRoleWithWebIdentity AWS IAM 호출을 사용하여 단기 IAM 역할 증명서를 얻을 수 있으며, 장기적으로 존재하는 IAM 사용자 증명서에 의존하지 않고 AWS CDK 프로그램을 배치할 수 있다.잘 됐다!

이 설정이 어떻게 작용하는지 한 걸음 한 걸음 봅시다.

행동 중

이제 구체적인 질문으로 넘어가겠습니다. GitHub OIDC provider를 사용하여 GitHub AWS CDK 배치 파이프라인을 설치하여 단기 증빙을 이용하는 방법을 설명합니다.

Important: The following blog post assumes that you have the newStyleStackSynthesis AWS CDK feature flag turned on or are using AWS CDK v2. Read more about AWS CDK feature flags here.

2개의 개별 스택 및 AWS 계정

나는 응용 프로그램 코드를 작성하거나 AWS 인프라를 만들 때 서로 다른 관심사를 분리할 수 있다고 믿는다.일을 분리하는 정신에 따라 나는 두 개의 단독 AWS 계정에 두 개의 AWS CDK 창고를 만들 것이다.
AWS 계정은 문제가 발생했을 때 잠재적 폭발 반경을 줄이는 좋은 방법이다.사실AWS recommends using multiple AWS accounts to achieve resource independence and isolation.

Please note that if you are deploying relatively simple architectures, you do not need separate accounts here – it might be an overkill. If you are not interested in the multi-account setup, read on. I will show you how to do all we discussed today using a single account.

첫 번째 창고는'infrastructure'라고 하는데 GitHub OIDC IAM 제공 프로그램과'응용 프로그램'을 배치하는 데 사용되는 AWS IAM 역할을 포함한다.이 스택은 계정 A에 배치됩니다.

두 번째 스택은 응용 프로그램이라고 하며 응용 프로그램 자체를 저장합니다.이 스택은 계정 B에 배치됩니다

.

인프라 스택

OIDC 공급업체

AWS CDK를 사용하여 사용자 정의 OIDC 공급자를 만드는 것은 쉬운 일입니다.iam.OpenIdConnectProvider류는 AWS::IAM::OIDCProviderAWS 클라우드 정보자원에 대한 좋은 추상이다.
다음 AWS CDK 코드는 GitHub 작업의 컨텍스트에서 개발자가 사용할 수 있는 사용자 정의 AWS IAM OIDC 공급자를 만듭니다.

import { aws_iam } from "aws-cdk-lib";

// ...

const gitHubOIDCProvider = new aws_iam.OpenIdConnectProvider(
  this,
  "gitHubOIDCProvider",
  {
    url: "https://token.actions.githubusercontent.com",
    clientIds: ["sts.amazonaws.com"]
  }
);

Github는 OIDC 공급자와 AWS를 통합하는 방법에 대한 상세한 조언great guide을 가지고 있다.읽어봐!

배포자 역할

이전에 회피했던 바와 같이, 우리는 '배치자' 역할을 사용하여 우리의 주요 AWS CDK 응용 프로그램을 배치할 것이다.이 역할은 이전에 만든 사용자 정의 OIDC 제공 프로그램과 신뢰 관계를 맺어야 합니다. 그렇지 않으면 GitHub 작업이 실행되는 동안 이 역할을 맡을 수 없습니다.

import { aws_iam } from "aws-cdk-lib";

// ...

const gitHubOIDCProvider = ...

/**
 * Amend those to your needs.
 */
const yourGitHubUsername = "WojciechMatuszewski";
const yourGitHubRepoName = "github-oidc-aws-cdk-example";
const yourGitHubBranchName = "main";

const applicationDeployerRole = new aws_iam.Role(this, "applicationDeployerRole", {
  assumedBy: new iam.WebIdentityPrincipal(
    gitHubOIDCProvider.openIdConnectProviderArn,
    {
      StringLike: {
        "token.actions.githubusercontent.com:sub":
          // Notice the `ref:refs`. The `s` in the second `ref` is important!
          `repo:${yourGitHubUsername}/${yourGitHubRepoName}:ref:refs/heads/${yourGitHubBranchName}`
      }
    }
  ),
  inlinePolicies: {
    allowAssumeOnAccountB: new aws_iam.PolicyDocument({
      statements: [
        new aws_iam.PolicyStatement({
          effect: iam.Effect.ALLOW,
          actions: ["sts:AssumeRole"],
          resources: ["arn:aws:iam::ACCOUNT_B_ID:role/*"]
        })
      ]
    })
  }
});

이 코드에는 두 가지 중요한 일이 있으니 주의해야 한다.

이 정책의 조건은 매우 중요하다.신뢰할 수 없는 저장소에서 액세스 토큰applicationDeployerRole을 요청할 수 없습니다.

정책 성명.다중 계정 설정에서 이 역할을 사용할 것이기 때문에 계정 a에서 정의한 역할을 맡을 수 있는 권한을 부여해야 합니다. 한 계정에 두 개의 창고를 배치할 때 이 정책 문구는 필요 없습니다.

스택을 배포한 후 ARNallowAssumeOnAccountB을 복제합니다. 나중에 필요할 수도 있습니다.
응용 프로그램 스택으로 이동합니다.

어플리케이션 스택

기본적으로 AWS CDK 부트 프로세스는 다른 리소스에서 배포 프로세스와 관련된 5개의 IAM 역할을 작성합니다.
AWS Documentation에서 그들에 대한 정보를 더 많이 알 수 있다. 주로'캐릭터'부분이다.

더 중요한 것은 이 역할들이 전체 AWS 계정과 신뢰 관계를 가진다는 것이다. 스택은 그것으로부터 유도된다. (설정 가능)따라서 이론적으로 신뢰할 수 없는 IAM 엔터티가 어플리케이션을 자유롭게 배포할 수 있습니다.
AWS CDK 부트 템플릿을 변경하여 배포자 역할만 AWS CDK에서 만든 역할을 수행할 수 있도록 합니다.
자, 시작합시다.

부트 템플릿 수정

Check out the AWS documentation for how to customize AWS CDK bootstrapping process further.

첫 번째 단계는 부트 템플릿을 가져오는 것입니다.다행히 AWS CDKapplicationDeployerRole 명령은 bootstrap 로고를 공개했다.

npm run cdk bootstrap -- --get-template

두 번째 단계는 부트 템플릿의 역할에 대한 신뢰 관계를 수정하는 것입니다.전체 AWS 계정을 주체가 아닌'배포자'역할 ARN으로 설정합니다.
예를 들어, FilePublishingRole이 포함된 부트 템플릿에 수정되지 않은 전문가가 있습니다.

FilePublishingRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Action: sts:AssumeRole
          Effect: Allow
          Principal:
            AWS:
              Ref: AWS::AccountId

신뢰 관계를 수정하여'배치자'IAM 역할만 맡을 수 있도록 하려면 --get-template 아래 AWS 키의 값을 변경하십시오.

FilePublishingRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Action: sts:AssumeRole
          Effect: Allow
-          Principal:
-            AWS:
-              Ref: AWS::AccountId
+          Principal:
+            AWS: DEPLOYER_ROLE_ARN

자진하다

부트 템플릿을 수정하면 특수 플래그가 있는 Principal 명령을 실행할 수 있습니다.이 로고는 AWS CDK가 수정한 템플릿을 AWS 클라우드 정보의 실제 출처로 사용한다는 것을 알려 줍니다.

npm run cdk bootstrap -- --template YOUR_MODIFIED_TEMPLATE_NAME.yaml

부트 프로세스가 성공하면 GitHub 작업 흐름을 만들고 응용 프로그램을 배치할 수 있습니다.

배치하다

자, 이제 우리가 마지막으로 응용 프로그램을 내놓고 배치할 때입니다. 전 세계가 볼 수 있도록.이 블로그의 제목에 근거하여 나는 GitHub 조작을 사용하여 이 점을 실현할 것이다.
우리의 작업 절차 문서는 매우 간단할 것이다.

# .github/workflows/deployment.yaml
name: deployment

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Pull repository
        uses: actions/checkout@v2
      - name: Install dependencies
        working-directory: ./application
        run: npm install
      - name: Assume deployer role
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: YOUR_DEPLOYER_ROLE_ARN
          aws-region: eu-west-1 # Do not forget about adjusting the region!
      - name: Deploy the application
        working-directory: ./application
        run: npm run deploy:cicd

나는 cdk bootstrap 절차에 중점을 두고 싶다.Assume deployer role는 GitHub OIDC 제공 프로그램과 상호작용을 하고 GitHub OIDC 제공 프로그램이 제공하는 영패 실행aws-actions/configure-aws-credentials@v1을 호출한다.
'배치자'캐릭터를 지정하는 조건을 기억하십니까?

import { aws_iam } from "aws-cdk-lib";

// ...

const gitHubOIDCProvider = ...

/**
 * Amend those to your needs.
 */
const yourGitHubUsername = "WojciechMatuszewski";
const yourGitHubRepoName = "github-oidc-aws-cdk-example";
const yourGitHubBranchName = "main";

const applicationDeployerRole = new aws_iam.Role(this, "applicationDeployerRole", {
  assumedBy: new iam.WebIdentityPrincipal(
    gitHubOIDCProvider.openIdConnectProviderArn,
    {
      StringLike: {
        "token.actions.githubusercontent.com:sub":
          // Notice the `ref:refs`. The `s` in the second `ref` is important!
          `repo:${yourGitHubUsername}/${yourGitHubRepoName}:ref:refs/heads/${yourGitHubBranchName}`
      }
    }
  ),
  inlinePolicies: {
    allowAssumeOnAccountB: new aws_iam.PolicyDocument({
      statements: [
        new aws_iam.PolicyStatement({
          effect: iam.Effect.ALLOW,
          actions: ["sts:AssumeRole"],
          resources: ["arn:aws:iam::ACCOUNT_B_ID:role/*"]
        })
      ]
    })
  }
});

이것이 바로 그들이 역할을 발휘하는 곳이다.다른 저장소나 분기를 지정하면 sts:AssumeRoleWithWebIdentity 단계가 실패Assume deployer role하고 단기 자격 증명을 얻을 수 없습니다.조건이 일치하지 않기 때문에 aws-actions/configure-aws-credentials@v1 호출에 실패합니다.
만약 우리가 모든 내용을 정확하게 배치했다면, 모든 작업은 성공적으로 실행되어야 한다.

여러 AWS 계정을 사용하고 싶지 않습니다.

The example GitHub repository contains the single-account deployment AWS CDK code as well!

"인프라 시설"창고에 단독 계좌를 사용하고 싶지 않을 수도 있습니다. 이것은 충분히 이해할 수 있습니다.이런 상황에서 우리는 어떤 수정을 해야만 배치 업무를 정상적으로 할 수 있는지 봅시다.

'배치자'역할은 sts:AssumeRoleWithWebIdentity 전략이 필요 없다.allowAssumeOnAccountB 호출은 단일 계정의 상하문에서 발생하기 때문에 이 정책은 더 이상 관련되지 않습니다.

import { aws_iam } from "aws-cdk-lib";

// ...

const gitHubOIDCProvider = ...

const applicationDeployerRole = new iam.Role(this, "applicationDeployerRole", {
  assumedBy: new iam.WebIdentityPrincipal(
    gitHubOIDCProvider.openIdConnectProviderArn,
    {
      StringLike: {
        "token.actions.githubusercontent.com:sub":
          // Notice the `ref:refs`. The `s` in the second `ref` is important!
          `repo:${yourGitHubUsername}/${yourGitHubRepoName}:ref:refs/heads/${yourGitHubBranchName}`
      }
    }
  ),
- inlinePolicies: {
-   allowAssumeOnAccountB: new iam.PolicyDocument({
-      statements: [
-         new iam.PolicyStatement({
-          effect: iam.Effect.ALLOW,
-          actions: ["sts:AssumeRole"],
-          resources: ["arn:aws:iam::ACCOUNT_B_ID:role/*"]
-        })
-      ]
-    })
+  inlinePolicies: {}
  }
});

인프라 및 어플리케이션 스택을 부트할 때 지정the sts:AssumeRoleWithWebIdentity parameter.

기본적으로 같은 계정에 여러 개의 AWS CDK 스택을 배치하면 AWS CDK는 안내 프로세스에서 만든 자원을 다시 사용합니다.
"응용 프로그램"창고에서 안내하는 역할의 신뢰 정책을 변경할 수 없기 때문에 이런 상황이 발생하기를 원하지 않습니다.

부팅 시 제한 문자를 변경하려면 qualifier CLI 매개 변수를 사용합니다.

npm run cdk bootstrap -- --qualifier=application --template ./bootstrap-template.yaml

CDK 애플리케이션 수준qualifier 속성을 지정합니다.

const app = new cdk.App();
new ApplicationStack(app, "ApplicationStack", {
+  synthesizer: new cdk.DefaultStackSynthesizer({
+    qualifier: "YOUR_QUALIFIER"
+  })
});

이 과정의 나머지 부분은 다중 계정 설정과 같다.

끝말

AWS CDK 애플리케이션을 배포하는 방법에는 여러 가지가 있습니다.이 블로그는 GitHub 작업 중 하나를 보여주기 위한 것입니다.나는 네가 이 설정이 매우 가치가 있고 도움이 된다고 생각하기를 바란다.
일부 서버/AWS CDK 콘텐츠에 대해서는 Twitter에서 확인하십시오-
소중한 시간 감사합니다.