📣 DevOps 전문 기업 인포그랩이 만든 Teleport 공식 문서 한국어 페이지입니다.
이 페이지는 Teleport 공식 문서를 한국어로 번역해 제공합니다.
Infograb logo
Microsoft Teams를 통한 접근 요청

이 가이드는 Microsoft Teams를 설정하여 Teleport로부터 접근 요청 메시지를 수신하는 방법을 설명합니다. Teleport의 Microsoft Teams 통합은 개인에게 접근 요청을 알립니다. 사용자는 메시지 링크를 따라 접근 요청을 승인 및 거부할 수 있어 생산성을 저하시키지 않으면서 보안 모범 사례를 구현하기 쉽게 만듭니다.

필수 조건

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하기 무료 체험판을 이용해 보세요.

  • tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 16.2.0.

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

권장 사항: 짧은 수명의 Teleport 자격 증명을 플러그인에 제공하기 위해 머신 ID를 구성하십시오. 이 가이드를 따르기 전에 tbot 바이너리를 귀하의 인프라에서 실행하기 위해 머신 ID 배포 가이드를 따르십시오.

  • Microsoft Teams 라이센스 (Microsoft 365 Business).
  • Microsoft Teams 라이센스를 보유한 조직/디렉토리의 Azure 콘솔 접근.
  • 동일한 디렉토리에 Azure 리소스 그룹. 이곳은 Microsoft Teams 접근 요청 플러그인을 위한 리소스를 호스팅합니다. 이 리소스 그룹에서 Azure Bot Services를 생성 및 편집할 수 있는 충분한 권한이 있어야 합니다.
  • 플러그인에 대한 권한을 부여할 Azure Active Directory의 Global Admin 권한을 가진 사람.
  • Microsoft Teams 앱 설치 요청을 승인할 수 있는 Teams administrator 역할을 가진 사람.
  • Teleport Microsoft Teams 플러그인을 실행할 Azure 가상 머신 또는 Kubernetes 클러스터.

당신의 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단계/9. RBAC 리소스 정의

Microsoft Teams 플러그인을 설정하기 전에 Teleport 클러스터에서 역할 접근 요청을 활성화해야 합니다.

For the purpose of this guide, we will define an editor-requester role, which
can request the built-in editor role, and an editor-reviewer role that can
review requests for the editor role.

editor-request-rbac.yaml라는 파일을 생성하고 다음 내용을 추가하세요:

kind: role  
version: v5  
metadata:  
  name: editor-reviewer  
spec:  
  allow:  
    review_requests:  
      roles: ['editor']  
---  
kind: role  
version: v5  
metadata:  
  name: editor-requester  
spec:  
  allow:  
    request:  
      roles: ['editor']  
      thresholds:  
        - approve: 1  
          deny: 1

정의한 역할을 생성하세요:

tctl create -f editor-request-rbac.yaml
role 'editor-reviewer' has been created  role 'editor-requester' has been created

editor-requester 역할을 가진 사용자들로부터 요청을 검토할 수 있도록
editor-reviewer 역할을 자신의 계정에 할당하세요.

editor-reviewer 역할을 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?},editor-reviewer"

  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 섹션에 editor-reviewer을 추가합니다.

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

    여기에 예시가 있습니다:

      teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - editor-reviewer

  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 섹션에 editor-reviewer을 추가합니다.

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

    여기에 예시가 있습니다:

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

  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 섹션에 editor-reviewer을 추가합니다.

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

    여기에 예시가 있습니다:

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

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

    tctl create -f oidc.yaml

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

editor-requester 역할을 가진 사용자 myuser를 생성하세요. 이 사용자는
editor 역할을 요청하지 않는 한 클러스터 구성을 편집할 수 없습니다:

tctl users add myuser --roles=editor-requester

tctl은 터미널에 초대 URL을 출력할 것입니다. URL을 방문하고
myuser로 처음 로그인하여 Teleport 클러스터에 대해 설정된 자격 증명을 등록하세요.

이 가이드의 후반부에서 myuser가 editor 역할을 요청할 것이며,
이를 통해 요청을 검토할 수 있습니다.

2단계/9. Teleport Microsoft Teams 플러그인 설치

작업 공간에 Microsoft Teams 플러그인을 설치합니다. Kubernetes에 플러그인을 배포하는 경우, 이 가이드에서 나중에 업로드할 애플리케이션 아카이브를 생성하기 위해 로컬에 플러그인 설치가 여전히 필요합니다.

액세스 요청 플러그인은 amd64 및 arm64 Linux 이진 파일로 다운로드할 수 있습니다. ARCH를 필요로 하는 버전으로 바꿔주세요.

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

이진 파일이 설치되었는지 확인하세요:

teleport-msteams version
teleport-msteams v16.2.0 git:teleport-msteams-v16.2.0-fffffffff go1.22
docker pull public.ecr.aws/gravitational/teleport-plugin-msteams:16.2.0

다음 명령을 실행하여 플러그인이 설치되었는지 확인하세요:

docker run public.ecr.aws/gravitational/teleport-plugin-msteams:16.2.0 version
teleport-msteams v16.2.0 git:teleport-msteams-v16.2.0-api/14.0.0-gd1e081e 1.22

사용 가능한 태그 목록은 Amazon ECR Public Gallery를 방문하세요.

소스에서 설치하려면 git 및 go가 설치되어 있어야 합니다. Go가 설치되어 있지 않다면, Go 다운로드 페이지를 방문하세요.

git clone https://github.com/gravitational/teleport -b branch/v16
cd teleport/integrations/access/msteams
git checkout 16.2.0
make

teleport-msteams 이진 파일을 PATH로 이동하세요.

이진 파일이 설치되었는지 확인하세요:

teleport-msteams version
teleport-msteams v16.2.0 git:teleport-msteams-v16.2.0-fffffffff go1.22

Helm이 Teleport Helm 저장소에 호스팅된 차트를 설치할 수 있도록 허용하세요:

helm repo add teleport https://charts.releases.teleport.dev

원격 저장소에서 차트의 캐시를 업데이트하세요:

helm repo update

3단계/9. 플러그인을 위한 사용자 및 역할 생성

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

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

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

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

    여기에 예시가 있습니다:

      teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - access-plugin-impersonator

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

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

    여기에 예시가 있습니다:

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

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

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

    여기에 예시가 있습니다:

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

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

    tctl create -f oidc.yaml

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

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

4단계/9. 접근 플러그인 ID 내보내기

플러그인에 Teleport ID 파일에 접근하도록 허용합니다. 전시 배포의 경우 tctl을 사용하여 장기 키를 생성할 수 있지만, 우리는 기계 ID를 사용하는 것을 추천합니다.

tbot을 구성하여 the plugin에 필요한 자격증명을 생성하는 출력을 만듭니다. the plugin가 Teleport API에 접근할 것이므로, 올바른 출력 유형은 identity입니다.

이 가이드에서는 directory 대상을 사용합니다. 이를 통해 자격증명이 디스크의 지정된 디렉토리에 기록됩니다. 이 디렉토리는 tbot이 실행되는 리눅스 사용자가 쓸 수 있고, the plugin가 실행될 리눅스 사용자가 읽을 수 있어야 합니다.

tbot 구성을 수정하여 identity 출력을 추가하세요.

리눅스 서버에서 tbot을 실행하는 경우, /opt/machine-id 디렉토리에 자격증명 파일을 쓰기 위해 directory 출력을 사용하세요:

outputs:
- type: identity
  destination:
    type: directory
    # 이 가이드에서는 /opt/machine-id를 목적지 디렉토리로 사용합니다.
    # 필요에 따라 사용자 정의할 수 있습니다. 여러 출력은 동일한
    # 대상을 공유할 수 없습니다.
    path: /opt/machine-id

Kubernetes에서 tbot을 실행하는 경우, 대신 Kubernetes 비밀에 자격증명 파일을 기록하세요:

outputs:
  - type: identity
    destination:
      type: kubernetes_secret
      name: teleport-plugin-msteams-identity

tbot을 백그라운드 서비스로 운영하는 경우, 이를 재시작하세요. tbot을 원샷 모드로 실행하는 경우 지금 실행하세요.

이제 /opt/machine-id 아래에 identity 파일이 보이거나 teleport-plugin-msteams-identity이라는 이름의 Kubernetes 비밀이 보일 것입니다. 이는 the plugin가 Teleport Auth Service와 인증하는 데 필요한 개인 키와 서명된 인증서를 포함하고 있습니다.

모든 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 teleport-plugin-msteams-identity

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

5단계/9. Azure Bot 등록

Microsoft Teams용 접근 요청 플러그인은 Teleport Auth 서비스로부터 접근 요청 이벤트를 수신하고, 이를 Microsoft Teams 메시지로 포맷하여 Microsoft Teams API에 전송하여 워크스페이스에 게시합니다. 이를 위해 새 Azure Bot을 등록해야 합니다. Azure Bot은 Microsoft가 제공하는 관리 서비스로, Microsoft Teams를 포함한 다양한 채널을 통해 사용자와 상호 작용하는 봇을 개발할 수 있습니다.

새 Azure 봇 등록

https://portal.azure.com/#create/Microsoft.AzureBot 에서 새로운 봇을 생성하세요. Azure 콘솔에서 나중에 봇을 찾을 수 있도록 봇 핸들을 선택하세요 (봇 핸들은 사용자에게 표시되거나 Microsoft Teams 플러그인을 구성하는 데 사용되지 않습니다). Azure 구독, 리소스 그룹, 봇 가격 책정 계층도 편집하세요.

"Microsoft App ID" 섹션에서 "Single Tenant"와 "Create new Microsoft App ID"를 선택하세요.

봇을 Microsoft Teams에 연결

봇이 생성되면 Azure 콘솔의 리소스 페이지를 열고 "Channels" 탭으로 이동합니다. "Microsoft Teams"를 클릭하고 Microsoft Teams 채널을 추가하세요.

결과는 다음과 같아야 합니다:

Microsoft App에 대한 정보 얻기

봇의 "Configuration" 탭에서 "Microsoft App ID"와 "App Tenant ID"의 값을 복사하여 안전한 곳에 보관합니다. 이 두 UUID는 플러그인 구성에서 사용됩니다.

"Microsoft App ID" 옆의 "Manage" 링크를 클릭하세요. 그러면 앱 관리 뷰가 열립니다.

그런 다음 "Certificates & Secrets" 섹션으로 가서 "New client secret"을 생성하세요. 새로 생성된 비밀을 복사하기 위해 "Copy" 아이콘을 사용하고 이전에 복구한 App ID 및 Tenant ID와 함께 보관하세요.

클라이언트 비밀은 플러그인이 사용자를 검색하고 메시지를 게시할 때 봇의 앱으로 인증하는 데 사용됩니다.

앱에서 사용하는 권한 지정

여전히 앱 관리 뷰에서 ("Configuration", 그 후 Microsoft App ID 관리에서), "API permissions" 탭으로 가세요.

다음 Microsoft Graph 애플리케이션 권한을 추가하세요:

권한 이름이유
AppCatalog.Read.AllTeams 앱을 나열하고 앱이 설치되어 있는지 확인하는 데 사용됩니다.
User.Read.All알림 수신자를 얻는 데 사용됩니다.
TeamsAppInstallation.ReadWriteSelfForUser.AllTeams 앱과 이전에 상호 작용하지 않은 사용자와의 통신을 시작하는 데 사용됩니다.
TeamsAppInstallation.ReadWriteSelfForTeam.All팀에 앱이 설치되어 있는지 확인하는 데 사용됩니다.

이 시점에서 앱은 필요한 권한을 선언했지만, 이들 권한은 아직 부여되지 않았습니다.

당신이 관리자라면 "<directory name>\에 대해 관리자 동의 부여"를 클릭하세요. 관리자가 아닌 경우, 권한을 부여할 관리 사용자에게 연락하세요.

권한이 승인되면 페이지를 새로 고치고 승인 상태를 확인하세요. 결과는 다음과 같아야 합니다:

6단계/9. Teleport Microsoft Teams 플러그인 구성

이 시점에서 Teleport Microsoft Teams 플러그인은 Teleport 클러스터 및 Azure API와 통신하는 데 필요한 자격 증명을 보유하지만, 앱은 아직 Microsoft Teams에 설치되지 않았습니다.

이 단계에서는 Microsoft Teams 플러그인을 Azure 자격 증명을 사용하도록 구성하고 Microsoft Teams 앱 패키지를 생성하여 Microsoft Teams 앱을 설치하는 데 사용할 것입니다. 또한 플러그인이 접근 요청 업데이트를 수신할 때 올바른 Microsoft Teams 사용자에게 알리도록 구성합니다.

구성 파일 및 자산 생성

플러그인을 위한 구성 파일을 생성합니다. 지침은 플러그인을 가상 머신에서 배포하는지 Kubernetes에서 배포하는지에 따라 다릅니다:

Teleport Microsoft Teams 플러그인은 TOML 형식의 구성 파일을 사용합니다. configure 하위 명령은 TOML 구성 파일과 Teams 앱을 조직 카탈로그에 추가하는 데 사용될 app.zip 파일을 포함하는 디렉터리 /var/lib/teleport/plugins/msteams/assets를 생성합니다.

가상 머신에서 다음 명령을 실행하세요:

export AZURE_APPID="your-appid"
export AZURE_TENANTID="your-tenantid"
export AZURE_APPSECRET="your-appsecret"
teleport-msteams configure /var/lib/teleport/plugins/msteams/assets --appID "$AZURE_APPID" --tenantID "$AZURE_TENANTID" --appSecret "$AZURE_APPSECRET"

이 명령은 다음과 같은 구성 파일을 생성합니다:

(!examples/resources/plugins/teleport-msteams.toml!)

/var/lib/teleport/plugins/msteams/assets/app.zip 파일을 로컬 컴퓨터로 복사하세요. 나중에 Microsoft Teams에 업로드해야 합니다.

Microsoft Teams 플러그인을 실행할 호스트에서 /var/lib/teleport/plugins/msteams/assets/teleport-msteams.toml 파일을 /etc/teleport-msteams.toml로 이동하세요. 그러면 /etc/에 있는 복사를 편집할 수 있습니다.

로컬 컴퓨터에서 다음 명령을 실행하세요:

export AZURE_APPID="your-appid"
export AZURE_TENANTID="your-tenantid"
export AZURE_APPSECRET="your-appsecret"
teleport-msteams configure /var/lib/teleport/plugins/msteams/assets --appID "$AZURE_APPID" --tenantID "$AZURE_TENANTID" --appSecret "$AZURE_APPSECRET"

이 명령은 /var/lib/teleport/plugins/msteams/assets/app.zip에 애플리케이션 아카이브를 생성합니다. 나중에 이 아카이브를 Microsoft Teams에 업로드해야 합니다.

작업 공간에서 다음과 같은 내용을 가진 teleport-msteams-helm.yaml이라는 파일을 만드세요:

(!examples/resources/plugins/teleport-msteams-helm.yaml!)

다음 섹션에서 이 파일을 편집합니다.

설정 명령

configure 명령은 아이템포텐트(idempotent)가 아닙니다. 매 실행마다 새로운 Microsoft Teams 애플리케이션 UUID를 생성합니다. 서로 다른 실행에서 생성된 app.zip과 TOML 구성을 사용할 수 없습니다.

구성 파일 편집

아래 지침에 따라 구성 파일을 편집합니다.

[teleport]

Microsoft Teams 플러그인은 이 섹션을 사용하여 Teleport 클러스터에 연결합니다.

addr: Teleport Proxy Service 또는 Teleport Enterprise Cloud 테넌트의 호스트 이름과 HTTPS 포트를 포함하세요 (예: teleport.example.com:443 또는 mytenant.teleport.sh:443).

identity: 이전에 내보낸 식별자 파일의 경로를 입력하세요.

client_key, client_crt, root_cas: 이 구성에서는 사용하지 않으므로 주석 처리하세요.

address: Teleport Proxy Service 또는 Teleport Enterprise Cloud 테넌트의 호스트 이름과 HTTPS 포트를 포함하세요 (예: teleport.example.com:443 또는 mytenant.teleport.sh:443).

identitySecretName: 이전에 생성한 Kubernetes 비밀의 이름으로 identitySecretName 필드를 입력하세요.

identitySecretPath: Kubernetes 비밀 내의 식별자 파일 경로로 identitySecretPath 필드를 입력하세요. 위의 지침을 따랐다면, 이는 identity가 될 것입니다.

신뢰할 수 있는 링크를 통해 tbot 바이너리를 사용하여 플러그인에 자격 증명을 제공하는 경우,
identity의 값이 구성한 tbot이 생성하도록 설정한 정체성 파일의 경로와 동일한지 확인하세요.
/opt/machine-id/identity.

플러그인이 주기적으로 정체성 파일을 다시 로드하도록 구성하여,
만료된 자격 증명으로 Teleport Auth Service에 연결을 시도하지 않도록 합니다.

구성의 teleport 섹션에 다음을 추가하세요:

refresh_identity = true

[msapi]/msTeams

app_id, app_secret, tenant_id 및 teams_app_id 필드가 이 가이드에서 이전에 얻은 올바른 정보로 채워져 있는지 확인하세요.

appID, tenantID, teamsAppID 필드가 이 가이드에서 이전에 얻은 올바른 정보로 채워져 있는지 확인하세요.

[role_to_recipients]

role_to_recipients 맵 (roleToRecipients는 Helm 사용자를 위해)을 사용하여 Microsoft Teams 플러그인이 특정 역할에 대한 접근 요청이 있을 때 알릴 사용자 및 채널을 구성합니다. Microsoft Teams 플러그인이 Auth 서비스로부터 접근 요청을 수신하면 요청된 역할을 검색하여 알릴 Microsoft Teams 사용자 및 채널을 식별합니다.

다음은 role_to_recipients 맵의 예입니다:

[role_to_recipients]
"*" = "alice@example.com"
"dev" = ["alice@example.com", "bob@example.com"]
"dba" = "https://teams.microsoft.com/l/channel/19%3somerandomid%40thread.tacv2/ChannelName?groupId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&tenantId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

다음은 role_to_recipients 맵의 예입니다:

roleToRecipients:
  "*": "alice@example.com"
  "dev": ["alice@example.com", "bob@example.com"]
  "dba": "https://teams.microsoft.com/l/channel/19%3somerandomid%40thread.tacv2/ChannelName?groupId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&tenantId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

role_to_recipients 맵에서 각 키는 Teleport 역할의 이름입니다. 각 값은 알릴 Teams 사용자(들)를 구성합니다. 값은 단일 문자열이나 문자열 배열일 수 있습니다. 각 문자열은 Microsoft Teams 사용자의 이메일 주소나 채널 URL이어야 합니다.

채널의 URL은 채널을 열고 "채널에 대한 링크 가져오기" 버튼을 클릭하여 찾을 수 있습니다:

role_to_recipients 맵에는 "*"에 대한 항목도 포함되어야 하며, 플러그인은 특정 역할 이름과 일치하는 항목이 없는 경우 이 항목을 조회합니다. 위의 예에서 dev 및 dba 외의 역할 요청은 alice@example.com에게 알릴 것입니다.

사용자는 접근 요청을 생성할 때 검토자를 제안할 수 있습니다. 예:

tsh request create --roles=dbadmin --reviewers=alice@example.com,ivan@example.com

접근 요청에 제안된 검토자가 포함되어 있다면, Microsoft Teams 플러그인은 이를 알릴 채널 목록에 추가합니다. 제안된 검토자가 이메일 주소인 경우 플러그인은 해당 주소에 대한 직접 메시지 채널을 조회하고 그 채널에 메시지를 게시할 것입니다.

Microsoft Teams 플러그인을 통해 사용자가 editor 역할을 요청할 때 알림을 받도록 구성하기 위해 다음을 role_to_recipients 구성에 추가하세요 (여기서 TELEPORT_USERNAME을 이전에 editor-reviewer 역할을 부여한 사용자의 이메일로 바꾸세요):

[role_to_recipients]
"*" = "TELEPORT_USERNAME"
"editor" = "TELEPORT_USERNAME"

roleToRecipients:
  "*": "TELEPORT_USERNAME"
  "editor": "TELEPORT_USERNAME"

최종 구성 파일은 다음과 유사해야 합니다:

(!examples/resources/plugins/teleport-msteams.toml!)

(!examples/resources/plugins/teleport-msteams-helm.yaml!)

7단계/9. Teams 앱 추가 및 구성

Teams 앱 업로드

Microsoft Teams를 열고 "Apps", "Manage your apps"로 이동한 후, 추가 선택 메뉴에서 "Upload an App"을 선택합니다.

Teams 앱 업로드

Teams 관리자인 경우, "Upload an app to your org's app catalog"를 선택하세요. 이렇게 하면 승인 단계를 건너뛸 수 있습니다. Teams 관리자가 아닌 경우, "Submit an app to your org"을 선택하세요.

이전에 생성한 app.zip 파일을 업로드하세요.

Teams 앱 승인

Teams 관리자가 아니고 "Submit an app to your org" 을 선택한 경우, Teams 관리자에게 승인을 요청해야 합니다.

그들은 Teams 관리자 대시보드에 접속하여 "TeleBot"을 검색하고 선택한 후 "Allow"를 선택할 수 있습니다.

Teams 앱을 팀에 추가

앱이 승인되면 "귀하의 조직을 위한 앱" 섹션에 나타나야 합니다. 새로 업로드한 앱을 팀에 추가하세요. 앱을 열고 "팀에 추가"를 클릭한 후 팀의 "일반" 채널을 선택하고 "봇 설정"을 클릭하세요.

Teams 앱 추가

참고: 앱이 팀에 추가되면 모든 채널에 게시할 수 있습니다.

8단계/9. Teams 앱 테스트

Teleport가 실행 중이고 Teams 앱을 생성하여 플러그인을 구성한 후, 플러그인을 실행하고 워크플로를 테스트할 수 있습니다.

Microsoft Teams 연결성 테스트

검증 모드에서 플러그인을 시작하세요:

teleport-msteams validate <email of your teams account>

모든 것이 잘 작동하면 로그 출력은 다음과 같아야 합니다:

teleport-msteams v16.2.0 go1.22

 - 애플리케이션 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 상태 확인 중...
 - 팀 앱 스토어에서 애플리케이션 발견됨 (내부 ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
 - 사용자 xxxxxx@xxxxxxxxx.xxx 발견됨: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 - 사용자에 대한 애플리케이션 설치 ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 - 사용자 채팅 ID: 19:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx@unq.gbl.spaces
 - 채팅 웹 URL: https://teams.microsoft.com/l/chat/19%3Axxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%40unq.gbl.spaces/0?tenantId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 - 사용자에게 요청 전송 중...
 - 메시지 발송됨, ID: XXXXXXXXXXXXX

Microsoft Teams를 확인하세요!

플러그인은 종료되어야 하며 Microsoft Teams를 통해 두 개의 메시지를 수신해야 합니다.

봇 메시지 검증

MS Teams 플러그인 시작

MS Teams 플러그인을 구성하고 검증한 후, 플러그인을 실행하고 워크플로를 테스트할 수 있습니다.

다음 명령을 실행하여 Teleport MS Teams 플러그인을 시작합니다. -d 플래그는 플러그인이 MS Teams 및 Teleport 클러스터에 연결할 수 있도록 디버그 정보를 제공합니다:

teleport-msteams start -d
DEBU   DEBUG logging enabled msteams/main.go:120INFO   Teleport MS Teams 플러그인 시작 16.2.0: msteams/app.go:74DEBU   teleport.example.com:443/webapi/find 요청 시도 webclient/webclient.go:129DEBU   Teleport 서버 버전 확인 msteams/app.go:242INFO   조직 앱 스토어에서 발견된 MS Teams 앱 id:292e2881-38ab-7777-8aa7-cefed1404a63 이름:TeleBot msteams/app.go:179INFO   수신자 데이터 미리 로드 중... msteams/app.go:185INFO   수신자 발견, 채팅 발견 채팅 ID:19:a8c06deb-aa2b-4db5-9c78-96e48f625aef_a36aec2e-f11c-4219-b79a-19UUUU57de70@unq.gbl.spaces 종류:사용자 수신자:jeff@example.com msteams/app.go:195INFO   수신자 데이터 미리 로드 및 캐시됨. msteams/app.go:198DEBU   관찰자 연결됨 watcherjob/watcherjob.go:121INFO   플러그인이 준비되었습니다 msteams/app.go:227

플러그인 실행:

docker run -v <path-to-config>:/etc/teleport-msteams.toml public.ecr.aws/gravitational/teleport-plugin-msteams:16.2.0 start

플러그인 설치:

helm upgrade --install teleport-plugin-msteams teleport/teleport-plugin-msteams --values teleport-msteams-helm.yaml

플러그인의 로그를 검사하려면 다음 명령을 사용하세요:

kubectl logs deploy/teleport-plugin-msteams

디버그 로그를 활성화하려면 teleport-msteams-helm.yaml에서 log.severity를 DEBUG로 설정하고 위의 helm upgrade ... 명령을 다시 실행하세요. 그런 다음 다음 명령으로 플러그인을 다시 시작할 수 있습니다:

kubectl rollout restart deployment teleport-plugin-msteams

접근 요청 만들기

접근 요청을 만들고 다음 단계를 통해 플러그인이 예상대로 작동하는지 확인하세요.

Teleport 관리자는 tctl을 사용하여 다른 사용자의 액세스 요청을 생성할 수 있습니다:

tctl request create myuser --roles=editor

사용자는 tsh를 사용하여 액세스 요청을 생성하고 승인된 역할로 로그인할 수 있습니다:

tsh request create --roles=editor
요청 승인 중... (id: 8f77d2d1-2bbf-4031-a300-58926237a807)

사용자는 "액세스 요청" 탭을 방문하고 "새 요청"을 클릭하여 웹 UI를 사용하여 액세스를 요청할 수 있습니다:

이전에 구성한 사용자는 "TeleBot"으로부터 Microsoft Teams에서 직접 메시지를 수신하여 Teleport 웹 UI의 링크를 방문하고 요청을 승인하거나 거부할 수 있습니다.

요청 해결

접근 요청 메시지를 수신하면 링크를 클릭하여 Teleport를 방문하고 요청을 승인하거나 거부하세요:

명령줄에서도 접근 요청을 검토할 수 있습니다:

REQUEST_ID를 요청의 ID로 교체하세요
tctl request approve REQUEST_ID
tctl request deny REQUEST_ID
REQUEST_ID를 요청의 ID로 교체하세요
tsh request review --approve REQUEST_ID
tsh request review --deny REQUEST_ID

요청이 해결되면 Microsoft Teams 봇은 접근 요청 메시지를 업데이트하여 새로운 상태를 반영합니다.

접근 요청 감사하기

Microsoft Teams 플러그인이 채널에 접근 요청 알림을 게시하면, 해당 채널에 접근할 수 있는 모든 사용자가 알림을 보고 링크를 따를 수 있습니다. 사용자는 접근 요청을 검토하기 위해 Teleport 역할에 따라 권한이 부여되어야 하지만, 올바른 사용자가 올바른 요청을 검토하는지 확인하기 위해 Teleport 감사 로그를 여전히 확인해야 합니다.

접근 요청 검토를 감사할 때, Teleport 웹 UI에서 Access Request Reviewed 유형의 이벤트를 확인하세요.

9단계/9. systemd 설정

이 섹션은 Teleport Microsoft Teams 플러그인을 가상 머신에서 실행하는 경우에만 관련이 있습니다.

생산 환경에서는 systemd와 같은 초기 시스템을 통해 Teleport 플러그인 데몬을 시작하는 것을 권장합니다. 다음은 systemd를 위한 권장 Teleport 플러그인 서비스 유닛 파일입니다:

(!examples/systemd/plugins/teleport-msteams.service!)

이를 /usr/lib/systemd/system/ 또는 Systemd에서 지원하는 다른 유닛 파일 로드 경로로 teleport-msteams.service로 저장하세요.

플러그인을 활성화하고 시작하세요:

sudo systemctl enable teleport-msteams
sudo systemctl start teleport-msteams

다음 단계

Teleport 원문 보기