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

이중 승인

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

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

이 가이드에서는 Teleport의 Just-in-Time Access Requests를 설정하여
특권 역할 dbadmin 에 대해 두 팀원의 승인을 요구합니다.

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

이중 승인은 Teleport Enterprise가 필요합니다.

전제 조건

Mattermost 설치됨.

실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하여 무료 평가판을 이용해 보십시오.
tctl 관리자 도구 및 tsh 클라이언트 도구.

tctl 및 tsh 다운로드에 대한 지침은 설치 를 방문하십시오.

Docker로 Mattermost를 로컬에서 실행하기

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

연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  17.0.0-dev
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1/2단계. Teleport 봇 설정

Mattermost 내에서 봇 생성

"System Console -> Integrations"에서 봇 계정 생성을 활성화합니다.

Enable Bot Account Creation 를 활성화합니다.

팀 설정으로 돌아가서 "Integrations -> Bot Accounts"로 이동합니다. "Add Bot Account"를 클릭합니다.

새 계정에서 "Post All" 권한을 추가합니다.

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

플러그인을 위한 RBAC 설정

Teleport의 접근 요청 플러그인은 접근 요청을 나열하고 읽을 수 있는 권한을 가진 사용자로서 Teleport 클러스터에 인증합니다. 이렇게 하면 플러그인이 Teleport Auth Service에서 접근 요청을 검색하여 리뷰어에게 제공합니다.

다음 내용을 access-plugin.yaml 이라는 파일에 추가하여 access-plugin 이라는 사용자와 역할을 정의하십시오:

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

모든 Teleport 사용자와 마찬가지로, Teleport Auth 서비스는 access-plugin 사용자를 짧은 수명의 TLS 자격 증명을 발급하여 인증합니다. 이 경우, access-plugin 역할과 사용자를 임시로 사용자화하여 자격 증명을 수동으로 요청해야 합니다.

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

사용자에게 access-plugin 에 대한 임시 사용자화 권한을 부여하려면, 다음 YAML 문서를 access-plugin-impersonator.yaml 이라는 파일에 붙여넣어 access-plugin-impersonator 라는 역할을 정의하십시오:

kind: role
version: v7
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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

텍스트 편집기에서 github 인증 커넥터를 엽니다:
```
tctl edit github/github
```
github 커넥터를 수정하여 teams_to_roles 섹션에 access-plugin-impersonator 을 추가합니다.

이 역할에 매핑해야 하는 팀은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 팀은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 팀이어야 합니다.

예시는 다음과 같습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - access-plugin-impersonator
```
파일을 편집하고 저장하여 변경 사항을 적용합니다.
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

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

액세스 플러그인 아이덴티티 파일 내보내기

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

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

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

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

아이덴티티 파일인 identity 는 TLS 및 SSH 자격 증명을 모두 포함합니다. plugin는 SSH 자격 증명을 사용하여 Proxy Service에 연결하고, Proxy Service는 Auth Service로의 역 터널 연결을 설정합니다. plugin는 이 역 터널과 TLS 자격 증명을 사용하여 Auth Service의 gRPC 엔드포인트에 연결합니다.

기본적으로 tctl auth sign 은 상대적으로 짧은 수명의 인증서를 생성합니다. 운영 배포를 위해, 우리는 Machine ID를 사용하여 프로그램적으로 인증서를 발급하고 갱신할 것을 제안합니다. 이에 대한 자세한 내용은 Machine ID 시작 가이드를 참조하십시오.

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

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

리눅스 서버에서 plugin를 실행 중이라면, plugin의 인증서 파일을 보관할 데이터 디렉토리를 생성하십시오:

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

Kubernetes에서 plugin를 실행 중이라면, Teleport 아이덴티티 파일을 포함하는 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-v13.3.7-linux-ARCH-bin.tar.gz
tar -xzf teleport-access-mattermost-v13.3.7-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/v17
cd teleport/integrations/access/mattermost
git checkout 13.3.7
make

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

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

# Mattermost 구성 TOML 파일 예시

[teleport]
auth_server = "myinstance.teleport.sh:443"                   # Teleport Cloud 프록시 HTTPS 주소
identity = "/var/lib/teleport/plugins/mattermost/identity"   # Identity 파일 경로
refresh_identity = true                                      # Identity 파일을 주기적으로 갱신합니다.

[mattermost]
url = "https://mattermost.example.com" # Mattermost 서버 URL
team = "team-name"                     # 채널이 속한 Mattermost 팀 이름
channel = "channel-name"               # 요청을 게시할 Mattermost 채널 이름
token = "api-token"                    # Mattermost 봇 OAuth 토큰
secret = "signing-secret-value"        # Mattermost API 서명 비밀값

[http]
public_addr = "example.com" # 외부에서 콜백 서버에 접근 가능한 URL, 예: [https://]teleport-mattermost.example.com
# listen_addr = ":8081" # 콜백 서버가 수신하는 네트워크 주소 형식 [addr]:port, 예: 0.0.0.0:443
https_key_file = "/var/lib/teleport/plugins/mattermost/server.key"  # TLS 개인 키
https_cert_file = "/var/lib/teleport/plugins/mattermost/server.crt" # TLS 인증서

[log]
output = "stderr" # 로거 출력. "stdout", "stderr" 또는 "/var/lib/teleport/mattermost.log" 중 하나를 선택할 수 있습니다.
severity = "INFO" # 로거 심각도. "INFO", "ERROR", "DEBUG" 또는 "WARN" 중 하나를 선택할 수 있습니다.

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

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

역할에 대한 이중 승인 요구

앨리스와 이반은 검토자입니다. 그들은 dbadmin 역할을 맡기 위한 요청을 승인할 수 있습니다. 밥은 DevOps 엔지니어이며 두 명의 reviewer 역할을 가진 회원이 요청을 승인하면 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"

아래의 명령은 로컬 사용자 밥, 앨리스 및 이반을 생성합니다.

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

접근 요청 생성

밥은 자신에게 dbadmin 역할이 할당되지 않았지만, 이를 위한 접근 요청을 생성할 수 있습니다.

밥은 웹 UI 또는 CLI에서 dbadmin 역할에 대한 접근 요청을 생성할 수 있습니다:

설정해야 합니다. $ tsh request create --roles=dbadmin--reviewers=alice@example.com,ivan@example.com ```</TabItem></Tabs>
챗봇은 앨리스와 이반 모두에게 알림을 보냅니다:
![Mattermost-Request](../../../../img/access-controls/dual-authz/mattermost-5-request.png)
앨리스와 이반은 웹 UI 또는 CLI를 사용하여 요청을 검토하고 승인할 수 있습니다:
<Tabs><TabItem label="Web UI">![Teleport-Approve](../../../../img/access-controls/dual-authz/teleport-6-ivan-approve.png)</TabItem>
<TabItem label="CLI">```codetsh request list

ID                                   User             Roles   Created (UTC)       Status
------------------------------------ ---------------  ------- ------------------- -------
9c721e54-b049-4ef8-a7f6-c777aa066764 bob@example.com  dbadmin 03 Apr 21 03:58 UTC PENDING

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

밥이 CLI를 사용하여 요청을 생성했다면, 요청이 승인되면 역할을 맡게 됩니다. 밥은 웹 UI를 사용하여 승인된 접근 요청 역할도 맡을 수 있습니다:

문제 해결

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

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

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

문제를 해결하려면 Auth Service에 공개 주소를 업데이트하고 Teleport를 재시작하십시오:

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

Teleport 원문 보기