Infograb logo
Jira 접근 요청 플러그인 실행

이 가이드는 Teleport Access Request 플러그인을 Jira에 설정하는 방법을 설명합니다.
Teleport의 Jira 통합 기능을 사용하면 Teleport 접근 요청을 Jira 이슈로 관리할 수 있습니다.

Teleport Jira 플러그인은 Jira 프로젝트 보드를 Teleport 클러스터에서 처리되는 접근 요청과 동기화합니다.
Teleport 내에서 접근 요청의 상태를 변경하면 플러그인이 보드를 업데이트합니다.
보드에서 접근 요청의 상태를 업데이트하면 플러그인이 Jira 웹훅을 통해 알림을 제공하고, 이는 Teleport에서 접근 요청을 수정합니다.

Teleport Enterprise Cloud에서 Teleport는 the Mattermost integration 을(를) 관리하며, Teleport 웹 UI에서 the Mattermost integration 을(를) 등록할 수 있습니다.

Teleport 웹 UI를 방문하여 화면 상단 메뉴 바에서 Access Management를 클릭하십시오.

왼쪽 사이드바에서 Enroll New Integration을 클릭하여 "새 통합 등록" 페이지로 이동합니다:

"통합 유형 선택" 메뉴에서 귀하의 통합에 대한 타일을 클릭하십시오. 그럼 통합 설정을 위한 지침이 포함된 페이지와 통합 구성을 위한 양식이 표시됩니다.

전제 조건

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

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

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

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

  • 애플리케이션 및 웹훅을 생성할 권한이 있는 Jira 계정.

  • Jira 웹훅을 위한 등록된 도메인 이름. Jira는 프로젝트 보드의 변경 사항을 웹훅에 알립니다.

  • Jira 플러그인을 실행할 환경. 이는 다음 중 하나이어야 합니다:

    • 포트 808081 이 열린 Linux 가상 머신과 호스트에 액세스할 수 있는 수단 (예: 작업 스테이션에 노출된 SSH 포트가 있는 OpenSSH).
    • 클라우드 공급자를 통해 배포된 Kubernetes 클러스터. 이 가이드는 LoadBalancer 서비스를 통해 Jira 플러그인에 트래픽을 허용하는 방법을 보여줍니다. 따라서 귀하의 환경은 이러한 종류의 서비스를 지원해야 합니다.
  • 플러그인에 의해 실행되는 Jira 웹훅에 대한 TLS 자격 증명을 제공하는 수단. TLS 인증서는 자체 서명되어서는 안 됩니다. 예를 들어, ACME 클라이언트를 사용하여 Let's Encrypt에서 웹훅에 대한 TLS 자격 증명을 얻을 수 있습니다.

    • 플러그인을 Linux 서버에서 실행하는 경우, 플러그인이 접근할 수 있는 디렉토리에 TLS 자격 증명을 제공해야 합니다.
    • 플러그인을 Kubernetes에서 실행하는 경우, 플러그인이 읽을 수 있는 비밀에 이러한 자격 증명을 작성해야 합니다. 이 가이드는 비밀의 이름이 teleport-plugin-jira-tls 라고 가정합니다.
  • 연결이 가능한지 확인하기 위해 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/7단계. RBAC 리소스 정의

역할 접근 요청 활성화

Jira 플러그인을 설정하기 전에 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 플러그인을 사용하여 검토할 수 있습니다.

플러그인을 위한 사용자 및 역할 만들기

Teleport의 Access Request 플러그인은 Access Requests를 목록화하고 읽으며 업데이트할 수 있는 권한을 가진 사용자로 Teleport 클러스터에 인증합니다. 이렇게 하면 플러그인이 Teleport Auth Service에서 Access Requests를 검색하고, 검토자에게 이를 제시하며, 검토 후에 수정할 수 있습니다.

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

kind: role
version: v5
metadata:
  name: access-plugin
spec:
  allow:
    rules:
      - resources: ["access_request"]
        verbs: ["list", "read", "update"]
      - 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 Service는 단기 TLS 자격 증명을 발급하여 access-plugin 사용자 인증을 수행합니다. 이 경우, access-plugin 역할과 사용자를 임시 사용자화 하여 자격 증명을 수동으로 요청해야 합니다.

자체 호스팅 Teleport Enterprise 배포를 실행하고 Auth Service 호스트에서 tctl 을 사용 중이라면 이미 임시 사용자화 권한이 부여된 상태입니다.

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

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

사용자 정의를 수정합니다:

TELEPORT_USER=$(tsh status --format=json | jq -r .active.username)
tctl edit users/${TELEPORT_USER?}

방금 생성한 역할을 포함하도록 사용자를 수정합니다:

  roles:
   - access
   - auditor
   - editor
+  - access-plugin-impersonator

Teleport 클러스터에서 로그아웃한 다음 다시 로그인합니다. 이제 access-plugin 역할과 사용자에 대한 서명된 인증서를 생성할 수 있습니다.

2/7단계. Teleport Jira 플러그인 설치

호스트(예: EC2 인스턴스) 또는 Kubernetes 클러스터에 플러그인을 배포하는 여부에 따라 아래의 지침에 따라 Teleport Jira 플러그인을 설치합니다.

Teleport Jira 플러그인은 Jira와 Teleport Proxy Service(또는 Teleport Enterprise Cloud 테넌트)에 모두 접근할 수 있는 호스트 또는 Kubernetes 클러스터에서 실행되어야 합니다.

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

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

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

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

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

docker run public.ecr.aws/gravitational/teleport-plugin-jira:13.3.7 version
teleport-jira v13.3.7 git:teleport-jira-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/jira
git checkout 13.3.7
make

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

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

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

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

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

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

helm repo update

3/7단계. 접근 플러그인 식별자 내보내기

플러그인에 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-slack-identity

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

이제 /opt/machine-id 아래에 identity 파일 또는 teleport-plugin-slack-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-jira-identity

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

4/7단계. Jira 프로젝트 설정하기

이 섹션에서는 Teleport 사용자가 액세스 요청을 생성하거나 업데이트할 때 Teleport 플러그인이 수정할 수 있는 Jira 프로젝트를 만듭니다. 그런 다음 플러그인은 Jira 웹후크를 사용하여 보드의 상태를 모니터링하고 생성한 티켓의 변경 사항에 응답합니다.

액세스 요청을 관리하기 위한 프로젝트 만들기

Jira에서 상단 탐색 막대를 찾고 프로젝트 -> 프로젝트 생성을 클릭합니다. 템플릿으로 칸반을 선택한 후 템플릿 사용을 클릭합니다. 회사 관리 프로젝트 선택을 클릭합니다.

프로젝트 이름을 입력할 수 있는 화면이 표시됩니다. 이 안내서에서는 프로젝트 이름을 "Teleport Access Requests"로 가정하며, 기본적으로 TAR 키를 받습니다.

"저장소, 문서 및 기타 연결"이 설정되어 있지 않은지 확인한 후 프로젝트 생성을 클릭합니다.

새 보드의 오른쪽 상단에 있는 세 점 메뉴를 클릭하여 보드 설정을 클릭한 다음 을 클릭합니다. 보드의 상태를 편집하여 다음 네 가지를 포함하도록 합니다:

  1. 대기 중
  2. 승인됨
  3. 거부됨
  4. 만료됨

각 상태와 같은 이름의 열을 만듭니다. 결과는 다음과 같아야 합니다:

프로젝트 보드에 이러한(그리고 오직 이들만의) 열이 포함되어 있지 않다면, 각 열은 같은 이름의 상태를 가져야 하며, Jira Access Request 플러그인은 예기치 않은 방식으로 동작할 것입니다. 모든 다른 열과 상태를 제거하십시오.

변경 사항을 검토하려면 보드로 돌아가기를 클릭합니다.

요청 ID 필드 설정

Teleport Jira 플러그인은 Teleport Access Requests 프로젝트의 작업이 teleportAccessRequestId 라는 필드를 포함할 것으로 예상하며, 이 필드는 개별 액세스 요청을 추적하는 데 사용됩니다. 이를 통해 사용자가 액세스 요청을 조작하거나 위조하는 것을 방지합니다.

teleportAccessRequestId 필드를 설정하려면 왼쪽 탐색 막대에서 프로젝트 설정을 클릭한 다음 이슈 -> 필드를 클릭합니다.

작업 메뉴에서 필드 편집을 클릭합니다. 왼쪽 사이드바의 사용자 정의 필드 탭을 클릭한 후 사용자 정의 필드 생성을 클릭합니다. teleportAccessRequestId 라는 이름의 짧은 텍스트 필드를 추가합니다. 해당 필드를 이 화면과 연결하려면 기본 화면 옆의 체크박스를 클릭합니다. 업데이트를 클릭합니다.

다음으로, 사용자 정의 필드를 Teleport Access Requests 프로젝트에 추가합니다. 프로젝트 > **Teleport Access Requests (TAR)**를 클릭한 후 프로젝트 설정을 클릭합니다. 왼쪽 사이드바에서 이슈 -> 유형을 클릭한 후 업무 > 필드를 클릭합니다. 필드 선택이라는 드롭다운 메뉴를 찾아 이전에 추가한 teleportAccessRequestId 필드를 선택합니다.

Jira API 토큰 가져오기

Teleport Access Request 플러그인이 Jira 프로젝트를 변경하는 데 사용할 API 토큰을 가져옵니다. 화면 오른쪽 상단의 기어 메뉴를 클릭한 다음 Atlassian 계정 설정을 클릭합니다. 보안 > API 토큰 생성 및 관리 > API 토큰 생성을 클릭합니다.

원하는 레이블을 선택하고 복사를 클릭합니다. API 토큰을 사용자의 편리한 위치(예: 비밀번호 관리자 또는 로컬 텍스트 문서)에 붙여넣어 나중에 Jira 플러그인을 구성할 때 사용할 수 있도록 합니다.

Jira 웹후크 설정

Teleport Jira 플러그인이 프로젝트를 관리하는 데 사용할 수 있는 API 키를 생성했으므로, 프로젝트가 업데이트될 때 Teleport Jira 플러그인에 알리도록 Jira에 웹후크를 생성합니다.

Jira로 돌아갑니다. 화면 오른쪽 상단의 기어 메뉴를 클릭합니다. 시스템 > 웹후크 > 웹후크 생성을 클릭합니다.

"이름" 필드에 "Teleport Access Request Plugin"을 입력합니다. "URL" 필드에는 플러그인을 위해 이전에 생성한 도메인 이름과 포트 8081 을 입력합니다.

"이름" 필드에 "Teleport Access Request Plugin"을 입력합니다. "URL" 필드에는 플러그인을 위해 이전에 생성한 도메인 이름과 포트 443 을 입력합니다.

웹후크는 이슈가 생성, 업데이트 또는 삭제될 때만 알림을 받아야 합니다. 나머지 상자는 비워두어도 됩니다.

생성을 클릭합니다.

5/7단계. Jira 접근 요청 플러그인 구성

앞서, Jira 플러그인이 Teleport 및 Jira API에 연결하는 데 사용하는 자격 증명을 검색했습니다. 이제 이러한 자격 증명을 사용하도록 플러그인을 구성하고, 앞서 구성한 주소에서 Jira 웹후크를 실행할 것입니다.

구성 파일 만들기

Teleport Jira 플러그인은 TOML 형식의 구성 파일을 사용합니다. 다음 명령을 실행하여 보일러플레이트 구성을 생성하십시오 (구성 파일이 /etc/teleport-jira.toml 에 있어야 플러그인이 실행됩니다):

teleport-jira configure | sudo tee /etc/teleport-jira.toml > /dev/null

이로 인해 아래와 같은 구성 파일이 생성되어야 합니다:

# Jira 플러그인 구성 TOML 파일 예시
[teleport]
# Proxy Service domain and HTTPS port
auth_server = "myinstance.teleport.sh:443"
# Teleport identity file location
identity = "/var/lib/teleport/plugins/jira/identity"
# Refresh identity file on a periodic basis.
refresh_identity = true

[jira]
url = "https://[my-jira].atlassian.net"    # JIRA URL
username = "bot@example.com"               # JIRA username
api_token = "token"                        # JIRA API token
project = "TAR"                            # JIRA Project key

[http]
# URL on which webhook server is accessible externally, for example,
# [https://]teleport-jira.example.com
public_addr = "example.com" 
https_key_file = "/var/lib/teleport/plugins/jira/server.key"  # TLS private key
https_cert_file = "/var/lib/teleport/plugins/jira/server.crt" # TLS certificate

[log]
output = "stderr" # Logger output. Could be "stdout", "stderr" or "/var/lib/teleport/jira.log"
severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".

Jira 플러그인의 Helm 차트는 플러그인을 구성하기 위해 YAML 값 파일을 사용합니다. 로컬 작업 공간에서 다음 예를 기반으로 teleport-jira-helm.yaml 이라는 파일을 만듭니다:

teleport:
  # Teleport Proxy Service 도메인 이름 및 HTTPS 포트. Teleport Enterprise Cloud를 사용하는 경우,
  # "your-account.teleport.sh:443" 형식이어야 합니다.
  address: "teleport.example.com:443"
  # Teleport Identity 문서를 포함하는 Secret
  identityFromSecret: teleport-plugin-jira-identity
  # Secret 내에서 Identity 파일이 위치한 경로
  identitySecretPath: identity

jira:
  url: "https://[my-jira].atlassian.net"      # Jira 인스턴스의 URL
  username: bot@example.com                   # 봇 사용자 이메일
  apiToken: token                             # 봇 사용자 토큰
  project: TAR                                # 이슈가 생성될 프로젝트

http:
  publicAddress: https://jira-teleport.example.com/ 
  # TLS 인증서를 포함하는 Secret
  tlsFromSecret: teleport-plugin-jira-tls            
  # tlsKeySecretPath: tls.key                # Secret 내 키의 이름
  # tlsCertSecretPath: tls.crt               # Secret 내 인증서의 이름

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

serviceType: ClusterIP

구성 파일 편집

Teleport Jira 플러그인을 위해 생성된 구성 파일을 열고 다음 필드를 업데이트하십시오:

[teleport]

Jira 플러그인은 이 섹션을 사용하여 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

jira

url: Jira 테넌트의 URL, 예: https://[your-jira].atlassian.net .

username: API 토큰을 생성할 때 로그인했던 사용자 이름입니다.

api_token: 앞서 검색한 Jira API 토큰입니다.

project: 프로젝트 키, 우리의 경우 TAR 입니다.

issue_type 은 기본값이 Task 이므로 Task 로 두거나 필드를 제거할 수 있습니다.

http

[http] 설정 블록은 플러그인의 웹후크가 작동하는 방식을 설명합니다.

listen_addr는 플러그인이 수신하는 주소를 나타내며 기본값은 :8081 입니다. 앞서 안내서에서 추천한 대로 플러그인 호스트에서 포트 8081 을 열었다면 이 옵션을 비워 둘 수 있습니다.

public_addr는 웹후크의 공용 주소입니다. 이는 앞서 생성한 DNS A 레코드에 추가한 도메인 이름입니다.

https_key_filehttps_cert_file는 이 가이드를 따르기 전에 얻은 개인 키 및 인증서에 해당합니다. 아래 값을 사용하되, 이전에 플러그인을 위해 생성한 도메인 이름에 example.com을 할당하십시오:

  • https_key_file:

    /var/teleport-jira/tls/certificates/acme-v02.api.letsencrypt.org-directory/example.com/example.com.key
  • https_cert_file:

    /var/teleport-jira/tls/certificates/acme-v02.api.letsencrypt.org-directory/example.com/example.com.crt

jira

url: 당신의 Jira 테넌트의 URL, 예: https://[your-jira].atlassian.net .

username: API 토큰을 생성할 때 로그인한 사용자 이름입니다.

apiToken: 이전에 가져온 API 토큰입니다.

project: 당신의 프로젝트 키, 우리의 경우 TAR 입니다.

issueTypeTask 로 두거나 필드를 제거할 수 있습니다. Task 가 기본값입니다.

http

http 설정 블록은 플러그인의 웹훅이 어떻게 작동하는지를 설명합니다.

publicAddress: 당신의 웹훅의 공용 주소입니다. 이것은 웹훅을 위해 생성한 도메인 이름입니다. (우리는 나중에 이 도메인 이름에 대한 DNS 레코드를 생성할 것입니다.)

tlsFromSecret: 웹훅의 TLS 자격 증명을 포함하는 Kubernetes 비밀의 이름입니다. teleport-plugin-jira-tls 를 사용하십시오.

6/7단계. Jira 플러그인 실행

구성을 완료한 후, 이제 플러그인을 실행하고 Jira 기반 접근 요청 흐름을 테스트할 수 있습니다:

Linux 호스트에서 다음 명령을 실행하십시오:

sudo teleport-jira start
INFO Teleport Jira Plugin 12.1.1 시작 중 jira/app.go:112INFO 플러그인이 준비되었습니다 jira/app.go:142

Teleport Jira 플러그인에 대한 Helm 차트를 설치하십시오:

helm install teleport-plugin-jira teleport/teleport-plugin-jira \ --namespace teleport \ --values values.yaml \ --version 13.3.7

Jira 플러그인 Helm 차트에 의해 생성된 로드 밸런서의 주소와 웹훅의 도메인 이름을 연결하는 DNS 레코드를 생성하십시오.

로드 밸런서에 도메인 이름이나 IP 주소가 있는지 확인하십시오:

kubectl -n teleport get services/teleport-plugin-jira
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEteleport-plugin-jira LoadBalancer 10.100.135.75 abc123.us-west-2.elb.amazonaws.com 80:30625/TCP,443:31672/TCP 134m

EXTERNAL-IP 필드에 값으로 도메인 이름이 있는 경우, 웹훅의 도메인이 로드 밸런서의 도메인 이름을 가리키도록 CNAME 레코드를 생성하십시오.

EXTERNAL-IP 필드의 값이 IP 주소인 경우, 대신 DNS A 레코드를 생성하십시오.

그런 다음 Jira 플러그인에 대한 서명된 TLS 자격 증명을 생성할 수 있습니다. 이는 Kubernetes 비밀에 작성되기를 기대합니다.

웹훅 상태 확인

GET 요청을 /status 엔드포인트로 보내 웹훅이 시작되었는지 확인하십시오. 웹훅이 실행 중이면 문서 바디 없이 200 상태 코드를 반환합니다:

curl -v https://example.com:8081/status 2>&1 | grep "^< HTTP/2"
< HTTP/2 200
curl -v https://example.com:443/status 2>&1 | grep "^< HTTP/2"
< HTTP/2 200

액세스 요청 생성

이전에 생성한 myuser 사용자로 클러스터에 로그인하고 액세스 요청을 생성합니다:

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

tctl request create myuser --roles=editor

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

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

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

요청을 생성하면 Teleport 액세스 요청 보드의 "대기 중" 열에 새 작업이 표시됩니다:

요청 해결

새 액세스 요청에 해당하는 카드를 "거부됨" 열로 이동한 다음, 카드를 클릭하고 Teleport로 이동합니다. 액세스 요청이 거부된 것을 볼 수 있습니다.

액세스 요청 감사

Jira 프로젝트 보드에 접근할 수 있는 모든 사람은 보드에 반영된 액세스 요청의 상태를 수정할 수 있습니다. 올바른 사용자가 올바른 요청을 검토하고 있는지 확인하기 위해 Teleport 감사 로그를 확인할 수 있습니다.

액세스 요청 리뷰를 감사할 때는 Teleport 웹 UI에서 Access Request Reviewed 유형의 이벤트를 확인하십시오.

7/7단계. systemd 설정

이 단계는 Linux 머신에서 Teleport Jira 플러그인을 실행하는 경우에만 적용됩니다.

운영 환경에서는 systemd와 같은 init 시스템을 통해 Teleport 플러그인 데몬을 시작하는 것을 권장합니다. 아래는 systemd용 권장 Teleport 플러그인 서비스 유닛 파일입니다:

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

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

[Install]
WantedBy=multi-user.target

이 파일을 teleport-jira.service 또는 systemd에서 지원하는 다른 유닛 파일 로드 경로로 저장합니다.

sudo systemctl enable teleport-jira
sudo systemctl start teleport-jira
Teleport 원문 보기