InfoGrab DocsInfoGrab Docs

tbot 배포

요약

머신 및 워크로드 아이덴티티 설정의 첫 번째 단계는 tbot 에이전트를 배포하고 Teleport 클러스터에 봇으로 조인하는 것입니다. 이 페이지에서는 tbot 배포 방법을 선택하는 방법을 설명하고, 배포를 완료하는 데 적합한 가이드를 선택하도록 안내합니다.

머신 및 워크로드 아이덴티티 설정의 첫 번째 단계는 tbot 에이전트를 배포하고 Teleport 클러스터에 봇으로 조인하는 것입니다. AWS 및 GitHub Actions에서 일반 Linux 서버 또는 Kubernetes 클러스터까지 다양한 플랫폼에서 tbot 바이너리를 실행할 수 있습니다.

이 페이지에서는 tbot 배포 방법을 선택하는 방법을 설명하고, 배포를 완료하는 데 적합한 가이드를 선택하도록 안내합니다.

배포 방법 선택#

인프라에 tbot 에이전트를 배포하는 방법을 결정할 때 고려해야 할 사항이 두 가지 있습니다.

인프라#

tbot 에이전트는 컨테이너 또는 Linux 가상 머신에서 실행됩니다. GitHub Actions에서 tbot을 실행하는 경우, 미리 만들어진 Teleport GitHub Actions 워크플로 중 하나를 사용할 수 있습니다.

조인 방법#

tbot 에이전트는 다음 인증 방법 중 하나를 사용하여 Teleport 클러스터에 조인합니다.

  • 플랫폼 서명 문서: Kubernetes 클러스터나 Amazon EC2 인스턴스와 같이 tbot을 호스팅하는 플랫폼이 서명된 아이덴티티 문서를 제공하며, Teleport는 이를 해당 플랫폼의 인증 기관(CA)을 사용하여 검증할 수 있습니다. 이는 공유 시크릿의 사용을 피할 수 있으므로 권장되는 접근 방식입니다.
  • 정적 조인 토큰: Teleport 클라이언트 도구가 문자열을 생성하여 Teleport Auth Service에 저장합니다. tbot은 Teleport 클러스터에 처음 연결할 때 이 문자열을 제공하여 자신이 클러스터에 속해 있음을 Auth Service에 증명합니다. 이후부터 tbot은 갱신 가능한 인증서로 Teleport 클러스터에 인증합니다.

배포 가이드#

이 섹션의 가이드는 머신 및 워크로드 아이덴티티 에이전트인 tbot을 배포하고 클러스터에 조인하는 방법을 보여줍니다.

플랫폼에 맞는 특정 가이드가 없는 경우, Linux 가이드가 대부분의 플랫폼과 호환됩니다. 커스텀 접근 방식이 필요한 경우 머신 및 워크로드 아이덴티티 레퍼런스아키텍처를 읽고 배포를 계획할 수도 있습니다.

, to: "./aws", name: "AWS", }, { icon: , to: "./azure", name: "Azure", }, { icon: , to: "./azure-devops", name: "Azure DevOps", }, { icon: , to: "./bitbucket", name: "Bitbucket Pipelines", }, { icon: , to: "./circleci", name: "CircleCI", }, { icon: , to: "./github-actions", name: "GitHub Actions", }, { icon: , to: "./gitlab", name: "GitLab CI", }, { icon: , to: "./gcp", name: "Google Cloud", }, { icon: , to: "./kubernetes", name: "Kubernetes", }, { icon: , to: "./kubernetes-oidc", name: "Kubernetes OIDC", }, { icon: , to: "./linux", name: "Linux", }, { icon: , to: "./linux-tpm", name: "Linux TPM", }, { icon: , to: "../../reference/machine-workload-identity/bound-keypair/getting-started", name: "Bound Keypair Joining", } ]} />

CI/CD#

지속적 통합 및 지속적 배포(CI/CD) 플랫폼에서 tbot을 배포하는 방법은 다음 가이드를 참조하세요.

, to: "./azure-devops", name: "Azure DevOps", }, { icon: , to: "./bitbucket", name: "Bitbucket Pipelines", }, { icon: , to: "./circleci", name: "CircleCI", }, { icon: , to: "./gitlab", name: "GitLab CI", }, { icon: , to: "./github-actions", name: "GitHub Actions", }, { icon: , to: "./jenkins", name: "Jenkins", }, { icon: , to: "../../configuration/terraform-provider/spacelift", name: "Spacelift", }, { icon: , to: "../../configuration/terraform-provider/terraform-cloud", name: "Terraform Cloud", }, { icon: , to: "../../reference/machine-workload-identity/bound-keypair/static-keys", name: "Bound Keypair static keys (Generic)", } ]} />


Unsupported Provider?

사용 중인 CI/CD 공급자에 대해 위에 나열된 전용 조인 방법이 없는 경우, 대체 방안으로 Bound Keypair 정적 키를 사용하는 것을 고려하세요.

tbot 배포

Teleport v18.9
원문 보기
요약

머신 및 워크로드 아이덴티티 설정의 첫 번째 단계는 tbot 에이전트를 배포하고 Teleport 클러스터에 봇으로 조인하는 것입니다. 이 페이지에서는 tbot 배포 방법을 선택하는 방법을 설명하고, 배포를 완료하는 데 적합한 가이드를 선택하도록 안내합니다.

머신 및 워크로드 아이덴티티 설정의 첫 번째 단계는 tbot 에이전트를 배포하고 Teleport 클러스터에 봇으로 조인하는 것입니다. AWS 및 GitHub Actions에서 일반 Linux 서버 또는 Kubernetes 클러스터까지 다양한 플랫폼에서 tbot 바이너리를 실행할 수 있습니다.

이 페이지에서는 tbot 배포 방법을 선택하는 방법을 설명하고, 배포를 완료하는 데 적합한 가이드를 선택하도록 안내합니다.

배포 방법 선택#

인프라에 tbot 에이전트를 배포하는 방법을 결정할 때 고려해야 할 사항이 두 가지 있습니다.

인프라#

tbot 에이전트는 컨테이너 또는 Linux 가상 머신에서 실행됩니다. GitHub Actions에서 tbot을 실행하는 경우, 미리 만들어진 Teleport GitHub Actions 워크플로 중 하나를 사용할 수 있습니다.

조인 방법#

tbot 에이전트는 다음 인증 방법 중 하나를 사용하여 Teleport 클러스터에 조인합니다.

  • 플랫폼 서명 문서: Kubernetes 클러스터나 Amazon EC2 인스턴스와 같이 tbot을 호스팅하는 플랫폼이 서명된 아이덴티티 문서를 제공하며, Teleport는 이를 해당 플랫폼의 인증 기관(CA)을 사용하여 검증할 수 있습니다. 이는 공유 시크릿의 사용을 피할 수 있으므로 권장되는 접근 방식입니다.
  • 정적 조인 토큰: Teleport 클라이언트 도구가 문자열을 생성하여 Teleport Auth Service에 저장합니다. tbot은 Teleport 클러스터에 처음 연결할 때 이 문자열을 제공하여 자신이 클러스터에 속해 있음을 Auth Service에 증명합니다. 이후부터 tbot은 갱신 가능한 인증서로 Teleport 클러스터에 인증합니다.

배포 가이드#

이 섹션의 가이드는 머신 및 워크로드 아이덴티티 에이전트인 tbot을 배포하고 클러스터에 조인하는 방법을 보여줍니다.

플랫폼에 맞는 특정 가이드가 없는 경우, Linux 가이드가 대부분의 플랫폼과 호환됩니다. 커스텀 접근 방식이 필요한 경우 머신 및 워크로드 아이덴티티 레퍼런스아키텍처를 읽고 배포를 계획할 수도 있습니다.

, to: "./aws", name: "AWS", }, { icon: , to: "./azure", name: "Azure", }, { icon: , to: "./azure-devops", name: "Azure DevOps", }, { icon: , to: "./bitbucket", name: "Bitbucket Pipelines", }, { icon: , to: "./circleci", name: "CircleCI", }, { icon: , to: "./github-actions", name: "GitHub Actions", }, { icon: , to: "./gitlab", name: "GitLab CI", }, { icon: , to: "./gcp", name: "Google Cloud", }, { icon: , to: "./kubernetes", name: "Kubernetes", }, { icon: , to: "./kubernetes-oidc", name: "Kubernetes OIDC", }, { icon: , to: "./linux", name: "Linux", }, { icon: , to: "./linux-tpm", name: "Linux TPM", }, { icon: , to: "../../reference/machine-workload-identity/bound-keypair/getting-started", name: "Bound Keypair Joining", } ]} />

CI/CD#

지속적 통합 및 지속적 배포(CI/CD) 플랫폼에서 tbot을 배포하는 방법은 다음 가이드를 참조하세요.

, to: "./azure-devops", name: "Azure DevOps", }, { icon: , to: "./bitbucket", name: "Bitbucket Pipelines", }, { icon: , to: "./circleci", name: "CircleCI", }, { icon: , to: "./gitlab", name: "GitLab CI", }, { icon: , to: "./github-actions", name: "GitHub Actions", }, { icon: , to: "./jenkins", name: "Jenkins", }, { icon: , to: "../../configuration/terraform-provider/spacelift", name: "Spacelift", }, { icon: , to: "../../configuration/terraform-provider/terraform-cloud", name: "Terraform Cloud", }, { icon: , to: "../../reference/machine-workload-identity/bound-keypair/static-keys", name: "Bound Keypair static keys (Generic)", } ]} />


Unsupported Provider?

사용 중인 CI/CD 공급자에 대해 위에 나열된 전용 조인 방법이 없는 경우, 대체 방안으로 Bound Keypair 정적 키를 사용하는 것을 고려하세요.