이 섹션에서는 Teleport 머신 ID의 내부 작동 방식을 개괄합니다.

머신 ID에 대한 초기 사양 및 설계는 토론 요청서에서 확인할 수 있습니다.

봇이란 무엇인가?

Teleport 내에서 "봇"은 기계에서 사용하도록 설계된 특별한 사용자입니다. 봇은 일반 사용자와 유사하지만, 정적 사용자 이름/비밀번호 자격 증명을 사용하여 인증하지 않습니다.

봇은 Teleport 내에서 단일 별개의 리소스로 존재하지 않습니다. 대신, 세 가지 연결된 리소스로 구성됩니다. 이들은 다음과 같습니다:

• 봇 사용자: 머신 ID 에이전트가 인증할 사용자입니다.
• 봇 역할: 봇 사용자에게 봇 역할이 할당되며, 봇 역할에는 봇이 기능하기 위해 필요한 다양한 권한이 포함되어 있습니다. 예를 들어, 인증 기관을 감시하는 능력과 역할 가장하기 능력이 있습니다.
• 토큰: 온보딩 시, 머신 ID 에이전트가 봇 사용자로 처음 인증할 수 있도록 허용하는 토큰이 존재해야 합니다. 기존 토큰이 지정되지 않으면 Auth 서버에 의해 단일 사용 가능 토큰이 생성됩니다.
• 봇 인스턴스: 봇의 단일 인스턴스입니다. 여러 tbot 클라이언트가 단일 봇 사용자 또는 단일 토큰으로 조인할 수 있으므로, 봇 인스턴스는 고유한 봇 조인의 실행 중 기록을 유지합니다.

이러한 리소스의 생성은 tctl bots add 에 의해 관리됩니다.

봇과 tbot 인스턴스 간의 구분이 중요합니다. 이는 항상 일대일 관계가 아니기 때문에, 많은 경우 동일한 봇 아이덴티티를 사용하는 여러 tbot 이 있을 수 있습니다.

역할 가장하기

역할 가장하기는 Teleport의 RBAC 기능으로, 머신 ID에서 많이 사용됩니다.

역할 가장하기를 사용하면 사용자가 요청한 역할 집합으로 자격 증명을 생성할 수 있습니다. 사용자는 이러한 역할을 보유할 필요는 없지만, 이를 가장하도록 허가받아야 합니다. 가장된 자격 증명에는 여전히 이를 생성한 사용자의 사용자 이름이 포함되므로, 작업은 사용자에게 귀속될 수 있습니다.

이러한 자격 증명은 역할의 구성된 권한에 의해 허용된 모든 작업을 완료하는 데 사용될 수 있습니다.

머신 ID의 경우, 봇 사용자에게 봇 역할이 할당되며, 여기에는 사용자가 구성한 역할을 가장할 수 있는 권한이 포함됩니다.

tbot

tbot 은 Teleport에 의해 보호되는 리소스에 접근해야 하는 기계에서 머신 ID의 에이전트 역할을 하는 바이너리입니다. 일반적으로 두 가지 모드 중 하나로 실행됩니다. 기본적으로, 데몬과 같은 긴 실행 프로세스입니다. 이는 기계가 긴 실행을 필요로 하고 리소스에 지속적으로 접근할 필요가 있는 상황에 적합합니다. 또한 tbot 은 종료하기 전에 기계에 대해 한 번 자격 증명을 가져오는 "한 번만" 모드로 실행할 수도 있습니다. 이는 CI/CD 워크플로와 같은 단기 환경에 적합합니다.

tbot 을 시작하기 전에 구성 파일 또는 tbot 이 실행될 때 제공된 인수로 최소 두 개의 구성 부분이 제공되어야 합니다. 이는 다음으로 구성됩니다:

• 봇이 Teleport 클러스터에 조인해야 하는지를 증명하기 위해 사용할 수 있는 조인 방법.
• 일련의 출력. 출력은 자격 증명이 출력되어야 하는 위치를 지정하는 구성 설정과 자격 증명에 적용해야 하는 모든 옵션(예: 어떤 역할이 가장되어야 하는지)을 포함합니다.

구성 옵션에 대한 자세한 내용은 참조 문서에서 확인하십시오.

초기 로드 시, tbot 은 구성된 조인 방법을 사용하여 Teleport Auth 서비스로부터 봇 사용자의 자격 증명 세트를 얻습니다. 그런 다음 이 자격 증명을 사용하여 봇으로서 Teleport Auth 서비스와 통신할 수 있습니다.

그런 다음 구성된 정기 기간에 따라 tbot 은 갱신 프로세스를 시작합니다. 봇의 자체 자격 증명을 새로 고치거나, 구성된 온보딩 방법에 따라 새로운 자격 증명을 가져오는 방식으로 봇의 자격 증명을 갱신하는 것으로 시작합니다.

tbot 구성에서 제공된 각 출력에 대해, tbot 프로그램은 구성이 각 출력에 대해 지정한 역할에 대한 자격 증명을 Auth 서비스에서 얻기 위해 가장을 사용합니다. tbot 이 역할에 대한 자격 증명을 가져오면, 이것들은 다양한 형식으로 출력의 목적지에 저장되며 현재 인증 기관 인증서와 같은 기타 유용한 아티팩트와 함께 저장됩니다.

이와 동시에, tbot 은 인증 기관의 인증서 회전을 감지하기 위해 Teleport 인증서를 모니터링합니다. 이 경우, 출력 목적지가 최신 인증 기관에 의해 서명된 인증서를 계속 보유할 수 있도록 추가 갱신을 트리거합니다.

서비스 연결 및 인증

연결은 tbot 이 Teleport Auth Service에 봇으로서 처음 인증하는 과정입니다.

Machine ID는 Teleport 내에 있는 기존 토큰 리소스를 활용하며, 토큰에는 토큰과 연관된 봇 사용자와 연결된 추가 botName 필드가 포함되어 있습니다.

Machine ID는 현재 몇 가지 주요 차이가 있는 두 가지 연결 방법을 지원합니다.

임시 토큰

• 토큰의 이름은 Teleport 클러스터에 연결하는 데 필요한 불투명한 비밀로 사용됩니다. 이는 안전하게 저장하고 전달되어야 함을 의미합니다.
• 한 번 사용되면, 토큰 리소스는 자동으로 파괴됩니다. 이는 단일 봇만 Teleport 클러스터에 연결하는 데 사용할 수 있음을 의미합니다.

이러한 토큰은 한 번만 사용할 수 있으므로, 임시 토큰을 사용할 때 발급되는 인증서들은 갱신이 가능합니다. 이는 단기간 인증서를 사용하여 새로운 단기간 인증서를 요청할 수 있게 해줍니다.

봇 사용자 자격 증명이 도난당하고 악의적인 행위자가 지속적으로 이를 갱신하는 위험을 완화하기 위해, 갱신 가능한 봇 사용자 인증서는 봇 인스턴스의 세대 카운터를 검증합니다.

세대 카운터는 Bot Instance의 일부로 데이터베이스에 저장되고 인증서 내에 포함됩니다. 이 카운터는 이 봇 인스턴스가 인증서를 갱신할 때마다 증가합니다. 봇이 갱신을 시도할 때, Auth Service는 인증서 내의 값과 데이터베이스 내의 값이 일치하는지 확인합니다. 일치하지 않을 경우, 봇 사용자는 자동으로 잠기게 됩니다. 이는 인증서를 도난당하고 봇이 여전히 실행 중인 상태에서 갱신을 시도할 경우, 다음 갱신이 그것들을 무용지물로 만들어버림을 의미합니다.

동적 조인 토큰 (예: AWS IAM)

• 이러한 토큰은 외부 권한에 의존하여 봇이 클러스터에 연결할 수 있는 권한이 있음을 증명할 수 있게 해줍니다. 토큰의 이름은 Teleport 내의 구성 정보를 포함하는 토큰 리소스를 식별합니다.
• 이 토큰은 원하는 만큼 많은 봇이 연결되는 데 사용될 수 있으며, 임시 토큰과 같은 방식으로 자동 파괴되지 않습니다.
• 토큰에 대해 교환된 인증서는 갱신이 불가능합니다. 봇이 인증서를 갱신하고 싶을 때, 원래의 연결 단계를 반복하면 됩니다.

가능한 경우, 비밀을 다룰 필요가 없으므로 임시 토큰보다 동적 조인 토큰을 사용하는 것이 좋습니다.

봇 인스턴스

봇 인스턴스는 인증서 갱신 및 재조인 과정을 통해서도 단일 봇 아이덴티티의 계보를 식별합니다. tbot 클라이언트가 클러스터에 처음 인증할 때, 봇 인스턴스가 생성되고 그 UUID가 반환된 클라이언트 아이덴티티에 포함됩니다.

그 후 해당 봇이 갱신하거나 재인증할 때, 이전 클라이언트 인증서를 사용하여 Teleport Auth Service에 인증하며, 그 아이덴티티에서 봇 인스턴스 ID가 추출됩니다. 인증 이벤트 기록은 Teleport Auth Service에 저장되며, 아이덴티티 생성 카운터와 함께 기록됩니다. 생성 카운터는 모든 조인 유형(임시 및 동적)에 대해 추적되지만, 현재 token 유형 조인에 대해서만 집행됩니다.

봇 인스턴스는 또한 tbot 인스턴스에 대한 다양한 정보를 추적하며, 여기에는 아키텍처 및 OS 버전과 같은 tbot 호스트에 대한 기본 정보를 포함하는 정기 하트비트도 포함됩니다.

봇 인스턴스를 추적하려면 각 인증 시도 동안 봇이 자신의 아이덴티티를 증명해야 하므로, 이는 시간이 지남에 따라 단일 봇 인스턴스 ID를 유지하고자 하는 봇들이 상태를 유지해야 함을 의미합니다. 많은 Machine ID 사용 사례에 대한 상태 유지는 기대되거나 실현 가능하지 않습니다: 예를 들어, CI/CD 워크플로우는 일반적으로 매번 처음부터 다시 연결해야 합니다. 이는 기대되는 행동이며, 이러한 사용 사례가 있는 봇들은 장기 클라이언트보다 더 많은 고유한 봇 인스턴스를 생성하게 될 것입니다.

봇 인스턴스는 상대적으로 짧은 수명을 가지며, 특정 인스턴스에 대해 발급된 가장 최근의 아이덴티티가 만료된 후 만료됩니다. 특정 봇 인스턴스와 연관된 tbot 클라이언트가 갱신하거나 재조인하면 봇 인스턴스의 만료가 재설정됩니다. 이는 사용자가 자신들의 Teleport 클러스터와 상호작용하는 활성 tbot 클라이언트의 수를 정확하게 볼 수 있도록 Bot Instances를 나열할 수 있도록 설계되었습니다.

파일 권한

tbot 에서 사용되는 두 가지 유형의 폴더가 있습니다:

• 봇 자체의 파일: 이러한 파일은 tbot 프로세스에 속하는 자격 증명을 저장합니다. 이러한 자격 증명은 잠재적으로 갱신 가능하며, 봇 사용자에게 할당된 모든 역할을 가장할 수 있도록 허용합니다. 따라서 이들은 매우 민감한 정보로 취급해야 합니다. 봇의 파일은 기본적으로 /var/lib/teleport/bot/에 저장됩니다.
• 출력 목적지: 디렉토리 목적지가 구성되면, 봇은 지정된 디렉토리에 역할을 가장한 자격 증명을 파일로 출력합니다.

이러한 파일에 접근할 수 있는 Linux 프로세스 및 사용자의 수를 가능한 한 최소화하는 것이 중요합니다.

봇 자체의 파일의 경우, tbot 를 실행하기 위해 특별히 Linux 사용자를 만드는 것이 모범 사례이며, 이 사용자만이 이 디렉토리에 접근할 수 있도록 해야 합니다.

디렉토리 목적지의 경우, 봇이 실행되는 프로세스는 읽기 및 쓰기 권한이 필요하며, 봇이 출력하는 자격 증명이 필요한 프로세스는 읽기 권한이 필요합니다. 이러한 파일에 접근해야 하는 프로세스를 위한 특정 Linux 사용자를 만드는 것이 좋습니다. tbot init 를 사용할 때, 이 Linux 사용자를 "reader"로 지정하여 목적지에 대한 접근 권한을 부여하십시오.

기본 POSIX 파일 시스템 권한 외에도, tbot init 는 시스템에서 지원하는 경우 Linux ACL도 설정합니다. 이를 통해 개별 사용자에 대한 보다 세밀한 접근 권한 제어가 가능합니다.

마지막으로, 이를 지원하는 시스템에서 tbot 는 기본적으로 파일을 읽고 쓸 때 심볼릭 링크의 해석을 방지하려고 합니다. 이는 때때로 symlink 공격이라고 불리는 공격의 종류를 예방합니다. 이 동작은 목적지를 구성할 때 insecure 심볼릭 옵션을 사용하여 비활성화할 수 있습니다.