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 노드에 연결하도록 구성합니다.

사전 요구사항#

• 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

• tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     

       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

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

Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음, 현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.

예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의 도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여 다음 명령을 실행합니다:

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

cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다. 자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를 호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.

1/5단계. Teleport 리소스 구성#

먼저, 다음 세 가지 새 Teleport 리소스를 생성해야 합니다:

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

먼저, 역할과 봇을 생성하겠습니다. 다음 내용으로 awx-bot-resources.yaml을 생성합니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    # Allow login to the Linux user 'root'.
    logins: ['root']
    # Allow connection to any node. Adjust these labels to match only nodes
    # your Ansible jobs need to access.
    node_labels:
      '*': '*'
---
kind: bot
version: v1
metadata:
  # name is a unique identifier for the Bot in the cluster.
  name: awx-bot
spec:
  # roles is a list of roles to grant to the Bot. This includes the role above,
  # but you can add any additional roles needed to grants the bot SSH access to
  # all the nodes you want to access via your Ansible jobs.
  roles: [example-role]

필요에 따라 이 구성을 다음과 같이 조정하세요:

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

준비가 완료되면 다음 명령을 실행하여 Teleport 클러스터에 리소스를 생성합니다:

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

다음으로, tctl tokens configure-kube를 사용하여 사용할 최적의 Kubernetes 조인 방식을 자동으로 감지하고 조인 토큰을 자동으로 생성하겠습니다. 다음을 실행하세요:

$ tctl tokens configure-kube \
  --bot awx-bot \
  --namespace awx \
  --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 리소스는 tbot용 ConfigMap입니다.

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: tbot-awx-config
  namespace: awx
data:
  tbot.yaml: |
    version: v2
    onboarding:
      join_method: kubernetes
      # ensure token is set to the name of the join token you created earlier
      token: awx-bot
    storage:
      # a memory destination is used for the bots own state since the kubernetes
      # join method does not require persistence.
      type: memory
    # ensure this is configured to the address of your Teleport Proxy Service.
    proxy_server: example.teleport.sh:443
    services:
    # The `ssh-multiplexer` service provides a high-performance multiplexer
    # socket for use in Ansible jobs.
    - type: ssh-multiplexer
      # This path (/tbot/) must match the volume mount for the `tbot-binaries`
      # shared volume.
      proxy_command: ["/tbot/fdpass-teleport"]
      destination:
        type: directory
        # The path in the pod where credentials and the multiplexer socket will
        # be created. This must match the volume mounts for both the worker and
        # tbot containers as configured in your AWX container group template.
        path: "/tbot-output"

이 구성 파일에 사용 가능한 값에 대한 자세한 내용은 Machine ID의 구성 참조를 확인하세요.

이 ConfigMap 리소스는 사용자의 환경에 맞게 조정해야 할 수도 있습니다. 여기서는 AWX 작업이 네임스페이스 awx에서 실행되고, 자격 증명은 example.teleport.sh의 Teleport 클러스터에서 가져온다고 가정합니다. 준비가 완료되면 리소스를 생성합니다:

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

또한 아래에서 구성할 기본 AWX 컨테이너 그룹 템플릿과 일치하도록 기본 서비스 네임스페이스 서비스 계정을 사용한다는 점에 유의하세요. 커스텀 서비스 계정을 만들고 싶다면, 생성해야 할 Kubernetes RBAC 리소스와 해당 계정이 조인할 수 있도록 Teleport 토큰에 필요한 조정 사항의 예시는 일반 Kubernetes 가이드를 참고하세요.

3/5단계. 새 컨테이너 그룹 생성#

파드 스펙 변경 사항 요약#

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

이 가이드에서 기본 파드 스펙에 적용할 변경 사항을 간략히 정리하면 다음과 같으며, 직접 구현할 때 고려할 수 있는 대안도 함께 소개합니다:

1. tbot 및 fdpass-teleport 바이너리를 실행 환경에서 사용할 수 있도록 해야 합니다. 이 가이드에서는 Teleport initContainer를 사용하여 이러한 바이너리를 (awx-ee와 같은) 임의의 실행 환경에 복사하지만, 자체 EE를 빌드하는 경우에는 이러한 Teleport 바이너리를 EE에 직접 설치할 수 있으며 initContainer를 사용할 필요가 없습니다.
2. Teleport에 연결하고, SSH 자격 증명을 가져오고 갱신하며, Teleport로 관리되는 SSH 호스트에 효율적으로 연결할 수 있도록 ssh-multiplexer 소켓을 제공하는 tbot 사이드카가 추가됩니다.
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" initContainer와 awx-ee 워커 컨테이너 모두에 마운트되어, Ansible 작업이 런타임에 바이너리를 실행할 수 있습니다
   2. tbot-output 볼륨은 awx-ee 워커 컨테이너와 tbot 사이드카 모두에 마운트되어, tbot이 런타임에 생성한 자격 증명을 Ansible 작업과 공유할 수 있습니다
   3. tbot-config 및 join-sa-token 볼륨은 tbot 사이드카에만 마운트됩니다

AWX 구성#

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

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

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

apiVersion: v1
kind: Pod
metadata:
  namespace: 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
      # Configure security context to match 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: 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:
    # We have to disable gather_facts at the start because we can't expect to
    # have SSH access until Teleport's ssh_config is ready. Now that it is, we
    # can run the module explicitly.
    - name: Gather facts
      ansible.builtin.setup:

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

이 예시는 Teleport Proxy를 통해 안정적으로 호스트에 접근할 수 있도록 다음과 같은 몇 가지 단계를 거칩니다:

• 시작 시점에는 SSH 프록시가 준비되어 있다고 보장할 수 없으므로 초기 gather_facts는 비활성화됩니다
• wait_for 작업은 tbot이 생성한 ssh_config가 디스크에 기록되기를 기다리며, 이는 SSH 연결 요청을 받을 준비가 되었음을 나타냅니다
• 준비가 완료되면 ansible_ssh_common_args가 생성된 ssh_config를 가리키도록 설정되고 플레이북이 계속 진행됩니다
• 처음에 건너뛰었던 팩트 수집을 위해 ansible.builtin.setup이 수동으로 실행됩니다

환경과 플레이북에 더 적합하도록 여기서 수행하는 정확한 단계를 조정하고 싶을 수 있습니다. 예를 들어 Teleport를 사용하지 않는 SSH 호스트와 플레이북을 재사용하기 위해 인벤토리 수준에서 ansible_ssh_common_args를 지정하고 싶을 수 있습니다. 이 경우, 호스트에 연결을 시도하기 전에 Teleport의 ssh_config가 사용 준비가 되었는지 플레이북에서 반드시 확인하도록 하세요.

준비가 완료되면 새로 만든 tbot이 활성화된 컨테이너 그룹을 사용하여 AWX 작업에서 플레이북을 실행하기 위해 다음을 수행합니다:

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

완료되면 새 작업 템플릿을 저장합니다. 결과로 나타나는 세부 정보 페이지에서 "Launch"를 선택하여 작업을 실행합니다. 성공하면 성공적인 작업 실행이 표시됩니다. verbose 로깅이 활성화되어 있었다면, 각 인벤토리 노드에 대한 로그 출력에서 "stdout": "$hostname"을 확인할 수 있습니다.

문제 해결#

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

이는 수정된 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 클러스터에서 실행된다고 가정합니다.

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

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

이 키들은 인증을 시도하는 봇이 신뢰할 수 있는 Kubernetes 클러스터에서 서명된 JWT를 사용하고 있는지 Teleport가 검증할 수 있게 해줍니다. 이 값을 다음 단계를 위해 보관해 두세요.

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

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    # Allow login to the Linux user 'root'.
    logins: ['root']
    # Allow connection to any node. Adjust these labels to match only nodes
    # your Ansible jobs need to access.
    node_labels:
      '*': '*'
---
kind: bot
version: v1
metadata:
  # name is a unique identifier for the Bot in the cluster.
  name: awx-bot
spec:
  # roles is a list of roles to grant to the Bot. This includes the role above,
  # but you can add any additional roles needed to grants the bot SSH access to
  # all the nodes you want to access via your Ansible jobs.
  roles: [example-role]
---
kind: token
version: v2
metadata:
  # name will be specified in the `tbot` to use this token
  name: awx-bot
spec:
  roles: [Bot]
  # bot_name should match the name of the bot resource above
  bot_name: awx-bot
  join_method: kubernetes
  kubernetes:
    # static_jwks configures the Auth Service to validate the JWT presented by
    # `tbot` using the public key from a statically configured JWKS.
    type: static_jwks
    static_jwks:
      jwks: |
        # Replace this section (including this comment) with the JWKS keys you
        # retrieved above.
        {"keys":[--snip--]}
    # allow specifies the rules by which the Auth Service determines if `tbot`
    # should be allowed to join.
    allow:
    - service_account: "awx:default" # namespace:service_account

필요에 따라 이 구성을 다음과 같이 조정하세요:

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

준비가 완료되면 다음 명령을 실행하여 Teleport 클러스터에 리소스를 생성합니다:

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

이 리소스들이 생성되었다면, 2단계부터 계속 진행하세요.

다음 단계#

• Kubernetes에 tbot 배포에 대해 자세히 알아보세요
• 사용 가능한 모든 구성 옵션을 살펴보려면 구성 참조를 읽어보세요

AWX Project는 Red Hat, Inc.의 상표이며, 허가를 받아 사용됩니다.