세션 및 아이덴티티 잠금 | Teleport 공식 기술 문서 한국판 by 인포그랩

세션 및 아이덴티티 잠금

시스템 관리자는 손상된 사용자 또는 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 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:
```
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
```

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

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

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

github 인증 커넥터를 가져옵니다:
```
tctl get github/github --with-secrets > github.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.
github.yaml을 편집하고 teams_to_roles 섹션에 myrole을 추가합니다.

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

여기에 예시가 있습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - myrole
```
변경 사항을 적용합니다:
```
tctl create -f github.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

saml 구성 리소스를 가져옵니다:
```
tctl get --with-secrets saml/mysaml > saml.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.
saml.yaml을 편집하고 attributes_to_roles 섹션에 myrole을 추가합니다.

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

여기에 예시가 있습니다:
```
  attributes_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - myrole
```
변경 사항을 적용합니다:
```
tctl create -f saml.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

oidc 구성 리소스를 가져옵니다:
```
tctl get oidc/myoidc --with-secrets > oidc.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.
oidc.yaml을 편집하고 claims_to_roles 섹션에 myrole을 추가합니다.

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

여기에 예시가 있습니다:
```
  claims_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - myrole
```
변경 사항을 적용합니다:
```
tctl create -f oidc.yaml
```
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 원문 보기