InfoGrab DocsInfoGrab Docs

Bound Keypair 참여 개념

요약

이 페이지에서는 Bound Keypair 참여를 이해하는 데 필요한 주요 개념을 설명합니다. "bound keypair"라는 용어는 자격 증명의 유형과 Teleport에서 이를 사용하는 방식을 동시에 가리킵니다. Bound Keypair 참여를 사용하는 봇은 일반적인 단기 Teleport 인증서를 발급받으며, 갱신 가능한 인증서와 유사한 방식으로 이를 정기적으로 갱신합니다.

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

Bound keypair#

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

Bound Keypair 참여를 사용하는 봇은 일반적인 단기 Teleport 인증서를 발급받으며, 갱신 가능한 인증서와 유사한 방식으로 이를 정기적으로 갱신합니다. 하지만 이와 더불어 인증서에 직접 연결되지 않는 추가적인 공개/개인 키 쌍도 사용합니다. 결정적으로, 이는 이 키 쌍에 만료일이 없다는 것을 의미하며, Teleport와 Bound Keypair 봇 사이에 수립된 신뢰 관계가 시간의 경과가 아니라 Teleport 내의 서버 측 구성에 의해 제어된다는 것을 의미합니다.

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

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

  • 복구 시도 횟수를 제한하고, 선택적으로 각 복구마다 (서버 측) 사람의 개입을 요구합니다.
  • 참여 상태 검증을 사용하여 개인 키의 재사용이나 탈취를 방지합니다.

온보딩#

온보딩은 최초 참여 시 이루어지며, 공개 키가 토큰에 바인딩되는 단계입니다. 봇이 이 단계를 완료하는 데 사용할 수 있는 방법은 두 가지입니다:

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

등록 시크릿이 사용되는 경우, 봇은 이 최초 연결에서 자신의 아이덴티티를 증명하기 위해 등록 시크릿을 사용하고, 즉석에서 키 쌍을 생성한 다음, 공개 키를 Teleport에 등록합니다.

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

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

복구#

복구는 봇이 새 인증서를 요청하기 위해 자신의 개인 키를 사용할 때 이루어집니다. 이는 다음 두 가지 상황에서 발생할 수 있습니다:

  • 봇에 인증서가 없는 최초 참여 시.
  • 봇이 구성된 certificate_ttl보다 오래 오프라인 상태였던 경우와 같이, 봇의 인증서가 갱신되기 전에 만료되는 경우.

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

복구 프로세스의 동작은 토큰 리소스에 구성된 두 가지 값, 즉 복구 모드 (spec.bound_keypair.recovery.mode)와 복구 한도(spec.bound_keypair.recovery.limit)에 따라 달라집니다. 모드는 다음 값을 가질 수 있습니다:

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

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

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

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

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

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

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

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

    이 모드는 봇이 반복적으로 다시 참여할 수 있고 변경 가능한 클라이언트 측 상태 없이도 작동할 수 있으므로 가장 유연합니다. 하지만 이는 대부분의 추가 보안 검사를 비활성화하므로 신중하게 사용해야 합니다. insecure 모드를 실제로 사용하는 방법에 대한 자세한 내용은 관리자 가이드를 참조하세요.

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

참여 상태 검증#

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

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

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

이 시스템은 Teleport의 단기 인증서와 봇의 잦은 재인증을 활용합니다. 공격자가 어떤 방법으로든 봇의 키 쌍 사본을 획득하여 Teleport 인증서를 가져오는 데 사용하려 시도한다면, 처음에는 성공할 것입니다. 하지만 원래의 봇은 결국 이제는 오래된 참여 상태 문서를 사용하여 또 다른 인증 시도를 하게 됩니다. 오래된 문서를 사용한 이 참여 시도는 잠금을 유발하여 원래의 봇과 공격자가 사용 중인 자격 증명 모두를 차단합니다.

토큰의 spec.bound_keypair.recovery.mode가 insecure로 설정된 경우 참여 상태 검증이 비활성화된다는 점에 유의하세요.

정적 키#

정적 키는 유연성을 위해 일부 보안 보장을 희생하며, 봇이 그렇지 않으면 인증할 수 없는 환경, 예를 들어 다음과 같은 환경에서 tbot을 사용할 수 있도록 돕습니다:

  • Teleport에 전용 참여 방법이 없는 CI/CD 제공업체
  • TPM이 없는 임시 베어메탈 노드
  • 영구 저장소를 사용할 수 없는 그 밖의 모든 환경
  • 임시 CI 러너와 같이 임의의 수의 인스턴스가 참여할 수 있는 모든 환경

하지만 정적 키에는 다음과 같은 단점이 있습니다:

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

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

정적 키를 사용할 때(tbot keypair create --static ...)는 insecure 복구 모드가 필요합니다. 이 모드는 참여 상태 문서를 위한 클라이언트 측 저장소를 비활성화하기 때문입니다. 이전 상태가 없으면 봇은 참여 상태 검증을 완료할 수 없으며, 최초 인증 시도 이후에는 복구할 수 없습니다. 따라서 참여 상태 검증은 비활성화되어야 합니다.

이러한 배경을 염두에 두고, 정적 키를 사용할 때는 개인 키를 알고 있는 모든 클라이언트가 추가 제약 없이 Teleport에 인증할 수 있다는 점에 유의하세요. 정적 키를 사용하는 봇을 배포하기 전에, 환경의 위협 모델과 보안 요구 사항을 충분히 이해하고, Teleport의 RBAC를 사용하여 접근을 제한함으로써 키 쌍이 침해될 경우 발생할 수 있는 영향 범위를 최소한으로 줄이도록 추가로 주의를 기울이세요.

Bound Keypair 참여 개념

Teleport v18.9
원문 보기
요약

이 페이지에서는 Bound Keypair 참여를 이해하는 데 필요한 주요 개념을 설명합니다. "bound keypair"라는 용어는 자격 증명의 유형과 Teleport에서 이를 사용하는 방식을 동시에 가리킵니다. Bound Keypair 참여를 사용하는 봇은 일반적인 단기 Teleport 인증서를 발급받으며, 갱신 가능한 인증서와 유사한 방식으로 이를 정기적으로 갱신합니다.

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

Bound keypair#

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

Bound Keypair 참여를 사용하는 봇은 일반적인 단기 Teleport 인증서를 발급받으며, 갱신 가능한 인증서와 유사한 방식으로 이를 정기적으로 갱신합니다. 하지만 이와 더불어 인증서에 직접 연결되지 않는 추가적인 공개/개인 키 쌍도 사용합니다. 결정적으로, 이는 이 키 쌍에 만료일이 없다는 것을 의미하며, Teleport와 Bound Keypair 봇 사이에 수립된 신뢰 관계가 시간의 경과가 아니라 Teleport 내의 서버 측 구성에 의해 제어된다는 것을 의미합니다.

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

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

  • 복구 시도 횟수를 제한하고, 선택적으로 각 복구마다 (서버 측) 사람의 개입을 요구합니다.
  • 참여 상태 검증을 사용하여 개인 키의 재사용이나 탈취를 방지합니다.

온보딩#

온보딩은 최초 참여 시 이루어지며, 공개 키가 토큰에 바인딩되는 단계입니다. 봇이 이 단계를 완료하는 데 사용할 수 있는 방법은 두 가지입니다:

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

등록 시크릿이 사용되는 경우, 봇은 이 최초 연결에서 자신의 아이덴티티를 증명하기 위해 등록 시크릿을 사용하고, 즉석에서 키 쌍을 생성한 다음, 공개 키를 Teleport에 등록합니다.

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

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

복구#

복구는 봇이 새 인증서를 요청하기 위해 자신의 개인 키를 사용할 때 이루어집니다. 이는 다음 두 가지 상황에서 발생할 수 있습니다:

  • 봇에 인증서가 없는 최초 참여 시.
  • 봇이 구성된 certificate_ttl보다 오래 오프라인 상태였던 경우와 같이, 봇의 인증서가 갱신되기 전에 만료되는 경우.

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

복구 프로세스의 동작은 토큰 리소스에 구성된 두 가지 값, 즉 복구 모드 (spec.bound_keypair.recovery.mode)와 복구 한도(spec.bound_keypair.recovery.limit)에 따라 달라집니다. 모드는 다음 값을 가질 수 있습니다:

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

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

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

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

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

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

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

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

    이 모드는 봇이 반복적으로 다시 참여할 수 있고 변경 가능한 클라이언트 측 상태 없이도 작동할 수 있으므로 가장 유연합니다. 하지만 이는 대부분의 추가 보안 검사를 비활성화하므로 신중하게 사용해야 합니다. insecure 모드를 실제로 사용하는 방법에 대한 자세한 내용은 관리자 가이드를 참조하세요.

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

참여 상태 검증#

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

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

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

이 시스템은 Teleport의 단기 인증서와 봇의 잦은 재인증을 활용합니다. 공격자가 어떤 방법으로든 봇의 키 쌍 사본을 획득하여 Teleport 인증서를 가져오는 데 사용하려 시도한다면, 처음에는 성공할 것입니다. 하지만 원래의 봇은 결국 이제는 오래된 참여 상태 문서를 사용하여 또 다른 인증 시도를 하게 됩니다. 오래된 문서를 사용한 이 참여 시도는 잠금을 유발하여 원래의 봇과 공격자가 사용 중인 자격 증명 모두를 차단합니다.

토큰의 spec.bound_keypair.recovery.mode가 insecure로 설정된 경우 참여 상태 검증이 비활성화된다는 점에 유의하세요.

정적 키#

정적 키는 유연성을 위해 일부 보안 보장을 희생하며, 봇이 그렇지 않으면 인증할 수 없는 환경, 예를 들어 다음과 같은 환경에서 tbot을 사용할 수 있도록 돕습니다:

  • Teleport에 전용 참여 방법이 없는 CI/CD 제공업체
  • TPM이 없는 임시 베어메탈 노드
  • 영구 저장소를 사용할 수 없는 그 밖의 모든 환경
  • 임시 CI 러너와 같이 임의의 수의 인스턴스가 참여할 수 있는 모든 환경

하지만 정적 키에는 다음과 같은 단점이 있습니다:

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

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

정적 키를 사용할 때(tbot keypair create --static ...)는 insecure 복구 모드가 필요합니다. 이 모드는 참여 상태 문서를 위한 클라이언트 측 저장소를 비활성화하기 때문입니다. 이전 상태가 없으면 봇은 참여 상태 검증을 완료할 수 없으며, 최초 인증 시도 이후에는 복구할 수 없습니다. 따라서 참여 상태 검증은 비활성화되어야 합니다.

이러한 배경을 염두에 두고, 정적 키를 사용할 때는 개인 키를 알고 있는 모든 클라이언트가 추가 제약 없이 Teleport에 인증할 수 있다는 점에 유의하세요. 정적 키를 사용하는 봇을 배포하기 전에, 환경의 위협 모델과 보안 요구 사항을 충분히 이해하고, Teleport의 RBAC를 사용하여 접근을 제한함으로써 키 쌍이 침해될 경우 발생할 수 있는 영향 범위를 최소한으로 줄이도록 추가로 주의를 기울이세요.