InfoGrab Docs

Bound Keypair 참여 개념

요약

이 페이지에서는 Bound Keypair 참여를 이해하는 데 필요한 주요 개념을 설명합니다. "bound keypair"라는 용어는 Teleport에서 자격 증명의 유형과 사용 방식 모두를 의미합니다. Bound Keypair 참여를 사용하는 bot은 정기적이고 수명이 짧은 Teleport 인증서를 받고 갱신 가능한 인증서와 유사한 방식으로 정기적으로 갱신하지만, 인증서에 직접 연결되지 않은 추가적인 공개/개인 키 쌍도 활용합니다.

이 페이지에서는 Bound Keypair 참여를 이해하는 데 필요한 주요 개념을 설명합니다.

Bound keypair#

"bound keypair"라는 용어는 Teleport에서 자격 증명의 유형과 사용 방식 모두를 의미합니다. 먼저, bot이 표준 공개/개인 키 쌍을 생성합니다. 다음으로, Teleport는 해당 공개 키를 신뢰하도록 구성되며, 이 공개 키를 토큰에 바인딩합니다.

Bound Keypair 참여를 사용하는 bot은 정기적이고 수명이 짧은 Teleport 인증서를 받고 갱신 가능한 인증서와 유사한 방식으로 정기적으로 갱신하지만, 인증서에 직접 연결되지 않은 추가적인 공개/개인 키 쌍도 활용합니다. 중요한 것은, 이 키 쌍에는 만료 날짜가 없으며, Teleport와 Bound Keypair bot 간의 신뢰 관계는 시간의 경과가 아니라 Teleport 내의 서버 측 구성에 의해 제어된다는 점입니다.

이 신뢰 관계가 확립되면, bot은 어떤 의미에서 클라우드 공급자가 호스트나 CI 워크플로 실행의 신원을 증명하는 것과 유사하게 자체 신원 권한으로 기능할 수 있습니다. Teleport는 참여하는 bot에게 고유한 암호화 챌린지를 발행하고, bot은 개인 키로 이에 서명하며, 결과는 Teleport에 등록된 키를 사용하여 검증됩니다.

이 자체 증명만으로는 충분한 보안 보장이 되지 않으므로, Bound Keypair 참여는 다음을 포함하여 참여 시도 허용 여부를 제어하는 추가적인 서버 측 규칙을 활용합니다:

  • 복구 시도 횟수 제한 및 각 복구에 대해 (서버 측) 사람의 개입 선택적 요구.
  • 참여 상태 검증을 사용하여 개인 키의 재사용이나 도용 방지.

온보딩#

온보딩은 첫 번째 참여 시 발생하며, 공개 키가 토큰에 바인딩되는 단계입니다. bot이 이 단계를 완료하는 데 사용할 수 있는 두 가지 방법이 있습니다:

  • 사전 등록된 키: 개인 키가 bot 호스트에 로컬로 생성되고, 공개 키는 사람 사용자나 스크립트에 의해 대역 외(out-of-band)로 Teleport에 복사됩니다. 이 방법은 시스템 간에 비밀 값이 복사되지 않도록 보장합니다.
  • 등록 시크릿: Teleport에서 일회용 임의 시크릿이 생성되고 임시 token 참여 방법과 유사하게 사람 사용자나 스크립트를 통해 bot 호스트에 제공됩니다.

등록 시크릿을 사용하면, bot은 등록 시크릿을 사용하여 첫 번째 연결에서 신원을 증명하고, 즉석에서 키 쌍을 생성하며, 공개 키를 Teleport에 등록합니다.

등록 시크릿은 기본적으로 사용됩니다. 토큰이 생성되고 초기 (사전 등록된) 공개 키가 제공되지 않으면, 등록 시크릿이 Teleport에 의해 무작위로 생성되어 토큰의 status.bound_keypair.registration_secret 필드에 기록됩니다.

두 경우 모두—등록 후 또는 사전 등록된 키를 사용할 때—참여하는 bot은 참여 챌린지를 완료해야 합니다. Teleport가 고유한 암호화 챌린지를 생성하고 bot은 이에 서명하여 반환해야 합니다. 서명이 등록된 공개 키와 일치하면 온보딩이 성공합니다. 공개 키는 토큰에 영구적으로 바인딩되고, 인증서 번들이 발행되며, 다음 참여 시도에 사용할 참여 상태 문서가 제공됩니다.

복구#

복구는 bot이 개인 키를 사용하여 새 인증서를 요청할 때 발생합니다. 이는 두 가지 상황에서 발생할 수 있습니다:

  • 첫 번째 참여 시, bot에 인증서가 없을 때.
  • bot의 인증서가 갱신되기 전에 만료될 때, 예를 들어 bot이 구성된 certificate_ttl보다 오랫동안 오프라인 상태인 경우.

bot이 유효한 Teleport 자격 증명을 유지하는 한—기본적으로 bot 인증서는 1시간 동안 유효하고 20분마다 갱신되지만 이 값은 구성 가능합니다—초기 참여 후에는 복구가 필요하지 않습니다. 복구는 bot이 구성된 인증서 TTL(예: 1시간)보다 오랫동안 인증서를 갱신할 수 없는 경우에만 필요합니다.

복구 프로세스의 동작은 토큰 리소스에 구성된 두 가지 값에 따라 달라집니다: 복구 모드(spec.bound_keypair.recovery.mode) 및 복구 제한(spec.bound_keypair.recovery.limit). 모드의 가능한 값:

  • standard (기본값): limit 복구 시도만 자동으로 시도할 수 있습니다.

    이 모드는 대부분의 상황에 권장됩니다. 복구 횟수(status.bound_keypair.recovery_count)가 구성된 제한을 초과하지 않는 한 bot은 자동으로 복구할 수 있으며, 이를 통해 클러스터 관리자가 자동 bot 복구 시도에 대한 허용 범위를 선택할 수 있습니다.

    참여 상태 검증이 활성화되어 있어 키 쌍 재사용을 방지하는 데 도움이 되지만, 클라이언트가 각 참여 시 추가 데이터를 저장해야 합니다.

    초기 참여가 복구 시도로 계산되므로, 초기 참여가 성공하려면 limit이 항상 최소 1 이상이어야 합니다.

  • relaxed: limit은 무시되지만 참여 상태 검증은 활성화된 상태로 유지됩니다.

    이 모드는 무제한 복구 시도를 허용하며, 보안 영향이 낮은 bot이나 bot이 정기적으로 오랫동안 오프라인 상태가 될 것으로 예상되는 배포에 유용합니다.

    standard 모드와 마찬가지로, 키 쌍 재사용을 방지하는 데 도움이 되도록 참여 상태 검증이 활성화되어 있지만, 클라이언트가 각 참여 시 추가 상태를 저장해야 합니다.

  • insecure: limit은 무시되고 참여 상태 검증이 비활성화됩니다.

    이 모드는 가장 유연하며, bot이 반복적으로 재참여할 수 있고 변경 가능한 클라이언트 측 상태 없이도 작동할 수 있습니다. 그러나 이는 대부분의 추가 보안 검사를 비활성화하므로 주의하여 사용해야 합니다. 실제 insecure 모드 사용에 대한 자세한 내용은 관리자 가이드를 참조하세요.

    정적 키 참여(tbot keypair create --static ...)는 클라이언트 측 자격 증명 저장을 비활성화하므로 insecure 모드를 사용해야 하며, 이는 bot이 참여 상태 검증을 완료할 수 없음을 의미합니다.

참여 상태 검증#

참여 상태 문서는 참여하는 bot에게 일반적인 Teleport 인증서 번들과 함께 제공되는 추가 정보입니다. 각 참여 시도를 고유하게 식별하는 시퀀스 번호를 포함하여 참여 프로세스 상태에 대한 서명된 정보를 포함합니다.

참여 상태 검증은 bot이 유효하고 서명된 참여 상태 문서를 제공할 수 있는지 확인하고, 문서에 예상된 시퀀스 번호가 포함되어 있는지 확인합니다.

  • 성공하면, 참여 시도가 진행될 수 있으며 증가된 시퀀스 카운터와 함께 새 참여 상태 문서가 발행됩니다.
  • 클라이언트가 제시한 시퀀스 번호가 오래된 경우, 참여 시도가 거부되고 기존 클라이언트가 Teleport 클러스터에 대한 추가 접근이 거부되도록 잠금이 생성됩니다.

이 시스템은 Teleport의 수명이 짧은 인증서와 빈번한 bot 재인증을 활용합니다. 공격자가 어떤 방식으로든 bot의 키 쌍 사본을 얻어 이를 사용하여 Teleport 인증서를 검색하려 시도하면, 처음에는 성공할 것입니다. 그러나 원래 bot은 결국 다른 인증 시도를 하게 되고, 이때 이미 오래된 참여 상태 문서를 사용하게 됩니다. 오래된 문서를 사용한 이 참여 시도는 잠금을 트리거하여 원래 bot과 공격자가 사용 중인 자격 증명을 모두 차단합니다.

토큰의 spec.bound_keypair.recovery.mode가 insecure로 설정되면 참여 상태 검증이 비활성화됩니다.

정적 키#

정적 키는 일부 보안 보장을 유연성과 교환하며, bot이 달리 인증할 수 없는 환경에서 tbot 사용을 가능하게 하는 데 도움이 됩니다. 예를 들어:

  • Teleport가 전용 참여 방법을 지원하지 않는 CI/CD 공급자
  • TPM이 없는 임시 베어메탈 노드
  • 영구 저장소를 사용할 수 없는 다른 모든 환경
  • 임시 CI 러너처럼 임의 수의 인스턴스가 참여할 수 있는 모든 환경.

그러나 정적 키에는 단점이 있습니다:

  • insecure 모드는 개인 키를 가진 모든 클라이언트가 제한 없이 참여할 수 있음을 의미합니다. 키가 도용되면 공격자는 Teleport와 bot이 접근할 수 있는 모든 리소스에 접근할 수 있게 됩니다.
  • insecure 모드는 bound keypair 토큰의 사용 횟수를 제한할 수 없음을 추가로 의미합니다(spec.bound_keypair.recovery.limit).
  • 클라이언트 저장소가 쓰기 가능하지 않아 키 쌍 교체가 지원되지 않으며, 교체를 요구하려는 시도는 bot의 참여를 방해합니다.

정적 키를 사용할 때, 키 쌍은 미리 생성되고 Teleport에 사전 등록됩니다. 그런 다음 파일이나 TBOT_BOUND_KEYPAIR_STATIC_KEY 환경 변수를 사용하여 tbot 클라이언트에 키 쌍을 제공할 수 있습니다.

insecure 복구 모드는 정적 키를 사용할 때 필수입니다(tbot keypair create --static ...). 이 모드는 참여 상태 문서에 대한 클라이언트 측 저장을 비활성화하기 때문입니다. 이전 상태 없이는 bot이 참여 상태 검증을 완료할 수 없으며, 첫 번째 인증 시도 후에 복구할 수 없습니다. 따라서 참여 상태 검증을 비활성화해야 합니다.

이러한 맥락을 고려할 때, 정적 키를 사용하는 경우 개인 키에 대한 지식을 가진 모든 클라이언트가 추가 제한 없이 Teleport에 인증할 수 있다는 점을 인식하십시오. 정적 키로 bot을 배포하기 전에, 환경의 위협 모델과 보안 요구 사항을 충분히 이해하고, 키 쌍이 손상될 경우 최소한의 피해 반경을 보장하기 위해 Teleport의 RBAC를 사용하여 접근을 제한하도록 추가 주의를 기울이세요.

Bound Keypair 참여 개념

원문 보기
요약

이 페이지에서는 Bound Keypair 참여를 이해하는 데 필요한 주요 개념을 설명합니다. "bound keypair"라는 용어는 Teleport에서 자격 증명의 유형과 사용 방식 모두를 의미합니다. Bound Keypair 참여를 사용하는 bot은 정기적이고 수명이 짧은 Teleport 인증서를 받고 갱신 가능한 인증서와 유사한 방식으로 정기적으로 갱신하지만, 인증서에 직접 연결되지 않은 추가적인 공개/개인 키 쌍도 활용합니다.

이 페이지에서는 Bound Keypair 참여를 이해하는 데 필요한 주요 개념을 설명합니다.

Bound keypair#

"bound keypair"라는 용어는 Teleport에서 자격 증명의 유형과 사용 방식 모두를 의미합니다. 먼저, bot이 표준 공개/개인 키 쌍을 생성합니다. 다음으로, Teleport는 해당 공개 키를 신뢰하도록 구성되며, 이 공개 키를 토큰에 바인딩합니다.

Bound Keypair 참여를 사용하는 bot은 정기적이고 수명이 짧은 Teleport 인증서를 받고 갱신 가능한 인증서와 유사한 방식으로 정기적으로 갱신하지만, 인증서에 직접 연결되지 않은 추가적인 공개/개인 키 쌍도 활용합니다. 중요한 것은, 이 키 쌍에는 만료 날짜가 없으며, Teleport와 Bound Keypair bot 간의 신뢰 관계는 시간의 경과가 아니라 Teleport 내의 서버 측 구성에 의해 제어된다는 점입니다.

이 신뢰 관계가 확립되면, bot은 어떤 의미에서 클라우드 공급자가 호스트나 CI 워크플로 실행의 신원을 증명하는 것과 유사하게 자체 신원 권한으로 기능할 수 있습니다. Teleport는 참여하는 bot에게 고유한 암호화 챌린지를 발행하고, bot은 개인 키로 이에 서명하며, 결과는 Teleport에 등록된 키를 사용하여 검증됩니다.

이 자체 증명만으로는 충분한 보안 보장이 되지 않으므로, Bound Keypair 참여는 다음을 포함하여 참여 시도 허용 여부를 제어하는 추가적인 서버 측 규칙을 활용합니다:

  • 복구 시도 횟수 제한 및 각 복구에 대해 (서버 측) 사람의 개입 선택적 요구.
  • 참여 상태 검증을 사용하여 개인 키의 재사용이나 도용 방지.

온보딩#

온보딩은 첫 번째 참여 시 발생하며, 공개 키가 토큰에 바인딩되는 단계입니다. bot이 이 단계를 완료하는 데 사용할 수 있는 두 가지 방법이 있습니다:

  • 사전 등록된 키: 개인 키가 bot 호스트에 로컬로 생성되고, 공개 키는 사람 사용자나 스크립트에 의해 대역 외(out-of-band)로 Teleport에 복사됩니다. 이 방법은 시스템 간에 비밀 값이 복사되지 않도록 보장합니다.
  • 등록 시크릿: Teleport에서 일회용 임의 시크릿이 생성되고 임시 token 참여 방법과 유사하게 사람 사용자나 스크립트를 통해 bot 호스트에 제공됩니다.

등록 시크릿을 사용하면, bot은 등록 시크릿을 사용하여 첫 번째 연결에서 신원을 증명하고, 즉석에서 키 쌍을 생성하며, 공개 키를 Teleport에 등록합니다.

등록 시크릿은 기본적으로 사용됩니다. 토큰이 생성되고 초기 (사전 등록된) 공개 키가 제공되지 않으면, 등록 시크릿이 Teleport에 의해 무작위로 생성되어 토큰의 status.bound_keypair.registration_secret 필드에 기록됩니다.

두 경우 모두—등록 후 또는 사전 등록된 키를 사용할 때—참여하는 bot은 참여 챌린지를 완료해야 합니다. Teleport가 고유한 암호화 챌린지를 생성하고 bot은 이에 서명하여 반환해야 합니다. 서명이 등록된 공개 키와 일치하면 온보딩이 성공합니다. 공개 키는 토큰에 영구적으로 바인딩되고, 인증서 번들이 발행되며, 다음 참여 시도에 사용할 참여 상태 문서가 제공됩니다.

복구#

복구는 bot이 개인 키를 사용하여 새 인증서를 요청할 때 발생합니다. 이는 두 가지 상황에서 발생할 수 있습니다:

  • 첫 번째 참여 시, bot에 인증서가 없을 때.
  • bot의 인증서가 갱신되기 전에 만료될 때, 예를 들어 bot이 구성된 certificate_ttl보다 오랫동안 오프라인 상태인 경우.

bot이 유효한 Teleport 자격 증명을 유지하는 한—기본적으로 bot 인증서는 1시간 동안 유효하고 20분마다 갱신되지만 이 값은 구성 가능합니다—초기 참여 후에는 복구가 필요하지 않습니다. 복구는 bot이 구성된 인증서 TTL(예: 1시간)보다 오랫동안 인증서를 갱신할 수 없는 경우에만 필요합니다.

복구 프로세스의 동작은 토큰 리소스에 구성된 두 가지 값에 따라 달라집니다: 복구 모드(spec.bound_keypair.recovery.mode) 및 복구 제한(spec.bound_keypair.recovery.limit). 모드의 가능한 값:

  • standard (기본값): limit 복구 시도만 자동으로 시도할 수 있습니다.

    이 모드는 대부분의 상황에 권장됩니다. 복구 횟수(status.bound_keypair.recovery_count)가 구성된 제한을 초과하지 않는 한 bot은 자동으로 복구할 수 있으며, 이를 통해 클러스터 관리자가 자동 bot 복구 시도에 대한 허용 범위를 선택할 수 있습니다.

    참여 상태 검증이 활성화되어 있어 키 쌍 재사용을 방지하는 데 도움이 되지만, 클라이언트가 각 참여 시 추가 데이터를 저장해야 합니다.

    초기 참여가 복구 시도로 계산되므로, 초기 참여가 성공하려면 limit이 항상 최소 1 이상이어야 합니다.

  • relaxed: limit은 무시되지만 참여 상태 검증은 활성화된 상태로 유지됩니다.

    이 모드는 무제한 복구 시도를 허용하며, 보안 영향이 낮은 bot이나 bot이 정기적으로 오랫동안 오프라인 상태가 될 것으로 예상되는 배포에 유용합니다.

    standard 모드와 마찬가지로, 키 쌍 재사용을 방지하는 데 도움이 되도록 참여 상태 검증이 활성화되어 있지만, 클라이언트가 각 참여 시 추가 상태를 저장해야 합니다.

  • insecure: limit은 무시되고 참여 상태 검증이 비활성화됩니다.

    이 모드는 가장 유연하며, bot이 반복적으로 재참여할 수 있고 변경 가능한 클라이언트 측 상태 없이도 작동할 수 있습니다. 그러나 이는 대부분의 추가 보안 검사를 비활성화하므로 주의하여 사용해야 합니다. 실제 insecure 모드 사용에 대한 자세한 내용은 관리자 가이드를 참조하세요.

    정적 키 참여(tbot keypair create --static ...)는 클라이언트 측 자격 증명 저장을 비활성화하므로 insecure 모드를 사용해야 하며, 이는 bot이 참여 상태 검증을 완료할 수 없음을 의미합니다.

참여 상태 검증#

참여 상태 문서는 참여하는 bot에게 일반적인 Teleport 인증서 번들과 함께 제공되는 추가 정보입니다. 각 참여 시도를 고유하게 식별하는 시퀀스 번호를 포함하여 참여 프로세스 상태에 대한 서명된 정보를 포함합니다.

참여 상태 검증은 bot이 유효하고 서명된 참여 상태 문서를 제공할 수 있는지 확인하고, 문서에 예상된 시퀀스 번호가 포함되어 있는지 확인합니다.

  • 성공하면, 참여 시도가 진행될 수 있으며 증가된 시퀀스 카운터와 함께 새 참여 상태 문서가 발행됩니다.
  • 클라이언트가 제시한 시퀀스 번호가 오래된 경우, 참여 시도가 거부되고 기존 클라이언트가 Teleport 클러스터에 대한 추가 접근이 거부되도록 잠금이 생성됩니다.

이 시스템은 Teleport의 수명이 짧은 인증서와 빈번한 bot 재인증을 활용합니다. 공격자가 어떤 방식으로든 bot의 키 쌍 사본을 얻어 이를 사용하여 Teleport 인증서를 검색하려 시도하면, 처음에는 성공할 것입니다. 그러나 원래 bot은 결국 다른 인증 시도를 하게 되고, 이때 이미 오래된 참여 상태 문서를 사용하게 됩니다. 오래된 문서를 사용한 이 참여 시도는 잠금을 트리거하여 원래 bot과 공격자가 사용 중인 자격 증명을 모두 차단합니다.

토큰의 spec.bound_keypair.recovery.mode가 insecure로 설정되면 참여 상태 검증이 비활성화됩니다.

정적 키#

정적 키는 일부 보안 보장을 유연성과 교환하며, bot이 달리 인증할 수 없는 환경에서 tbot 사용을 가능하게 하는 데 도움이 됩니다. 예를 들어:

  • Teleport가 전용 참여 방법을 지원하지 않는 CI/CD 공급자
  • TPM이 없는 임시 베어메탈 노드
  • 영구 저장소를 사용할 수 없는 다른 모든 환경
  • 임시 CI 러너처럼 임의 수의 인스턴스가 참여할 수 있는 모든 환경.

그러나 정적 키에는 단점이 있습니다:

  • insecure 모드는 개인 키를 가진 모든 클라이언트가 제한 없이 참여할 수 있음을 의미합니다. 키가 도용되면 공격자는 Teleport와 bot이 접근할 수 있는 모든 리소스에 접근할 수 있게 됩니다.
  • insecure 모드는 bound keypair 토큰의 사용 횟수를 제한할 수 없음을 추가로 의미합니다(spec.bound_keypair.recovery.limit).
  • 클라이언트 저장소가 쓰기 가능하지 않아 키 쌍 교체가 지원되지 않으며, 교체를 요구하려는 시도는 bot의 참여를 방해합니다.

정적 키를 사용할 때, 키 쌍은 미리 생성되고 Teleport에 사전 등록됩니다. 그런 다음 파일이나 TBOT_BOUND_KEYPAIR_STATIC_KEY 환경 변수를 사용하여 tbot 클라이언트에 키 쌍을 제공할 수 있습니다.

insecure 복구 모드는 정적 키를 사용할 때 필수입니다(tbot keypair create --static ...). 이 모드는 참여 상태 문서에 대한 클라이언트 측 저장을 비활성화하기 때문입니다. 이전 상태 없이는 bot이 참여 상태 검증을 완료할 수 없으며, 첫 번째 인증 시도 후에 복구할 수 없습니다. 따라서 참여 상태 검증을 비활성화해야 합니다.

이러한 맥락을 고려할 때, 정적 키를 사용하는 경우 개인 키에 대한 지식을 가진 모든 클라이언트가 추가 제한 없이 Teleport에 인증할 수 있다는 점을 인식하십시오. 정적 키로 bot을 배포하기 전에, 환경의 위협 모델과 보안 요구 사항을 충분히 이해하고, 키 쌍이 손상될 경우 최소한의 피해 반경을 보장하기 위해 Teleport의 RBAC를 사용하여 접근을 제한하도록 추가 주의를 기울이세요.