📣 DevOps 전문 기업 인포그랩이 만든 Teleport 공식 문서 한국어 페이지입니다.
이 페이지는 Teleport 공식 문서를 한국어로 번역해 제공합니다.
Infograb logo
세션 및 아이덴티티 잠금

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

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

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

  • 사용자의 이름으로 Teleport 사용자
  • 역할의 이름으로 Teleport RBAC 역할
  • 장치 ID로 Teleport 신뢰할 수 있는 장치
  • 장치의 UUID로 MFA 장치
  • OS/UNIX 로그인
  • 에이전트의 서버 UUID로 Teleport 에이전트 (실질적으로 클러스터에서 등록 해제됨)
  • 데스크톱의 이름으로 Windows 데스크톱
  • UUID로 액세스 요청

전제 조건

  • 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

  • tctl 관리 도구와 tsh 클라이언트 도구.

    tctl과 tsh 다운로드에 대한 지침은 설치를 방문하세요.

  • 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어: 
    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl status
    클러스터  teleport.example.com
    버전  16.2.0
    CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
    클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

단계 1/2. 잠금 만들기

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

tctl lock --user=foo@example.com --message="의심스러운 활동." --ttl=10h
"dc7cee9d-fe5e-4534-a90d-db770f0234a1"이라는 이름의 잠금을 생성했습니다.

대상 역할과 일치하는 할당된 역할이 있는 모든 사용자가 잠금됩니다.

tctl lock --role=contractor --message="모든 계약자 접근이 10시간 동안 비활성화되었습니다." --ttl=10h
"dc7cee9d-fe5e-4534-a90d-db770f0234a1"이라는 이름의 잠금을 생성했습니다.

장치 ID와 일치하는 장치에서 시작된 모든 연결이 잠금됩니다.

tctl lock --device 9cdfc0ad-64b7-4d9c-9342-50e97f418ba0 --message="손상된 장치" --ttl=48h
"5444970a-39a0-4814-968d-e58b4a8fa686"이라는 이름의 잠금을 생성했습니다.

장치 ID와 일치하는 세션별 MFA로 시작된 모든 연결이 잠금됩니다.

tctl lock --mfa-device=d6c06a18-e147-4232-9dfe-6f83a28d5850 --message="모든 계약자 접근이 10시간 동안 비활성화되었습니다." --ttl=10h
"d6c06a18-e147-4232-9dfe-6f83a28d5850"이라는 이름의 잠금을 생성했습니다.

지정된 에이전트에 대한 모든 연결이 잠기고 에이전트는 Teleport 클러스터에서 제외됩니다.

tctl lock --server-id=363256df-f78a-4d99-803c-bae19da9ede4 --message="Kubernetes 서비스와 데이터베이스 서비스가 조사가 진행 중입니다." --ttl=10h
"dc7cee9d-fe5e-4534-a90d-db770f0234a1"이라는 이름의 잠금을 생성했습니다.

지정된 Windows 데스크톱에 대한 모든 연결이 잠금됩니다.

tctl lock --windows-desktop=WIN-FMPFM5UF1SS-teleport-example-com --ttl=10h
"dc7cee9d-fe5e-4534-a90d-db770f0234a1"이라는 이름의 잠금을 생성했습니다.

일치하는 액세스 요청에서 상승된 권한을 사용하는 모든 연결이 잠금됩니다.

tctl lock --access-request=261e80c5-357b-4c43-9b67-40a6bc4c6e4d --ttl=24h
"dc7cee9d-fe5e-4534-a90d-db770f0234a1"이라는 이름의 잠금을 생성했습니다.

사용자에게 잠금 권한이 없는 경우 잠금을 생성할 때 오류가 발생합니다:

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

locksmith라는 역할을 정의하세요:

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

역할을 생성하세요:

tctl create -f locksmith.yaml
역할 'locksmith'가 생성되었습니다.

myrole 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

  1. 로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:

    ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')

  2. 로컬 사용자를 편집하여 새로운 역할을 추가합니다:

    tctl users update $(tsh status -f json | jq -r '.active.username') \  --set-roles "${ROLES?},myrole"

  3. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  1. github 인증 커넥터를 가져옵니다:

    tctl get github/github --with-secrets > github.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.

  2. github.yaml을 편집하고 teams_to_roles 섹션에 myrole을 추가합니다.

    이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.

    여기에 예시가 있습니다:

      teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - myrole

  3. 변경 사항을 적용합니다:

    tctl create -f github.yaml

  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

  1. saml 구성 리소스를 가져옵니다:

    tctl get --with-secrets saml/mysaml > saml.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.

  2. saml.yaml을 편집하고 attributes_to_roles 섹션에 myrole을 추가합니다.

    이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

    여기에 예시가 있습니다:

      attributes_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - myrole

  3. 변경 사항을 적용합니다:

    tctl create -f saml.yaml

  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  1. oidc 구성 리소스를 가져옵니다:

    tctl get oidc/myoidc --with-secrets > oidc.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.

  2. oidc.yaml을 편집하고 claims_to_roles 섹션에 myrole을 추가합니다.

    이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

    여기에 예시가 있습니다:

      claims_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - myrole

  3. 변경 사항을 적용합니다:

    tctl create -f oidc.yaml

  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

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

이 상황에서 반환된 오류와 경고는 다음과 같은 형식을 가진 메시지를 특징으로 합니다:

잠금 대상 사용자:"foo@example.com"이 적용됩니다: 의심스러운 활동.
Note

--message 매개변수로 사용자에게 반환되는 메시지를 조정할 수 있습니다:

tctl lock --user=foo@example.com --message="내일 다시 오세요." --ttl=24h

--ttl 또는 --expires를 지정하지 않으면 생성된 잠금은 명시적으로 tctl rm로 제거될 때까지 유지됩니다. 모든 지원 매개변수 목록은 tctl lock --help를 참조하세요.

내부적으로, tctl lock은 리소스를 생성합니다:

kind: lock
version: v2
metadata:
  name: dc7cee9d-fe5e-4534-a90d-db770f0234a1
spec:
  target:
    user: foo@example.com
  message: "의심스러운 활동."
  expires: "2021-08-14T22:27:00Z"  # RFC3339 형식

kind: lock 리소스는 또한 일반적으로 tctl create를 사용하여 생성 및 업데이트할 수 있습니다. 자세한 내용은 Admin Guide를 참조하세요.

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

모든 활성 잠금을 나열하려면 tctl get 명령어를 사용하세요:

tctl get locks

잠금 리소스를 삭제하세요:

tctl rm locks/24679348-baff-4987-a2cd-e820ab7f9d2b
잠금 "24679348-baff-4987-a2cd-e820ab7f9d2b"이 삭제되었습니다.

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

다음 단계: 잠금 모드

Teleport 노드 또는 프록시 서비스가 로컬 잠금 뷰를 백엔드와 제대로 동기화할 수 없는 경우, 마지막으로 알려진 잠금을 사용할 것인지에 대한 결정을 내릴 수 있습니다. 이 결정 전략은 두 가지 모드 중 하나로 인코딩됩니다:

  • strict 모드는 잠금이 최신 상태로 보장되지 않을 때 모든 상호 작용을 종료합니다.
  • best_effort 모드는 가장 최근의 잠금을 계속 사용할 수 있습니다.

클러스터 전체 모드는 기본적으로 best_effort로 설정됩니다. API 또는 CLI를 통해 cluster_auth_preference 리소스 또는 정적 구성 파일을 사용하여 기본 잠금 모드를 설정할 수 있습니다:

cap.yaml라는 YAML 파일을 생성하거나 tctl get cap를 사용하여 기존 파일을 가져옵니다.

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

리소스를 생성합니다:

tctl create -f cap.yaml
클러스터 인증 기본 설정이 업데이트되었습니다.

인증 서버에서 /etc/teleport.yaml를 편집하세요:

auth_service:
    authentication:
        locking_mode: best_effort

변경 사항을 적용하려면 인증 서버를 다시 시작하세요.

클러스터 전체 모드는 기본적으로 best_effort로 설정됩니다. API 또는 CLI를 통해 cluster_auth_preference 리소스를 사용하여 기본 잠금 모드를 설정할 수 있습니다:

cap.yaml라는 YAML 파일을 생성하거나 tctl get cap를 사용하여 기존 파일을 가져옵니다.

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

리소스를 생성합니다:

tctl create -f cap.yaml
클러스터 인증 기본 설정이 업데이트되었습니다.

특정 역할의 잠금 모드를 구성하는 것도 가능합니다:

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

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

여러 잠금 모드가 상충될 가능성이 있을 때(클러스터 전체 기본값과 개별 역할 설정) strict가 한 번만 발생해도 로컬 잠금 뷰가 엄격하게 평가됩니다.

Teleport 원문 보기