InfoGrab DocsInfoGrab Docs

Bitbucket Pipelines에서 tbot 배포하기

요약

이 가이드에서는 Machine & Workload Identity의 에이전트인 tbot을 Bitbucket Pipelines 워크플로 내에서 실행하도록 구성합니다. bitbucket 조인 방식은 Machine & Workload Identity 봇이 공유 시크릿을 사용하지 않고도 Teleport Auth Service에 안전하게 인증할 수 있는 방법입니다.

이 가이드에서는 Machine & Workload Identity의 에이전트인 tbot을 Bitbucket Pipelines 워크플로 내에서 실행하도록 구성합니다. 이 봇은 장기 유효 시크릿이 필요 없도록 bitbucket 위임 조인(delegated joining) 방식을 사용하도록 구성됩니다.

작동 방식#

bitbucket 조인 방식은 Machine & Workload Identity 봇이 공유 시크릿을 사용하지 않고도 Teleport Auth Service에 안전하게 인증할 수 있는 방법입니다. 대신 Bitbucket Pipelines가 작업 환경에 삽입하는 OpenID Connect 토큰을 사용합니다.

이 토큰은 Teleport Auth Service로 전송되며, Auth Service가 Bitbucket의 ID 공급자를 신뢰하도록 구성되어 있고 모든 아이덴티티 어설션이 일치한다고 가정할 때 인증 시도가 성공합니다.

사전 요구사항#

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

  • tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

      $ TELEPORT_DOMAIN=teleport.example.com:443
      $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
      
    2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     
Warning
       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음, 현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.

예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의 도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여 다음 명령을 실행합니다:

$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다. 자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를 호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.

  • 푸시할 수 있는 Bitbucket 리포지터리.

1단계/4단계. Bitbucket 구성 확인#

Bitbucket 조인에는 리포지터리 설정에서 확인할 수 있는 여러 구성 매개변수가 필요합니다. Bitbucket 리포지터리에서 "Repository settings"로 이동한 다음, 사이드바의 "Pipelines" 아래에서 "OpenID Connect"를 선택합니다.

이 페이지에서 다음 값을 확인합니다.

  • ID 공급자 URL (identity-provider-url)
  • Audience (audience)
  • 워크스페이스 UUID (중괄호 포함) (workspace-uuid)
  • 리포지터리 UUID (중괄호 포함) (repository-uuid)

2단계/4단계. 봇 생성#

다음으로 Bot을 생성해야 합니다. Bot은 머신 또는 머신 그룹을 위한 Teleport identity입니다. 사용자와 마찬가지로 bot에는 무엇에 액세스할 수 있는지 정의하는 role 및 trait 집합이 있습니다.

bot.yaml을 생성합니다:

kind: bot
version: v1
metadata:
  # name is a unique identifier for the Bot in the cluster.
  name: example
spec:
  # roles is a list of roles to grant to the Bot. Don't worry if you don't know
  # what roles you need to specify here, the Access Guides will walk you through
  # creating and assigning roles to the already created Bot.
  roles: []

example을 Bot에 대한 고유하고 설명적인 이름으로 반드시 교체하십시오.

tctl을 사용하여 이 파일을 적용합니다:

$ tctl create bot.yaml

3단계/4단계. Bitbucket Pipelines용 조인 토큰 생성#

Pipelines 워크플로가 Teleport 클러스터에 인증할 수 있도록 하려면 먼저 조인 토큰을 생성해야 합니다. 이 토큰은 Auth Service가 봇이나 노드의 조인 허용 여부를 결정하는 기준을 설정합니다.

bot-token.yaml 파일을 만들고, identity_provider_url, audience, workspace_uuid, repository_uuid를 1단계에서 확인한 값으로 반드시 교체합니다.

kind: token
version: v2
metadata:
  name: example-bot
spec:
  roles: [Bot]
  join_method: bitbucket
  bot_name: example
  bitbucket:
    identity_provider_url: identity-provider-url
    audience: audience
    # allow specifies the rules by which the Auth Service determines if `tbot`
    # should be allowed to join.
    allow:
    - workspace_uuid: 'workspace-uuid'
      repository_uuid: 'repository-uuid'

토큰 리소스의 필드를 좀 더 자세히 살펴보겠습니다.

  • metadata.name은 토큰의 이름을 정의합니다. 이 값은 이후 구성의 다른 부분에서도 사용해야 한다는 점에 유의하세요.
  • spec.bot_name은 이 토큰이 접근 권한을 부여할 Machine ID 봇의 이름입니다. 이 값은 이후 구성의 다른 부분에서도 사용해야 한다는 점에 유의하세요.
  • spec.roles는 이 토큰이 접근 권한을 부여할 역할을 정의합니다. [Bot] 값은 이 토큰이 Machine & Workload Identity 봇에 접근 권한을 부여함을 나타냅니다.
  • spec.join_method는 토큰이 적용되는 조인 방식을 정의합니다. 이 가이드는 Bitbucket Pipelines만 다루므로 이 값을 bitbucket으로 설정합니다.
  • spec.bitbucket.identity_provider_url은 Bitbucket 리포지터리 설정의 Pipelines 및 OpenID Connect에 표시된 ID 공급자 URL입니다.
  • spec.bitbucket.audience는 Bitbucket 리포지터리 설정의 Pipelines 및 OpenID Connect에 표시된 audience 값입니다.
  • spec.bitbucket.allow는 어떤 Bitbucket Pipelines 실행이 이 토큰을 사용해 인증할 수 있는지에 대한 규칙을 설정하는 데 사용됩니다.

유효한 필드의 전체 목록은 토큰 참조를 참고하세요.

tctl을 사용하여 이를 Teleport 클러스터에 적용합니다.

$ tctl create -f bot-token.yaml

4단계/4단계. Bitbucket Pipelines 워크플로 구성#

봇과 조인 토큰이 생성되었으므로 이제 Teleport에 인증할 수 있는 워크플로를 구성할 수 있습니다.

이 예제 워크플로는 "Pipelines" 또는 "Branches" 뷰에서 수동으로 트리거할 수 있는 "custom" 파이프라인을 정의합니다.

image: atlassian/default-image:3

pipelines:
  custom:
    run-tbot:
      - step:
          oidc: true
          script:
            # Install Teleport
            - curl "https://example.teleport.sh:443/scripts/install.sh" | bash

            # Run `tbot` in identity mode for SSH access
            - tbot start identity --destination=./tbot-user --join-method=bitbucket --proxy-server=example.teleport.sh:443 --token=example-bot --oneshot

            # Make use of the generated SSH credentials
            - ssh -F ./tbot-user/ssh_config user@node.example.teleport.sh echo "hello world"

example.teleport.sh를 Teleport Proxy Service의 주소로 바꾸세요.

이 예제는 SSH 자격 증명을 생성하기 위해 tbot을 identity 모드로 시작합니다. 데이터베이스, 애플리케이션, 쿠버네티스 접근 등 다른 모드를 사용하는 방법에 대한 자세한 내용은 tbot 문서를 참고하세요.

기존 워크플로를 조정하는 경우 다음 단계를 참고하세요.

  1. 해당 단계에 토큰이 발급되도록 스텝 속성에 oidc: true를 설정합니다
  2. 클러스터의 설치 스크립트로부터 Teleport를 설치합니다
  3. --join-method=bitbucket, --token=example-bot(또는 3단계에서 구성한 이름), --oneshot을 지정하여 tbot을 실행합니다
Sharing credentials between steps

Bitbucket Pipelines에서는 artifacts를 사용하여 저장된 출력이 CI 실행 완료 후에도 다운로드 가능한 상태로 남아 있기 때문에, 출력을 스텝 간에 안전하게 공유할 수 없다는 점에 유의하세요.

이러한 제한 때문에 Teleport 자격 증명을 사용하는 모든 작업은 동일한 스텝 내에서 수행해야 합니다. 필요하다면, 한 번의 실행에서 여러 스텝에 걸쳐 자격 증명이 필요한 경우를 위해 여기에 표시된 스크립트를 복제하여 tbot을 여러 번 다운로드하고 실행할 수 있습니다.

다음 단계#

  • 접근 가이드를 따라 환경에 맞게 tbot 구성을 마무리하세요.
  • 구성 참조를 읽고 사용 가능한 모든 구성 옵션을 살펴보세요.
  • Bitbucket Pipelines 자체에 대한 자세한 내용은 해당 문서를 참고하세요.

Bitbucket Pipelines에서 tbot 배포하기

Teleport v18.9
원문 보기
요약

이 가이드에서는 Machine &#x26; Workload Identity의 에이전트인 tbot을 Bitbucket Pipelines 워크플로 내에서 실행하도록 구성합니다. bitbucket 조인 방식은 Machine &#x26; Workload Identity 봇이 공유 시크릿을 사용하지 않고도 Teleport Auth Service에 안전하게 인증할 수 있는 방법입니다.

이 가이드에서는 Machine & Workload Identity의 에이전트인 tbot을 Bitbucket Pipelines 워크플로 내에서 실행하도록 구성합니다. 이 봇은 장기 유효 시크릿이 필요 없도록 bitbucket 위임 조인(delegated joining) 방식을 사용하도록 구성됩니다.

작동 방식#

bitbucket 조인 방식은 Machine & Workload Identity 봇이 공유 시크릿을 사용하지 않고도 Teleport Auth Service에 안전하게 인증할 수 있는 방법입니다. 대신 Bitbucket Pipelines가 작업 환경에 삽입하는 OpenID Connect 토큰을 사용합니다.

이 토큰은 Teleport Auth Service로 전송되며, Auth Service가 Bitbucket의 ID 공급자를 신뢰하도록 구성되어 있고 모든 아이덴티티 어설션이 일치한다고 가정할 때 인증 시도가 성공합니다.

사전 요구사항#

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

  • tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

      $ TELEPORT_DOMAIN=teleport.example.com:443
      $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
      
    2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     
Warning
       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음, 현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.

예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의 도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여 다음 명령을 실행합니다:

$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다. 자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를 호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.

  • 푸시할 수 있는 Bitbucket 리포지터리.

1단계/4단계. Bitbucket 구성 확인#

Bitbucket 조인에는 리포지터리 설정에서 확인할 수 있는 여러 구성 매개변수가 필요합니다. Bitbucket 리포지터리에서 "Repository settings"로 이동한 다음, 사이드바의 "Pipelines" 아래에서 "OpenID Connect"를 선택합니다.

이 페이지에서 다음 값을 확인합니다.

  • ID 공급자 URL (identity-provider-url)
  • Audience (audience)
  • 워크스페이스 UUID (중괄호 포함) (workspace-uuid)
  • 리포지터리 UUID (중괄호 포함) (repository-uuid)

2단계/4단계. 봇 생성#

다음으로 Bot을 생성해야 합니다. Bot은 머신 또는 머신 그룹을 위한 Teleport identity입니다. 사용자와 마찬가지로 bot에는 무엇에 액세스할 수 있는지 정의하는 role 및 trait 집합이 있습니다.

bot.yaml을 생성합니다:

kind: bot
version: v1
metadata:
  # name is a unique identifier for the Bot in the cluster.
  name: example
spec:
  # roles is a list of roles to grant to the Bot. Don't worry if you don't know
  # what roles you need to specify here, the Access Guides will walk you through
  # creating and assigning roles to the already created Bot.
  roles: []

example을 Bot에 대한 고유하고 설명적인 이름으로 반드시 교체하십시오.

tctl을 사용하여 이 파일을 적용합니다:

$ tctl create bot.yaml

3단계/4단계. Bitbucket Pipelines용 조인 토큰 생성#

Pipelines 워크플로가 Teleport 클러스터에 인증할 수 있도록 하려면 먼저 조인 토큰을 생성해야 합니다. 이 토큰은 Auth Service가 봇이나 노드의 조인 허용 여부를 결정하는 기준을 설정합니다.

bot-token.yaml 파일을 만들고, identity_provider_url, audience, workspace_uuid, repository_uuid를 1단계에서 확인한 값으로 반드시 교체합니다.

kind: token
version: v2
metadata:
  name: example-bot
spec:
  roles: [Bot]
  join_method: bitbucket
  bot_name: example
  bitbucket:
    identity_provider_url: identity-provider-url
    audience: audience
    # allow specifies the rules by which the Auth Service determines if `tbot`
    # should be allowed to join.
    allow:
    - workspace_uuid: 'workspace-uuid'
      repository_uuid: 'repository-uuid'

토큰 리소스의 필드를 좀 더 자세히 살펴보겠습니다.

  • metadata.name은 토큰의 이름을 정의합니다. 이 값은 이후 구성의 다른 부분에서도 사용해야 한다는 점에 유의하세요.
  • spec.bot_name은 이 토큰이 접근 권한을 부여할 Machine ID 봇의 이름입니다. 이 값은 이후 구성의 다른 부분에서도 사용해야 한다는 점에 유의하세요.
  • spec.roles는 이 토큰이 접근 권한을 부여할 역할을 정의합니다. [Bot] 값은 이 토큰이 Machine & Workload Identity 봇에 접근 권한을 부여함을 나타냅니다.
  • spec.join_method는 토큰이 적용되는 조인 방식을 정의합니다. 이 가이드는 Bitbucket Pipelines만 다루므로 이 값을 bitbucket으로 설정합니다.
  • spec.bitbucket.identity_provider_url은 Bitbucket 리포지터리 설정의 Pipelines 및 OpenID Connect에 표시된 ID 공급자 URL입니다.
  • spec.bitbucket.audience는 Bitbucket 리포지터리 설정의 Pipelines 및 OpenID Connect에 표시된 audience 값입니다.
  • spec.bitbucket.allow는 어떤 Bitbucket Pipelines 실행이 이 토큰을 사용해 인증할 수 있는지에 대한 규칙을 설정하는 데 사용됩니다.

유효한 필드의 전체 목록은 토큰 참조를 참고하세요.

tctl을 사용하여 이를 Teleport 클러스터에 적용합니다.

$ tctl create -f bot-token.yaml

4단계/4단계. Bitbucket Pipelines 워크플로 구성#

봇과 조인 토큰이 생성되었으므로 이제 Teleport에 인증할 수 있는 워크플로를 구성할 수 있습니다.

이 예제 워크플로는 "Pipelines" 또는 "Branches" 뷰에서 수동으로 트리거할 수 있는 "custom" 파이프라인을 정의합니다.

image: atlassian/default-image:3

pipelines:
  custom:
    run-tbot:
      - step:
          oidc: true
          script:
            # Install Teleport
            - curl "https://example.teleport.sh:443/scripts/install.sh" | bash

            # Run `tbot` in identity mode for SSH access
            - tbot start identity --destination=./tbot-user --join-method=bitbucket --proxy-server=example.teleport.sh:443 --token=example-bot --oneshot

            # Make use of the generated SSH credentials
            - ssh -F ./tbot-user/ssh_config user@node.example.teleport.sh echo "hello world"

example.teleport.sh를 Teleport Proxy Service의 주소로 바꾸세요.

이 예제는 SSH 자격 증명을 생성하기 위해 tbot을 identity 모드로 시작합니다. 데이터베이스, 애플리케이션, 쿠버네티스 접근 등 다른 모드를 사용하는 방법에 대한 자세한 내용은 tbot 문서를 참고하세요.

기존 워크플로를 조정하는 경우 다음 단계를 참고하세요.

  1. 해당 단계에 토큰이 발급되도록 스텝 속성에 oidc: true를 설정합니다
  2. 클러스터의 설치 스크립트로부터 Teleport를 설치합니다
  3. --join-method=bitbucket, --token=example-bot(또는 3단계에서 구성한 이름), --oneshot을 지정하여 tbot을 실행합니다
Sharing credentials between steps

Bitbucket Pipelines에서는 artifacts를 사용하여 저장된 출력이 CI 실행 완료 후에도 다운로드 가능한 상태로 남아 있기 때문에, 출력을 스텝 간에 안전하게 공유할 수 없다는 점에 유의하세요.

이러한 제한 때문에 Teleport 자격 증명을 사용하는 모든 작업은 동일한 스텝 내에서 수행해야 합니다. 필요하다면, 한 번의 실행에서 여러 스텝에 걸쳐 자격 증명이 필요한 경우를 위해 여기에 표시된 스크립트를 복제하여 tbot을 여러 번 다운로드하고 실행할 수 있습니다.

다음 단계#

  • 접근 가이드를 따라 환경에 맞게 tbot 구성을 마무리하세요.
  • 구성 참조를 읽고 사용 가능한 모든 구성 옵션을 살펴보세요.
  • Bitbucket Pipelines 자체에 대한 자세한 내용은 해당 문서를 참고하세요.