InfoGrab Docs

Ansible AWX와 함께하는 머신 및 워크로드 아이덴티티

요약

Ansible AWX(이전에 Ansible Tower라고 알려진)는 Ansible 위에서 Ansible 워크플로를 실행하고 조율하는 데 사용할 수 있는 인터페이스입니다. 이 가이드는 오픈 소스 Ansible AWX와 오픈 소스 Ansible AWX 엔진 위에 구축된 Red Hat의 상용 Ansible Automation Platform 자동화 컨트롤러 모두에 적용됩니다.

Ansible AWX(이전에 Ansible Tower라고 알려진)는 Ansible 위에서 Ansible 워크플로를 실행하고 조율하는 데 사용할 수 있는 인터페이스입니다. 이 워크플로는 SSH를 통해 원격 호스트에 연결하며 인증 방식이 필요합니다. 머신 및 워크로드 아이덴티티는 AWX를 통해 실행되는 Ansible 작업에 단기 인증서를 제공하여 작업이 Teleport에 등록된 SSH 노드에 안전하고 감사 가능한 방식으로 연결할 수 있게 합니다.

이 가이드는 오픈 소스 Ansible AWX와 오픈 소스 Ansible AWX 엔진 위에 구축된 Red Hat의 상용 Ansible Automation Platform 자동화 컨트롤러 모두에 적용됩니다.

작동 방식#

이 가이드에서는 Ansible AWX의 컨테이너 그룹이 머신 및 워크로드 아이덴티티 에이전트 tbot을 사이드카로 실행하도록 설정합니다. 이는 Ansible AWX 작업에 자격 증명과 고성능 멀티플렉싱 프록시를 제공합니다. 그런 다음 Ansible이 이 자격 증명을 사용하여 Teleport Proxy Service를 통해 SSH 노드에 연결하도록 설정합니다.

사전 조건#

  • A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
      $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
      
    2. Follow the instructions for your platform to install tctl and tsh clients:

  • 접근 가능한 Kubernetes 클러스터에서 실행 중인 Ansible AWX(또는 Ansible Tower, Ansible Automation Platform) 설치본.
  • 로컬 머신에 kubectl 클라이언트가 설치되어 있고 Ansible AWX가 실행 중인 Kubernetes 클러스터에 접근하도록 설정되어 있어야 합니다.
  • 새 컨테이너 그룹을 만들 권한이 있어야 합니다.
  • 이 가이드는 Kubernetes 외부에서 실행되는 인스턴스 그룹에는 적용되지 않습니다. 이 경우 기존 Ansible 노드로 취급하고 기존 Ansible 가이드를 따르세요.
  • 선택 사항이지만, 이 가이드에서 수행할 단계의 기반이 되는 Kubernetes에 tbot을 배포하는 방법을 자세히 알려면 Kubernetes에 tbot 배포 또는 OIDC를 사용한 Kubernetes에 tbot 배포 가이드를 읽어보세요.

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

1단계/5단계. Teleport 리소스 설정#

먼저 세 개의 새 Teleport 리소스를 만들어야 합니다:

  1. tbot 사이드카가 원하는 SSH 노드에 접근할 수 있도록 권한을 부여하는 Teleport 역할
  2. 봇에 이름을 지정하고 허용 역할 목록을 지정하는 봇 리소스
  3. 봇이 Teleport에 인증할 수 있게 하는 조인 토큰(join token)
수동 설정

수동으로 조인을 설정하거나 Terraform 또는 다른 도구와 함께 사용하는 수동 단계로 적용하려면 아래의 대안 단계를 참조하세요.

먼저 역할과 봇을 만듭니다. 다음 내용으로 awx-bot-resources.yaml을 만듭니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    # Linux 사용자 'root'로 로그인 허용.
    logins: ['root']
    # 모든 노드에 대한 연결 허용. Ansible 작업이 접근해야 하는
    # 노드에만 일치하도록 이 레이블을 조정하세요.
    node_labels:
      '*': '*'
---
kind: bot
version: v1
metadata:
  # name은 클러스터에서 봇의 고유 식별자입니다.
  name: awx-bot
spec:
  # roles는 봇에 부여할 역할 목록입니다. 위의 역할을 포함하지만
  # Ansible 작업을 통해 접근하려는 모든 노드에 봇의 SSH 접근을 허용하는
  # 추가 역할을 추가할 수 있습니다.
  roles: [example-role]

필요에 따라 이 설정을 조정하세요:

  • Ansible 작업 실행에 필요한 노드와 로그인만으로 접근을 제한하도록 예시 역할의 loginsnode_labels 필드를 조정하세요.
  • 봇 정의의 spec.roles 목록에 추가하여 봇에 원하는 추가 역할을 부여하세요.

준비가 되면 다음 명령을 실행하여 Teleport 클러스터에 리소스를 만듭니다:

$ tctl create -f awx-bot-resources.yaml

다음으로, tctl tokens configure-kube를 사용하여 사용할 최적의 Kubernetes 조인 방법을 자동으로 감지하고 조인 토큰을 자동으로 만듭니다. 다음을 실행합니다:

$ tctl tokens configure-kube \
  --bot awx-bot \
  --namespace  \
  --service-account default \
  --token-name awx-bot

기본적으로 configure-kube 헬퍼는 현재 선택된 kubectl 컨텍스트를 사용하므로 계속하기 전에 kubectl이 원하는 Kubernetes 클러스터에 접근하도록 설정되어 있는지 확인하세요. 필요한 경우 --context 플래그를 사용하여 대안 컨텍스트를 선택할 수 있습니다. 유용한 파라미터의 전체 목록은 tctl tokens configure-kube --help로 볼 수 있습니다.

플래그를 적절히 조정한 후 명령을 실행하면 사용 가능한 최적의 조인 방법을 감지하고 봇이 사용할 조인 토큰을 만듭니다. 출력되는 helm 지침은 무시하고 생성되는 values.yaml은 삭제할 수 있습니다 - 이 가이드에서는 teleport/tbot Helm 차트를 사용하지 않습니다.

원하는 경우 다음 명령을 실행하여 생성된 조인 토큰을 확인할 수 있습니다:

$ tctl get token/awx-bot

...하지만 다음 단계에서 토큰 이름(awx-bot)만 알면 됩니다.

2단계/5단계. Kubernetes 리소스 설정#

다음으로 AWX 작업이 실행될 Kubernetes 클러스터에 ConfigMap 리소스를 준비합니다. 이 ConfigMap에는 머신 및 워크로드 아이덴티티 에이전트 tbot의 설정이 포함됩니다. 특히:

  • Teleport 클러스터의 주소
  • 이전 단계에서 만든 조인 토큰을 사용하여 Teleport 클러스터에 조인하는 방법
  • 봇이 내부 데이터를 저장할 위치(AWX 작업이 일시적이므로 메모리에 저장)
  • 봇이 실행할 추가 서비스, 이 경우 SSH 노드에 대한 효율적인 접근을 제공하는 ssh-multiplexer

수동으로 설정해야 하는 유일한 Kubernetes 리소스는 tbotConfigMap입니다.

다음을 configmap-tbot-awx-config.yaml에 작성합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: tbot-awx-config
  namespace:  name="awx" />
data:
  tbot.yaml: |
    version: v2
    onboarding:
      join_method: kubernetes
      # token이 이전에 만든 조인 토큰 이름으로 설정되어 있는지 확인하세요
      token: awx-bot
    storage:
      # kubernetes 조인 방법은 지속성이 필요하지 않으므로
      # 봇 자체 상태에는 메모리 대상을 사용합니다.
      type: memory
    # Teleport Proxy Service의 주소로 설정되어 있는지 확인하세요.
    proxy_server: :443
    services:
    # `ssh-multiplexer` 서비스는 Ansible 작업에서 사용할
    # 고성능 멀티플렉서 소켓을 제공합니다.
    - type: ssh-multiplexer
      # 이 경로(/tbot/)는 `tbot-binaries` 공유 볼륨의
      # 볼륨 마운트와 일치해야 합니다.
      proxy_command: ["/tbot/fdpass-teleport"]
      destination:
        type: directory
        # 자격 증명과 멀티플렉서 소켓이 생성될 파드의 경로입니다.
        # AWX 컨테이너 그룹 템플릿에서 설정한 대로 워커 컨테이너와
        # tbot 컨테이너 모두의 볼륨 마운트와 일치해야 합니다.
        path: "/tbot-output"

이 설정 파일의 가능한 값에 대한 자세한 내용은 Machine ID의 설정 레퍼런스를 참조하세요.

ssh-multiplexer에 대하여

Machine ID의 ssh-multiplexer 서비스는 많은 SSH 연결을 열 때 성능을 향상시키는 데 사용됩니다. fdpass-teleport 실행 파일이 Teleport에 대한 단일 공유 연결을 통해 새 SSH 세션을 열 수 있는 Unix 소켓을 제공합니다. /tbot-output/ssh_config에 기록된 SSH 설정이 이를 수행하도록 자동으로 설정됩니다.

ssh-multiplexer 서비스에 대한 자세한 내용은 레퍼런스 페이지를 참조하세요.

ConfigMap 리소스는 환경에 맞게 조정해야 할 수 있습니다. 여기서는 AWX 작업이 네임스페이스에서 실행되고 의 Teleport 클러스터에서 자격 증명을 가져와야 한다고 가정합니다. 준비가 되면 리소스를 만듭니다:

$ kubectl create -f configmap-tbot-awx-config.yaml

또한 아래에서 설정할 기본 AWX 컨테이너 그룹 템플릿과 일치하는 기본 서비스 네임스페이스 서비스 계정을 사용한다는 점에 주의하세요. 사용자 지정 서비스 계정을 사용하려면 생성해야 하는 Kubernetes RBAC 리소스와 해당 계정의 조인을 허용하기 위해 Teleport 토큰에 필요한 조정 사항에 대한 예시를 보려면 일반 Kubernetes 가이드를 참조하세요.

3단계/5단계. 새 컨테이너 그룹 만들기#

파드 스펙 변경 요약#

이 섹션은 Ansible AWX에서 실행되는 워크플로에서 Teleport의 리소스에 접근하는 한 가지 방법만 설명하며, 환경에 맞게 여기서 설명하는 단계를 조정해야 할 수 있습니다.

이 가이드에서 기본 파드 스펙에 적용할 변경 사항과 직접 구현할 때 고려할 수 있는 대안을 간단히 요약합니다:

  1. tbotfdpass-teleport 바이너리를 실행 환경에서 사용할 수 있어야 합니다. Teleport initContainer를 사용하여 이 바이너리를 임의의 실행 환경(예: awx-ee)에 복사하지만, 직접 EE를 구축한다면 이 Teleport 바이너리를 EE에 직접 설치하고 initContainer를 사용할 필요가 없습니다.
  2. tbot 사이드카가 추가되어 Teleport에 연결하고 SSH 자격 증명을 가져와 업데이트하며, Teleport가 관리하는 SSH 호스트에 대한 효율적인 SSH 연결을 위한 ssh-multiplexer 소켓을 제공합니다.
  3. 파드 스펙에 네 개의 추가 볼륨이 추가됩니다:
    1. Kubernetes 조인에 사용되는 프로젝션된 서비스 계정 토큰(join-sa-token)
    2. Teleport 바이너리를 포함하는 emptyDir 볼륨(tbot-binaries)
    3. 생성된 Teleport SSH 자격 증명을 포함하는 emptyDir 볼륨(tbot-output)
    4. tbot 사이드카에 사용되는 YAML 설정을 포함하는 configMap 볼륨(tbot-config)
  4. 여러 볼륨 마운트가 추가됩니다:
    1. tbot-binaries 볼륨이 "tbot-installer" initContainerawx-ee 워커 컨테이너 모두에 마운트되어 Ansible 작업이 런타임에 바이너리를 실행할 수 있습니다.
    2. tbot-output 볼륨이 awx-ee 워커 컨테이너와 tbot 사이드카 모두에 마운트되어 런타임에 생성된 자격 증명을 Ansible 작업과 공유할 수 있습니다.
    3. tbot-configjoin-sa-token 볼륨은 tbot 사이드카에만 마운트됩니다.

AWX 설정#

다음으로, Kubernetes(또는 OpenShift)에서 작업을 생성하는 새 컨테이너 인스턴스 그룹을 만들어야 합니다. 또한 파드 스펙을 커스터마이즈하여 awx-ee 워커 컨테이너와 함께 tbot을 사이드카로 실행하여 작업에 SSH 자격 증명을 제공합니다.

AWX 웹 UI에서 Administration, Instance Groups로 이동하여 "Add" 버튼을 선택하고 "Add container group"을 선택합니다. 원하는 이름을 입력하고 환경에 맞게 필드를 설정합니다.

AWX 버전

이 사용자 지정 파드 스펙은 Ansible AWX 버전 24.6.1용으로 작성되었습니다. 다른 버전을 사용하거나 환경에 추가적인 파드 스펙 변경이 필요한 경우, 아래 예시 파드 스펙을 주의 깊게 검토하고 필요한 조정을 해야 합니다.

다음으로 "Customize pod specification" 체크박스를 선택합니다. 기본 파드 스펙이 포함된 텍스트 필드가 나타납니다. 다음으로 교체합니다:

apiVersion: v1
kind: Pod
metadata:
  namespace:  name="awx" />
spec:
  serviceAccountName: default
  automountServiceAccountToken: false
  initContainers:
    - name: tbot-installer
      image: public.ecr.aws/gravitational/tbot-distroless:(=teleport.version=)
      command: ["tbot"]
      args: ["copy-binaries", "--include-fdpass", "/tbot"]
      volumeMounts:
        - name: tbot-binaries
          mountPath: /tbot
  containers:
    - image: quay.io/ansible/awx-ee:latest
      name: worker
      args:
        - ansible-runner
        - worker
        - '--private-data-dir=/runner'
      resources:
        requests:
          cpu: 250m
          memory: 100Mi
      volumeMounts:
        - name: tbot-binaries
          mountPath: /tbot
        - name: tbot-output
          mountPath: /tbot-output
    - name: tbot
      image: public.ecr.aws/gravitational/tbot-distroless:(=teleport.version=)
      command: ["tbot"]
      args:
        - start
        - -c
        - /config/tbot.yaml
      env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: KUBERNETES_TOKEN_PATH
          value: /var/run/secrets/tokens/join-sa-token
      volumeMounts:
        - mountPath: /config
          name: tbot-config
        - mountPath: /var/run/secrets/tokens
          name: join-sa-token
        - mountPath: /tbot-output
          name: tbot-output
      # awx-ee와 일치하도록 보안 컨텍스트 설정
      securityContext:
        runAsUser: 1000
        runAsGroup: 0
  volumes:
    - name: tbot-binaries
      emptyDir: {}
    - name: tbot-output
      emptyDir: {}
    - name: tbot-config
      configMap:
        name: tbot-awx-config
    - name: join-sa-token
      projected:
        sources:
          - serviceAccountToken:
              path: join-sa-token
              expirationSeconds: 600
              audience:  name="example.teleport.sh" />

환경에 따라 추가적인 변경이 필요할 수 있지만, 최소한 다음 필드를 조정하세요:

  • 최상위 metadata.namespace 필드는 AWX가 이 인스턴스 그룹에 대한 파드를 생성하는 네임스페이스와 일치해야 합니다.
  • join-sa-token 볼륨의 audience 필드는 Teleport 클러스터 이름으로 설정해야 합니다.
  • default 이외의 서비스 계정을 사용하려면 설정된 serviceAccountName을 조정해야 합니다.

필요한 모든 수정이 완료되면 "Save"를 선택하여 새 컨테이너 그룹 설정을 완료합니다.

4단계/5단계. 인벤토리 정의#

이 단계에서는 AWX에서 연결하는 방법을 보여주기 위해 Teleport SSH 호스트를 포함하는 간단한 인벤토리를 만듭니다.

Ansible AWX 웹 인터페이스에서 Teleport를 통해 접근 가능한 노드를 포함하는 인벤토리를 만듭니다. Resources, Inventories로 이동하여 "Add" 버튼을 선택한 다음 "Add inventory"를 선택합니다.

이름과 다른 필드를 원하는 대로 설정한 후 새 인벤토리를 저장합니다. 새 인벤토리의 세부 페이지에서 Hosts 탭으로 이동하여 "Add"를 선택하여 인벤토리에 새 호스트를 추가합니다.

노드 이름은 기존 서버 접근과 동일한 규칙을 따릅니다. 예를 들어 Teleport 클러스터 이름이 example.teleport.sh이고 foo라는 노드가 있다면 foo.example.teleport.sh를 추가합니다. 하나 이상의 노드를 추가하고 다음 단계로 진행합니다.

향후 확장을 위해 스마트 인벤토리와 구성된 인벤토리를 포함한 Ansible AWX의 일반적인 도구를 사용하여 인벤토리를 구성할 수 있습니다.

5단계/5단계. Ansible 플레이북에서 자격 증명 사용#

tbot이 AWX 작업에 자격 증명을 제공하도록 설정되면 플레이북이 Teleport로 보호되는 호스트에 연결을 시작할 수 있습니다.

먼저 이 간단한 hello_world.yml 플레이북 예시로 시작하세요:

- name: Hello World Sample
  hosts: all
  gather_facts: false
  pre_tasks:
    - name: Wait for Teleport ssh_config to become available # noqa: run-once[task] (best effort)
      delegate_to: localhost
      run_once: true
      ansible.builtin.wait_for:
        path: /tbot-output/ssh_config
        state: present
        timeout: 120

    - name: Configure SSH via Teleport
      ansible.builtin.set_fact:
        ansible_ssh_common_args: "-F /tbot-output/ssh_config"

  tasks:
    # Teleport의 ssh_config가 준비될 때까지 SSH 접근을 기대할 수 없으므로
    # 처음에 gather_facts를 비활성화합니다. 이제 준비되었으므로 모듈을
    # 명시적으로 실행할 수 있습니다.
    - name: Gather facts
      ansible.builtin.setup:

    - name: "Print node hostname"
      ansible.builtin.command: "hostname"
      changed_when: false

이 예시는 Teleport 프록시를 통해 호스트에 안정적으로 접근하기 위해 몇 가지 단계를 수행합니다:

  • 초기 gather_facts는 SSH 프록시가 시작 시 즉시 준비되는 것을 기대할 수 없으므로 비활성화됩니다.
  • wait_for 작업은 tbot이 생성한 ssh_config가 디스크에 기록될 때까지 기다려 SSH 연결 요청을 수락할 준비가 되었음을 신호합니다.
  • 준비가 되면 ansible_ssh_common_args가 생성된 ssh_config를 가리키도록 설정되고 플레이북이 계속됩니다.
  • ansible.builtin.setup을 수동으로 실행하여 초기에 건너뛴 팩트를 수집합니다.

환경과 플레이북에 더 잘 맞도록 여기서 취하는 정확한 단계를 조정할 수 있습니다. 예를 들어 Teleport가 아닌 SSH 호스트로 플레이북을 재사용하기 위해 인벤토리 수준에서 ansible_ssh_common_args를 지정할 수 있습니다. 이 경우 호스트에 연결하기 전에 Teleport ssh_config가 사용 준비가 되었는지 플레이북이 여전히 확인하도록 하세요.

AWX 작업에서 새 tbot 지원 컨테이너 그룹을 사용하여 플레이북을 실행할 준비가 되면 다음을 수행합니다:

  1. 이 두 파일을 Git 저장소에 커밋합니다.
  2. AWX 대시보드에서 해당 저장소를 가리키는 새 프로젝트를 만들고 Git 저장소에 동기화되어 있는지 확인합니다.
  3. 새 작업 템플릿을 만들고 다음 값을 설정합니다:
    • 선택 대화 상자를 사용하여 4단계에서 만든 인벤토리를 선택합니다.
    • 선택 대화 상자에서 방금 만든 프로젝트를 선택합니다.
    • 드롭다운에서 hello_world.yml 플레이북을 선택합니다.
    • 선택 대화 상자에서 3단계에서 만든 인스턴스 그룹을 선택합니다.
    • 노드 호스트 이름 출력을 보려면 드롭다운에서 상세 수준 "1 (Verbose)"를 선택합니다.
  4. 환경에 따라 필요한 추가 커스터마이즈를 수행합니다.

완료되면 새 작업 템플릿을 저장합니다. 결과 세부 페이지에서 "Launch"를 선택하여 작업을 실행합니다. 성공하면 성공적인 작업 실행을 볼 수 있습니다. 상세 로깅이 활성화된 경우 각 인벤토리 노드에 대한 로그 출력에서 "stdout": "$hostname"을 볼 수 있습니다.

문제 해결#

Ansible이 "Shared connection to foo.example.teleport.sh closed."와 같은 오류로 Teleport 호스트에 연결하지 못하는 경우#

이는 수정된 Teleport 버그로 인한 것이며 최신 Teleport 릴리즈로 업그레이드하면 가장 잘 해결됩니다. 그렇지 않으면 프로젝트에 다음 내용이 포함된 ansible.cfg를 통해 OpenSSH의 내장 멀티플렉싱을 비활성화하여 ControlMaster 문제를 해결할 수 있습니다:

[ssh_connection]
ssh_args = -o ControlMaster=no -o ControlPersist=no

tbot 클라이언트를 자체 멀티플렉서(ssh-multiplexer 서비스를 통해)를 제공하도록 설정했으므로 성능은 동등해야 합니다.

OIDC 조인 수동 설정#

어떤 이유로 tctl tokens configure-kube가 작동하지 않거나 토큰 및 기타 Teleport 리소스를 수동으로 설정하려는 경우 다음 단계를 따를 수 있습니다.

먼저 세 개의 새 Teleport 리소스를 만들어야 합니다:

  1. tbot 사이드카가 원하는 SSH 노드에 접근할 수 있도록 권한을 부여하는 Teleport 역할
  2. 봇에 이름을 지정하고 허용 역할 목록을 지정하는 봇 리소스
  3. 봇이 Teleport에 인증할 수 있게 하는 조인 토큰

이 예시에서는 AWX 작업이 봇이 Kubernetes static_jwks 조인 모드를 사용하여 조인할 수 있는 Kubernetes 클러스터에서 실행된다고 가정합니다.

OIDC 조인

Amazon EKS, Azure AKS, Google Kubernetes Engine과 같은 클라우드 공급자에서 실행되는 Kubernetes 클러스터는 JWKS 키를 자주 순환하므로 Kubernetes OIDC 조인을 사용해야 합니다. 이러한 공급자에서 조인 토큰을 설정하는 방법은 Kubernetes OIDC 조인 가이드를 참조하세요.

표준 지침에 설명된 tctl tokens configure-kube 헬퍼가 자동으로 최적의 Kubernetes 조인 유형을 감지합니다.

클러스터의 JWKS 키를 확인하려면 다음 명령을 실행합니다:

$ kubectl get --raw /openid/v1/jwks
{"keys":[--snip--]}

이 키를 사용하면 Teleport가 인증하려는 봇이 신뢰할 수 있는 Kubernetes 클러스터에서 서명된 JWT를 사용하고 있는지 확인할 수 있습니다. 다음 단계를 위해 이 값을 유지하세요.

다음으로, 위에서 설명한 세 가지 리소스를 포함하는 awx-bot-resources.yaml을 만듭니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    # Linux 사용자 'root'로 로그인 허용.
    logins: ['root']
    # 모든 노드에 대한 연결 허용. Ansible 작업이 접근해야 하는
    # 노드에만 일치하도록 이 레이블을 조정하세요.
    node_labels:
      '*': '*'
---
kind: bot
version: v1
metadata:
  # name은 클러스터에서 봇의 고유 식별자입니다.
  name: awx-bot
spec:
  # roles는 봇에 부여할 역할 목록입니다. 위의 역할을 포함하지만
  # Ansible 작업을 통해 접근하려는 모든 노드에 봇의 SSH 접근을 허용하는
  # 추가 역할을 추가할 수 있습니다.
  roles: [example-role]
---
kind: token
version: v2
metadata:
  # name은 이 토큰을 사용하는 `tbot`에서 지정됩니다.
  name: awx-bot
spec:
  roles: [Bot]
  # bot_name은 위의 봇 리소스 이름과 일치해야 합니다.
  bot_name: awx-bot
  join_method: kubernetes
  kubernetes:
    # static_jwks는 Auth Service가 정적으로 설정된 JWKS의 공개 키를 사용하여
    # `tbot`이 제시한 JWT를 검증하도록 설정합니다.
    type: static_jwks
    static_jwks:
      jwks: |
        # 이 섹션(이 주석 포함)을 위에서 검색한 JWKS 키로 교체하세요.
        {"keys":[--snip--]}
    # allow는 Auth Service가 `tbot`의 조인 허용 여부를 결정하는 규칙을 지정합니다.
    allow:
    - service_account: "awx" />:default" # namespace:service_account

필요에 따라 이 설정을 조정하세요:

  • Ansible 작업 실행에 필요한 노드와 로그인만으로 접근을 제한하도록 예시 역할의 loginsnode_labels 필드를 조정하세요.
  • 봇 정의의 spec.roles 목록에 추가하여 봇에 원하는 추가 역할을 부여하세요.
  • 토큰의 spec.kubernetes.static_jwks.jwks 필드 값을 위에서 검색한 JWKS 키로 교체하세요.
  • AWX 작업이 실행될 네임스페이스와 서비스 계정과 일치하도록 토큰의 spec.kubernetes.allow 항목을 조정하세요.

준비가 되면 다음 명령을 실행하여 Teleport 클러스터에 리소스를 만듭니다:

$ tctl create -f awx-bot-resources.yaml

이 리소스가 만들어지면 2단계부터 계속 진행합니다.

다음 단계#

AWX 프로젝트는 Red Hat, Inc.의 상표이며 허가를 받아 사용합니다.

Ansible AWX와 함께하는 머신 및 워크로드 아이덴티티

원문 보기
요약

Ansible AWX(이전에 Ansible Tower라고 알려진)는 Ansible 위에서 Ansible 워크플로를 실행하고 조율하는 데 사용할 수 있는 인터페이스입니다. 이 가이드는 오픈 소스 Ansible AWX와 오픈 소스 Ansible AWX 엔진 위에 구축된 Red Hat의 상용 Ansible Automation Platform 자동화 컨트롤러 모두에 적용됩니다.

Ansible AWX(이전에 Ansible Tower라고 알려진)는 Ansible 위에서 Ansible 워크플로를 실행하고 조율하는 데 사용할 수 있는 인터페이스입니다. 이 워크플로는 SSH를 통해 원격 호스트에 연결하며 인증 방식이 필요합니다. 머신 및 워크로드 아이덴티티는 AWX를 통해 실행되는 Ansible 작업에 단기 인증서를 제공하여 작업이 Teleport에 등록된 SSH 노드에 안전하고 감사 가능한 방식으로 연결할 수 있게 합니다.

이 가이드는 오픈 소스 Ansible AWX와 오픈 소스 Ansible AWX 엔진 위에 구축된 Red Hat의 상용 Ansible Automation Platform 자동화 컨트롤러 모두에 적용됩니다.

작동 방식#

이 가이드에서는 Ansible AWX의 컨테이너 그룹이 머신 및 워크로드 아이덴티티 에이전트 tbot을 사이드카로 실행하도록 설정합니다. 이는 Ansible AWX 작업에 자격 증명과 고성능 멀티플렉싱 프록시를 제공합니다. 그런 다음 Ansible이 이 자격 증명을 사용하여 Teleport Proxy Service를 통해 SSH 노드에 연결하도록 설정합니다.

사전 조건#

  • A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
      $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
      
    2. Follow the instructions for your platform to install tctl and tsh clients:

  • 접근 가능한 Kubernetes 클러스터에서 실행 중인 Ansible AWX(또는 Ansible Tower, Ansible Automation Platform) 설치본.
  • 로컬 머신에 kubectl 클라이언트가 설치되어 있고 Ansible AWX가 실행 중인 Kubernetes 클러스터에 접근하도록 설정되어 있어야 합니다.
  • 새 컨테이너 그룹을 만들 권한이 있어야 합니다.
  • 이 가이드는 Kubernetes 외부에서 실행되는 인스턴스 그룹에는 적용되지 않습니다. 이 경우 기존 Ansible 노드로 취급하고 기존 Ansible 가이드를 따르세요.
  • 선택 사항이지만, 이 가이드에서 수행할 단계의 기반이 되는 Kubernetes에 tbot을 배포하는 방법을 자세히 알려면 Kubernetes에 tbot 배포 또는 OIDC를 사용한 Kubernetes에 tbot 배포 가이드를 읽어보세요.

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

1단계/5단계. Teleport 리소스 설정#

먼저 세 개의 새 Teleport 리소스를 만들어야 합니다:

  1. tbot 사이드카가 원하는 SSH 노드에 접근할 수 있도록 권한을 부여하는 Teleport 역할
  2. 봇에 이름을 지정하고 허용 역할 목록을 지정하는 봇 리소스
  3. 봇이 Teleport에 인증할 수 있게 하는 조인 토큰(join token)
수동 설정

수동으로 조인을 설정하거나 Terraform 또는 다른 도구와 함께 사용하는 수동 단계로 적용하려면 아래의 대안 단계를 참조하세요.

먼저 역할과 봇을 만듭니다. 다음 내용으로 awx-bot-resources.yaml을 만듭니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    # Linux 사용자 'root'로 로그인 허용.
    logins: ['root']
    # 모든 노드에 대한 연결 허용. Ansible 작업이 접근해야 하는
    # 노드에만 일치하도록 이 레이블을 조정하세요.
    node_labels:
      '*': '*'
---
kind: bot
version: v1
metadata:
  # name은 클러스터에서 봇의 고유 식별자입니다.
  name: awx-bot
spec:
  # roles는 봇에 부여할 역할 목록입니다. 위의 역할을 포함하지만
  # Ansible 작업을 통해 접근하려는 모든 노드에 봇의 SSH 접근을 허용하는
  # 추가 역할을 추가할 수 있습니다.
  roles: [example-role]

필요에 따라 이 설정을 조정하세요:

  • Ansible 작업 실행에 필요한 노드와 로그인만으로 접근을 제한하도록 예시 역할의 loginsnode_labels 필드를 조정하세요.
  • 봇 정의의 spec.roles 목록에 추가하여 봇에 원하는 추가 역할을 부여하세요.

준비가 되면 다음 명령을 실행하여 Teleport 클러스터에 리소스를 만듭니다:

$ tctl create -f awx-bot-resources.yaml

다음으로, tctl tokens configure-kube를 사용하여 사용할 최적의 Kubernetes 조인 방법을 자동으로 감지하고 조인 토큰을 자동으로 만듭니다. 다음을 실행합니다:

$ tctl tokens configure-kube \
  --bot awx-bot \
  --namespace  \
  --service-account default \
  --token-name awx-bot

기본적으로 configure-kube 헬퍼는 현재 선택된 kubectl 컨텍스트를 사용하므로 계속하기 전에 kubectl이 원하는 Kubernetes 클러스터에 접근하도록 설정되어 있는지 확인하세요. 필요한 경우 --context 플래그를 사용하여 대안 컨텍스트를 선택할 수 있습니다. 유용한 파라미터의 전체 목록은 tctl tokens configure-kube --help로 볼 수 있습니다.

플래그를 적절히 조정한 후 명령을 실행하면 사용 가능한 최적의 조인 방법을 감지하고 봇이 사용할 조인 토큰을 만듭니다. 출력되는 helm 지침은 무시하고 생성되는 values.yaml은 삭제할 수 있습니다 - 이 가이드에서는 teleport/tbot Helm 차트를 사용하지 않습니다.

원하는 경우 다음 명령을 실행하여 생성된 조인 토큰을 확인할 수 있습니다:

$ tctl get token/awx-bot

...하지만 다음 단계에서 토큰 이름(awx-bot)만 알면 됩니다.

2단계/5단계. Kubernetes 리소스 설정#

다음으로 AWX 작업이 실행될 Kubernetes 클러스터에 ConfigMap 리소스를 준비합니다. 이 ConfigMap에는 머신 및 워크로드 아이덴티티 에이전트 tbot의 설정이 포함됩니다. 특히:

  • Teleport 클러스터의 주소
  • 이전 단계에서 만든 조인 토큰을 사용하여 Teleport 클러스터에 조인하는 방법
  • 봇이 내부 데이터를 저장할 위치(AWX 작업이 일시적이므로 메모리에 저장)
  • 봇이 실행할 추가 서비스, 이 경우 SSH 노드에 대한 효율적인 접근을 제공하는 ssh-multiplexer

수동으로 설정해야 하는 유일한 Kubernetes 리소스는 tbotConfigMap입니다.

다음을 configmap-tbot-awx-config.yaml에 작성합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: tbot-awx-config
  namespace:  name="awx" />
data:
  tbot.yaml: |
    version: v2
    onboarding:
      join_method: kubernetes
      # token이 이전에 만든 조인 토큰 이름으로 설정되어 있는지 확인하세요
      token: awx-bot
    storage:
      # kubernetes 조인 방법은 지속성이 필요하지 않으므로
      # 봇 자체 상태에는 메모리 대상을 사용합니다.
      type: memory
    # Teleport Proxy Service의 주소로 설정되어 있는지 확인하세요.
    proxy_server: :443
    services:
    # `ssh-multiplexer` 서비스는 Ansible 작업에서 사용할
    # 고성능 멀티플렉서 소켓을 제공합니다.
    - type: ssh-multiplexer
      # 이 경로(/tbot/)는 `tbot-binaries` 공유 볼륨의
      # 볼륨 마운트와 일치해야 합니다.
      proxy_command: ["/tbot/fdpass-teleport"]
      destination:
        type: directory
        # 자격 증명과 멀티플렉서 소켓이 생성될 파드의 경로입니다.
        # AWX 컨테이너 그룹 템플릿에서 설정한 대로 워커 컨테이너와
        # tbot 컨테이너 모두의 볼륨 마운트와 일치해야 합니다.
        path: "/tbot-output"

이 설정 파일의 가능한 값에 대한 자세한 내용은 Machine ID의 설정 레퍼런스를 참조하세요.

ssh-multiplexer에 대하여

Machine ID의 ssh-multiplexer 서비스는 많은 SSH 연결을 열 때 성능을 향상시키는 데 사용됩니다. fdpass-teleport 실행 파일이 Teleport에 대한 단일 공유 연결을 통해 새 SSH 세션을 열 수 있는 Unix 소켓을 제공합니다. /tbot-output/ssh_config에 기록된 SSH 설정이 이를 수행하도록 자동으로 설정됩니다.

ssh-multiplexer 서비스에 대한 자세한 내용은 레퍼런스 페이지를 참조하세요.

ConfigMap 리소스는 환경에 맞게 조정해야 할 수 있습니다. 여기서는 AWX 작업이 네임스페이스에서 실행되고 의 Teleport 클러스터에서 자격 증명을 가져와야 한다고 가정합니다. 준비가 되면 리소스를 만듭니다:

$ kubectl create -f configmap-tbot-awx-config.yaml

또한 아래에서 설정할 기본 AWX 컨테이너 그룹 템플릿과 일치하는 기본 서비스 네임스페이스 서비스 계정을 사용한다는 점에 주의하세요. 사용자 지정 서비스 계정을 사용하려면 생성해야 하는 Kubernetes RBAC 리소스와 해당 계정의 조인을 허용하기 위해 Teleport 토큰에 필요한 조정 사항에 대한 예시를 보려면 일반 Kubernetes 가이드를 참조하세요.

3단계/5단계. 새 컨테이너 그룹 만들기#

파드 스펙 변경 요약#

이 섹션은 Ansible AWX에서 실행되는 워크플로에서 Teleport의 리소스에 접근하는 한 가지 방법만 설명하며, 환경에 맞게 여기서 설명하는 단계를 조정해야 할 수 있습니다.

이 가이드에서 기본 파드 스펙에 적용할 변경 사항과 직접 구현할 때 고려할 수 있는 대안을 간단히 요약합니다:

  1. tbotfdpass-teleport 바이너리를 실행 환경에서 사용할 수 있어야 합니다. Teleport initContainer를 사용하여 이 바이너리를 임의의 실행 환경(예: awx-ee)에 복사하지만, 직접 EE를 구축한다면 이 Teleport 바이너리를 EE에 직접 설치하고 initContainer를 사용할 필요가 없습니다.
  2. tbot 사이드카가 추가되어 Teleport에 연결하고 SSH 자격 증명을 가져와 업데이트하며, Teleport가 관리하는 SSH 호스트에 대한 효율적인 SSH 연결을 위한 ssh-multiplexer 소켓을 제공합니다.
  3. 파드 스펙에 네 개의 추가 볼륨이 추가됩니다:
    1. Kubernetes 조인에 사용되는 프로젝션된 서비스 계정 토큰(join-sa-token)
    2. Teleport 바이너리를 포함하는 emptyDir 볼륨(tbot-binaries)
    3. 생성된 Teleport SSH 자격 증명을 포함하는 emptyDir 볼륨(tbot-output)
    4. tbot 사이드카에 사용되는 YAML 설정을 포함하는 configMap 볼륨(tbot-config)
  4. 여러 볼륨 마운트가 추가됩니다:
    1. tbot-binaries 볼륨이 "tbot-installer" initContainerawx-ee 워커 컨테이너 모두에 마운트되어 Ansible 작업이 런타임에 바이너리를 실행할 수 있습니다.
    2. tbot-output 볼륨이 awx-ee 워커 컨테이너와 tbot 사이드카 모두에 마운트되어 런타임에 생성된 자격 증명을 Ansible 작업과 공유할 수 있습니다.
    3. tbot-configjoin-sa-token 볼륨은 tbot 사이드카에만 마운트됩니다.

AWX 설정#

다음으로, Kubernetes(또는 OpenShift)에서 작업을 생성하는 새 컨테이너 인스턴스 그룹을 만들어야 합니다. 또한 파드 스펙을 커스터마이즈하여 awx-ee 워커 컨테이너와 함께 tbot을 사이드카로 실행하여 작업에 SSH 자격 증명을 제공합니다.

AWX 웹 UI에서 Administration, Instance Groups로 이동하여 "Add" 버튼을 선택하고 "Add container group"을 선택합니다. 원하는 이름을 입력하고 환경에 맞게 필드를 설정합니다.

AWX 버전

이 사용자 지정 파드 스펙은 Ansible AWX 버전 24.6.1용으로 작성되었습니다. 다른 버전을 사용하거나 환경에 추가적인 파드 스펙 변경이 필요한 경우, 아래 예시 파드 스펙을 주의 깊게 검토하고 필요한 조정을 해야 합니다.

다음으로 "Customize pod specification" 체크박스를 선택합니다. 기본 파드 스펙이 포함된 텍스트 필드가 나타납니다. 다음으로 교체합니다:

apiVersion: v1
kind: Pod
metadata:
  namespace:  name="awx" />
spec:
  serviceAccountName: default
  automountServiceAccountToken: false
  initContainers:
    - name: tbot-installer
      image: public.ecr.aws/gravitational/tbot-distroless:(=teleport.version=)
      command: ["tbot"]
      args: ["copy-binaries", "--include-fdpass", "/tbot"]
      volumeMounts:
        - name: tbot-binaries
          mountPath: /tbot
  containers:
    - image: quay.io/ansible/awx-ee:latest
      name: worker
      args:
        - ansible-runner
        - worker
        - '--private-data-dir=/runner'
      resources:
        requests:
          cpu: 250m
          memory: 100Mi
      volumeMounts:
        - name: tbot-binaries
          mountPath: /tbot
        - name: tbot-output
          mountPath: /tbot-output
    - name: tbot
      image: public.ecr.aws/gravitational/tbot-distroless:(=teleport.version=)
      command: ["tbot"]
      args:
        - start
        - -c
        - /config/tbot.yaml
      env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: KUBERNETES_TOKEN_PATH
          value: /var/run/secrets/tokens/join-sa-token
      volumeMounts:
        - mountPath: /config
          name: tbot-config
        - mountPath: /var/run/secrets/tokens
          name: join-sa-token
        - mountPath: /tbot-output
          name: tbot-output
      # awx-ee와 일치하도록 보안 컨텍스트 설정
      securityContext:
        runAsUser: 1000
        runAsGroup: 0
  volumes:
    - name: tbot-binaries
      emptyDir: {}
    - name: tbot-output
      emptyDir: {}
    - name: tbot-config
      configMap:
        name: tbot-awx-config
    - name: join-sa-token
      projected:
        sources:
          - serviceAccountToken:
              path: join-sa-token
              expirationSeconds: 600
              audience:  name="example.teleport.sh" />

환경에 따라 추가적인 변경이 필요할 수 있지만, 최소한 다음 필드를 조정하세요:

  • 최상위 metadata.namespace 필드는 AWX가 이 인스턴스 그룹에 대한 파드를 생성하는 네임스페이스와 일치해야 합니다.
  • join-sa-token 볼륨의 audience 필드는 Teleport 클러스터 이름으로 설정해야 합니다.
  • default 이외의 서비스 계정을 사용하려면 설정된 serviceAccountName을 조정해야 합니다.

필요한 모든 수정이 완료되면 "Save"를 선택하여 새 컨테이너 그룹 설정을 완료합니다.

4단계/5단계. 인벤토리 정의#

이 단계에서는 AWX에서 연결하는 방법을 보여주기 위해 Teleport SSH 호스트를 포함하는 간단한 인벤토리를 만듭니다.

Ansible AWX 웹 인터페이스에서 Teleport를 통해 접근 가능한 노드를 포함하는 인벤토리를 만듭니다. Resources, Inventories로 이동하여 "Add" 버튼을 선택한 다음 "Add inventory"를 선택합니다.

이름과 다른 필드를 원하는 대로 설정한 후 새 인벤토리를 저장합니다. 새 인벤토리의 세부 페이지에서 Hosts 탭으로 이동하여 "Add"를 선택하여 인벤토리에 새 호스트를 추가합니다.

노드 이름은 기존 서버 접근과 동일한 규칙을 따릅니다. 예를 들어 Teleport 클러스터 이름이 example.teleport.sh이고 foo라는 노드가 있다면 foo.example.teleport.sh를 추가합니다. 하나 이상의 노드를 추가하고 다음 단계로 진행합니다.

향후 확장을 위해 스마트 인벤토리와 구성된 인벤토리를 포함한 Ansible AWX의 일반적인 도구를 사용하여 인벤토리를 구성할 수 있습니다.

5단계/5단계. Ansible 플레이북에서 자격 증명 사용#

tbot이 AWX 작업에 자격 증명을 제공하도록 설정되면 플레이북이 Teleport로 보호되는 호스트에 연결을 시작할 수 있습니다.

먼저 이 간단한 hello_world.yml 플레이북 예시로 시작하세요:

- name: Hello World Sample
  hosts: all
  gather_facts: false
  pre_tasks:
    - name: Wait for Teleport ssh_config to become available # noqa: run-once[task] (best effort)
      delegate_to: localhost
      run_once: true
      ansible.builtin.wait_for:
        path: /tbot-output/ssh_config
        state: present
        timeout: 120

    - name: Configure SSH via Teleport
      ansible.builtin.set_fact:
        ansible_ssh_common_args: "-F /tbot-output/ssh_config"

  tasks:
    # Teleport의 ssh_config가 준비될 때까지 SSH 접근을 기대할 수 없으므로
    # 처음에 gather_facts를 비활성화합니다. 이제 준비되었으므로 모듈을
    # 명시적으로 실행할 수 있습니다.
    - name: Gather facts
      ansible.builtin.setup:

    - name: "Print node hostname"
      ansible.builtin.command: "hostname"
      changed_when: false

이 예시는 Teleport 프록시를 통해 호스트에 안정적으로 접근하기 위해 몇 가지 단계를 수행합니다:

  • 초기 gather_facts는 SSH 프록시가 시작 시 즉시 준비되는 것을 기대할 수 없으므로 비활성화됩니다.
  • wait_for 작업은 tbot이 생성한 ssh_config가 디스크에 기록될 때까지 기다려 SSH 연결 요청을 수락할 준비가 되었음을 신호합니다.
  • 준비가 되면 ansible_ssh_common_args가 생성된 ssh_config를 가리키도록 설정되고 플레이북이 계속됩니다.
  • ansible.builtin.setup을 수동으로 실행하여 초기에 건너뛴 팩트를 수집합니다.

환경과 플레이북에 더 잘 맞도록 여기서 취하는 정확한 단계를 조정할 수 있습니다. 예를 들어 Teleport가 아닌 SSH 호스트로 플레이북을 재사용하기 위해 인벤토리 수준에서 ansible_ssh_common_args를 지정할 수 있습니다. 이 경우 호스트에 연결하기 전에 Teleport ssh_config가 사용 준비가 되었는지 플레이북이 여전히 확인하도록 하세요.

AWX 작업에서 새 tbot 지원 컨테이너 그룹을 사용하여 플레이북을 실행할 준비가 되면 다음을 수행합니다:

  1. 이 두 파일을 Git 저장소에 커밋합니다.
  2. AWX 대시보드에서 해당 저장소를 가리키는 새 프로젝트를 만들고 Git 저장소에 동기화되어 있는지 확인합니다.
  3. 새 작업 템플릿을 만들고 다음 값을 설정합니다:
    • 선택 대화 상자를 사용하여 4단계에서 만든 인벤토리를 선택합니다.
    • 선택 대화 상자에서 방금 만든 프로젝트를 선택합니다.
    • 드롭다운에서 hello_world.yml 플레이북을 선택합니다.
    • 선택 대화 상자에서 3단계에서 만든 인스턴스 그룹을 선택합니다.
    • 노드 호스트 이름 출력을 보려면 드롭다운에서 상세 수준 "1 (Verbose)"를 선택합니다.
  4. 환경에 따라 필요한 추가 커스터마이즈를 수행합니다.

완료되면 새 작업 템플릿을 저장합니다. 결과 세부 페이지에서 "Launch"를 선택하여 작업을 실행합니다. 성공하면 성공적인 작업 실행을 볼 수 있습니다. 상세 로깅이 활성화된 경우 각 인벤토리 노드에 대한 로그 출력에서 "stdout": "$hostname"을 볼 수 있습니다.

문제 해결#

Ansible이 "Shared connection to foo.example.teleport.sh closed."와 같은 오류로 Teleport 호스트에 연결하지 못하는 경우#

이는 수정된 Teleport 버그로 인한 것이며 최신 Teleport 릴리즈로 업그레이드하면 가장 잘 해결됩니다. 그렇지 않으면 프로젝트에 다음 내용이 포함된 ansible.cfg를 통해 OpenSSH의 내장 멀티플렉싱을 비활성화하여 ControlMaster 문제를 해결할 수 있습니다:

[ssh_connection]
ssh_args = -o ControlMaster=no -o ControlPersist=no

tbot 클라이언트를 자체 멀티플렉서(ssh-multiplexer 서비스를 통해)를 제공하도록 설정했으므로 성능은 동등해야 합니다.

OIDC 조인 수동 설정#

어떤 이유로 tctl tokens configure-kube가 작동하지 않거나 토큰 및 기타 Teleport 리소스를 수동으로 설정하려는 경우 다음 단계를 따를 수 있습니다.

먼저 세 개의 새 Teleport 리소스를 만들어야 합니다:

  1. tbot 사이드카가 원하는 SSH 노드에 접근할 수 있도록 권한을 부여하는 Teleport 역할
  2. 봇에 이름을 지정하고 허용 역할 목록을 지정하는 봇 리소스
  3. 봇이 Teleport에 인증할 수 있게 하는 조인 토큰

이 예시에서는 AWX 작업이 봇이 Kubernetes static_jwks 조인 모드를 사용하여 조인할 수 있는 Kubernetes 클러스터에서 실행된다고 가정합니다.

OIDC 조인

Amazon EKS, Azure AKS, Google Kubernetes Engine과 같은 클라우드 공급자에서 실행되는 Kubernetes 클러스터는 JWKS 키를 자주 순환하므로 Kubernetes OIDC 조인을 사용해야 합니다. 이러한 공급자에서 조인 토큰을 설정하는 방법은 Kubernetes OIDC 조인 가이드를 참조하세요.

표준 지침에 설명된 tctl tokens configure-kube 헬퍼가 자동으로 최적의 Kubernetes 조인 유형을 감지합니다.

클러스터의 JWKS 키를 확인하려면 다음 명령을 실행합니다:

$ kubectl get --raw /openid/v1/jwks
{"keys":[--snip--]}

이 키를 사용하면 Teleport가 인증하려는 봇이 신뢰할 수 있는 Kubernetes 클러스터에서 서명된 JWT를 사용하고 있는지 확인할 수 있습니다. 다음 단계를 위해 이 값을 유지하세요.

다음으로, 위에서 설명한 세 가지 리소스를 포함하는 awx-bot-resources.yaml을 만듭니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    # Linux 사용자 'root'로 로그인 허용.
    logins: ['root']
    # 모든 노드에 대한 연결 허용. Ansible 작업이 접근해야 하는
    # 노드에만 일치하도록 이 레이블을 조정하세요.
    node_labels:
      '*': '*'
---
kind: bot
version: v1
metadata:
  # name은 클러스터에서 봇의 고유 식별자입니다.
  name: awx-bot
spec:
  # roles는 봇에 부여할 역할 목록입니다. 위의 역할을 포함하지만
  # Ansible 작업을 통해 접근하려는 모든 노드에 봇의 SSH 접근을 허용하는
  # 추가 역할을 추가할 수 있습니다.
  roles: [example-role]
---
kind: token
version: v2
metadata:
  # name은 이 토큰을 사용하는 `tbot`에서 지정됩니다.
  name: awx-bot
spec:
  roles: [Bot]
  # bot_name은 위의 봇 리소스 이름과 일치해야 합니다.
  bot_name: awx-bot
  join_method: kubernetes
  kubernetes:
    # static_jwks는 Auth Service가 정적으로 설정된 JWKS의 공개 키를 사용하여
    # `tbot`이 제시한 JWT를 검증하도록 설정합니다.
    type: static_jwks
    static_jwks:
      jwks: |
        # 이 섹션(이 주석 포함)을 위에서 검색한 JWKS 키로 교체하세요.
        {"keys":[--snip--]}
    # allow는 Auth Service가 `tbot`의 조인 허용 여부를 결정하는 규칙을 지정합니다.
    allow:
    - service_account: "awx" />:default" # namespace:service_account

필요에 따라 이 설정을 조정하세요:

  • Ansible 작업 실행에 필요한 노드와 로그인만으로 접근을 제한하도록 예시 역할의 loginsnode_labels 필드를 조정하세요.
  • 봇 정의의 spec.roles 목록에 추가하여 봇에 원하는 추가 역할을 부여하세요.
  • 토큰의 spec.kubernetes.static_jwks.jwks 필드 값을 위에서 검색한 JWKS 키로 교체하세요.
  • AWX 작업이 실행될 네임스페이스와 서비스 계정과 일치하도록 토큰의 spec.kubernetes.allow 항목을 조정하세요.

준비가 되면 다음 명령을 실행하여 Teleport 클러스터에 리소스를 만듭니다:

$ tctl create -f awx-bot-resources.yaml

이 리소스가 만들어지면 2단계부터 계속 진행합니다.

다음 단계#

AWX 프로젝트는 Red Hat, Inc.의 상표이며 허가를 받아 사용합니다.