InfoGrab Docs

GitLab CI에 tbot 배포

요약

이 가이드에서는 Teleport 머신 및 워크로드 아이덴티티를 사용하여 GitLab 파이프라인이 장기 시크릿 없이 Teleport SSH 노드에 안전하게 연결할 수 있도록 합니다. GitLab용 머신 및 워크로드 아이덴티티는 GitLab의 클라우드 호스팅 옵션과 자체 호스팅 GitLab 설치와 함께 작동합니다.

이 가이드에서는 Teleport 머신 및 워크로드 아이덴티티를 사용하여 GitLab 파이프라인이 장기 시크릿 없이 Teleport SSH 노드에 안전하게 연결할 수 있도록 합니다.

GitLab용 머신 및 워크로드 아이덴티티는 GitLab의 클라우드 호스팅 옵션과 자체 호스팅 GitLab 설치와 함께 작동합니다. 최소 지원 GitLab 버전은 15.7입니다.

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

사전 조건#

  • A running Teleport 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.

  • Teleport에 연결할 GitLab 프로젝트. GitLab의 클라우드 호스팅 서비스(gitlab.com) 또는 자체 호스팅 GitLab 인스턴스에 있을 수 있습니다. 자체 호스팅 GitLab 인스턴스를 사용하는 경우 Teleport Auth Service가 GitLab 인스턴스에 연결할 수 있어야 하고 GitLab 인스턴스에 유효한 TLS 인증서가 설정되어 있어야 합니다.

1단계/4단계. 봇 만들기#

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

2단계/4단계. 조인 토큰 만들기#

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

이 예시에서는 특정 GitLab 프로젝트 내의 모든 GitLab CI 작업에 접근을 허용하는 규칙이 있는 토큰을 만듭니다. GitLab 프로젝트의 정규화된 경로를 확인합니다. 여기에는 사용자명(또는 그룹)과 프로젝트 이름이 포함됩니다(예: my-user/my-project).

bot-token.yaml 파일을 만듭니다. 이 예시의 주석에서 제안한 대로 모든 값을 교체합니다:

kind: token
version: v2
metadata:
  name: example-bot
spec:
  # Bot 역할은 이 토큰이 노드 조인이 아닌 봇 사용자에게 접근을 허용함을 나타냅니다.
  # 이 역할은 Teleport에 내장되어 있습니다.
  roles: [Bot]
  join_method: gitlab
  # bot_name은 이 토큰이 접근을 허용할 봇 사용자를 나타냅니다.
  # 1단계에서 만든 봇의 이름과 일치해야 합니다.
  bot_name: example
  gitlab:
    # domain은 GitLab 인스턴스의 도메인이어야 합니다.
    # GitLab의 클라우드 호스팅 서비스를 사용하는 경우 이 필드를 완전히 생략합니다.
    domain: gitlab.example.com
    # allow는 Teleport가 어떤 GitLab 토큰을 수락할지 제어하는 규칙을 지정합니다.
    # allow 규칙과 일치하지 않는 토큰은 거부됩니다.
    allow:
        # project_path는 이전에 확인한 GitLab 프로젝트의 정규화된 경로여야 합니다.
        # 이렇게 하면 해당 프로젝트의 모든 GitLab CI 실행에 접근이 허용됩니다.
      - project_path: my-user/my-project

조인 토큰 레퍼런스 페이지에서 GitLab 조인의 토큰 설정 옵션 전체 목록을 확인할 수 있습니다.

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

$ tctl create -f bot-token.yaml

3단계/4단계. GitLab 파이프라인 설정#

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

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

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

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

교체:

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

이제 GitLab CI 파이프라인을 정의할 수 있습니다. 파이프라인이 tbot을 사용하기 전에 환경 내에서 사용 가능해야 합니다. 이 예시에서는 CI 단계의 일부로 tbot을 다운로드하는 것을 보여주지만, 프로덕션 구현에서는 Teleport CDN에 의존하지 않도록 이 바이너리를 포함하는 docker 이미지를 구축하는 것이 좋습니다.

저장소 내에 .gitlab-ci.yml을 만듭니다:

stages:
  - deploy

deploy-job:
  stage: deploy
  # id_tokens는 GitLab이 GitLab 실행 환경에 자동으로 주입하는 ID 토큰을 설정합니다.
  #
  # GitLab의 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 Service는 토큰이 다른 서비스나
      # Teleport 클러스터가 아닌 자신을 위한 것임을 알 수 있습니다.
      aud:  name="example.teleport.sh"/>
  script:
    - curl "https://example.teleport.sh"/>:443/scripts/install.sh" | bash
    - 'TELEPORT_ANONYMOUS_TELEMETRY=1 tbot start -c tbot.yaml'

교체:

  • aud의 를 Teleport 클러스터의 이름으로. 이것은 반드시 Teleport 클러스터의 주소일 필요는 없으며 포트나 체계(예: http/https)를 포함하지 않습니다.
  • 를 Teleport Proxy Service의 주소로.

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

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

GitLab CI 상태를 확인하고 커밋의 로그 결과에서 실패가 없는지 검사합니다.

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

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.

추가 단계#

GitLab CI에 tbot 배포

원문 보기
요약

이 가이드에서는 Teleport 머신 및 워크로드 아이덴티티를 사용하여 GitLab 파이프라인이 장기 시크릿 없이 Teleport SSH 노드에 안전하게 연결할 수 있도록 합니다. GitLab용 머신 및 워크로드 아이덴티티는 GitLab의 클라우드 호스팅 옵션과 자체 호스팅 GitLab 설치와 함께 작동합니다.

이 가이드에서는 Teleport 머신 및 워크로드 아이덴티티를 사용하여 GitLab 파이프라인이 장기 시크릿 없이 Teleport SSH 노드에 안전하게 연결할 수 있도록 합니다.

GitLab용 머신 및 워크로드 아이덴티티는 GitLab의 클라우드 호스팅 옵션과 자체 호스팅 GitLab 설치와 함께 작동합니다. 최소 지원 GitLab 버전은 15.7입니다.

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

사전 조건#

  • A running Teleport 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.

  • Teleport에 연결할 GitLab 프로젝트. GitLab의 클라우드 호스팅 서비스(gitlab.com) 또는 자체 호스팅 GitLab 인스턴스에 있을 수 있습니다. 자체 호스팅 GitLab 인스턴스를 사용하는 경우 Teleport Auth Service가 GitLab 인스턴스에 연결할 수 있어야 하고 GitLab 인스턴스에 유효한 TLS 인증서가 설정되어 있어야 합니다.

1단계/4단계. 봇 만들기#

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

2단계/4단계. 조인 토큰 만들기#

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

이 예시에서는 특정 GitLab 프로젝트 내의 모든 GitLab CI 작업에 접근을 허용하는 규칙이 있는 토큰을 만듭니다. GitLab 프로젝트의 정규화된 경로를 확인합니다. 여기에는 사용자명(또는 그룹)과 프로젝트 이름이 포함됩니다(예: my-user/my-project).

bot-token.yaml 파일을 만듭니다. 이 예시의 주석에서 제안한 대로 모든 값을 교체합니다:

kind: token
version: v2
metadata:
  name: example-bot
spec:
  # Bot 역할은 이 토큰이 노드 조인이 아닌 봇 사용자에게 접근을 허용함을 나타냅니다.
  # 이 역할은 Teleport에 내장되어 있습니다.
  roles: [Bot]
  join_method: gitlab
  # bot_name은 이 토큰이 접근을 허용할 봇 사용자를 나타냅니다.
  # 1단계에서 만든 봇의 이름과 일치해야 합니다.
  bot_name: example
  gitlab:
    # domain은 GitLab 인스턴스의 도메인이어야 합니다.
    # GitLab의 클라우드 호스팅 서비스를 사용하는 경우 이 필드를 완전히 생략합니다.
    domain: gitlab.example.com
    # allow는 Teleport가 어떤 GitLab 토큰을 수락할지 제어하는 규칙을 지정합니다.
    # allow 규칙과 일치하지 않는 토큰은 거부됩니다.
    allow:
        # project_path는 이전에 확인한 GitLab 프로젝트의 정규화된 경로여야 합니다.
        # 이렇게 하면 해당 프로젝트의 모든 GitLab CI 실행에 접근이 허용됩니다.
      - project_path: my-user/my-project

조인 토큰 레퍼런스 페이지에서 GitLab 조인의 토큰 설정 옵션 전체 목록을 확인할 수 있습니다.

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

$ tctl create -f bot-token.yaml

3단계/4단계. GitLab 파이프라인 설정#

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

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

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

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

교체:

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

이제 GitLab CI 파이프라인을 정의할 수 있습니다. 파이프라인이 tbot을 사용하기 전에 환경 내에서 사용 가능해야 합니다. 이 예시에서는 CI 단계의 일부로 tbot을 다운로드하는 것을 보여주지만, 프로덕션 구현에서는 Teleport CDN에 의존하지 않도록 이 바이너리를 포함하는 docker 이미지를 구축하는 것이 좋습니다.

저장소 내에 .gitlab-ci.yml을 만듭니다:

stages:
  - deploy

deploy-job:
  stage: deploy
  # id_tokens는 GitLab이 GitLab 실행 환경에 자동으로 주입하는 ID 토큰을 설정합니다.
  #
  # GitLab의 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 Service는 토큰이 다른 서비스나
      # Teleport 클러스터가 아닌 자신을 위한 것임을 알 수 있습니다.
      aud:  name="example.teleport.sh"/>
  script:
    - curl "https://example.teleport.sh"/>:443/scripts/install.sh" | bash
    - 'TELEPORT_ANONYMOUS_TELEMETRY=1 tbot start -c tbot.yaml'

교체:

  • aud의 를 Teleport 클러스터의 이름으로. 이것은 반드시 Teleport 클러스터의 주소일 필요는 없으며 포트나 체계(예: http/https)를 포함하지 않습니다.
  • 를 Teleport Proxy Service의 주소로.

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

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

GitLab CI 상태를 확인하고 커밋의 로그 결과에서 실패가 없는지 검사합니다.

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

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.

추가 단계#