이 페이지는 Machine & Workload Identity(MWI)에 대한 자주 묻는 질문에 대한 답변을 제공합니다. Teleport 전반에 대한 자주 묻는 질문 목록은 자주 묻는 질문을 참조하세요.

MWI를 CI/CD 작업 내에서 사용할 수 있나요?#

워크플로가 임시(ephemeral) 환경에서 실행되는 CI/CD 플랫폼(예: 개별 워크플로 실행 간에 영구 상태가 존재하지 않는 경우)에서는, 지원되는 조인 방법이 존재하는 경우 MWI가 가장 잘 작동합니다. 지원되는 조인 방법은 다음과 같습니다:

• GitHub Actions
• CircleCI
• GitLab
• AWS
• GCP
• Azure
• Kubernetes
• Spacelift
• Terraform Cloud

러너 환경을 직접 제어하는 CI/CD 플랫폼(예: 자체 호스팅 Jenkins 러너)에서는, MWI가 러너에서 데몬으로 실행될 수 있으며 생성된 자격 증명을 개별 워크플로 실행 환경에 마운트할 수 있습니다.

MWI를 트러스티드 클러스터와 함께 사용할 수 있나요?#

신뢰할 수 있는 리프 클러스터(leaf cluster)에서 SSH 접근을 위해 MWI를 사용할 수 있습니다.

현재 리프 클러스터에서 애플리케이션, 데이터베이스, 쿠버네티스 클러스터에 대한 접근은 지원하지 않습니다.

허용된 로그인을 사용자 트레이트로 정의해야 하나요, 아니면 역할 내에서 정의해야 하나요?#

봇이 사용할 수 있도록 허용할 로그인을 정의할 때는 다음 두 가지 옵션이 있습니다:

• 봇이 임퍼소네이션할 역할의 logins 섹션에 로그인을 직접 추가하는 방법.
• 봇 사용자의 로그인 트레이트에 로그인을 추가하고, {{ internal.logins }} 역할 변수를 포함하는 역할을 임퍼소네이션하는 방법. 이는 일반적으로 봇을 생성할 때 --logins 매개변수를 제공하여 수행됩니다.

봇이 단일 서비스나 역할만 사용할 것으로 예상되는 더 단순한 시나리오의 경우, 봇 사용자의 로그인 트레이트에 로그인을 추가할 수 있습니다. 이 방식을 사용하면 access와 같은 기본 역할을 활용할 수 있습니다.

봇이 서로 다른 서비스에서 서로 다른 역할에 대한 인증서를 생성하는 상황에서는, 로그인 트레이트를 사용하는 것이 의도하지 않은 리소스에 대한 접근을 부여하는지 여부를 신중히 고려하는 것이 중요합니다. 로그인 트레이트가 의도하지 않은 접근을 부여하지 않도록 하려면, 인증서에 포함되어야 하는 로그인을 명시적으로 지정하는 맞춤형 역할을 만드는 것을 권장합니다.

MWI를 세션별 MFA와 함께 사용할 수 있나요?#

현재 MWI와 세션별 MFA를 함께 사용하는 것은 지원하지 않습니다. 세션별 MFA를 전역적으로 활성화하거나 MWI가 임퍼소네이션하는 역할에 대해 활성화하면, MWI가 생성한 자격 증명을 사용하여 리소스에 연결할 수 없게 됩니다.

이에 대한 우회 방법으로, 세션별 MFA를 전역적으로 강제하는 대신 개별 역할에 대해서만 강제하도록 하고, MWI를 사용하여 임퍼소네이션할 역할에는 강제하지 않도록 하세요.

MWI를 Device Trust와 함께 사용할 수 있나요?#

현재 MWI와 Device Trust를 함께 사용하는 것은 지원하지 않습니다. 클러스터 전체에서 또는 MWI가 임퍼소네이션하는 역할에 대해 Device Trust를 요구하면, MWI가 생성한 자격 증명을 사용하여 리소스에 연결할 수 없게 됩니다.

이에 대한 우회 방법으로, Device Trust 강제를 역할별로 구성하고 MWI를 사용하여 임퍼소네이션할 역할에는 요구되지 않도록 하세요.

MWI를 사용하여 장기 유효 인증서를 생성할 수 있나요?#

MWI는 현재 24시간보다 더 오래 유효한 인증서를 생성하는 데 사용할 수 없으며, credential_ttl 매개변수를 사용하여 더 긴 인증서를 요청하더라도 이 24시간 제한으로 축소됩니다.

이 제한은 여러 목적을 수행합니다. 첫째, 매우 수명이 짧은 인증서만 발급함으로써 보안 모범 사례를 장려합니다. 또한, MWI는 인증서 갱신을 허용하므로, 이 제한은 MWI 아이덴티티가 손상되었을 경우 추가적인 악용을 방지하는 데 도움이 됩니다. 즉, 공격자가 도난당한 갱신 가능한 인증서를 사용하여 매우 수명이 긴 인증서를 요청하고 훨씬 더 오랜 기간 동안 접근을 유지하는 것을 막을 수 있습니다.

사용 사례에서 반드시 장기 유효 인증서가 필요한 경우, tctl auth sign을 대신 사용할 수 있지만, 이 경우 MWI의 수명이 짧은 갱신 가능한 인증서가 제공하는 보안 이점을 잃게 됩니다.

MWI를 사용하여 여러 쿠버네티스 클러스터에 연결할 수 있나요?#

이는 Teleport v17.2.7 이상에서 tbot의 새로운 kubernetes/v2 출력 서비스 유형을 사용하여 가능합니다. 이 서비스는 생성된 kubeconfig.yaml의 컨텍스트를 통해 한 번에 여러 클러스터를 노출할 수 있으며, 라벨 선택기(label selector)를 사용하는 경우 Teleport에서 클러스터가 추가되거나 제거될 때 컨텍스트를 동적으로 추가합니다.

이 기능을 활용하려면 tbot과 Teleport Proxy가 모두 v17.2.7을 실행하고 있어야 한다는 점에 유의하세요.

자세한 내용은 CLI 참조 및 구성 참조를 참조하세요.

tbot은 Windows를 지원하나요?#

예, tbot 바이너리는 Windows용으로 제공됩니다. 이는 tsh 및 tctl도 포함하는 클라이언트 도구 아카이브에서 찾을 수 있습니다. 자세한 내용은 Teleport 설치 가이드를 참조하세요.

다만 다음과 같은 몇 가지 제한 사항에 유의해야 합니다:

• Unix 도메인 소켓에 의존하는 기능(예: SSH 멀티플렉서, SPIFFE Workload API 등)은 사용할 수 없습니다.
• 디렉터리 목적지(destination)에 대한 심볼릭 링크 보호 구성과 관련된 기능은 사용할 수 없습니다.
• 디렉터리 목적지에 대한 ACL 관리와 관련된 기능은 사용할 수 없습니다.
• 대부분의 위임 조인 방법은 올바르게 작동하지 않을 가능성이 높습니다.

경우에 따라, Windows에서 네이티브로 tbot을 실행하기보다 Windows Subsystem for Linux 내에서 실행하는 것이 더 실용적일 수 있습니다. 이는 tbot의 출력을 사용하는 도구가 어디에서 실행되는지에 따라 달라집니다.