Jenkins에 Machine ID 배포하기

Jenkins는 Continuous Integration 및 Continuous Delivery (CI/CD) 파이프라인을 구축하는 데 자주 사용되는 오픈 소스 자동화 서버입니다.

이 가이드에서는 기존 Jenkins 파이프라인을 최소한의 변경으로 Machine ID를 활용하도록 마이그레이션하는 방법을 보여줍니다.

사전 요구 사항

Jenkins와 함께 Teleport를 사용하려면 다음 도구가 필요합니다.

실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
tctl 관리자 도구와 tsh 클라이언트 도구.

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

ssh OpenSSH 도구
Jenkins
연결이 가능한지 확인하기 위해 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 명령어를 실행할 수도 있습니다.

아키텍처

시작하기 전에, Jenkins는 보안하기 어려운 도구라는 점을 주목해야 합니다. Machine ID는 인프라를 보호하는 데 중요한 부분이지만, 그것만으로는 충분하지 않습니다. 아래에서는 Jenkins 설치의 보안 태세를 개선하는 데 도움이 되는 기본 지침을 제공합니다.

단일 호스트 배포

가장 간단한 Jenkins 배포는 컨트롤러(구성을 저장하고, 플러그인 및 UI를 관리하는 프로세스)와 에이전트(작업을 실행하는 프로세스)가 동일한 호스트에서 실행되는 것입니다. 이 배포 모델은 시작하기 간단하지만, 단일 파이프라인 내의 jenkins 사용자에 대한 어떤 손상이 발생해도 전체 CI/CD 인프라가 compromised될 수 있습니다.

다중 호스트 배포

조금 더 복잡하지만 보안이 강화된 배포는 Jenkins 컨트롤러와 에이전트를 서로 다른 호스트에서 실행하고 특정 에이전트에 작업을 고정하는 것입니다. 이 배포 방식은 단순한 배포에 비해 개선된 점이 있으며, 단일 파이프라인의 compromised가 CI/CD 인프라 전체가 아닌 일부로 제한됩니다.

모범 사례

가능한 경우 두 번째 배포 모델을 사용하는 것을 강력히 권장합니다. ephemeral 호스트와 IAM을 가능한 경우 결합하여 사용하세요. 이 모델에서 Machine ID를 사용할 때는 각 호스트에 대해 Machine ID 봇을 생성하고 특정 파이프라인을 워커에 고정하세요. 이렇게 하면 각 파이프라인에 대해 서버 접근의 최소 범위를 설정하고, 하나의 파이프라인이 compromised될 경우 영향을 제한하며, 악의적인 행동을 탐지할 경우 원격으로 파이프라인을 감사하고 잠글 수 있습니다.

Jenkins 배포

1/2단계. Machine ID 구성 및 시작

우선, Machine ID를 위한 새 역할을 만들지 아니면 기존의 역할을 사용할지 결정해야 합니다. tctl get roles 를 실행하여 기존 역할을 검사할 수 있습니다.

아래의 예시에서 api-workers.yaml 이라는 파일을 생성하고 아래 내용을 삽입하여 api-workers 라는 새 역할을 생성합니다. 이 역할을 사용하면 group: api 라는 레이블이 붙은 노드에 jenkins 라는 리눅스 사용자로 로그인할 수 있습니다.

kind: "role"
version: "v3"
metadata:
  name: "api-workers"
spec:
  allow:
    logins: ["jenkins"]
    node_labels:
      "group": "api"

클라이언트 머신에서 tsh 를 사용하여 Teleport에 로그인한 후 tctl 을 사용하세요.

tctl create -f api-workers.yaml
tctl bots add jenkins --roles=api-workers

Teleport Auth 서버에 연결하고 tctl 을 사용하여 시스템에 어떤 역할이 있는지 확인합니다.

tctl create -f api-workers.yaml
tctl bots add jenkins --roles=api-workers

Machine ID는 리눅스 접근 제어 목록 (ACL)을 사용하여 디스크에 인증서 접근을 제어하는 데 사용됩니다. 이를 통해 Jenkins가 Machine ID가 발급하는 단기 인증서에 대한 접근을 제한할 수 있습니다.

다음 예시에서는 teleport 라는 리눅스 사용자를 생성하여 Machine ID를 실행하되, 단기 인증서는 리눅스 사용자 jenkins 로 디스크에 기록됩니다.

sudo adduser \    --disabled-password \    --no-create-home \    --shell=/bin/false \    --gecos "" \    teleport

tbot init 명령을 사용하여 필요한 디렉터리를 생성하고 초기화합니다.

sudo tbot init \    --destination-dir=/opt/machine-id \    --bot-user=teleport \    --owner=teleport:teleport \    --reader-user=jenkins

봇 디렉토리를 만들고 소유권을 teleport 사용자에게 할당합니다.
sudo mkdir -p /var/lib/teleport/bot
sudo chown teleport:teleport /var/lib/teleport/bot
teleport 사용자에게 디렉토리를 열 수 있는 권한 부여
sudo chmod +x /var/lib/teleport /var/lib/teleport/bot

다음으로, 각 Jenkins 작업자의 백그라운드에서 Machine ID를 시작해야 합니다.

먼저 /etc/tbot.yaml 에 대한 Machine ID의 구성 파일을 생성합니다.

version: v2
# "example.teleport.sh:443"를 Teleport 프록시 또는 Teleport 클라우드 테넌트의 주소로 바꾸세요.
proxy_server: "example.teleport.sh:443"
onboarding:
  join_method: "token"
  # `tctl bots add` 를 실행했을 때 출력된 토큰 필드를 교체하십시오.
  token: "00000000000000000000000000000000"
storage:
  type: directory
  path: /var/lib/teleport/bot
outputs:
  - type: identity
    destination:
      type: directory
      path: /opt/machine-id

`tbot` systemd 유닛 파일 만들기

기본적으로 tbot 은 데몬 모드로 실행됩니다. 그러나 이를 위해서는 Linux 호스트의 서비스 관리자를 통해 서비스를 구성해야 합니다. 서비스 관리자는 부팅 시 tbot 을 시작하고 실패할 경우 다시 시작하도록 보장합니다. 이 가이드에서는 systemd를 시연하지만, tbot 은 모든 일반적인 대안과 호환되어야 합니다.

tbot install systemd 를 사용하여 systemd 서비스 파일을 생성합니다:

tbot install systemd \   --write \   --config /etc/tbot.yaml \   --user teleport \   --group teleport \   --anonymous-telemetry

다음 항목을 교체해야 합니다:

teleport 는 tbot 을 실행할 Linux 사용자 이름으로 바꿉니다.
/etc/tbot.yaml 은 생성한 구성 파일의 경로로 바꿉니다.

--write 를 생략하면 시스템 서비스 파일이 콘솔에 출력되며 디스크에 작성되지 않습니다.

--anonymous-telemetry 는 익명 사용 통계를 제출하는 기능을 활성화합니다. 이를 통해 tbot 의 미래 개발에 도움을 줄 수 있습니다. 이를 비활성화하려면 이 파라미터를 생략하면 됩니다.

다음으로, 서비스가 부팅 시 시작되도록 활성화하고 서비스를 시작합니다:

sudo systemctl daemon-reload
sudo systemctl enable tbot
sudo systemctl start tbot

서비스가 성공적으로 시작되었는지 확인합니다:

sudo systemctl status tbot

2/2단계. Jenkins 파이프라인 업데이트 및 실행

Jenkins 파이프라인 내에서 Machine ID를 사용하는 것은 이제 한 줄의 변경으로 가능합니다. 예를 들어, 원격 호스트에서 hostname 명령을 실행하려면 Jenkins 파이프라인에 다음을 추가하세요.

steps {
  sh "ssh -F /opt/machine-id/ssh_config root@node-name.example.com hostname"
}

모든 준비가 완료되었습니다. 짧은 기간 동안 유효한 인증서를 Jenkins에 제공하여 기계 ID에 연결할 수 있으며, 이 인증서는 회전, 감사 및 모든 익숙한 Teleport 접근 제어를 통해 관리할 수 있습니다.

다음 단계

TELEPORT_ANONYMOUS_TELEMETRY 에 대한 자세한 정보.

Teleport 원문 보기