이중 승인 | Teleport 공식 기술 문서 한국판 by 인포그랩

이중 승인

Teleport를 설정하여 몇 가지 중요한 작업을 수행하기 위해 여러 팀원의 승인을 요구할 수 있습니다.
가장 일반적인 시나리오는 다음과 같습니다:

시스템의 보안을 개선하고 성공적인 피싱 공격 하나가 시스템을 손상시키는 것을 방지합니다.
두 명의 승인된 개인의 승인을 요구하는 FedRAMP AC-3 이중 승인 제어를 충족합니다.

이번 가이드에서는 Teleport의 적시 접근 요청을 설정하여
특권 역할 dbadmin을 위해 두 팀원의 승인을 요구합니다.

아래 단계에서는 Teleport를 Mattermost와 함께 사용하는 방법을 설명합니다.
또한 다른 여러 공급자와 통합할 수 있습니다.

이중 승인은 Teleport Enterprise를 요구합니다.

전제 조건

Mattermost 설치됨.

실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하기 무료 체험판을 이용해 보세요.
tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 16.2.0.

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

Docker로 Mattermost 로컬 실행

docker run --name mattermost-preview -d --publish 8065:8065 --add-host dockerhost:127.0.0.1 mattermost/mattermost-preview

당신의 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 단계. Teleport 봇 설정

Mattermost 내에서 봇 생성

"시스템 콘솔 -> 통합"에서 봇 계정 생성을 활성화합니다.

Enable Bot Account Creation을 전환합니다.

팀 설정으로 돌아가서 "통합 -> 봇 계정"으로 이동합니다. "봇 계정 추가"를 누릅니다.

새 계정에 "모든 게시물" 권한을 추가합니다.

봇을 생성하고 액세스 토큰을 저장합니다.

플러그인을 위한 RBAC 설정

Teleport의 Access Request 플러그인은 Access Requests를 나열하고 읽을 수 있는 권한을 가진 사용자로 Teleport 클러스터에 인증합니다. 이렇게 하면 플러그인이 Teleport Auth Service에서 Access Requests를 검색하고 이를 검토자에게 제시할 수 있습니다.

access-plugin이라는 사용자 및 역할을 정의하려면 access-plugin.yaml이라는 파일에 다음 내용을 추가합니다:

kind: role
version: v5
metadata:
  name: access-plugin
spec:
  allow:
    rules:
      - resources: ['access_request']
        verbs: ['list', 'read']
      - resources: ['access_plugin_data']
        verbs: ['update']
---
kind: user
metadata:
  name: access-plugin
spec:
  roles: ['access-plugin']
version: v2

사용자와 역할을 생성합니다:

tctl create -f access-plugin.yaml

As with all Teleport users, the Teleport Auth Service authenticates the
access-plugin 사용자를 발급하는 짧은 수명의 TLS 자격 증명을 통해 인증합니다. 이 경우, 우리는 임시 사용자를 통해
access-plugin 역할 및 사용자를 가장하여 자격 증명을 수동으로 요청해야 합니다.

자체 호스팅 Teleport Enterprise 배포를 실행하고 Auth Service 호스트에서
tctl을 사용하는 경우, 이미 임시 권한이 있습니다.

access-plugin에 대한 임시 권한을 부여하려면,
access-plugin-impersonator라는 역할을 정의하며 다음 YAML 문서를
access-plugin-impersonator.yaml라는 파일에 붙여넣습니다:

kind: role
version: v5
metadata:
  name: access-plugin-impersonator
spec:
  allow:
    impersonate:
      roles:
      - access-plugin
      users:
      - access-plugin

access-plugin-impersonator 역할을 생성합니다:

tctl create -f access-plugin-impersonator.yaml

기계 ID로 플러그인에 대한 신원 파일을 제공하는 경우,
기계 ID 봇 사용자에게 access-plugin 역할을 부여하십시오. 그렇지 않으면,
access-plugin 역할 및 사용자에 대한 자격 증명을 생성하는 데 사용할 사용자에게 이 역할을 부여하십시오:

access-plugin-impersonator 역할을 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?},access-plugin-impersonator"

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 섹션에 access-plugin-impersonator을 추가합니다.

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

여기에 예시가 있습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - access-plugin-impersonator
```
변경 사항을 적용합니다:
```
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 섹션에 access-plugin-impersonator을 추가합니다.

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

여기에 예시가 있습니다:
```
  attributes_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - access-plugin-impersonator
```
변경 사항을 적용합니다:
```
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 섹션에 access-plugin-impersonator을 추가합니다.

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

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

이제 access-plugin 역할 및 사용자의 서명된 인증서를 생성할 수 있습니다.

액세스 플러그인 ID 파일 내보내기

모든 Teleport 사용자와 마찬가지로, access-plugin는 Teleport 클러스터에 연결하기 위해 서명된 자격 증명이 필요합니다. 이러한 자격 증명을 요청하기 위해 tctl auth sign 명령을 사용합니다.

다음의 tctl auth sign 명령은 access-plugin 사용자로 가장하고, 서명된 자격 증명을 생성하며, 로컬 디렉토리에 ID 파일을 작성합니다:

tctl auth sign --user=access-plugin --out=identity

plugin는 TLS를 통해 Teleport Auth Service의 gRPC 엔드포인트에 연결합니다.

ID 파일인 identity는 TLS 및 SSH 자격 증명을 포함합니다. plugin는 SSH 자격 증명을 사용하여 Proxy Service에 연결하고, 이 Proxy Service는 Auth Service에 대한 리버스 터널 연결을 설정합니다. plugin는 이 리버스 터널과 TLS 자격 증명을 사용하여 Auth Service의 gRPC 엔드포인트에 연결합니다.

기본적으로, tctl auth sign은 비교적 짧은 수명의 인증서를 생성합니다. 프로덕션 배포의 경우, Machine ID를 사용하여 플러그인에 대해 인증서를 프로그램matically Issuing과 Renew하는 것을 권장합니다. 우리의 Machine ID 시작 가이드를 참조하여 자세히 알아보세요.

기존 자격 증명보다 유효 기간이 긴 인증서를 발급할 수 없습니다. 예를 들어, 1000시간의 TTL을 가진 인증서를 발급하려면 최소한 1000시간 동안 유효한 세션으로 로그인해야 합니다. 즉, 사용자는 최소 1000시간(60000분)의 max_session_ttl을 허용하는 역할을 가지고 있어야 하며, 로그인할 때 --ttl을 지정해야 합니다:

tsh login --proxy=teleport.example.com --ttl=60060

Linux 서버에서 plugin를 실행하는 경우, plugin를 위한 인증서 파일을 보관할 데이터 디렉토리를 만드세요:

sudo mkdir -p /var/lib/teleport/api-credentials
sudo mv identity /var/lib/teleport/plugins/api-credentials

Kubernetes에서 plugin를 실행하는 경우, Teleport ID 파일을 포함하는 Kubernetes 비밀을 생성하세요:

kubectl -n teleport create secret generic --from-file=identity plugin-identity

Teleport 자격 증명이 만료되면, 다시 tctl auth sign 명령을 실행하여 갱신해야 합니다.

플러그인 구성 시 나중에 내보낸 파일을 참조합니다.

플러그인 설치

액세스 요청 플러그인은 amd64 또는 arm64 Linux 바이너리로 다운로드할 수 있습니다.
ARCH를 필요한 버전으로 교체하세요.

curl -L https://cdn.teleport.dev/teleport-access-mattermost-v16.2.0-linux-ARCH-bin.tar.gz
tar -xzf teleport-access-mattermost-v16.2.0-linux-ARCH-bin.tar.gz
cd teleport-access-mattermost
./install

소스에서 설치하려면 git와 go >= 1.22가 설치되어 있어야 합니다.

Teleport 리포지토리를 체크아웃하고 mattermost 액세스 플러그인 디렉터리로 이동합니다.
git clone https://github.com/gravitational/teleport.git -b branch/v16
cd teleport/integrations/access/mattermost
git checkout 16.2.0
make

teleport-mattermost configure > /etc/teleport-mattermost.toml

Teleport 주소, Mattermost URL 및 봇 토큰으로 구성을 업데이트합니다:

(!examples/resources/plugins/teleport-mattermost-cloud.toml!)

2/2 단계. 이중 승인 구성

이번 섹션에서는 사용자가 역할을 가정하기 위해 이중 승인을 요구하는 방법을 보여주는 예제를 사용합니다.

역할에 대한 이중 승인 요구

Alice와 Ivan은 검토자입니다. 그들은 역할 dbadmin을 가정하는 요청을 승인할 수 있습니다. Bob은 DevOps 엔지니어로,
dbadmin 역할의 요청을 승인할 경우에만 이를 가정할 수 있습니다.

다음과 같은 dbadmin, dbreviewer 및 devops 역할을 생성합니다:

kind: role
version: v5
metadata:
  name: dbreviewer
spec:
  allow:
    review_requests:
      roles: ['dbadmin']
---
kind: role
version: v5
metadata:
  name: devops
spec:
  allow:
    request:
      roles: ['dbadmin']
      thresholds:
        - approve: 2
          deny: 1
---
kind: role
version: v5
metadata:
  name: dbadmin
spec:
  allow:
    logins: ['root']
    node_labels:
      'env': 'prod'
      'type': 'db'

아래 명령어는 로컬 사용자 Bob, Alice 및 Ivan을 생성합니다.

tctl users add bob@example.com --roles=devops
tctl users add alice@example.com --roles=dbreviewer
tctl users add ivan@example.com --roles=dbreviewer

액세스 요청 생성

Bob은 역할 dbadmin이 할당되어 있지 않지만 이를 위한 액세스 요청을 생성할 수 있습니다.

Bob은 웹 UI 또는 CLI에서 dbadmin 역할에 대한 액세스 요청을 생성할 수 있습니다:

Bob은 Mattermost와 일치하는 Alice와 Ivan의 유효한 이메일을 설정해야 합니다.
tsh request create --roles=dbadmin --reviewers=alice@example.com,ivan@example.com

챗봇은 Alice와 Ivan 모두에게 알림을 보냅니다:

Alice와 Ivan은 웹 UI 또는 CLI를 사용하여 요청을 검토하고 승인할 수 있습니다:

tsh request list

ID                                   사용자            역할     생성일시 (UTC)       상태
------------------------------------ ---------------  ------- ------------------- -------
9c721e54-b049-4ef8-a7f6-c777aa066764 bob@example.com  dbadmin 21년 4월 3일 03:58 UTC 대기 중

tsh request review --approve --reason="hello" 9c721e54-b049-4ef8-a7f6-c777aa066764
검토가 성공적으로 제출되었습니다. 요청 상태: 승인됨

Bob이 CLI를 사용하여 요청을 생성한 경우, 승인이 완료되면 해당 요청을 가정합니다.
Bob은 웹 UI를 사용하여 허가된 액세스 요청 역할을 가정할 수 있습니다:

문제 해결

자체 호스팅 배포에서의 인증서 오류

서버 인증서에 주소가 누락된 경우 Teleport의 인증 서비스에서 인증서 오류가 발생할 수 있습니다:

authentication handshake failed: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

x509: certificate is valid for,*.teleport.cluster.local, teleport.cluster.local, not example.com

문제를 해결하려면 인증 서비스의 공용 주소를 업데이트하고 Teleport를 재시작합니다:

auth_service:
  public_addr: ['localhost:3025', 'example.com:3025']

Teleport 원문 보기