Documentation

10. 인증 정보

인증 정보는 머신에 대해 작업을 시작하고, 인벤토리 소스와 동기화하고, 버전 제어 시스템에서 프로젝트 콘텐츠를 가져올 때 인증에 사용됩니다.

인증 정보를 사용자에게 실제로 노출하지 않고도 이러한 인증 정보를 사용할 수 있는 기능을 사용자 및 팀에 부여할 수 있습니다. 사용자가 다른 팀으로 이동하거나 조직을 떠나는 경우 |at|에서 해당 인증 정보를 사용할 수 있었기 때문에 모든 시스템을 다시 입력할 필요가 없습니다.

참고

|at|는 데이터베이스의 암호 및 키 정보를 암호화하고 API를 통해 시크릿 정보를 표시하지 않습니다. 자세한 내용은 :ref:`Automation Controller Administration Guide <administration:ag_secret_handling>`를 참조하십시오.

10.1. 인증 정보 작동 방식 이해

|at|에서는 SSH를 사용하여 원격 호스트(또는 Windows와 동등한 시스템)에 연결합니다. |at|에서 SSH로 키를 전달하려면 키의 암호를 해독해야 이름이 지정된 파이프를 작성할 수 있습니다. 그러면 |at|에서 해당 파이프를 사용하여 SSH로 키를 보냅니다(디스크에 기록되지 않음).

암호를 사용하는 경우 |at|는 암호 프롬프트에 직접 응답하고 프롬프트에 쓰기 전에 암호를 해독하여 처리합니다.

10.2. 인증 정보 시작하기

왼쪽 탐색 모음에서 **인증 정보**를 클릭하여 인증 정보 페이지에 액세스합니다. 인증 정보 페이지에는 사용 가능한 모든 인증 정보로 구성된 검색 가능한 목록이 표시되고, **이름**으로 정렬할 수 있습니다.

Credentials - home with example credentials

팀에 추가된 인증 정보는 팀의 모든 멤버가 사용할 수 있지만 사용자에게 추가된 인증 정보는 기본적으로 해당 사용자만 사용할 수 있습니다.

참고

다른 작업 항목에서 사용하는 항목을 삭제하면 삭제의 영향을 받는 항목이 나열된 메시지가 열리고, 삭제를 확인하라는 메시지가 표시됩니다. 일부 화면에는 유효하지 않거나 이전에 삭제된 항목이 포함되며 이러한 항목은 실행되지 않습니다. 다음은 이러한 메시지의 예입니다.

_images/warning-deletion-dependencies.png

시작하는 데 도움이 되도록 데모 인증 정보가 생성되어 있어 사용할 수 있습니다.

데모 인증 정보**에 대한 링크를 클릭하면 이 인증 정보의 **세부 정보 뷰로 이동합니다.

Credentials - home with demo credential details

액세스 탭을 클릭하면 이 인증 정보 및 부여된 역할(소유자, 관리자, 감사자 등)과 연결된 사용자 및 팀이 표시됩니다.

Credentials - home with permissions credential details

참고

역할이 연결된 인증 정보는 다른 조직에 다시 할당된 후에도 유지됩니다.

추가 버튼을 클릭하여 이 데모 인증 정보**를 추가 사용자에게 할당할 수 있습니다. 사용자가 존재하지 않는 경우 **사용자 메뉴에서 추가하고 자세한 내용은 사용자 섹션을 참조하십시오.

10.3. 새 인증 정보 추가

새 인증 정보를 생성하려면 다음을 수행합니다.

  1. 인증 정보 화면에서 추가 버튼을 클릭합니다.

Create credential

  1. 이름 필드에 새 인증 정보 이름을 입력합니다.

  2. 필요한 경우 설명을 입력하고 인증 정보가 연결된 조직의 이름을 입력하거나 선택합니다.

참고

한 조직과 연결된 권한 세트가 있는 인증 정보는 인증 정보를 다른 조직에 다시 할당한 후에도 유지됩니다.

  1. 생성할 인증 정보 유형을 입력하거나 선택합니다.

_images/credential-types-drop-down-menu.png
  1. 다음 섹션, :ref:`ug_credentials_cred_types`에 설명된 대로 선택한 인증 정보 유형에 따라 적절한 세부 정보를 입력합니다.

  2. 완료되면 **저장**을 클릭합니다.

10.4. 인증 정보 유형

|at|에서 지원되는 인증 정보 유형은 다음과 같습니다.

The credential types associated with Centrify, CyberArk, HashiCorp Vault, Microsoft Azure Key Management System (KMS), and Thycotic are part of the credential plugins capability that allows an external system to lookup your secrets information. See the 시크릿 관리 시스템 section for further detail.

10.4.1. Amazon Web Services

이 인증 정보 유형을 선택하면 Amazon Web Services와 클라우드 인벤토리의 동기화가 활성화됩니다.

다음은 |at|에서 AWS 인증 정보로 사용하는 환경 변수로, 사용자 인터페이스에서 입력하도록 요청하는 필드입니다.

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SECURITY_TOKEN

Credentials - create AWS credential

기존 Amazon Web Services 인증 정보는 AWS **액세스 키**와 **시크릿 키**로 구성됩니다.

|at|는 EC2 STS 토큰(IAM STS 인증 정보라고도 함)을 지원합니다. STS(Security Token Service)는 AWS Identity and Access Management(IAM) 사용자에 대해 권한이 제한된 임시 자격 증명을 요청할 수 있는 웹 서비스입니다. IAM/EC2 STS 토큰에 대한 자세한 내용은 http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html을 참조하십시오.

참고

EC2의 태그 값에 부울(Yes/No/True/False)이 포함되는 경우 따옴표로 묶어야 합니다.

경고

암시적 IAM 역할 인증 정보를 사용하려면 IAM 역할을 사용하여 AWS API에 액세스할 때 |at|에서 AWS 클라우드 인증 정보를 연결하지 마십시오. AWS 클라우드 인증 정보를 작업 템플릿에 연결하는 것이 합리적으로 보일 수 있지만, 그렇게 하면 AWS 인증 정보가 강제로 사용되고 IAM 역할 인증 정보를 사용하도록 《넘어가지》 않습니다(이는 boto 라이브러리를 사용하기 때문임).

10.4.2. Ansible Galaxy/Automation Hub API 토큰

이 인증 정보를 선택하면 |at|에서 Galaxy에 액세스하거나 로컬 |ah|에 게시된 컬렉션을 사용할 수 있습니다. 자세한 내용은 :ref:`ug_collections_usage`을 참조하십시오. 이 화면에서는 Galaxy 서버 URL을 입력하기만 하면 됩니다.

Credentials - create galaxy credential

10.4.3. Centrify Vault Credential Provider Lookup

This is considered part of the secret management capability. See Centrify Vault Credential Provider Lookup for more detail.

10.4.4. Container Registry

Selecting this credential allows the automation controller to access a collection of container images. See What is a container registry? for more information.

Aside from specifying a name, the Authentication URL is the only required field on this screen, and it is already pre-populated with a default value. You may change this default by specifying the authentication endpoint for a different container registry.

Credentials - create container credential

10.4.5. CyberArk AIM Credential Provider Lookup

This is considered part of the secret management capability. See CyberArk AIM 인증 정보 공급자 조회 for more detail.

10.4.6. CyberArk Conjur Secret Lookup

This is considered part of the secret management capability. See CyberArk Conjur 시크릿 조회 for more detail.

10.4.7. GitHub 개인 액세스 토큰

이 인증 정보를 선택하면 GitHub를 통해 가져온 개인 액세스 토큰(PAT)을 사용하여 GitHub에 액세스할 수 있습니다. 자세한 내용은 :ref:`ug_webhooks`를 참조하십시오. 이 화면에서는 제공된 토큰을 입력하기만 하면 됩니다.

Credentials - create GitHub credential

GitHub PAT credentials require a value in the Token field, which is provided in your GitHub profile settings.

이 인증 정보는 Webhook 리스너 작업에서 사용하기 위해 GitHub에 대한 API 연결을 설정하여 상태 업데이트를 게시하는 데 사용할 수 있습니다.

10.4.8. GitLab 개인 액세스 토큰

이 인증 정보를 선택하면 GitLab을 통해 가져온 개인 액세스 토큰(PAT)을 사용하여 GitLab에 액세스할 수 있습니다. 자세한 내용은 :ref:`ug_webhooks`를 참조하십시오. 이 화면에서는 제공된 토큰을 입력하기만 하면 됩니다.

Credentials - create GitLab credential

GitLab PAT credentials require a value in the Token field, which is provided in your GitLab profile settings.

이 인증 정보는 Webhook 리스너 작업에서 사용하기 위해 GitLab에 대한 API 연결을 설정하여 상태 업데이트를 게시하는 데 사용할 수 있습니다.

10.4.9. Google Compute Engine

이 인증 정보 유형을 선택하면 Google Compute Engine(GCE)과 클라우드 인벤토리의 동기화가 활성화됩니다.

다음은 |at|에서 GCE 인증 정보로 사용하는 환경 변수로, 사용자 인터페이스에서 입력하도록 요청하는 필드입니다.

GCE_EMAIL
GCE_PROJECT
GCE_CREDENTIALS_FILE_PATH

Credentials - create GCE credential

GCE 인증 정보에는 다음과 같은 필수 입력 사항이 있습니다.

  • 서비스 계정 이메일 주소: Google Compute Engine **서비스 계정**에 할당된 이메일 주소입니다.

  • 프로젝트: 필요한 경우 GCE 할당 ID 또는 프로젝트 생성 시 제공한 고유한 프로젝트 ID를 제공합니다.

  • 서비스 계정 JSON 파일: 필요한 경우 GCE 서비스 계정 파일을 업로드합니다. 폴더(file-browser) 아이콘을 사용하여 다른 Google Cloud Platform API와 상호 작용하기 위해 GCE 인스턴스에서 실행 중인 서비스 및 애플리케이션에서 사용할 수 있는 특수 계정 정보가 포함된 파일을 찾습니다. 이 파일은 서비스 계정 및 가상 머신 인스턴스에 권한을 부여합니다.

  • RSA 개인 키: 서비스 계정 이메일과 연결된 PEM 파일입니다.

10.4.10. HashiCorp Vault Secret Lookup

This is considered part of the secret management capability. See HashiCorp Vault 시크릿 조회 for more detail.

10.4.11. HashiCorp Vault Signed SSH

This is considered part of the secret management capability. See HashiCorp Vault 서명 SSH for more detail.

10.4.12. Insights

이 인증 정보 유형을 선택하면 Red Hat Insights와 클라우드 인벤토리의 동기화가 활성화됩니다.

Credentials - create Insights credential

Insights 인증 정보는 Insights 사용자 이름**암호**로 구성되며, 이는 사용자의 Red Hat Customer Portal 계정 사용자 이름과 암호에 해당합니다.

10.4.13. 머신

머신 인증 정보를 사용하면 |at|가 사용자가 관리 중인 호스트에서 Ansible을 호출할 수 있습니다. 명령행에서 Ansible을 사용하는 것과 마찬가지로 SSH 사용자 이름을 지정하고, 필요한 경우 암호, SSH 키, 키 암호를 제공하거나 |at|에서 배포 시 사용자에게 암호를 요청하도록 설정할 수도 있습니다. 이러한 인증 정보는 플레이북에 대한 ssh 및 사용자 수준 권한 에스컬레이션 액세스를 정의하고 원격 호스트에서 플레이북을 실행하기 위해 작업을 제출할 때 사용됩니다. 네트워크 연결((httpapi, netconf, network_cli)은 인증 정보 유형으로 **머신**을 사용합니다.

시스템/SSH 인증 정보에서는 환경 변수를 사용하지 않습니다. 대신 ansible -u 플래그를 통해 사용자 이름을 전달하고 기본 SSH 클라이언트에서 SSH 암호를 요청할 때 대화식으로 해당 암호를 작성합니다.

Credentials - create machine credential

머신 인증 정보에는 다음과 같이 구성할 수 있는 다양한 특성이 있습니다.

  • 사용자 이름: SSH 인증에 사용할 사용자 이름입니다.

  • 암호: SSH 인증에 사용할 실제 암호입니다. 이 암호를 입력하면 데이터베이스에 암호화되어 저장됩니다. 또는 |at|시작 시 프롬프트**를 선택하여 시작 시 사용자에게 암호를 묻도록 **를 구성할 수 있습니다. 이 경우 작업이 시작될 때 대화 상자가 열리고 사용자에게 암호를 입력하고 확인하도록 요청합니다.

  • SSH 개인 키: 머신 인증 정보용 SSH 개인 키를 복사하거나 끌어서 놓습니다.

  • 개인 키 암호: 사용된 SSH 개인 키가 암호로 보호되는 경우 개인 키에 대한 키 암호를 구성할 수 있습니다. 이 암호를 입력하면 데이터베이스에 암호화되어 저장됩니다. 또는 **시작 시 프롬프트**를 선택하여 시작 시 사용자에게 암호를 묻도록 |at|를 구성할 수 있습니다. 이 경우 작업이 시작될 때 대화 상자가 열리고 사용자에게 암호를 입력하고 확인하도록 요청합니다.

  • 권한 에스컬레이션 메서드: 특정 사용자에게 할당할 에스컬레이션 권한 유형을 지정합니다. 이 항목은 --become-method=BECOME_METHOD 매개변수를 지정하는 것과 동일합니다. 여기서 ``BECOME_METHOD``는 아래에 설명된 일반적인 메서드이거나 사용자가 작성한 사용자 정의 메서드일 수 있습니다. 메서드 이름을 입력하기 시작하면 적절한 이름이 자동으로 채워집니다.

_images/credentials-create-machine-credential-priv-escalation.png
  • 빈 선택: 작업/플레이의 ``become``을 ``yes``로 설정하고 선택하지 않은 상태로 사용하면 기본적으로 ``sudo``로 설정됩니다.

  • sudo: 슈퍼유저(루트 사용자) 권한을 사용하여 단일 명령 수행

  • su: 슈퍼유저(루트 사용자) 계정(또는 다른 사용자 계정)으로 전환

  • pbrun: 애플리케이션 또는 명령이 제어된 계정에서 실행되도록 요청하고 고급 루트 권한 위임 및 키로깅 제공

  • pfexec: 특정 사용자 또는 그룹 ID와 같이 사전 정의된 프로세스 특성을 사용하여 명령 실행

  • dzdo: Centrify의 Active Directory 서비스에서 RBAC 정보를 사용하는 향상된 sudo 버전(Centrify의 site on DZDO 참조)

  • pmrun: 애플리케이션이 제어된 계정에서 실행되도록 요청 (Privilege Manager for Unix 6.0 참조)

  • runas: 현재 사용자로 실행할 수 있도록 허용

  • enable: 네트워크 장치에서 승격된 권한으로 전환

  • doas: 원격/로그인 사용자가 Doas(《Do as user》) 유틸리티를 통해 다른 사용자로 명령을 실행할 수 있도록 허용

  • ksu: 원격/로그인 사용자가 Kerberos 액세스를 통해 다른 사용자로 명령을 실행할 수 있도록 허용

  • machinectl: systemd 머신 관리자를 통해 컨테이너를 관리할 수 있도록 허용

  • sesu: 원격/로그인 사용자가 CA Privileged Access Manager를 통해 다른 사용자로 명령을 실행할 수 있도록 허용

참고

사용자 정의 become 플러그인은 Ansible 2.8부터 사용 가능합니다. 이 개념에 대한 자세한 내용은 Understanding Privilege Escalation https://docs.ansible.com/ansible/latest/user_guide/become.html`list of become plugins https://docs.ansible.com/ansible/latest/plugins/become.html#plugin-list`를 참조하십시오.

  • 권한 에스컬레이션 사용자 이름: 권한 에스컬레이션에 대한 옵션을 선택한 경우에만 표시되는 필드입니다. 원격 시스템에서 에스컬레이션 권한과 함께 사용할 사용자 이름을 입력합니다.

  • 권한 에스컬레이션 암호: 권한 에스컬레이션에 대한 옵션을 선택한 경우에만 표시되는 필드입니다. 원격 시스템에서 선택한 권한 에스컬레이션 유형을 통해 사용자를 인증하는 데 사용할 실제 암호를 입력합니다. 이 암호를 입력하면 데이터베이스에 암호화되어 저장됩니다. 또는 **시작 시 프롬프트**를 선택하여 시작 시 사용자에게 암호를 묻도록 |at|를 구성할 수도 있습니다. 이 경우 작업이 시작될 때 대화 상자가 열리고 사용자에게 암호를 입력하고 확인하도록 요청합니다.

참고

sudo 암호는 SSH 암호 또는 SSH 개인 키와 함께 사용해야 합니다. |at|에서 sudo를 호출하여 sudo 사용자로 변경하기 전에 먼저 호스트와 인증된 SSH 연결을 설정해야 하기 때문입니다.

경고

스케줄링된 작업*에서 사용되는 인증 정보는 《**시작 시 프롬프트*》로 구성해서는 안 됩니다.

10.4.14. Microsoft Azure Key Vault

This is considered part of the secret management capability. See Microsoft Azure Key Vault for more detail.

10.4.15. Microsoft Azure Resource Manager

이 인증 정보 유형을 선택하면 Microsoft Azure Resource Manager와 클라우드 인벤토리의 동기화가 활성화됩니다.

Credentials - create Azure credential

Microsoft Azure Resource Manager 인증 정보에는 다음과 같이 구성할 수 있는 다양한 특성이 있습니다.

  • 서브스크립션 ID: Microsoft Azure 계정의 서브스크립션 UUID(필수)입니다.

  • 사용자 이름: Microsoft Azure 계정 연결에 사용할 사용자 이름입니다.

  • 암호: Microsoft Azure 계정 연결에 사용할 암호입니다.

  • 클라이언트 ID: Microsoft Azure 계정의 클라이언트 ID입니다.

  • 클라이언트 시크릿: Microsoft Azure 계정의 클라이언트 시크릿입니다.

  • 테넌트 ID: Microsoft Azure 계정의 테넌트 ID입니다.

  • Azure 클라우드 환경: Azure 클라우드 또는 Azure 스택 환경 관련 변수입니다.

해당 필드는 API의 변수와 동일합니다. 서비스 주체 인증 정보를 전달하려면 다음 변수를 정의합니다.

AZURE_CLIENT_ID
AZURE_SECRET
AZURE_SUBSCRIPTION_ID
AZURE_TENANT
AZURE_CLOUD_ENVIRONMENT

Active Directory 사용자 이름/암호 쌍을 전달하려면 다음 변수를 정의합니다.

AZURE_AD_USER
AZURE_PASSWORD
AZURE_SUBSCRIPTION_ID

인증 정보를 플레이북 내의 작업에 매개변수로 전달할 수도 있습니다. 우선순위는 매개변수, 환경 변수 그리고 마지막으로 홈 디렉터리에 있는 파일순입니다.

인증 정보를 작업에 매개변수로 전달하려면 다음 매개변수를 서비스 주체 인증 정보로 사용하십시오.

client_id
secret
subscription_id
tenant
azure_cloud_environment

또는 다음 매개변수를 Active Directory 사용자 이름/암호로 전달합니다.

ad_user
password
subscription_id

10.4.16. 네트워크

Ansible 네트워크 모듈을 사용하여 네트워크 장치를 연결하고 관리하도록 local`와의 `provider 연결을 사용하는 경우에만 네트워크 인증 정보 유형을 선택합니다. 네트워크 장치에 연결할 때 인증 정보 유형이 연결 유형과 일치해야 합니다.

  • provider``를 사용하는 ``local 연결의 경우 인증 정보 유형은 **네트워크**여야 합니다.

  • 기타 모든 네트워크 연결(httpapi, netconf, network_cli)의 경우 인증 정보 유형은 **머신**이어야 합니다.

네트워크 장치에 사용할 수 있는 연결 유형에 대한 개요는 `Multiple Communication Protocols`_을 참조하십시오.

다음은 |at|에서 네트워크 인증 정보로 사용하는 환경 변수로, 사용자 인터페이스에서 입력하도록 요청하는 필드입니다.

ANSIBLE_NET_USERNAME
ANSIBLE_NET_PASSWORD

Credentials - create network credential

네트워크 인증 정보에는 다음과 같이 구성할 수 있는 다양한 특성이 있습니다.

  • 사용자 이름: 네트워크 장치와 함께 사용할 사용자 이름(필수)입니다.

  • 암호: 네트워크 장치와 함께 사용할 암호입니다.

  • SSH 개인 키: SSH를 통해 네트워크에 사용자를 인증하는 데 사용할 실제 SSH 개인 키를 복사하거나 끌어서 놓습니다.

  • 개인 키 암호: SSH를 통해 네트워크에 사용자를 인증하는 데 사용할 개인 키의 실제 암호입니다.

  • 승인: 권한 있는 모드로 전환할지의 여부를 제어하려면 옵션 필드에서 이 항목을 선택합니다.

  • 승인**이 선택되어 있으면 **암호 승인 필드에 암호를 입력하여 권한 있는 모드에 액세스합니다.

자세한 내용은 플레이북 내부 블로그, `Porting Ansible Network Playbooks with New Connection Plugins`_을 참조하십시오.

10.4.17. OpenShift 또는 Kubernetes API 전달자 토큰

이 인증 정보 유형을 선택하면 Kubernetes 또는 OpenShift 컨테이너를 가리키는 인스턴스 그룹을 생성할 수 있습니다. 이 개념에 대한 자세한 내용은 :ref:`ag_ext_exe_env`을 참조하십시오.

Credentials - create Containers credential

컨테이너 인증 정보에는 다음과 같은 입력 사항이 있습니다.

  • OpenShift 또는 Kubernetes API 끝점 (필수): OpenShift 또는 Kubernetes 컨테이너 연결에 사용할 끝점

  • API 인증 전달자 토큰 (필수): 연결을 인증하는 데 사용할 토큰

  • SSL 확인: 필요한 경우 이 옵션을 선택하여 서버의 SSL 인증서가 유효하고 신뢰할 수 있는지 확인할 수 있습니다. 내부 또는 개인 CA를 사용하는 환경에서는 확인을 비활성화도록 이 옵션을 선택하지 않은 상태로 두어야 합니다.

  • 인증 기관 데이터: 제공되는 경우 인증서를 붙여넣을 때 BEGIN CERTIFICATEEND CERTIFICATE 행을 포함합니다.

A ContainerGroup is a type of InstanceGroup that has an associated Credential that allows for connecting to an OpenShift cluster. To set up a container group, you must first have the following:

  • A namespace you can launch into (every cluster has a “default” namespace, but you may want to use a specific namespace)

  • 이 네임스페이스의 Pod를 시작하고 관리할 수 있는 역할이 있는 서비스 계정

  • 프라이빗 레지스트리에서 |ees|을 사용하고 이 환경에 연결된 컨테이너 레지스트리 인증 정보가 자동화 컨트롤러에 있는 경우 네임스페이스에서 비밀을 가져오고, 생성하고, 삭제하는 역할도 서비스 계정에 필요합니다. 이러한 역할을 서비스 계정에 부여하지 않으려면 ``ImagePullSecrets``를 사전 생성하여 ContainerGroup의 Pod 사양에 지정할 수 있습니다. 이 경우 |ee|에는 연결된 컨테이너 레지스트리 인증 정보가 없어야 합니다. 그렇지 않으면 컨트롤러가 네임스페이스에 비밀을 생성하려고 합니다.

  • 서비스 계정과 연결된 토큰(OpenShift 또는 Kubernetes Bearer 토큰)

  • 클러스터와 연결된 CA 인증서

This section describes creating a Service Account in an Openshift cluster (or K8s) in order to be used to run jobs in a container group via automation controller. After the Service Account is created, its credentials are provided to the controller in the form of an Openshift or Kubernetes API bearer token credential. Below describes how to create a service account and collect the needed information for configuring automation controller.

To configure the controller:

  1. To create a service account, you may download and use this sample service account, containergroup sa and modify it as needed to obtain the above credentials.

  2. containergroup-sa.yml::의 구성을 적용합니다.

    oc apply -f containergroup-sa.yml
    
  3. 서비스 계정과 연결된 시크릿 이름을 가져옵니다.

    export SA_SECRET=$(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"')
    
  4. 시크릿에서 토큰을 가져옵니다.

    oc get secret $(echo ${SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token
    
  5. CA 인증서를 가져옵니다.

    oc get secret $SA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt
    
  6. containergroup-sa.tokencontainergroup-ca.crt 콘텐츠를 사용하여 컨테이너 그룹에 필요한 OpenShift 또는 Kubernetes API 전달자 토큰 에 대한 정보를 제공합니다.

10.4.18. OpenStack

이 인증 정보 유형을 선택하면 OpenStack과 클라우드 인벤토리의 동기화가 활성화됩니다.

Credentials - create OpenStack credential

OpenStack 인증 정보에는 다음과 같은 필수 입력 사항이 있습니다.

  • 사용자 이름: OpenStack 연결에 사용할 사용자 이름입니다.

  • 암호(API 키): OpenStack 연결에 사용할 암호 또는 API 키입니다.

  • 호스트(인증 URL): 인증에 사용할 호스트입니다.

  • 프로젝트(테넌트 이름): OpenStack에 사용되는 테넌트 이름 또는 테넌트 ID입니다. 이 값은 일반적으로 사용자 이름과 동일합니다.

  • 프로젝트(도메인 이름): 필요한 경우 도메인과 연결된 프로젝트 이름을 제공합니다.

  • 도메인 이름: 필요한 경우 OpenStack 연결에 사용할 FQDN을 제공합니다.

OpenStack 클라우드 인증 정보 사용에 관심이 있는 경우 샘플 플레이북을 포함한 자세한 내용은 이 가이드의 :ref:`ug_CloudCredentials`을 참조하십시오.

10.4.19. Red Hat Ansible Automation Platform

이 인증 정보를 선택하면 다른 automation controller 인스턴스에 액세스할 수 있습니다.

Credentials - create tower credential

Automation controller 인증 정보에는 다음과 같은 필수 입력 사항이 있습니다.

  • 컨트롤러 호스트 이름: 연결할 다른 인스턴스의 기본 URL 또는 IP 주소입니다.

  • 사용자 이름: 연결에 사용하는 사용자 이름입니다.

  • 암호: 연결에 사용하는 암호입니다.

  • Oauth 토큰: 사용자 이름과 암호를 사용하지 않는 경우 인증에 사용할 OAuth 토큰을 제공합니다.

10.4.20. Red Hat Satellite 6

이 인증 정보 유형을 선택하면 Red Hat Satellite 6와 클라우드 인벤토리의 동기화가 활성화됩니다.

|at|는 사용자 인터페이스에서 입력하도록 요청하는 필드를 기반으로 Satellite 구성 파일을 작성합니다. 파일의 절대 경로는 다음 환경 변수에 설정됩니다.

FOREMAN_INI_PATH

Credentials - create Red Hat Satellite 6 credential

Satellite 인증 정보에는 다음과 같은 필수 입력 사항이 있습니다.

  • Satellite 6 URL: 연결할 Satellite 6 URL 또는 IP 주소입니다.

  • 사용자 이름: Satellite 6 연결에 사용할 사용자 이름입니다.

  • 암호: Satellite 6 연결에 사용할 암호입니다.

10.4.21. Red Hat Virtualization

이 인증 정보를 사용하면 |at|가 Red Hat Virtualization(RHV)에서 관리하는 Ansible의 oVirt4.py 동적 인벤토리 플러그인에 액세스할 수 있습니다.

다음은 |at|에서 Red Hat Virtualization 인증 정보로 사용하는 환경 변수로, 사용자 인터페이스의 필드입니다.

OVIRT_URL
OVIRT_USERNAME
OVIRT_PASSWORD

Credentials - create rhv credential

RHV 인증 정보에는 다음과 같은 필수 입력 사항이 있습니다.

  • 호스트(인증 URL): 연결할 호스트 URL 또는 IP 주소입니다. 인벤토리와 동기화하려면 인증 정보 URL에 ovirt-engine/api 경로를 포함해야 합니다.

  • 사용자 이름: oVirt4 연결에 사용할 사용자 이름입니다. 연결에 성공하려면 도메인 프로필을 포함해야 합니다(예: username@ovirt.host.com).

  • 암호: 연결에 사용하는 암호입니다.

  • CA 파일: 필요한 경우 oVirt 인증서 파일에 대한 절대 경로를 제공합니다(.pem, .cer, ``.crt``확장명으로 끝날 수 있지만 일관성을 위해 ``.pem``이 바람직함).

10.4.22. 소스 제어

SCM(소스 제어) 인증 정보는 프로젝트와 함께 사용되어 Git 또는 Subversion과 같은 원격 버전 제어 시스템에서 로컬 소스 코드 리포지터리를 복제 및 업데이트합니다.

Credentials - create SCM credential

소스 제어 인증 정보에는 다음과 같이 구성할 수 있는 다양한 특성이 있습니다.

  • 사용자 이름: 소스 제어 시스템과 함께 사용할 사용자 이름입니다.

  • 암호: 소스 제어 시스템과 함께 사용할 암호입니다.

  • SCM 개인 키: SSH를 통해 소스 제어 시스템에 사용자를 인증하는 데 사용할 실제 SSH 개인 키를 복사하거나 끌어서 놓습니다.

  • 개인 키 암호: 사용된 SSH 개인 키가 암호로 보호되는 경우 개인 키에 대한 키 암호를 구성할 수도 있습니다.

참고

소스 제어 인증 정보는 《시작 시 프롬프트》로 구성할 수 없습니다. 소스 제어 인증 정보에 GitHub 계정을 사용하고 계정에 2단계 인증(Two Factor Authenication, 2FA)을 활성화한 경우, 암호 필드에 계정 암호 대신 개인 액세스 토큰을 사용해야 합니다.

10.4.23. Thycotic DevOps Secrets Vault

This is considered part of the secret management capability. See Thycotic DevOps Secrets Vault for more detail.

10.4.24. Thycotic Secret Server

This is considered part of the secret management capability. See Thycotic Secret Server for more detail.

10.4.25. Vault

이 인증 정보 유형을 선택하면 Ansible Vault와 인벤토리의 동기화가 활성화됩니다.

Credentials - create Vault credential

다중 Vault 인증을 적용하는 경우 Vault 인증 정보에는 Vault 암호 및 선택적 **Vault ID**가 필요합니다. automation controller 다중 Vault 지원에 대한 자세한 내용은 |ata|의 다중 자격 증명 모음 인증 정보 섹션을 참조하십시오.

**시작 시 프롬프트**를 선택하여 시작 시 사용자에게 암호를 묻도록 |at|를 구성할 수도 있습니다. 이 경우 작업이 시작될 때 대화 상자가 열리고 사용자에게 암호를 입력하고 확인하도록 요청합니다.

경고

스케줄링된 작업*에서 사용되는 인증 정보는 《**시작 시 프롬프트*》로 구성해서는 안 됩니다.

Ansible Vault에 대한 자세한 내용은 http://docs.ansible.com/ansible/playbooks_vault.html을 참조하십시오.

10.4.26. VMware vCenter

이 인증 정보 유형을 선택하면 VMware vCenter와 인벤토리의 동기화가 활성화됩니다.

다음은 |at|에서 VMware vCenter 인증 정보로 사용하는 환경 변수로, 사용자 인터페이스에서 입력하도록 요청하는 필드입니다.

VMWARE_HOST
VMWARE_USER
VMWARE_PASSWORD
VMWARE_VALIDATE_CERTS

Credentials - create VMware credential

VMware 인증 정보에는 다음과 같은 필수 입력 사항이 있습니다.

  • vCenter Host: 연결할 vCenter 호스트 이름 또는 IP 주소입니다.

  • 사용자 이름: vCenter 연결에 사용할 사용자 이름입니다.

  • 암호: vCenter 연결에 사용할 암호입니다.

참고

VMware 게스트 툴이 인스턴스에서 실행되지 않는 경우 VMware 인벤토리 동기화에서 해당 인스턴스의 IP 주소를 반환하지 않을 수 있습니다.