시스템 관리자는 세션, 사용자 또는 호스트 아이덴티티에 잠금을 설정하여 침해된 사용자나 Teleport 에이전트를 비활성화하거나, 클러스터 유지보수 중 접근을 방지할 수 있습니다.

Teleport는 새 API 요청을 거부하고 잠금의 대상과 일치하는 SSH, 애플리케이션, 데이터베이스, 데스크톱, Kubernetes 세션에 대한 활성 연결을 종료합니다.

잠금은 다음 객체 또는 속성을 대상으로 할 수 있습니다:

• 사용자 이름으로 Teleport 사용자
• 역할 이름으로 Teleport RBAC 역할
• 디바이스 ID로 Teleport 트러스티드 디바이스
• 디바이스의 UUID로 MFA 디바이스
• OS/UNIX 로그인
• Agent의 서버 UUID로 Teleport 에이전트(사실상 클러스터에서 등록 해제됨)
• 데스크톱 이름으로 Windows 데스크톱
• UUID로 접근 요청
• 봇 인스턴스 ID(Machine & Workload Identity 봇용)
• 조인 토큰 이름(위임된 조인 방식을 사용하는 Machine & Workload Identity 봇용)

이 가이드에서는 잠금을 생성하고, 활성 잠금 목록을 조회하고, 더 이상 필요하지 않은 잠금을 삭제하는 방법을 알아봅니다.

작동 방식#

잠금은 Teleport Auth 서비스 백엔드에 저장되는 동적 Teleport 리소스입니다. Teleport 서비스는 잠금 생성과 관련된 Auth 서비스 이벤트를 구독하는 잠금 워처(lock watcher)를 구현합니다. 이러한 서비스가 잠금이 생성되거나 수정되었다는 알림을 받으면, 잠긴 사용자로부터의 접근을 방지하는 등 다양한 작업을 막기 위한 보호 조치를 시행합니다.

사전 요구 사항#

• 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

• tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     

       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음, 현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.

예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의 도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여 다음 명령을 실행합니다:

$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다. 자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를 호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.

1단계/2단계. 잠금 생성#

tctl lock 명령으로 새 잠금을 생성할 수 있습니다. 다음 옵션 중 하나로 잠금 대상을 지정하세요.

$ tctl lock --user=foo@example.com --message="Suspicious activity." --ttl=10h
# Created a lock with name "dc7cee9d-fe5e-4534-a90d-db770f0234a1".

$ tctl lock --role=contractor --message="All contractor access is disabled for 10h." --ttl=10h
# Created a lock with name "dc7cee9d-fe5e-4534-a90d-db770f0234a1".

$ tctl lock --device 9cdfc0ad-64b7-4d9c-9342-50e97f418ba0 --message="Compromised device" --ttl=48h
Created a lock with name "5444970a-39a0-4814-968d-e58b4a8fa686".

$ tctl lock --mfa-device=d6c06a18-e147-4232-9dfe-6f83a28d5850 --message="All contractor access is disabled for 10h." --ttl=10h
# Created a lock with name "d6c06a18-e147-4232-9dfe-6f83a28d5850".

$ tctl lock --server-id=363256df-f78a-4d99-803c-bae19da9ede4 --message="The server running the Kubernetes Service and Database Service is under investigation." --ttl=10h
# Created a lock with name "dc7cee9d-fe5e-4534-a90d-db770f0234a1".

$ tctl lock --windows-desktop=WIN-FMPFM5UF1SS-teleport-example-com --ttl=10h
# Created a lock with name "dc7cee9d-fe5e-4534-a90d-db770f0234a1".

$ tctl lock --access-request=261e80c5-357b-4c43-9b67-40a6bc4c6e4d --ttl=24h
# Created a lock with name "dc7cee9d-fe5e-4534-a90d-db770f0234a1".

$ tctl lock --join-token=example-token-name

$ tctl lock --bot-instance-id aabbccdd-1234-5678-0000-3b04d7d03acc

$ tctl lock --user bot-example

ERROR: access denied to perform action "create" on "lock"

kind: role
version: v5
metadata:
  name: locksmith
spec:
  allow:
    rules:
      - resources: [lock]
        verbs: [list, create, read, update, delete]

$ tctl create -f locksmith.yaml
# role 'locksmith' has been created

잠금이 시행되면 잠금 대상과 관련된 기존 연결이 모두 종료되고 새로운 요청은 거부됩니다.

이 상황에서 반환되는 오류와 기록되는 경고는 다음과 같은 형식의 메시지를 포함합니다.

lock targeting User:"foo@example.com" is in force: Suspicious activity.

$ tctl lock --user=foo@example.com --message="Please come back tomorrow." --ttl=24h

kind: lock
version: v2
metadata:
  name: dc7cee9d-fe5e-4534-a90d-db770f0234a1
spec:
  target:
    user: foo@example.com
  message: "Suspicious activity."
  expires: "2021-08-14T22:27:00Z"  # RFC3339 format

2단계/2단계. 활성 잠금 목록 조회 및 삭제#

tctl get 명령을 사용하여 모든 활성 잠금을 나열합니다.

$ tctl get locks

잠금 리소스를 삭제합니다.

$ tctl rm locks/24679348-baff-4987-a2cd-e820ab7f9d2b
lock "24679348-baff-4987-a2cd-e820ab7f9d2b" has been deleted

잠금을 삭제하면 새 세션이나 호스트 연결이 허용됩니다.

다음 단계: 잠금 모드#

Teleport 노드 또는 프록시 서비스가 로컬 잠금 뷰를 백엔드와 제대로 동기화할 수 없는 경우, 마지막으로 알려진 잠금에 의존할지 여부를 결정해야 합니다. 이 결정 전략은 다음 두 가지 모드 중 하나로 인코딩됩니다.

• strict 모드는 잠금이 최신 상태임을 보장할 수 없을 때 모든 상호작용을 종료합니다.
• best_effort 모드는 가장 최근의 잠금에 계속 의존합니다.

auth_service:
    authentication:
        locking_mode: best_effort

$ tctl edit cap

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  locking_mode: best_effort
version: v2

$ tctl edit cap

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  locking_mode: best_effort
version: v2

특정 역할에 대해 잠금 모드를 구성하는 것도 가능합니다.

kind: role
version: v5
metadata:
    name: example-role-with-strict-locking
spec:
    options:
       lock: strict

상호작용에 관련된 역할 중 어느 것도 모드를 지정하지 않거나 관련된 사용자가 없는 경우, 모드는 클러스터 전체 설정에서 가져옵니다.

잠재적으로 충돌할 수 있는 여러 잠금 모드(클러스터 전체 기본값과 개별 역할별 설정)가 있는 경우, strict가 하나라도 나타나면 로컬 잠금 뷰는 엄격하게 평가됩니다.