이 섹션은 Teleport 머신 및 워크로드 아이덴티티의 내부 작동 방식에 대한 개요를 제공합니다.

머신 및 워크로드 아이덴티티의 초기 사양과 설계는 Request For Discussion에서 확인할 수 있습니다.

bot이란 무엇인가?#

Teleport에서 "bot"은 머신이 사용하도록 의도된 특수한 사용자를 의미합니다. Bot은 일반 사용자와 유사하지만, 정적 사용자명/패스워드 자격증명을 사용하여 인증하지 않습니다.

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

• Bot 사용자: 머신 및 워크로드 아이덴티티 에이전트가 인증하는 사용자가 됩니다.
• Bot 역할: bot 사용자에게 bot 역할이 할당되며, bot 역할에는 bot이 기능하기 위해 필요한 다양한 권한이 포함됩니다. 예를 들어, 인증서 기관을 감시하는 기능과 역할 가장 기능이 있습니다.
• 토큰: 온보딩을 위해, 머신 및 워크로드 아이덴티티 에이전트가 최초로 bot 사용자로 인증할 수 있도록 허용하는 토큰이 존재해야 합니다. 기존 토큰이 지정되지 않은 경우, Auth Service에 의해 단일 사용 토큰이 생성됩니다.
• Bot 인스턴스: bot의 단일 인스턴스입니다. 여러 tbot 클라이언트가 단일 Bot 사용자 또는 단일 토큰으로 합류할 수 있으므로, Bot 인스턴스는 고유한 bot 합류 기록을 유지합니다.

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

bot과 tbot의 인스턴스 간의 차이를 인식하는 것이 중요합니다. 이는 항상 일대일 관계가 아니기 때문입니다. 많은 경우에 여러 tbot이 동일한 bot 신원을 사용하고 있을 수 있습니다.

Role Impersonation#

Role Impersonation은 머신 및 워크로드 아이덴티티에서 많이 사용되는 Teleport의 RBAC 기능입니다.

Role Impersonation을 사용하면 사용자가 요청된 역할 집합을 가진 자격증명을 생성할 수 있습니다. 사용자가 이러한 역할을 보유할 필요는 없지만, 해당 역할을 가장할 수 있는 권한이 부여되어 있어야 합니다. 가장된 자격증명에는 여전히 이를 생성한 사용자의 사용자명이 포함되어 있으므로, 작업은 해당 사용자에게 귀속될 수 있습니다.

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

머신 및 워크로드 아이덴티티의 경우, bot 사용자에게 bot 역할이 할당되며, 이 역할에는 사용자가 구성한 역할을 가장할 수 있는 권한이 포함되어 있습니다.

tbot#

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

tbot을 시작하기 전에, 구성 파일이나 tbot이 실행될 때 제공되는 인수를 통해 최소 두 가지 구성이 제공되어야 합니다. 이는 다음으로 구성됩니다:

• Bot이 Teleport 클러스터에 합류할 수 있어야 함을 증명하는 데 사용할 수 있는 합류 방법.
• 일련의 출력. 출력은 자격증명 집합이 출력되어야 할 위치와 해당 자격증명에 적용되어야 할 옵션(예: 어떤 역할을 가장해야 하는지)을 지정하는 구성 설정으로 구성됩니다.

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

최초 로드 시, tbot은 구성된 합류 방법을 사용하여 Teleport Auth Service에서 bot 사용자를 위한 자격증명 집합을 얻습니다. 그런 다음 이러한 자격증명을 사용하여 bot으로서 Teleport Auth Service와 통신할 수 있습니다.

그런 다음 구성된 정기적인 주기마다 tbot은 갱신 프로세스를 시작합니다. 구성된 온보딩 방법에 따라 갱신하거나 새로운 자격증명 집합을 가져옴으로써 bot 자체의 자격증명을 새로 고침하는 것으로 시작됩니다.

tbot 구성에 제공된 각 출력에 대해, tbot 프로그램은 가장을 사용하여 해당 출력에 대한 구성에 지정된 역할에 대한 Auth Service로부터 자격증명을 얻습니다. tbot이 해당 역할에 대한 자격증명을 가져온 후, 현재 인증서 기관 인증서와 같은 다른 유용한 아티팩트와 함께 다양한 형식으로 출력의 대상에 저장됩니다.

이와 동시에, tbot은 Teleport 인증서 기관을 모니터링하여 인증서 교체를 감지합니다. 이 경우, 출력 대상이 최신 인증서 기관에 의해 서명된 인증서를 계속 가지도록 추가 갱신을 트리거합니다.

합류 및 인증#

합류는 tbot이 Teleport Auth Service에 bot으로서 최초로 인증하는 프로세스입니다.

머신 및 워크로드 아이덴티티는 Teleport 내의 기존 토큰 리소스를 활용하며, 토큰에는 토큰과 연결된 bot 사용자를 식별하는 추가 botName 필드가 포함되어 있습니다.

머신 및 워크로드 아이덴티티는 현재 몇 가지 주요 차이점이 있는 두 가지 합류 방법을 지원합니다.

임시 토큰#

• 토큰의 이름은 Teleport 클러스터에 합류하는 데 필요한 불투명한 비밀로 사용됩니다. 이는 안전하게 저장하고 통신해야 함을 의미합니다.
• 한 번 사용되면, 토큰 리소스는 자체 파괴됩니다. 이는 단일 bot을 Teleport 클러스터에 합류시키는 데만 사용할 수 있음을 의미합니다.

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

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

세대 카운터는 데이터베이스와 인증서 내의 Bot 인스턴스의 일부로 저장됩니다. 이 카운터는 이 bot 인스턴스가 인증서를 갱신할 때마다 증가합니다. bot이 갱신을 시도할 때, Auth Service는 인증서와 데이터베이스의 값이 일치하는지 확인합니다. 일치하지 않으면, bot 사용자는 자동으로 잠깁니다. 이는 인증서가 도용되고, bot이 여전히 실행 중인 동안 갱신을 시도한다면, 다음 갱신 시 해당 인증서를 쓸모없게 만든다는 것을 의미합니다.

동적 합류 토큰 (예: AWS IAM)#

• 이러한 토큰은 bot이 클러스터에 합류할 수 있음을 증명하는 외부 기관에 의존합니다. 토큰의 이름은 구성을 포함하는 Teleport의 Token 리소스를 식별합니다.
• 토큰은 원하는 만큼 많은 bot에 합류하는 데 사용할 수 있으며, 임시 토큰과 같은 방식으로 자체 파괴되지 않습니다.
• 토큰과 교환되는 인증서는 갱신할 수 없습니다. bot이 인증서를 갱신하려면, 단순히 원래 합류 단계를 반복합니다.

가능하면, 비밀을 처리할 필요성을 제거하는 동적 합류 토큰을 임시 토큰보다 선호해야 합니다.

Bot 인스턴스#

Bot 인스턴스는 인증서 갱신 및 재합류를 거쳐도 단일 bot 신원의 계보를 식별합니다. tbot 클라이언트가 클러스터에 처음 인증될 때, Bot 인스턴스가 생성되고 해당 UUID가 반환된 클라이언트 신원에 임베드됩니다.

해당 bot이 나중에 갱신하거나 재인증할 때, 이전 클라이언트 인증서를 사용하여 Teleport Auth Service에 인증하며, Bot 인스턴스 ID는 해당 신원에서 추출됩니다. 인증 이벤트의 기록은 Teleport Auth Service에 신원 세대 카운터와 함께 저장됩니다. 세대 카운터는 모든 합류 유형(임시 및 동적)에 대해 추적되지만, 현재는 token 유형 합류에 대해서만 적용됩니다.

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

Bot 인스턴스 추적에는 각 인증 시도 시 bot이 신원을 증명해야 하므로, 시간이 지남에 따라 단일 Bot 인스턴스 ID를 유지하려면 bot이 상태를 유지해야 합니다. 많은 머신 및 워크로드 아이덴티티 사용 사례의 경우 상태를 유지하는 것이 예상되거나 가능하지 않습니다. 예를 들어, CI/CD 워크플로는 일반적으로 매번 처음부터 재합류해야 합니다. 이는 예상되는 동작이며, 이와 같은 사용 사례를 가진 bot은 장기 실행 클라이언트보다 더 많은 고유한 Bot 인스턴스를 생성합니다.

Bot 인스턴스의 수명은 비교적 짧으며, 해당 인스턴스에 대해 발급된 가장 최근 신원이 만료된 후에 만료되도록 설정됩니다. 특정 Bot 인스턴스와 연결된 tbot 클라이언트가 갱신하거나 재합류하면, bot 인스턴스의 만료가 재설정됩니다. 이는 사용자가 Teleport 클러스터와 상호 작용하는 활성 tbot 클라이언트 수를 정확하게 확인하기 위해 Bot 인스턴스를 나열할 수 있도록 설계되었습니다.

파일 권한#

tbot이 사용하는 두 가지 유형의 폴더가 있습니다:

• Bot 자체 파일: tbot 프로세스 자체에 속한 자격증명을 저장합니다. 이러한 자격증명은 잠재적으로 갱신 가능하며, bot 사용자에게 할당한 모든 역할의 가장을 허용하므로, 매우 민감한 것으로 취급해야 합니다. Bot 자체 파일은 기본적으로 /var/lib/teleport/bot/에 저장됩니다.
• 출력 대상: 디렉터리 대상이 구성된 경우, bot은 지정된 디렉터리의 파일로 역할 가장 자격증명을 출력합니다.

이러한 파일이 시스템에서 필요한 최소한의 Linux 프로세스 및 사용자만 접근할 수 있도록 해야 합니다.

Bot 자체 파일의 경우, tbot을 실행하기 위해 특별히 Linux 사용자를 생성하고 이 사용자만 이 디렉터리에 접근할 수 있도록 하는 것이 모범 사례입니다.

디렉터리 대상의 경우, bot이 실행되는 프로세스에는 읽기 및 쓰기 권한이 필요하고, bot이 출력하는 자격증명이 필요한 프로세스에는 읽기 권한이 필요합니다. 이러한 파일에 접근해야 하는 프로세스에 특정한 Linux 사용자를 생성하는 것을 권장합니다. tbot init을 사용할 때, 이 Linux 사용자를 "reader"로 지정하여 대상에 대한 접근 권한을 부여하십시오.

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

마지막으로, 지원하는 시스템에서 tbot은 기본적으로 파일 읽기 및 쓰기 시 심볼릭 링크 해결을 방지하려고 시도합니다. 이는 때때로 심볼릭 링크 공격으로 알려진 공격 클래스를 방지합니다. 이 동작은 대상을 구성할 때 insecure 심볼릭 링크 옵션을 사용하여 비활성화할 수 있습니다.