Terraform Provider가 group/project의 GitLab CI 파이프라인에서 조인할 수 있도록 하려면 gitlab.example.com GitLab 인스턴스에서 다음 terraform-bot-token.yaml 을 생성하십시오:

kind: token
version: v2
metadata:
  name: terraform-bot
spec:
  roles: [Bot]
  join_method: gitlab
  bot_name: terraform
  gitlab:
    # domain은 GitLab 인스턴스의 도메인이어야 합니다.
    # GitLab의 클라우드 호스팅 서비스를 사용하는 경우, 이 필드를 완전히 생략하십시오.
    domain: gitlab.example.com
    # allow는 Teleport가 수락할 GitLab 토큰을 제어하는 규칙을 지정합니다.
    # 어떤 allow 규칙과도 일치하지 않는 토큰은 거부됩니다.
    allow:
      - project_path: group/project

Teleport 클러스터에 연결할 수 있는 CircleCI 워크플로우 규칙을 구성하려면, CircleCI 조직의 ID를 결정하고 CircleCI 컨텍스트를 만들어야 합니다.

조직 ID 찾기

CircleCI를 열고 내비게이션 바에서 "조직 설정"으로 이동합니다.
"개요"라는 제목의 인터페이스가 표시되고 "조직 ID"라는 섹션이 보일 것입니다. 이 값을 기록해 두고 구성 예제에서 organization-id를 이 값으로 대체하십시오.

컨텍스트 만들기

CircleCI에는 컨텍스트라는 조직 수준의 개념이 있습니다. 이는 워크플로우 작업에 노출되어야 하는 일련의 비밀을 구성할 수 있게 해줍니다. CircleCI를 구성하여 컨텍스트와 연결된 작업을 트리거할 수 있는 액터를 제어할 수 있습니다.

워크플로우 작업에 할당된 컨텍스트는 CircleCI가 작업을 위해 생성하는 ID 토큰에 인코딩됩니다. 이는 Teleport가 어떤 CircleCI 작업이 Teleport 클러스터에 대한 액세스를 부여받아야 하는지를 결정하는 이상적인 방법입니다.

이 예제에서는 teleport-access 라는 이름의 CircleCI 컨텍스트를 만들 것입니다. 그런 다음 이 컨텍스트에 Teleport 클러스터에 대한 액세스를 부여합니다.

CircleCI에서 컨텍스트를 만들기 위해 "조직 설정"을 열고 "컨텍스트"로 이동합니다. "컨텍스트 생성"을 클릭하고 만들고자 하는 컨텍스트의 이름으로 teleport-access를 제공하십시오. 조직에 더 적합한 문자열로 이 값을 대체할 수 있지만, 이 가이드의 향후 단계에서 teleport-access를 여러분의 값으로 교체해야 합니다.

방금 생성한 컨텍스트를 선택합니다. 이제 컨텍스트를 구성할 수 있는 페이지로 이동합니다. Teleport를 구성하는 데 사용할 컨텍스트의 ID를 찾기 위해, 컨텍스트 설정 페이지의 URL을 확인합니다. 이 URL은 다음과 유사한 형식을 가질 것입니다:

https://app.circleci.com/settings/organization/github/gravitational/contexts/00000000-0000-0000-0000-000000000000

이 경우, 컨텍스트 ID는: 00000000-0000-0000-0000-000000000000 입니다.
이 값을 기록해 두고 구성 예제에서 context-id를 이 값으로 대체하십시오.

그런 다음, 다음 terraform-bot-token.yaml 을 생성하십시오:

kind: token
version: v2
metadata:
  name: terraform-bot
spec:
  roles: [Bot]
  join_method: circleci
  bot_name: terraform
  circleci:
    organization_id: organization-id
    # allow는 Auth 서버가 `tbot` 의 조인을 허용해야 하는 규칙을 정의합니다.
    allow:
      - context_id: context-id

다음 사항을 확인하십시오:

• Teleport 클러스터에 접근을 허용할 AWS IAM 역할. 이 역할은 sts:GetCallerIdentity 가 부여되어야 합니다. 이 가이드에서는 이 역할을 instance-iam-role라고 명명합니다.
• Terraform 제공자를 실행할 IAM 역할이 연결된 AWS EC2 가상 머신.
• AWS 계정 ID: 111111111111

그런 다음, 다음 terraform-bot-token.yaml 을 생성하십시오:

kind: token
version: v2
metadata:
  name: terraform-bot
spec:
  roles: [Bot]
  bot_name: terraform
  join_method: iam
  allow:
    - aws_account: "111111111111"
      aws_arn: "arn:aws:sts::organization-id:assumed-role/instance-iam-role/i-*"

다음 사항을 확인하십시오:

• 제공자를 실행할 VM에 연결된 GCP 서비스 계정(SA). 이는 기본 컴퓨팅 SA일 수 없습니다. 이 가이드에서는 이 SA를 my-service-account라고 명명합니다.
• GCP 프로젝트 ID: my-project-123456

그런 다음, 다음 terraform-bot-token.yaml 을 생성하십시오:

kind: token
version: v2
metadata:
  name: terraform-bot
spec:
  roles: [Bot]
  bot_name: terraform
  join_method: gcp
  gcp:
    allow:
    - project_ids:
        - "my-project-123456"
      service_accounts:
        - "my-service-account@my-project-123456.iam.gserviceaccount.com"

GitLab CI 파이프라인을 실행하는 GitLab 저장소에 main.tf 파일을 복사합니다.

CircleCI 파이프라인을 실행하는 Git 저장소에 main.tf 파일을 복사합니다.

Terraform을 실행할 EC2 인스턴스에 main.tf 파일을 복사합니다.

Terraform을 실행할 GCP VM에 main.tf 파일을 복사합니다.

클러스터 이름을 복구합니다:

tctl status

Cluster       teleport.example.comVersion       16.2.0
...

Terraform 코드가 포함된 저장소에서 .gitlab-ci.yaml 파일을 생성(존재하지 않는 경우)하고 다음 내용을 추가합니다:

stages:
  - plan
image:
  name: hashicorp/terraform:1.9
  entrypoint: [""]
terraform-job:
  stage: plan
  # id_tokens는 GitLab이 자동으로 GitLab 실행 환경에 주입하는 ID 토큰을 구성합니다.
  #
  # id_tokens 구성에 대한 자세한 설명은 https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html에서 확인할 수 있습니다.
  id_tokens:
    TBOT_GITLAB_JWT:
      # TBOT_GITLAB_JWT의 aud는 Teleport 클러스터의 이름으로 구성되어야 합니다.
      # 이는 반드시 Teleport 클러스터의 주소일 필요는 없으며 포트나 스킴(http/https)를 포함하지 않습니다.
      #
      # 이는 Teleport Auth 서버가 토큰이 자신을 위한 것이고 다른 서비스나 Teleport 클러스터 용이 아님을 알리는 데 도움이 됩니다.
      aud: "teleport.example.com"
  script:
    - terraform init
    - terraform plan

변경 사항을 커밋하고 임의의 브랜치에 푸시하여 GitLab CI 파이프라인을 트리거합니다. 파이프라인 로그에서 Terraform 계획이 성공적으로 실행되는 것을 확인할 수 있습니다.

Terraform 코드가 포함된 저장소에서 .circleci/config.yml 에 다음 CircleCI 구성을 추가합니다:

version: '2.1'
orbs:
  terraform: circleci/terraform@3.1
workflows:
  deploy_infrastructure:
    jobs:
      - terraform/init:
          tag: 1.9.5
          checkout: true
          context: teleport-access
      - terraform/plan:
          tag: 1.9.5
          context: teleport-access
          requires:
            - terraform/init

변경 사항을 커밋하고 임의의 브랜치에 푸시하여 CircleCI 파이프라인을 트리거합니다. 파이프라인 로그에서 Terraform 계획이 성공적으로 실행되는 것을 확인할 수 있습니다.

EC2 인스턴스에서 Terraform 명령을 실행합니다:

terraform init
백엔드 초기화 중...
플러그인 공급자 초기화 중...- terraform.releases.teleport.dev/gravitational/teleport 버전 찾는 중 ...
terraform plan
Terraform은 선택한 공급자를 사용하여 다음 실행 계획을 생성했습니다. 리소스 작업은 다음 기호로 표시됩니다:  + 생성
Terraform은 다음 작업을 수행할 것입니다:
  # teleport_role.test가 생성됩니다  + resource "teleport_role" "test" {      + id       = (적용 후 알 수 있음)      + kind     = (적용 후 알 수 있음)      + metadata = {          + name      = "test"          + namespace = (적용 후 알 수 있음)        }      + spec     = {}      + version  = "v7"    }
계획: 1 추가, 0 변경, 0 삭제.

GCP VM에서 Terraform 명령을 실행합니다:

terraform init
백엔드 초기화 중...
플러그인 공급자 초기화 중...- terraform.releases.teleport.dev/gravitational/teleport 버전 찾는 중 ...
terraform plan
Terraform은 선택한 공급자를 사용하여 다음 실행 계획을 생성했습니다. 리소스 작업은 다음 기호로 표시됩니다:  + 생성
Terraform은 다음 작업을 수행할 것입니다:
  # teleport_role.test가 생성됩니다  + resource "teleport_role" "test" {      + id       = (적용 후 알 수 있음)      + kind     = (적용 후 알 수 있음)      + metadata = {          + name      = "test"          + namespace = (적용 후 알 수 있음)        }      + spec     = {}      + version  = "v7"    }
계획: 1 추가, 0 변경, 0 삭제.