InfoGrab Docs

머신 및 워크로드 아이덴티티 FAQ

요약

이 페이지는 머신 및 워크로드 아이덴티티 (MWI)에 관한 자주 묻는 질문에 대한 답변을 제공합니다. 워크플로가 임시 환경(예: 개별 워크플로 실행 간에 지속적인 상태가 없음)에서 실행되는 CI/CD 플랫폼에서는, 지원되는 조인 방법이 있는 경우 MWI가 가장 잘 작동합니다.

이 페이지는 머신 및 워크로드 아이덴티티 (MWI)에 관한 자주 묻는 질문에 대한 답변을 제공합니다. Teleport 전반에 관한 자주 묻는 질문 목록은 자주 묻는 질문을 참조하십시오.

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

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

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

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

MWI를 신뢰할 수 있는 클러스터와 함께 사용할 수 있나요?#

신뢰할 수 있는 리프 클러스터에서 SSH 접근에 MWI를 사용할 수 있습니다.

현재 리프 클러스터의 애플리케이션, 데이터베이스, 또는 Kubernetes 클러스터에 대한 접근은 지원하지 않습니다.

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

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

  • 봇이 가장할 역할의 logins 섹션에 직접 로그인을 추가합니다.
  • 봇 사용자의 logins 특성에 로그인을 추가하고, {{ internal.logins }} 역할 변수를 포함하는 역할을 가장합니다. 이는 일반적으로 봇 생성 시 --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를 여러 Kubernetes 클러스터에 연결하는 데 사용할 수 있나요?#

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

tbot과 Teleport 프록시 모두 이 기능을 활용하려면 v17.2.7을 실행해야 합니다.

자세한 내용은 CLI 참조 및 구성 참조를 참조하십시오.

tbot은 Windows를 지원하나요?#

예, tbot 바이너리는 Windows에서 사용 가능합니다. tsh 및 tctl도 포함된 클라이언트 도구 아카이브에서 찾을 수 있습니다. 자세한 내용은 Teleport 설치 가이드를 참조하십시오.

그러나 몇 가지 알아야 할 제한 사항이 있습니다:

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

경우에 따라 Windows에서 직접 실행하는 것보다 Linux용 Windows 하위 시스템에서 tbot을 실행하는 것이 더 실용적일 수 있습니다. 이는 tbot의 출력을 소비할 도구가 실행되는 위치에 따라 다릅니다.

머신 및 워크로드 아이덴티티 FAQ

원문 보기
요약

이 페이지는 머신 및 워크로드 아이덴티티 (MWI)에 관한 자주 묻는 질문에 대한 답변을 제공합니다. 워크플로가 임시 환경(예: 개별 워크플로 실행 간에 지속적인 상태가 없음)에서 실행되는 CI/CD 플랫폼에서는, 지원되는 조인 방법이 있는 경우 MWI가 가장 잘 작동합니다.

이 페이지는 머신 및 워크로드 아이덴티티 (MWI)에 관한 자주 묻는 질문에 대한 답변을 제공합니다. Teleport 전반에 관한 자주 묻는 질문 목록은 자주 묻는 질문을 참조하십시오.

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

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

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

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

MWI를 신뢰할 수 있는 클러스터와 함께 사용할 수 있나요?#

신뢰할 수 있는 리프 클러스터에서 SSH 접근에 MWI를 사용할 수 있습니다.

현재 리프 클러스터의 애플리케이션, 데이터베이스, 또는 Kubernetes 클러스터에 대한 접근은 지원하지 않습니다.

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

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

  • 봇이 가장할 역할의 logins 섹션에 직접 로그인을 추가합니다.
  • 봇 사용자의 logins 특성에 로그인을 추가하고, {{ internal.logins }} 역할 변수를 포함하는 역할을 가장합니다. 이는 일반적으로 봇 생성 시 --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를 여러 Kubernetes 클러스터에 연결하는 데 사용할 수 있나요?#

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

tbot과 Teleport 프록시 모두 이 기능을 활용하려면 v17.2.7을 실행해야 합니다.

자세한 내용은 CLI 참조 및 구성 참조를 참조하십시오.

tbot은 Windows를 지원하나요?#

예, tbot 바이너리는 Windows에서 사용 가능합니다. tsh 및 tctl도 포함된 클라이언트 도구 아카이브에서 찾을 수 있습니다. 자세한 내용은 Teleport 설치 가이드를 참조하십시오.

그러나 몇 가지 알아야 할 제한 사항이 있습니다:

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

경우에 따라 Windows에서 직접 실행하는 것보다 Linux용 Windows 하위 시스템에서 tbot을 실행하는 것이 더 실용적일 수 있습니다. 이는 tbot의 출력을 소비할 도구가 실행되는 위치에 따라 다릅니다.