Infograb logo
Microsoft Teams를 통한 접근 요청

이 가이드는 Microsoft Teams를 설정하여 Teleport에서 접근 요청 메시지를 수신하는 방법을 설명합니다. Teleport의 Microsoft Teams 통합은 개인에게 접근 요청에 대한 알림을 보냅니다. 사용자는 메시지 링크를 따라 접근 요청을 승인하거나 거부할 수 있어 보안 모범 사례를 손상시키지 않으면서 생산성을 유지할 수 있습니다.

필수 조건

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하여 무료 평가판을 이용해 보십시오.

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

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

권장: 플러그인에 단기간 사용 가능한 Teleport 자격 증명을 제공하기 위해 Machine ID를 구성합니다. 이 가이드를 따르기 전에 Machine ID 배포 가이드를 따라 tbot 바이너리를 인프라에서 실행하세요.

  • Microsoft Teams 라이센스 (Microsoft 365 비즈니스).
  • Microsoft Teams 라이센스가 포함된 조직/디렉토리의 Azure 콘솔 접근 권한.
  • 동일한 디렉토리에 있는 Azure 리소스 그룹. 이곳에 Microsoft Teams 접근 요청 플러그인을 위한 리소스가 호스팅됩니다. 이 리소스 그룹에서 Azure Bot Services를 생성하고 편집할 수 있는 충분한 권한이 있어야 합니다.
  • 플러그인에 대한 권한을 부여할 Azure Active Directory의 글로벌 관리자 권한을 가진 사람.
  • Microsoft Teams 애플리케이션 설치 요청을 승인할 수 있는 Teams administrator 역할을 가진 사람.
  • Teleport Microsoft Teams 플러그인을 실행할 Azure 가상 머신 또는 Kubernetes 클러스터.

연결이 가능한지 확인하기 위해 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/9단계. RBAC 리소스 정의

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

'이 가이드를 위해, 내장된 editor 역할을 요청할 수 있는 editor-requester 역할과 editor 역할에 대한 요청을 검토할 수 있는 editor-reviewer 역할을 정의하겠습니다.

다음 내용을 포함하는 editor-request-rbac.yaml 파일을 생성하십시오:

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

정의한 역할을 생성하십시오:

tctl create -f editor-request-rbac.yaml
role 'editor-reviewer'가 생성되었습니다role 'editor-requester'가 생성되었습니다

editor-reviewer 역할을 할당하여 editor-requester 역할을 가진 사용자의 요청을 검토할 수 있도록 하십시오.

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

  1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

    tctl edit github/github
  2. github 커넥터를 수정하여 teams_to_roles 섹션에 editor-reviewer 을 추가합니다.

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

    예시는 다음과 같습니다:

      teams_to_roles:
        - organization: octocats
          team: admins
          roles:
            - access
    +       - editor-reviewer
    
  3. 파일을 편집하고 저장하여 변경 사항을 적용합니다.

  4. Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

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

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

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

tctl users add myuser --roles=editor-requester

tctl 은 터미널에 초대 URL을 출력합니다. URL을 방문하고 myuser 로 처음 로그인하여 Teleport 클러스터에 맞게 구성된 자격 증명을 등록하십시오.

이 가이드의 후반부에서는 myusereditor 역할을 요청할 것이며, 그 요청을 Teleport 플러그인을 사용하여 검토할 수 있습니다.

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

작업 공간에 Microsoft Teams 플러그인을 설치합니다. Kubernetes에 플러그인을 배포하는 경우에도 이 가이드의 이후 단계에서 업로드할 애플리케이션 아카이브를 생성하기 위해 로컬에 플러그인을 설치해야 합니다.

Access Request Plugins는 다운로드를 위해 amd64arm64 Linux 바이너리로 제공됩니다.
ARCH 를 필요한 버전으로 교체하십시오.

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

바이너리가 설치되었는지 확인하십시오:

teleport-msteams version
teleport-msteams v13.3.7 git:teleport-msteams-v13.3.7-fffffffff go1.22
docker pull public.ecr.aws/gravitational/teleport-plugin-msteams:13.3.7

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

docker run public.ecr.aws/gravitational/teleport-plugin-msteams:13.3.7 version
teleport-msteams v13.3.7 git:teleport-msteams-v13.3.7-api/14.0.0-gd1e081e 1.22

사용 가능한 태그 목록은 Amazon ECR Public Gallery를 방문하십시오.

소스에서 설치하려면 gitgo 가 설치되어 있어야 합니다. Go가 설치되어 있지 않다면, Go 다운로드 페이지를 방문하십시오.

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

teleport-msteams 바이너리를 PATH로 이동하십시오.

바이너리가 설치되었는지 확인하십시오:

teleport-msteams version
teleport-msteams v13.3.7 git:teleport-msteams-v13.3.7-fffffffff go1.22

Helm이 Teleport Helm 저장소에 호스트된 차트를 설치할 수 있도록 허용합니다:

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

원격 저장소에서 차트 캐시를 업데이트합니다:

helm repo update

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

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

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

  1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

    tctl edit github/github
  2. github 커넥터를 수정하여 teams_to_roles 섹션에 access-plugin-impersonator 을 추가합니다.

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

    예시는 다음과 같습니다:

      teams_to_roles:
        - organization: octocats
          team: admins
          roles:
            - access
    +       - access-plugin-impersonator
    
  3. 파일을 편집하고 저장하여 변경 사항을 적용합니다.

  4. Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

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

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

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

4/9단계. 접근 플러그인 아이덴티티 내보내기

플러그인에 Teleport 아이덴티티 파일에 대한 접근 권한을 부여합니다. 이는 유출되었을 경우 덜 위험한 단기 아이덴티티 파일을 생성하기 위해 Machine ID를 사용하는 것이 좋지만, 데모 배포의 경우 tctl 을 사용하여 장기 아이덴티티 파일을 생성할 수도 있습니다:

tbot 을 구성하여 the plugin 에 필요한 자격 증명을 생성하는 출력을 설정합니다. the plugin 가 Teleport API에 액세스할 것이므로, 사용할 올바른 출력 유형은 identity 입니다.

이 안내서에서는 directory 대상을 사용할 것입니다. 이는 이러한 자격 증명을 디스크의 지정된 디렉토리에 작성합니다. 이 디렉토리는 tbot 이 실행되는 Linux 사용자가 쓸 수 있도록 하여야 하며, the plugin 가 실행되는 Linux 사용자가 읽을 수 있도록 해야 합니다.

tbot 구성을 수정하여 identity 출력을 추가합니다.

Linux 서버에서 tbot 을 실행하는 경우, directory 출력을 사용하여 /opt/machine-id 디렉토리에 신원 파일을 작성합니다:

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 서비스에 인증하기 위해 필요한 개인 키와 서명된 인증서가 포함되어 있습니다.

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

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

5/9단계. Azure Bot 등록

Microsoft Teams의 접근 요청 플러그인은 Teleport Auth Service에서 접근 요청 이벤트를 수신하여 이를 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"를 선택하고 "새 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와 함께 보관하십시오.

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

앱에서 사용하는 권한 지정

아직 앱 관리 뷰("Configuration", 그런 다음 Microsoft App ID 관리)에서 "API permissions" 탭으로 이동합니다.

다음 Microsoft Graph 애플리케이션 권한을 추가하십시오:

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

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

관리자인 경우, "<directory name>"에 대한 관리 승인을 클릭하십시오. 관리자가 아닌 경우, 권한을 부여할 수 있도록 관리자 사용자에게 문의하십시오.

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

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

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

이번 단계에서는 Azure 자격 증명을 사용하고 Microsoft Teams 앱을 설치하는 데 사용할 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"

그 결과는 아래와 같은 구성 파일이어야 합니다:

# Microsoft Teams 플러그인 구성 TOML 파일 예시

# true로 설정하면 플러그인 시작 시 채널 및 사용자 존재 여부를 확인합니다. 사용자가 확인될 경우, 
# 앱이 이미 설치되어 있지 않다면 사용자에게 앱이 설치됩니다. 설치는 사용자당 최대 10초가 걸릴 수 있습니다.
# 모든 사용자가 이미 앱을 설치했음을 확신하지 않는 한, 액세스 요청 처리 시 발생할 수 있는 
# 시간 초과를 방지하기 위해 preloading을 활성화하는 것이 권장됩니다.
preload = true

[teleport]
# Teleport Auth/Proxy 서버 주소.
# addr = "example.com:3025"
#
# Auth 서버의 경우 포트 3025, Proxy의 경우 3080 또는 443이어야 합니다.
# Teleport Cloud의 경우 "your-account.teleport.sh:443" 형식이어야 합니다.

# `tctl auth sign` 명령어로 생성된 자격 증명.
#
# --format=file을 사용하는 경우:
# identity = "/var/lib/teleport/plugins/msteams/identity"   # Identity 파일
# refresh_identity = true                                   # Identity 파일을 주기적으로 갱신
#
# --format=tls를 사용하는 경우:
# client_key = "/var/lib/teleport/plugins/msteams/auth.key" # Teleport TLS 비밀 키
# client_crt = "/var/lib/teleport/plugins/msteams/auth.crt" # Teleport TLS 인증서
# root_cas = "/var/lib/teleport/plugins/msteams/auth.cas"   # Teleport CA 인증서
addr = "localhost:3025"
identity = "identity"
refresh_identity = true

[msapi]
# MS API ID. 문서를 참조하세요.
app_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# 앱 비밀 또는 비밀이 포함된 파일 경로를 포함합니다.
app_secret = "XXXXXXXXXXXXXXXXXXXXXX"
tenant_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
teams_app_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

[role_to_recipients]
# 역할을 수신자와 매핑합니다.
#
# 특정 역할에 대한 액세스 요청 시 msteams 사용자 이메일/ID 또는 채널 URL 수신자를 제공합니다.
# role.suggested_reviewers는 자동으로 추가 이메일 수신자로 처리됩니다.
# 지정되지 않은 역할에 대해 "*"를 제공해야 합니다.
#
# "dev" = "devs-msteams-channel"
# "*" = ["admin@email.com", "admin-msteams-channel"]
"*" = ["foo@example.com"]

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

/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 이라는 파일을 생성하고 다음 내용을 입력하십시오:

# Slack의 기본 값들.
# 이 파일은 YAML 형식으로 작성되었습니다.
# 템플릿에 전달될 변수를 선언합니다.

#
# 플러그인 관련 옵션
#
teleport:
  address: "teleport.example.com:443"
  identitySecretName: teleport-plugin-msteams-identity
  identitySecretPath: identity

msTeams:
  appID: "APP_ID"
  tenantID: "TENANT_ID"
  teamsAppID: "TEAMS_APP_ID"

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

log:
  output: stdout
  severity: INFO

다음 섹션에서 이 파일을 편집할 것입니다.

구성 명령

configure 명령은 비재귀적입니다. 각 실행 시 새로운 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 가 됩니다.

자신이 Linux 서버에서 실행되는 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 플러그인이 인증 서비스로부터 액세스 요청을 수신하면 요청된 역할을 찾아 알릴 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"

Helm 차트에서 role_to_recipients 필드는 roleToRecipients 라고 하며, 다음 형식을 사용하고, 키는 문자열이고 값은 문자열 배열입니다:

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 맵은 또한 주어진 역할 이름과 일치하는 다른 항목이 없을 경우 플러그인이 조회하는 "*" 항목을 포함해야 합니다. 위의 예에서 devdba 외의 역할에 대한 요청은 alice@example.com 에게 알릴 것입니다.

사용자는 액세스 요청을 생성할 때 검토자를 제안할 수 있습니다, 예를 들어:

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

액세스 요청에 제안된 검토자가 포함된 경우 Microsoft Teams 플러그인은 이러한 검토자를 알릴 채널 목록에 추가합니다. 제안된 검토자가 이메일 주소인 경우 플러그인은 해당 주소에 대한 직접 메시지 채널을 조회하여 해당 채널에 메시지를 게시합니다.

사용자가 editor 역할을 요청할 때 알리도록 Microsoft Teams 플러그인을 구성하려면 role_to_recipients 구성에 다음을 추가하십시오(여기서 TELEPORT_USERNAME 을 이전에 editor-reviewer 역할을 할당한 사용자의 이메일로 교체합니다):

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

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

# Microsoft Teams 플러그인 구성 TOML 파일 예시

# true로 설정하면 플러그인 시작 시 채널 및 사용자 존재 여부를 확인합니다. 사용자가 확인될 경우, 
# 앱이 이미 설치되어 있지 않다면 사용자에게 앱이 설치됩니다. 설치는 사용자당 최대 10초가 걸릴 수 있습니다.
# 모든 사용자가 이미 앱을 설치했음을 확신하지 않는 한, 액세스 요청 처리 시 발생할 수 있는 
# 시간 초과를 방지하기 위해 preloading을 활성화하는 것이 권장됩니다.
preload = true

[teleport]
# Teleport Auth/Proxy 서버 주소.
# addr = "example.com:3025"
#
# Auth 서버의 경우 포트 3025, Proxy의 경우 3080 또는 443이어야 합니다.
# Teleport Cloud의 경우 "your-account.teleport.sh:443" 형식이어야 합니다.

# `tctl auth sign` 명령어로 생성된 자격 증명.
#
# --format=file을 사용하는 경우:
# identity = "/var/lib/teleport/plugins/msteams/identity"   # Identity 파일
# refresh_identity = true                                   # Identity 파일을 주기적으로 갱신
#
# --format=tls를 사용하는 경우:
# client_key = "/var/lib/teleport/plugins/msteams/auth.key" # Teleport TLS 비밀 키
# client_crt = "/var/lib/teleport/plugins/msteams/auth.crt" # Teleport TLS 인증서
# root_cas = "/var/lib/teleport/plugins/msteams/auth.cas"   # Teleport CA 인증서
addr = "localhost:3025"
identity = "identity"
refresh_identity = true

[msapi]
# MS API ID. 문서를 참조하세요.
app_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# 앱 비밀 또는 비밀이 포함된 파일 경로를 포함합니다.
app_secret = "XXXXXXXXXXXXXXXXXXXXXX"
tenant_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
teams_app_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

[role_to_recipients]
# 역할을 수신자와 매핑합니다.
#
# 특정 역할에 대한 액세스 요청 시 msteams 사용자 이메일/ID 또는 채널 URL 수신자를 제공합니다.
# role.suggested_reviewers는 자동으로 추가 이메일 수신자로 처리됩니다.
# 지정되지 않은 역할에 대해 "*"를 제공해야 합니다.
#
# "dev" = "devs-msteams-channel"
# "*" = ["admin@email.com", "admin-msteams-channel"]
"*" = ["foo@example.com"]

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

# Slack의 기본 값들.
# 이 파일은 YAML 형식으로 작성되었습니다.
# 템플릿에 전달될 변수를 선언합니다.

#
# 플러그인 관련 옵션
#
teleport:
  address: "teleport.example.com:443"
  identitySecretName: teleport-plugin-msteams-identity
  identitySecretPath: identity

msTeams:
  appID: "APP_ID"
  tenantID: "TENANT_ID"
  teamsAppID: "TEAMS_APP_ID"

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

log:
  output: stdout
  severity: INFO

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

Teams 앱 업로드

Microsoft Teams를 열고 "앱", "앱 관리"로 이동한 다음 추가 선택 메뉴에서 "앱 업로드"를 선택합니다.

Teams 앱 업로드

Teams 관리자인 경우 "조직의 앱 카탈로그에 앱 업로드"를 선택하십시오. 이렇게 하면 승인 단계를 건너뛸 수 있습니다.
Microsoft Teams 관리자가 아닌 경우 "조직에 앱 제출"을 선택하십시오.

이전에 생성한 app.zip 파일을 업로드합니다.

Teams 앱 승인

Teams 관리자가 아니고 "조직에 앱 제출"을 선택한 경우, Teams 관리자에게 승인 요청을 해야 합니다.

그들은 Teams 관리 대시보드에 연결하여 "TeleBot"을 검색하고, 선택한 후 "허용"을 선택하여 승인할 수 있습니다.

팀에 Teams 앱 추가

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

Teams 앱 추가

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

8/9단계. Teams 앱 테스트

Teleport가 실행 중이고 Teams 앱을 생성했으며 플러그인이 구성되면 이제 플러그인을 실행하고 워크플로를 테스트할 수 있습니다.

Microsoft Teams 연결 테스트

유효성 검사 모드에서 플러그인을 시작하십시오:

teleport-msteams validate <귀하의 팀 계정 이메일>

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

teleport-msteams v13.3.7 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

MS Teams를 확인하십시오!

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

봇 메시지 확인

MS Teams 플러그인 시작

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

Teleport MS Teams 플러그인을 시작하려면 다음 명령을 실행하십시오. -d 플래그는 플러그인이 MS Teams 및 귀하의 Teleport 클러스터에 연결할 수 있는지 확인하기 위해 디버그 정보를 제공합니다:

teleport-msteams start -d
DEBU DEBUG 로깅이 활성화되었습니다 msteams/main.go:120INFO Teleport MS Teams 플러그인 시작 13.3.7: msteams/app.go:74DEBU teleport.example.com:443/webapi/find에 대한 GET 시도 중 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 수신자 발견, 채팅 발견 chat_id:19:a8c06deb-aa2b-4db5-9c78-96e48f625aef_a36aec2e-f11c-4219-b79a-19UUUU57de70@unq.gbl.spaces kind:user recipient:jeff@example.com msteams/app.go:195INFO 수신자 데이터 미리 로드 및 캐시 완료 msteams/app.go:198DEBU 감시자 연결됨 watcherjob/watcherjob.go:121INFO 플러그인이 준비되었습니다 msteams/app.go:227

플러그인을 실행하십시오:

docker run -v <설정 경로>:/etc/teleport-msteams.toml public.ecr.aws/gravitational/teleport-plugin-msteams:17.0.0-dev 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.severityDEBUG 로 설정하고 위의 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의 링크를 방문하고 요청을 승인하거나 거부할 수 있습니다.

요청 해결

Access Request 메시지를 수신하면 링크를 클릭하여 Teleport를 방문하고 요청을 승인하거나 거부하십시오:

명령줄에서 Access Request를 검토할 수도 있습니다:

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와 같은 init 시스템을 통해 Teleport 플러그인 데몬을 시작하는 것이 좋습니다. 다음은 systemd에 대한 권장 Teleport 플러그인 서비스 유닛 파일입니다:

[Unit]
Description=Teleport MsTeams Plugin
After=network.target

[Service]
Type=simple
Restart=on-failure
ExecStart=/usr/local/bin/teleport-msteams start --config=/etc/teleport-msteams.toml
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/teleport-msteams.pid

[Install]
WantedBy=multi-user.target

이 파일을 /usr/lib/systemd/system/ 또는 systemd가 지원하는 다른 유닛 파일 로드 경로teleport-msteams.service 로 저장하십시오.

플러그인을 활성화하고 시작하십시오:

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

다음 단계

Teleport 원문 보기