머신 ID를 CI/CD 작업에서 사용할 수 있습니까?

개별 워크플로 실행 간에 지속 상태가 존재하지 않는 임시 환경에서 워크플로가 실행되는 CI/CD 플랫폼에서는 머신 ID가 지원되는 조인 방법이 존재할 때 가장 잘 작동합니다. 지원되는 방법은 다음과 같습니다:

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

런너 환경을 제어하는 CI/CD 플랫폼에서는 머신 ID를 런너에서 데몬으로 실행할 수 있으며, 생성된 자격 증명을 개별 워크플로 실행 환경에 장착할 수 있습니다.

머신 ID를 신뢰된 클러스터와 함께 사용할 수 있습니까?

Teleport 12.2부터 신뢰된 리프 클러스터에서 SSH 액세스를 위해 머신 ID를 사용할 수 있습니다.

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

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

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

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

봇이 단일 출력이나 역할만 사용할 것으로 예상되는 간단한 시나리오에서는 봇 사용자의 로그인 특성에 로그인을 추가할 수 있습니다. 이 접근 방식은 access와 같은 기본 역할을 활용할 수 있습니다.

봇이 서로 다른 역할에 대해 서로 다른 출력을 위한 인증서를 생성하는 상황에서는 로그인 특성을 사용하여 의도하지 않은 리소스에 대한 액세스를 부여하지 않도록 고려하는 것이 중요합니다. 의도하지 않은 액세스를 방지하기 위해, 우리는 인증서에 포함되어야 하는 로그인을 명시적으로 지정하는 맞춤형 역할을 생성할 것을 권장합니다.

머신 ID를 세션별 MFA와 함께 사용할 수 있습니까?

현재 머신 ID와 세션별 MFA를 지원하지 않습니다. 세션별 MFA를 전 세계적으로 또는 머신 ID로 가장하는 역할에 적용하면 머신 ID로 생성된 자격 증명을 사용하여 리소스에 연결할 수 없게 됩니다.

우회 방법으로, 세션별 MFA를 전 세계적으로 강제 적용하는 것보다 개별 역할에 대해 강제 적용되도록 하고, 머신 ID로 가장할 역할에 대해 강제 적용되지 않도록 해야 합니다.

머신 ID를 장치 신뢰와 함께 사용할 수 있습니까?

현재 머신 ID와 장치 신뢰를 지원하지 않습니다. 장치 신뢰를 클러스터 전체 또는 머신 ID로 가장하는 역할에 요구하면 머신 ID로 생성된 자격 증명을 사용하여 리소스에 연결할 수 없게 됩니다.

우회 방법으로, 역할별로 장치 신뢰 강제를 구성하고 머신 ID로 가장할 역할에 대해 요구되지 않도록 해야 합니다.

머신 ID를 사용하여 장기 유효 인증서를 생성할 수 있습니까?

현재 머신 ID를 사용하여 24시간 이상 유효한 인증서를 생성할 수 없으며, certificate_ttl 매개변수를 사용하여 더 긴 인증서를 요청하면 이 24시간 제한으로 줄어듭니다.

이 제한은 여러 가지 목적을 가지고 있습니다. 첫째, 매우 짧은 유효 기간의 인증서만 발급함으로써 보안 모범 사례를 장려합니다. 또한 머신 ID가 인증서 갱신을 허용하기 때문에, 이 제한은 머신 ID 신원이 손상될 경우 추가적인 악용을 방지하는 데 도움이 됩니다. 공격자는 훔친 갱신 가능한 인증서를 사용하여 매우 장기 유효한 인증서를 요청하고 더 오랜 기간 액세스를 유지할 수 있습니다.

사용 사례가 반드시 장기 유효 인증서를 요구하는 경우, tctl auth sign를 대안으로 사용할 수 있지만, 이는 머신 ID의 짧은 유효 기간 갱신 인증서의 보안 이점을 잃게 됩니다.