InfoGrab Docs

Azure DevOps에 tbot 배포

요약

이 가이드에서는 Azure DevOps 파이프라인 실행 내에서 머신 및 워크로드 아이덴티티의 에이전트 tbot을 실행하도록 설정합니다. azure_devops 조인 방법은 공유 시크릿을 사용하지 않고 머신 및 워크로드 아이덴티티 봇이 Teleport Auth Service에 인증할 수 있는 안전한 방법입니다.

이 가이드에서는 Azure DevOps 파이프라인 실행 내에서 머신 및 워크로드 아이덴티티의 에이전트 tbot을 실행하도록 설정합니다. 봇은 장기 시크릿의 필요성을 제거하기 위해 azure_devops 위임 조인 방법을 사용하도록 설정됩니다.

작동 방식#

azure_devops 조인 방법은 공유 시크릿을 사용하지 않고 머신 및 워크로드 아이덴티티 봇이 Teleport Auth Service에 인증할 수 있는 안전한 방법입니다. 대신 Azure DevOps가 API를 통해 파이프라인 작업에 제공하는 OpenID Connect 토큰을 사용합니다.

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

이는 비밀번호 또는 SSH 개인 키와 같은 장기 시크릿이 Azure DevOps 조직에서 유출되는 위험을 완화하고 감사 및 세밀한 접근 제어와 같은 Teleport의 여러 다른 이점을 제공합니다.

사전 조건#

  • A running Teleport (v17.5.1 or higher) cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients

    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
$ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"

    2. Follow the instructions for your platform to install tctl and tsh clients:

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

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

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

1단계/5단계. Azure DevOps 조직 ID 확인#

Azure DevOps 파이프라인 내에서 실행 중인 tbot에 접근을 허용하기 전에 파이프라인이 실행되는 Azure DevOps 조직의 ID를 확인해야 합니다. 이는 나중에 조인 토큰을 설정하는 데 사용됩니다.

조직 ID를 확인하려면 System.CollectionId 변수를 출력하는 단계를 해당 조직 내에 있는 새 또는 기존 파이프라인에 추가합니다.

예를 들면:

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- script: |
    echo "Organization ID: $(System.CollectionId)"

이 파이프라인을 실행하고 단계의 출력을 검사합니다. 다음과 유사하게 로그에 조직 ID가 출력되어야 합니다:

========================== Starting Command Output ===========================
/usr/bin/bash --noprofile --norc /home/vsts/work/_temp/c4fdfbf7-6cd4-4737-a2a2-16702d201449.sh
Organization ID: 0ca3ddd9-0000-1111-2222-example58665

나중에 필요하므로 이 조직 ID를 기록해 두세요:

2단계/5단계. 봇 만들기#

Next, you need to create a Bot. A Bot is a Teleport identity for a machine or group of machines. Like users, bots have a set of roles and traits which define what they can access.

Create 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: []

Make sure you replace example with a unique, descriptive name for your Bot.

Use tctl to apply this file:

$ tctl create bot.yaml

3단계/5단계. 조인 토큰 만들기#

Azure DevOps 파이프라인이 Teleport 클러스터에 인증할 수 있도록 하려면 먼저 조인 토큰을 만들어야 합니다. Azure DevOps 조인 토큰에는 어떤 파이프라인이 해당 토큰을 사용하여 Teleport 클러스터에 조인할 수 있는지 설명하는 허용 규칙이 포함됩니다. 규칙에는 여러 필드가 포함될 수 있으며, 단일 규칙 내의 모든 필드와 일치하는 모든 파이프라인에 접근이 허용됩니다.

이 예시에서는 특정 프로젝트 내의 모든 Azure DevOps 파이프라인에 접근을 허용하는 규칙이 있는 토큰을 만듭니다.

bot-token.yaml 파일을 만들고 를 Azure DevOps 프로젝트 이름으로 설정합니다:

kind: token
version: v2
metadata:
  name: example-bot
spec:
  roles: [Bot]
  join_method: azure_devops
  bot_name: example
  azure_devops:
    organization_id:  name="organization-id" />
    allow:
      - project_name:  name="my-project" />

교체:

  • example-bot을 토큰을 설명하는 의미 있는 이름으로.
  • example을 2단계에서 만든 봇의 이름으로.
  • my-project를 봇 접근을 허용하려는 Azure DevOps 프로젝트 이름으로.

Azure DevOps 조인에 대한 토큰 설정 옵션의 전체 목록은 조인 방법 레퍼런스 페이지에서 확인할 수 있습니다.

tctl을 사용하여 이 파일을 Teleport 클러스터에 적용합니다:

$ tctl create -f bot-token.yaml

4단계/5단계. Azure DevOps 파이프라인 설정#

봇과 조인 토큰이 만들어지면 이를 사용하도록 tbot을 설정하는 Azure DevOps 파이프라인을 설정할 수 있습니다.

tbot을 설정하기 위해 YAML 파일이 사용됩니다. 이 예시에서는 저장소 자체 내에 설정을 저장하지만 CI 파이프라인 자체에서 생성할 수도 있습니다.

저장소 내에 tbot.yaml을 만듭니다:

version: v2
proxy_server:  name="example.teleport.sh" />:443
onboarding:
  join_method: azure_devops
  token: example-bot
oneshot: true
storage:
  type: memory
# services는 접근 가이드를 완료하는 동안 채워집니다.
services: []

교체:

  • 를 Teleport Proxy Service 또는 Auth Service의 주소로. Teleport Proxy Service의 주소를 사용하는 것이 좋습니다.
  • example-bot을 두 번째 단계에서 만든 토큰 이름으로.

이제 tbot을 설치하고 방금 만든 설정으로 실행하도록 Azure DevOps 파이프라인을 수정합니다.

프로덕션에서는 각 파이프라인 실행에서 tbot을 설치하는 대신 tbot 및 기타 의존성이 포함된 컨테이너 이미지를 만들고 해당 이미지를 기반으로 하는 컨테이너 내에서 파이프라인을 실행하는 것이 좋습니다.

다음 YAML로 새 파이프라인을 만들거나 기존 파이프라인을 수정합니다:

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- script: |
    curl "https://:443/scripts/install.sh" | sudo bash
    tbot start -c tbot.yaml
  displayName: 'Install Teleport and start tbot'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)
    TELEPORT_ANONYMOUS_TELEMETRY: 1

를 Teleport Proxy Service의 주소로 교체합니다.

SYSTEM_ACCESSTOKEN 환경 변수가 포함된 것에 주목하세요. 이 변수는 tbot이 실행되는 모든 단계에서 채워져야 합니다.

TELEPORT_ANONYMOUS_TELEMETRY는 익명 사용 텔레메트리 제출을 활성화합니다. 이는 tbot의 미래 개발을 형성하는 데 도움이 됩니다. 이것을 생략하면 비활성화할 수 있습니다.

이 두 파일을 저장소에 커밋하고 푸시합니다.

Azure DevOps 파이프라인 실행 상태를 확인합니다. 모든 것이 올바르게 설정되어 있다면 tbot이 성공적으로 시작되고, 클러스터에 조인하고, 종료되는 것을 볼 수 있습니다.

5단계/5단계. 서비스 설정#

You have now prepared the base configuration for tbot. At this point, it identifies itself to the Teleport cluster and renews its own credentials but does not output any credentials for other applications to use.

Follow one of the access guides to configure a service that meets your access needs.

추가 단계#

Azure DevOps에 tbot 배포

원문 보기
요약

이 가이드에서는 Azure DevOps 파이프라인 실행 내에서 머신 및 워크로드 아이덴티티의 에이전트 tbot을 실행하도록 설정합니다. azure_devops 조인 방법은 공유 시크릿을 사용하지 않고 머신 및 워크로드 아이덴티티 봇이 Teleport Auth Service에 인증할 수 있는 안전한 방법입니다.

이 가이드에서는 Azure DevOps 파이프라인 실행 내에서 머신 및 워크로드 아이덴티티의 에이전트 tbot을 실행하도록 설정합니다. 봇은 장기 시크릿의 필요성을 제거하기 위해 azure_devops 위임 조인 방법을 사용하도록 설정됩니다.

작동 방식#

azure_devops 조인 방법은 공유 시크릿을 사용하지 않고 머신 및 워크로드 아이덴티티 봇이 Teleport Auth Service에 인증할 수 있는 안전한 방법입니다. 대신 Azure DevOps가 API를 통해 파이프라인 작업에 제공하는 OpenID Connect 토큰을 사용합니다.

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

이는 비밀번호 또는 SSH 개인 키와 같은 장기 시크릿이 Azure DevOps 조직에서 유출되는 위험을 완화하고 감사 및 세밀한 접근 제어와 같은 Teleport의 여러 다른 이점을 제공합니다.

사전 조건#

  • A running Teleport (v17.5.1 or higher) cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients

    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
$ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"

    2. Follow the instructions for your platform to install tctl and tsh clients:

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

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

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

1단계/5단계. Azure DevOps 조직 ID 확인#

Azure DevOps 파이프라인 내에서 실행 중인 tbot에 접근을 허용하기 전에 파이프라인이 실행되는 Azure DevOps 조직의 ID를 확인해야 합니다. 이는 나중에 조인 토큰을 설정하는 데 사용됩니다.

조직 ID를 확인하려면 System.CollectionId 변수를 출력하는 단계를 해당 조직 내에 있는 새 또는 기존 파이프라인에 추가합니다.

예를 들면:

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- script: |
    echo "Organization ID: $(System.CollectionId)"

이 파이프라인을 실행하고 단계의 출력을 검사합니다. 다음과 유사하게 로그에 조직 ID가 출력되어야 합니다:

========================== Starting Command Output ===========================
/usr/bin/bash --noprofile --norc /home/vsts/work/_temp/c4fdfbf7-6cd4-4737-a2a2-16702d201449.sh
Organization ID: 0ca3ddd9-0000-1111-2222-example58665

나중에 필요하므로 이 조직 ID를 기록해 두세요:

2단계/5단계. 봇 만들기#

Next, you need to create a Bot. A Bot is a Teleport identity for a machine or group of machines. Like users, bots have a set of roles and traits which define what they can access.

Create 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: []

Make sure you replace example with a unique, descriptive name for your Bot.

Use tctl to apply this file:

$ tctl create bot.yaml

3단계/5단계. 조인 토큰 만들기#

Azure DevOps 파이프라인이 Teleport 클러스터에 인증할 수 있도록 하려면 먼저 조인 토큰을 만들어야 합니다. Azure DevOps 조인 토큰에는 어떤 파이프라인이 해당 토큰을 사용하여 Teleport 클러스터에 조인할 수 있는지 설명하는 허용 규칙이 포함됩니다. 규칙에는 여러 필드가 포함될 수 있으며, 단일 규칙 내의 모든 필드와 일치하는 모든 파이프라인에 접근이 허용됩니다.

이 예시에서는 특정 프로젝트 내의 모든 Azure DevOps 파이프라인에 접근을 허용하는 규칙이 있는 토큰을 만듭니다.

bot-token.yaml 파일을 만들고 를 Azure DevOps 프로젝트 이름으로 설정합니다:

kind: token
version: v2
metadata:
  name: example-bot
spec:
  roles: [Bot]
  join_method: azure_devops
  bot_name: example
  azure_devops:
    organization_id:  name="organization-id" />
    allow:
      - project_name:  name="my-project" />

교체:

  • example-bot을 토큰을 설명하는 의미 있는 이름으로.
  • example을 2단계에서 만든 봇의 이름으로.
  • my-project를 봇 접근을 허용하려는 Azure DevOps 프로젝트 이름으로.

Azure DevOps 조인에 대한 토큰 설정 옵션의 전체 목록은 조인 방법 레퍼런스 페이지에서 확인할 수 있습니다.

tctl을 사용하여 이 파일을 Teleport 클러스터에 적용합니다:

$ tctl create -f bot-token.yaml

4단계/5단계. Azure DevOps 파이프라인 설정#

봇과 조인 토큰이 만들어지면 이를 사용하도록 tbot을 설정하는 Azure DevOps 파이프라인을 설정할 수 있습니다.

tbot을 설정하기 위해 YAML 파일이 사용됩니다. 이 예시에서는 저장소 자체 내에 설정을 저장하지만 CI 파이프라인 자체에서 생성할 수도 있습니다.

저장소 내에 tbot.yaml을 만듭니다:

version: v2
proxy_server:  name="example.teleport.sh" />:443
onboarding:
  join_method: azure_devops
  token: example-bot
oneshot: true
storage:
  type: memory
# services는 접근 가이드를 완료하는 동안 채워집니다.
services: []

교체:

  • 를 Teleport Proxy Service 또는 Auth Service의 주소로. Teleport Proxy Service의 주소를 사용하는 것이 좋습니다.
  • example-bot을 두 번째 단계에서 만든 토큰 이름으로.

이제 tbot을 설치하고 방금 만든 설정으로 실행하도록 Azure DevOps 파이프라인을 수정합니다.

프로덕션에서는 각 파이프라인 실행에서 tbot을 설치하는 대신 tbot 및 기타 의존성이 포함된 컨테이너 이미지를 만들고 해당 이미지를 기반으로 하는 컨테이너 내에서 파이프라인을 실행하는 것이 좋습니다.

다음 YAML로 새 파이프라인을 만들거나 기존 파이프라인을 수정합니다:

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- script: |
    curl "https://:443/scripts/install.sh" | sudo bash
    tbot start -c tbot.yaml
  displayName: 'Install Teleport and start tbot'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)
    TELEPORT_ANONYMOUS_TELEMETRY: 1

를 Teleport Proxy Service의 주소로 교체합니다.

SYSTEM_ACCESSTOKEN 환경 변수가 포함된 것에 주목하세요. 이 변수는 tbot이 실행되는 모든 단계에서 채워져야 합니다.

TELEPORT_ANONYMOUS_TELEMETRY는 익명 사용 텔레메트리 제출을 활성화합니다. 이는 tbot의 미래 개발을 형성하는 데 도움이 됩니다. 이것을 생략하면 비활성화할 수 있습니다.

이 두 파일을 저장소에 커밋하고 푸시합니다.

Azure DevOps 파이프라인 실행 상태를 확인합니다. 모든 것이 올바르게 설정되어 있다면 tbot이 성공적으로 시작되고, 클러스터에 조인하고, 종료되는 것을 볼 수 있습니다.

5단계/5단계. 서비스 설정#

You have now prepared the base configuration for tbot. At this point, it identifies itself to the Teleport cluster and renews its own credentials but does not output any credentials for other applications to use.

Follow one of the access guides to configure a service that meets your access needs.

추가 단계#