Infograb logo
참여 방법 및 토큰

이 가이드는 Teleport 참여 프로세스의 핵심 개념을 설명하고, 모든 지원 참여 방법에 대한 참고 자료를 제공하며, 이를 보안 속성에 따라 분류합니다. 이 가이드는 각 참여 방법을 사용하여 인스턴스에 참여하는 방법을 단계별로 설명하지 않지만, 가능한 한 관련된 How-To 가이드에 링크를 제공합니다.

사전 요구 사항

이 페이지를 읽기 전에 Teleport 핵심 개념을 숙지해야 합니다.

정의

참여

Teleport 클러스터에 참여하는 것은 새로운 Teleport 인스턴스와 이미 Teleport 클러스터의 일원이 된 모든 인스턴스 간의 신뢰를 구축하는 행위입니다. 참여 프로세스가 끝나면 Auth Service는 참여 인스턴스에 대해 인증서를 서명합니다. 이 인증서는 구축된 신뢰를 나타냅니다. 이를 통해 새로 합류한 인스턴스는 다른 Teleport 인스턴스와 상호 작용할 수 있습니다.

인스턴스는 인증서를 요청하기 위해 Auth Service에 자신의 신원을 증명해야 합니다. Teleport는 참여 인스턴스가 그 정당성을 증명하는 여러 방법을 제공하며, 이를 참여 방법이라고 합니다.

참여 프로세스는 Teleport 서비스가 유효한 인증서를 가지고 있지 않을 때만 발생합니다. 토큰이 인증서로 교환되면, 그 인증서는 이후의 모든 연결 시도에 사용됩니다. 대부분의 경우, 이는 첫 번째 시작 중에 발생합니다.

참여 방법

참여 방법은 Auth Service가 Teleport 클러스터에 참여하고자 하는 인스턴스가 합법적인지 검증하는 방법입니다. 일부 참여 방법은 보편적이며 다른 방법은 참여 인스턴스의 맥락에 의존합니다. 예를 들어 클라우드 제공업체 참여 방법(iam, gcp 또는 azure 등)이나 CI 제공업체(github, gitlab, circleci 등)는 유연성이 더 크고 더 나은 보안 보장을 제공하지만, 참여 인스턴스가 특정 클라우드 제공업체에서 실행되도록 요구합니다.

다양한 참여 방법은 서로 다른 보안 보장을 제공할 수 있습니다. 예를 들어, 일부 참여 방법은 참여 인스턴스가 갱신 가능한 인증서를 요청할 수 있지만, 다른 방법은 인스턴스가 인증서를 갱신하기 위해 다시 참여해야 합니다.

참여 방법 및 그 매개변수는 토큰 리소스에 지정되어 있습니다.

토큰

토큰은 특정 맥락에서 어떤 참여 방법을 사용할 수 있는지를 지정하는 Teleport 리소스입니다. 예를 들어, 특정 토큰은 AWS 계정 333333333333 내의 SSH 서비스가 iam 참여 방법으로 참여할 수 있도록 허용할 수 있습니다:

kind: token
version: v2
metadata:
  name: my-iam-token
spec:
  roles: [Node]
  join_method: iam
  allow:
  - aws_account: "333333333333"
    aws_arn: "arn:aws:sts::333333333333:assumed-role/teleport-instance-role/i-*"
Important

토큰 이름은 참여 방법에 따라 민감할 수도 있고 민감하지 않을 수도 있습니다. 비밀 기반 참여 방법은 토큰 이름이 비밀이어야 합니다. 이러한 경우, 토큰 이름을 아는 것이 인스턴스가 클러스터에 참여하는 데 충분합니다.

참여 방법 분류

비밀 기반 vs 위임된

비밀 기반 참여 방법

비밀 기반 참여 방법은 보편적입니다: Teleport 서비스는 실행되는 플랫폼/클라우드 제공업체에 관계없이 비밀 기반 참여 방법을 사용할 수 있습니다. 참여 인스턴스는 비밀을 전송하고 Auth Service는 이를 알고 있는 비밀과 일치하는지 검증합니다. 이러한 참여 방법은 본질적으로 비밀 유출에 취약하며, 가능할 때 위임된 참여 방법이 선호되어야 합니다. 비밀 기반 참여 방법을 사용해야 하는 경우, 토큰 유출 위험을 줄이기 위해 단기 만료 토큰(예: 1시간만 유효한)을 사용하는 것이 좋습니다.

비밀 기반 참여 방법은 다음과 같습니다:

Warning

Teleport는 하위 호환성을 위해 정적 토큰을 지원하지만, 사용하는 것은 피해야 합니다.

위임된 참여 방법

위임된 참여 방법은 참여 인스턴스의 맥락과 제3자를 기반으로 신뢰를 구축합니다. 제3자는 클라우드 제공업체, CI 플랫폼 또는 컨테이너 런타임이 될 수 있습니다. 이러한 방법은 모든 인스턴스에서 사용할 수 없지만(예: Raspberry Pi에서 SSH 에이전트를 참여시키는 것은 불가능), 가능할 때 선호되어야 합니다.

위임된 참여 방법은 더 세부적일 수도 있습니다. 예를 들어, 클라우드 제공업체 기반 참여 방법은 인스턴스가 가용 영역, 서비스 계정 또는 클라우드 계정 ID에 따라 참여하도록 허용할 수 있습니다.

위임된 참여 방법은 다음과 같습니다:

갱신 가능 vs 비갱신

사용된 참여 방법에 따라 Auth Service는 갱신 가능 인증서 또는 비갱신 인증서를 발급할 수 있습니다.

인증서가 만료되기 직전에, 갱신 가능한 인증서를 가진 인스턴스는 다시 토큰을 사용하지 않고 새로운 인증서를 요청할 수 있습니다. 일반적으로 비밀 기반 참여 방법은 비밀 토큰이 민감하고 일반적으로 단기적이기 때문에 갱신 가능한 인증서를 제공합니다. 단일 참여로, 인스턴스는 클러스터의 일부로 무기한 유지될 수 있습니다.

갱신 가능한 참여 방법은 다음과 같습니다:

비갱신 인증서를 가진 노드는 만료되기 전에 새 인증서를 얻기 위해 다시 참여해야 합니다. 인스턴스는 다시 정당성을 증명해야 합니다. 비갱신 참여 방법은 인스턴스 인증서가 도난당한 공격자가 Teleport 클러스터에 대한 접근을 유지할 수 없게 보장합니다. 이러한 참여 방법은 더욱 보안적이며 CI/CD 파이프라인이나 컨테이너화된 환경과 같은 임시 작업에 더 적합할 수 있습니다.

비갱신 참여 방법은 다음과 같습니다:

토큰 리소스 참조

토큰 리소스는 모든 참여 방법에 대해 다음과 같은 공통 필드를 가지고 있습니다:

# token.yaml
kind: token
version: v2
metadata:
  name: my-token-name
spec:
  # 시스템 역할은 참여 Teleport 인스턴스가 실행할 수 있는 서비스를 설명합니다.
  # 이러한 역할은 인스턴스 인증서에 기록됩니다. 이를 변경하려면
  # (예: SSH 노드에 Application 접근 추가) 다음과 같이 해야 합니다:
  # - 역할을 업데이트하기 위해 토큰을 편집합니다 (예: "App" 추가)
  # - Teleport 인스턴스를 등록 취소합니다
  # - 새로운 서비스를 활성화하도록 구성을 수정합니다 (여기서 "app_service.enabled")
  # - 인스턴스가 다시 참여하게 합니다
  #
  # 필요한 최소한의 시스템 역할 집합을 사용해야 합니다.
  # 일반적인 역할은:
  # - SSH 서비스에 대한 "Node"
  # - Proxy 서비스에 대한 "Proxy"
  # - Kubernetes 서비스에 대한 "Kube"
  # - 애플리케이션 서비스에 대한 "App"
  # - 데이터베이스 서비스에 대한 "Db"
  # - Windows Desktop 서비스에 대한 "WindowsDesktop"
  # - Discovery 서비스에 대한 "Discovery"
  # - MachineID에 대한 "Bot" (설정 시 "spec.bot_name"은 토큰에 설정해야 합니다)
  roles:
    - Node
    - App
  join_method: gcp
  # 머신 ID 용도로 토큰이 사용될 때만 봇 이름을 설정합니다.
  # 설정되면, 토큰은 "Bot" 역할도 가져야 합니다.
  bot_name: my-bot
  # SuggestedLabels는 이 토큰을 사용하여 클러스터에 등록하는 자원이 설정해야 하는 레이블 집합입니다.
  # 현재, 노드 참여 스크립트만이 제안에 따라 구성을 생성합니다.
  suggested_labels:
    teams: ["sales-eng", "eng", "qa"]
    application: ["demo-product"]
  # SuggestedAgentMatcherLabels는 자원과 일치하도록 검색 에이전트가 사용할 레이블 세트입니다.
  # 에이전트가 이 토큰을 사용할 때, 에이전트는 해당 레이블과 일치하는 자원을 모니터링해야 합니다.
  # 데이터베이스의 경우, 이는 레이블을 `db_service.resources.labels`에 추가하는 것을 의미합니다.
  # 현재, 노드 참여 스크립트만이 제안에 따라 구성을 생성합니다.
  suggested_agent_matcher_labels:
    teams: ["sales-eng"]

참여 방법

정적 토큰

Danger

이 참여 방법은 본질적으로 덜 안전합니다. 왜냐하면 장기적으로 사용할 수 있는 토큰이 도난당할 수 있기 때문입니다. 이를 의존하는 것은 Teleport 사용의 보안 이점을 상당히 줄입니다. 대신 일회성 토큰을 사용해야 합니다.

정적 토큰은 Auth Service 구성(teleport.yaml)에서 정의됩니다. 토큰 이름은 비밀로 유지해야 하며, 이를 아는 것은 인스턴스가 Teleport 클러스터에 참여할 수 있게 합니다.

auth_service:
    enabled: yes
    # 클러스터에 새로운 인스턴스를 추가하기 위한 미리 정의된 토큰들입니다. 각 토큰은
    # 새로운 노드가 수락될 역할을 지정합니다. 인스턴스를 추가하는 더 안전한 방법은
    # `tctl nodes add --ttl` 명령어를 사용하여 자동 만료성을 가진 토큰을 생성하는 것입니다.
    #
    # 충분히 무작위적인 32+ 바이트 길이의 토큰을 생성하기 위해 `pwgen`와 같은 도구를 사용하는 것을 권장합니다.
    tokens:
        - "proxy,node:xxxxx"
        - "auth:yyyy"
        - "discovery,app,db:zzzzz"

일회성 토큰

일회성 토큰은 CLI 또는 Teleport API를 통해 동적으로 생성된 비밀 토큰입니다. 이들은 시간 제한이 있으며, 일반적으로 인스턴스를 Teleport 클러스터에 참여시키기 직전에 생성됩니다.

CLI를 통해 생성할 수 있습니다(지정하지 않으면 강력한 난수 값이 선택되며 기본 TTL은 30분입니다):

$ tctl tokens add --type discovery,app --ttl 15m

또는 Teleport 리소스로 생성할 수 있습니다:

kind: 토큰
version: v2
metadata:
  expires: "2023-11-24T21:45:40.104524Z"
  name: abcd123-insecure-do-not-use-this
spec:
  join_method: 토큰
  roles:
    - 발견
    - 

머신 ID 봇이 일회성 참여 토큰을 사용할 때, 토큰은 삭제됩니다.

AWS IAM 역할: iam

IAM 참여 방법은 IAM 자격 증명에 접근할 수 있는 모든 Teleport 프로세스에서 사용할 수 있으며, 예를 들어 IAM 역할이 붙어 있는 EC2 인스턴스에서 사용할 수 있습니다. 특별한 권한이나 IAM 정책이 필요하지 않으며, 연결된 정책이 없는 IAM 역할이면 충분합니다. Teleport Auth Service에서 IAM 자격 증명은 필요하지 않습니다.

프록시 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에서 클러스터에 참여하는 지원은 Teleport 13.0+에서 가능합니다.

이 방법은 AWS에서 실행되는 작업 부하에 참여하는 추천 방법입니다.

  # token.yaml
  kind: token
  version: v2
  metadata:
    # 이 토큰 이름은 비밀이 아닙니다. 인스턴스는 이 토큰을 사용하기 위해 
    # AWS 계정에서 실행되고 있음을 증명해야 합니다.
    name: iam-token
  spec:
    # 필요한 최소 권한 집합을 사용하세요 (예: Node, App, Kube, DB, WindowsDesktop)
    roles: [Node]
    
    # 이 토큰에 허용된 조인 방법을 설정하세요
    join_method: iam
    
    allow:
      # Teleport 프로세스가 조인할 수 있는 AWS 계정을 지정하세요
      - aws_account: "111111111111"
      # 여러 개의 허용 규칙이 지원됩니다
      - aws_account: "222222222222"
      # aws_arn은 선택 사항이며 Teleport 프로세스의 IAM 역할을 제한하는 데 사용됩니다
      - aws_account: "333333333333"
        aws_arn: "arn:aws:sts::333333333333:assumed-role/teleport-node-role/i-*"

AWS EC2 신원 문서: ec2

EC2 참여 방법은 EC2 인스턴스에서 실행되는 모든 Teleport 프로세스에서 사용할 수 있습니다. 각 EC2 인스턴스에는 하나의 Teleport 프로세스만이 EC2 참여 방법을 사용할 수 있습니다.

IAM 자격 증명으로 ec2:DescribeInstances 권한이 필요합니다. Teleport Auth Service에는 자격 증명이 필요하지 않으며 클러스터에 참여하는 Teleport 프로세스에는 자격 증명이 필요하지 않습니다.

EC2 참여 방법은 Teleport Enterprise Cloud 및 Teleport Team에서는 사용할 수 없습니다. Teleport Enterprise Cloud 및 Team 고객은 IAM 참여 방법 또는 일회성 비밀 토큰을 사용할 수 있습니다.

# token.yaml
kind: token
version: v2
metadata:
  # 토큰 이름은 비밀이 아닙니다. 인스턴스는 이 토큰을 사용하기 위해
  # 귀하의 AWS 계정에서 실행되고 있음을 증명해야 합니다.
  name: ec2-token
spec:
  # 필요한 최소 역할 집합을 사용하세요 (예: Node, App, Kube, DB, WindowsDesktop)
  roles: [Node]

  # 이 토큰에 대해 허용되는 조인 방법을 설정하세요.
  join_method: ec2

  # aws_iid_ttl은 EC2 인스턴스가 시작된 후
  # 클러스터에 조인할 수 있는 시간입니다. 짧은 TTL을 사용하여
  # 도난당한 EC2 인스턴스 신원 문서가 귀하의
  # 클러스터에 조인되는 위험을 줄이세요.
  #
  # EC2 조인 방법을 사용하여 첫 번째 Teleport 프로세스를 시작할 때,
  # Teleport를 설정하고 구성할 시간을 가지기 위해
  # 일시적으로 더 높은 `aws_iid_ttl` 값을 구성해야 할 수도 있습니다.
  # 이 기능은 Teleport가 EC2 AMI에서 자동으로 시작되도록 설정되었을 때 가장 잘 작동합니다.
  aws_iid_ttl: 5m

  allow:
  - aws_account: "111111111111" # 귀하의 AWS 계정 ID
    aws_regions: # 필요한 최소 AWS 리전 집합을 사용하세요.
    - us-west-1
    - us-west-2

Azure 관리 ID: azure

Azure 참여 방법은 Teleport 12.1+에서 사용할 수 있습니다. Azure 가상 머신에서 실행되는 모든 Teleport 프로세스에서 사용할 수 있습니다. 프록시 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에서 클러스터에 참여하는 지원은 Teleport 13.0+에서 가능합니다.

# token.yaml
kind: token
version: v2
metadata:
  # 토큰 이름은 비밀이 아닙니다. 인스턴스는 이 토큰을 사용하기 위해
  # Azure 구독에서 실행되고 있음을 증명해야 합니다.
  name: azure-token
spec:
  # 필요한 최소 역할 세트를 사용하세요.
  roles: [Node]
  join_method: azure
  azure:
    allow:
      # Teleport 프로세스가 가입할 수 있는 Azure 구독을 지정하세요.
      - subscription: 11111111-1111-1111-1111-111111111111
      # 여러 허용 규칙이 지원됩니다.
      - subscription: 22222222-2222-2222-2222-222222222222
      # resource_groups는 선택 사항이며, Teleport 프로세스의
      # 가입 리소스 그룹을 제한할 수 있습니다.
      - subscription: 33333333-3333-3333-3333-333333333333
        resource_groups: ["group1", "group2"]

GCP 서비스 계정: gcp

GCP 참여 방법은 GCP VM에서 실행되는 모든 Teleport 프로세스에서 사용할 수 있습니다. VM에는 서비스 계정이 할당되어 있어야 하며(기본 서비스 계정으로도 괜찮습니다). 클러스터에 참여하는 Teleport 프로세스에는 IAM 역할이 필요하지 않습니다.

# token.yaml
kind: token
version: v2
metadata:
  # 토큰 이름은 비밀이 아닙니다. 인스턴스는 이 토큰을 사용하기 위해
  # GCP 프로젝트에서 실행 중임을 증명해야 합니다.
  name: gcp-token
spec:
  # 필요한 최소 역할 집합을 사용하세요 (예: Node, Proxy, App, Kube, DB, WindowsDesktop)
  roles: [Node]

  # 이 토큰에 대해 허용되는 조인 방법을 설정하세요
  join_method: gcp

  gcp:
    allow:
      # VM이 조인할 수 있는 GCP 프로젝트 ID입니다.
      - project_ids: ["example-project-id"]
        # (선택 사항) VM이 조인할 수 있는 위치입니다. 주의: 지역과
        # 존 모두 허용됩니다.
        locations: ["us-west1", "us-west2-a"]
        # (선택 사항) VM이 조인할 수 있는 서비스 계정의 이메일 주소입니다.
        service_accounts: ["example@example.com"]

GitHub 액션: github

Teleport는 GitHub 호스팅 및 자체 호스팅 GitHub Actions 러너와 함께 안전한 참여를 지원합니다. 이 참여 방법은 일반적으로 Machine ID와 함께 사용하여 GitHub Actions 파이프라인에서 Teleport 보호 리소스에 접근합니다.

kind: token
version: v2
metadata:
  # name identifies the token. When configuring a bot or node to join using this
  # token, this name should be specified.
  name: github-token
spec:
  # For Machine ID and GitHub joining, roles will always be "Bot" and
  # join_method will always be "github".
  roles: [Bot]
  join_method: github

  # bot_name specifies the name of the bot that this token will grant access to
  # when it is used.
  bot_name: github-demo

  github:
    # enterprise_server_host allows joining from GitHub Actions workflows in a
    # GitHub Enterprise Server instance. For normal situations, where you are
    # using github.com, this option should be omitted. If you are using GHES,
    # this value should be configured to the hostname of your GHES instance.
    enterprise_server_host: ghes.example.com

    # enterprise_slug allows the slug of a GitHub Enterprise organisation to be
    # included in the expected issuer of the OIDC tokens. This is for
    # compatibility with the include_enterprise_slug option in GHE.
    #
    # This field should be set to the slug of your Github Enterprise organization if this is enabled. If
    # this is not enabled, then this field must be left empty. This field cannot
    # be specified if `enterprise_server_host` is specified.
    #
    # See https://docs.github.com/en/enterprise-cloud@latest/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-issuer-value-for-an-enterprise
    # for more information about customized issuer values.
    enterprise_slug: slug

    # allow is an array of rule configurations for what GitHub Actions workflows
    # should be allowed to join. All options configured within one allow entry
    # must be satisfied for the GitHub Actions run to be allowed to join. Where
    # multiple allow entries are specified, any run which satisfies all of the
    # options within a single entry will be allowed to join.
    #
    # An allow entry must include at least one of:
    # - repository
    # - repository_owner
    # - sub
    allow:
      - # repository is a fully qualified (e.g. including the owner) name of a
        # GitHub repository.
        repository: gravitational/teleport
        # repository_owner is the name of an organization or user that a
        # repository belongs to.
        repository_owner: gravitational
        # workflow is the exact name of a workflow as configured in the GitHub 
        # Action workflow YAML file.
        workflow: my-workflow
        # environment is the environment associated with the GitHub Actions run.
        # If no environment is configured for the GitHub Actions run, this will
        # be empty.
        environment: production
        # actor is the GitHub username that caused the GitHub Actions run,
        # whether by committing or by directly despatching the workflow.
        actor: octocat
        # ref is the git ref that triggered the action run.
        ref: ref/heads/main
        # ref_type is the type of the git ref that triggered the action run.
        ref_type: branch
        # sub is a concatenated string of various attributes of the workflow 
        # run. GitHub explains the format of this string at:
        # https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims
        sub: repo:gravitational/example-repo:environment:production

CircleCI: circleci

이 참여 방법은 일반적으로 Machine ID와 함께 사용하여 Circle CI 파이프라인에서 Teleport 보호 리소스에 접근합니다.

kind: token
version: v2
metadata:
  name: example-bot
spec:
  roles: []
  join_method: circleci
  bot_name: example
  circleci:
    organization_id: $ORGANIZATION_ID
    # allow는 Auth Server가 `tbot`이 참여할 수 있는지를 결정하는 규칙을 지정합니다.
    allow:
      - # CircleCI 컨텍스트 ID. CircleCI MachineID 가이드를 참조하여 
        # 컨텍스트를 생성하고 그 ID를 가져오는 방법을 알아보세요.
        context_id: 00000000-0000-0000-0000-000000000000
        # CircleCI projectID.
        project_id: 1234

GitLab: gitlab

Teleport는 클라우드 호스팅 및 자체 호스팅 GitLab 인스턴스를 통해 안전한 참여를 지원합니다. 지원되는 GitLab 최소 버전은 15.7입니다.

이 참여 방법은 일반적으로 MachineID와 함께 사용하여 GitLab CI 파이프라인에서 Teleport 보호 리소스에 접근합니다.

kind: token
version: v2
metadata:
  # 이 토큰을 식별하는 이름입니다. 봇이나 노드가 이 토큰을 사용하여 조인하도록 구성할 때
  # 이 이름을 지정해야 합니다.
  name: gitlab-demo
spec:
  # Bot 역할은 이 토큰이 봇 사용자에 대한 접근을 부여하며,
  # 노드가 조인하는 것을 허용하지 않음을 나타냅니다.
  roles: [Bot]
  # GitLab 조인을 위한 join_method는 항상 "gitlab"입니다.
  join_method: gitlab

  # bot_name은 이 토큰을 사용할 때 접근을 부여할 봇의 이름을 지정합니다.
  bot_name: gitlab-demo

  gitlab:
    # domain은 GitLab 인스턴스의 도메인이어야 합니다. 
    # GitLab의 클라우드 호스팅 제공을 사용하는 경우 이 필드를 완전히 생략하세요.
    domain: gitlab.example.com
    # allow는 GitLab CI 작업이 조인할 수 있는 규칙 구성을 위한 배열입니다.
    # 하나의 allow 항목 내에서 구성된 모든 옵션이 만족되어야
    # GitLab CI 실행이 조인할 수 있습니다. 여러 allow 항목이 지정된 경우
    # 단일 항목 내의 모든 옵션을 만족하는 작업은 조인할 수 있습니다.
    #
    # allow 항목에는 최소 한 개의 항목이 포함되어야 합니다:
    # - project_path
    # - namespace_path
    # - sub
    # 이는 다른 GitLab 사용자의 프로젝트에서 GitLab CI 실행이 
    # Teleport 클러스터에 접근하지 못하도록 합니다.
    allow:
      # project_path는 지정된 프로젝트 내에서 시작된 작업만 
      # 조인하도록 제한합니다.
      #
      # 이 필드는 glob 스타일의 매칭을 지원합니다:
      # - '*'를 사용하여 0개 이상의 문자를 매칭합니다.
      # - '?'를 사용하여 단일 문자를 매칭합니다.
      - project_path: my-user/my-project
        # namespace_path는 지정된 네임스페이스 내에 존재하는 
        # 프로젝트 내의 모든 실행으로의 조인을 제한합니다.
        # 네임스페이스는 사용자 이름 또는 그룹 이름일 수 있습니다.
        #
        # 이 필드는 glob 스타일의 매칭을 지원합니다:
        # - '*'를 사용하여 0개 이상의 문자를 매칭합니다.
        # - '?'를 사용하여 단일 문자를 매칭합니다.
        namespace_path: my-user
        # pipeline_source는 특정 기준에 의해 트리거된 작업만 
        # 조인하도록 제한합니다, 예를 들어 웹 인터페이스를 통해 트리거된 경우.
        pipeline_source: web
        # environment는 지정된 환경과 관련된 작업만 
        # 조인하도록 제한합니다.
        environment: production
        # ref_type은 특정 유형의 git 참조에 의해 트리거된 작업만 
        # 조인하도록 제한합니다. 'branch' 또는 'tag' 중 하나입니다.
        ref_type: branch
        # ref는 특정 git 참조에 의해 트리거된 작업만 
        # 조인하도록 제한합니다. 이와 `ref_type`을 결합하여 특정 
        # 브랜치 또는 태그에 의해 트리거될 수 있는 allow 규칙을 
        # 생성합니다.
        #
        # 이 필드는 glob 스타일의 매칭을 지원합니다:
        # - '*'를 사용하여 0개 이상의 문자를 매칭합니다.
        # - '?'를 사용하여 단일 문자를 매칭합니다.
        ref: main
        # sub는 project_path, ref_type 및 ref를 결합한 단일 문자열입니다.
        # 이는 조인을 제한하는 데 사용할 수 있으며,
        # 특정 프로젝트 및 git ref를 설명하는 데도 사용됩니다.
        #
        # 개별 필드를 사용하는 것이 더 좋으며, 
        # sub 문자열을 잘못 포맷하는 것이 쉽기 때문입니다.
        #
        # 이 필드는 glob 스타일의 매칭을 지원합니다:
        # - '*'를 사용하여 0개 이상의 문자를 매칭합니다.
        # - '?'를 사용하여 단일 문자를 매칭합니다.
        sub: project_path:my-user/my-project:ref_type:branch:ref:main
        # user_login은 특정 사용자 이름에 의해 트리거된 작업만 
        # 조인하도록 제한합니다.
        user_login: octocat
        # user_email은 주어진 이메일을 가진 특정 사용자에 의해 
        # 트리거된 작업만 조인하도록 제한합니다.
        user_email: octo.cat@example.com
        # ref_protected가 true로 설정되면 보호된 참조에 대해 
        # 실행되는 작업만 조인하도록 제한합니다.
        # 생략할 경우, 호출된 참조의 보호 상태는 점검되지 않습니다.
        ref_protected: true
        # environment_protected가 true로 설정되면 보호된 참조에 대해 
        # 실행되는 작업만 조인하도록 제한합니다.
        # 생략할 경우, 호출된 참조의 보호 상태는 점검되지 않습니다.
        environment_protected: true
        # ci_config_sha는 특정 CI 구성의 커밋을 사용하는 
        # 작업만 조인하도록 제한합니다.
        ci_config_sha: ffffffffffffffffffffffffffffffffffffffff
        # ci_config_ref_uri는 특정 CI 구성 소스를 사용하는 
        # 작업만 조인하도록 제한합니다.
        ci_config_ref_uri: gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main
        # deployment_tier는 특정 배포 계층에 배포하는 작업만 
        # 조인하도록 제한합니다.
        deployment_tier: production
        # project_visibility는 특정 가시성 구성과 관련된 
        # 프로젝트에서 실행되는 작업만 조인하도록 제한합니다.
        project_visibility: public

Kubernetes: kubernetes

Kubernetes 참여 방법은 두 가지 변형이 있습니다:

Kubernetes 클러스터 내

Kubernetes 클러스터 내에서 참여하는 것은 Auth Service와 동일한 Kubernetes 클러스터에서 실행되는 모든 Teleport 프로세스에서 사용할 수 있습니다. 이 방법은 Kubernetes ServiceAccount 토큰을 사용하여 pod 신원을 검증합니다. 이 메서드는 일반적으로 Kubernetes 클러스터 내에서만 접근할 수 있는 Kubernetes TokenReview API에 의존합니다. 이러한 제한으로 인해 이 참여 방법은 Kubernetes에서 자체 호스팅되는 Teleport 클러스터에만 사용할 수 있습니다.

가급적 이 방법을 선호해야 합니다. 왜냐하면 토큰은 pod가 Terminated 상태에 들어가자마자 폐기되기 때문입니다.

Kubernetes 클러스터 내 참여 방법은 자체 호스팅된 Teleport 12+ 버전에서 사용할 수 있습니다.

# token.yaml
kind: token
version: v2
metadata:
  # 토큰 이름은 비밀이 아니며, Kubernetes join 방법은
  # Kubernetes 서명에 의존하여 신뢰를 확립하고, join 토큰 이름에는 의존하지 않습니다.
  name: kubernetes-token
  # 긴 만료 시간을 설정합니다. 토큰의 기본값은 30분에 불과합니다.
  expires: "2050-01-01T00:00:00Z"
spec:
  # 필요한 최소 시스템 역할 집합을 사용합니다.
  roles: [App]

  # 이 토큰에 허용된 join 방법을 설정합니다.
  join_method: kubernetes
  
  kubernetes:
    # 유형이 지정되지 않으면 기본값은 in_cluster입니다.
    type: in_cluster
    allow:
      # 서비스 계정 이름은 "네임스페이스:서비스계정이름" 형식을 따릅니다.
      - service_account: "teleport-agent:teleport-app-service"

Kubernetes JWKS

Kubernetes JWKS 참여 방법은 Kubernetes에서 실행되는 모든 Teleport 프로세스에서 사용할 수 있습니다. Auth Service는 Kubernetes에서 실행될 필요는 없으며, 이 방법은 Teleport 클러스터에서 사용할 수 있으며 Teleport Cloud에서도 사용할 수 있습니다. 이 참여 방법은 공개 Kubernetes 서명 키를 내보내고 이를 사용하여 Kubernetes SA 토큰 서명을 검증합니다. 서명 검증은 Auth Service가 Kubernetes에 접근하지 않고도 수행할 수 있습니다.

Kubernetes JWKS 참여 방법은 Teleport 14+ 버전에서 사용할 수 있습니다.

kind: token
version: v2
metadata:
  name: 예제
spec:
  roles: []
  join_method: kubernetes
  kubernetes:
    # static_jwks는 Auth Server를 구성하여
    # `tbot`이 제시하는 JWT를 정적으로 구성된 JWKS의 공개 키를 사용하여 검증합니다.
    type: static_jwks
    static_jwks:
      jwks: |
        # 여기에 kubernetes JWKS를 배치하세요 (`kubectl get --raw /openid/v1/jwks`)
        {"keys":[--snip--]}
    # allow는 Auth Server가 노드가 참여할 수 있는지 결정하는 규칙을 지정합니다.
    allow:
      - service_account: "namespace:serviceaccount"
Warning

Kubernetes CA를 회전한 후, Kubernetes JWKS 토큰을 업데이트하여 새로운 Kubernetes 서명 키를 포함해야 합니다 (spec.kubernetes.static_jwks.jwks 필드 업데이트).

신뢰할 수 있는 플랫폼 모듈: tpm

tpm 조인 방법은 Bots와 Agents가 공유 비밀을 사용하지 않고 Teleport Auth Service와 인증하는 안전한 방법입니다. 공유 비밀 대신 호스트의 신뢰할 수 있는 플랫폼 모듈(Trusted Platform Module, TPM)의 고유한 신원과 공개 키 암호화를 사용하여 호스트를 인증합니다.

기계에 사용할 수 있는 다른 형태의 신원이 없는 환경, 예를 들어 온프레미스에서는 조인하는 가장 안전한 방법입니다. 이는 token 조인 방법에 필요한 공유 비밀을 배포할 필요가 없습니다.

신뢰할 수 있는 플랫폼 모듈(Trusted Platform Module, TPM)은 호스트에 설치된 안전한 물리적 암호 프로세서입니다. TPM은 암호화 자료를 저장하고 여러 암호화 작업을 수행할 수 있으며, 운영 체제에 암호화 자료를 노출하지 않습니다. 각 TPM은 고유한 키 쌍이 내장되어 있으며 이를 보증 키(Endorsement Key, EK)라고 합니다.

일부 TPM은 제조업체의 CA에 의해 서명된 이 키 쌍에 대한 X.509 인증서도 포함하고 있습니다. 이를 EK 인증서(EKCert)라고 하며, TPM이 제조업체의 CA를 신뢰하는 제3자에게 TPM이 진품이고 TPM 사양을 준수함을 증명하는 데 사용될 수 있습니다.

tpm 조인 방법을 사용할 때는 먼저 TPM의 공개 키를 쿼리한 다음 이 공개 키를 명시적으로 허용하는 조인 토큰을 생성해야 합니다. 호스트 운영 체제가 재설치되더라도 EK 공개 키는 변경되지 않으므로 TPM은 여전히 Teleport 클러스터에 조인하는 데 사용할 수 있습니다. 많은 호스트가 있는 경우 ansible과 같은 자동화 도구를 사용하여 귀하의 플릿 전체에서 TPM을 쿼리한 다음 조인 토큰을 생성하는 것이 좋습니다.

Warning

tpm 조인 방법은 현재 FIPS 140-2와 호환되지 않습니다.

kind: 토큰
version: v2
metadata:
  # 이름은 토큰을 식별합니다. 봇이나 노드를 이 토큰을 사용하여 참여하도록 구성할 때
  # 이 이름을 지정해야 합니다.
  name: tpm-token
spec:
  # 기계 ID 및 TPM 참여의 경우, 역할은 항상 "Bot"이며
  # join_method는 항상 "tpm"입니다.
  roles: [Bot]
  join_method: tpm

  # bot_name은 이 토큰이 사용될 때 액세스 권한을 부여할 봇의 이름을 지정합니다.
  bot_name: tpm-demo

  # tpm은 이 토큰에 대한 TPM 참여 방법에 대한 특정 구성입니다.
  tpm:
    # ekcert_allowed_cas는 TPM EKCerts를 검증하는 데 사용될 CA 인증서 목록입니다.
    # PEM으로 포장되어야 합니다.
    #
    # 지정된 경우, TPM은 지정된 CA 중 하나에 의해 서명된 EKCert를 제시해야 참여할 수 있습니다.
    # EKCert를 제시하지 않은 TPM은 참여할 수 없습니다.
    #
    # 지정되지 않은 경우, TPM은 EKCert 또는 EKPubHash로 참여할 수 있습니다.
    ekcert_allowed_cas:
      - |
        -----BEGIN CERTIFICATE-----
        ... CA 인증서 데이터 ...
        -----END CERTIFICATE-----
    # allow는 규칙 목록으로, 제시된 TPM은 이 토큰을 사용하여 참여하기 위해
    # 하나의 allow 규칙과 일치해야 합니다.
    allow:
        # description은 규칙에 대한 인간이 읽을 수 있는 설명입니다. 이는 TPM이 참여할 수 있는지 여부에 영향을 미치지 않지만,
        # 특정 호스트와 규칙을 연관시키는 데 사용할 수 있습니다 (예: TPM이 위치한 서버의 자산 태그 등).
      - description: "example-build-server-100"
        # ek_public_hash는 PKIX 형식으로 마샬링된 EKPub의 SHA256 해시이며
        # 16진수로 인코딩됩니다. 이 값은 TPM이 EKCert를 제출했을 때도 확인되며,
        # EKCert의 공개 키는 이 확인에 사용됩니다.
        ek_public_hash: "d4b4example6fabfc568d74f2example6c35a05337d7af9a6example6c891aa6"
        # ek_certificate_serial은 EKCert의 일련 번호로 16진수이며
        # 콜론으로 구분된 니블로 구성됩니다. 이 값은 TPM에 EKCert가 구성되지 않은 경우에는 확인되지 않습니다.
        ek_certificate_serial: "01:23:45:67:89:ex:am:pl:e0:23:45:67:89:ab:cd:ef"
Teleport 원문 보기