Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

2.2. 설치

Ansible Automation Platform의 보안 준비에 영향을 미치는 설치 시간 결정이 있습니다. 설치 프로세스에는 여러 변수를 설정하는 작업이 포함되며, 그 중 일부는 Ansible Automation Platform 인프라 강화와 관련이 있습니다. Ansible Automation Platform을 설치하기 전에 이 가이드의 설치 섹션에서 지침을 고려하십시오.

2.2.1. 전용 설치 호스트에서 설치

Ansible Automation Platform 설치 프로그램은 자동화 컨트롤러와 같은 인프라 서버 중 하나 또는 Ansible Automation Platform 인프라 서버에 대한 SSH 액세스 권한이 있는 외부 시스템에서 실행할 수 있습니다. Ansible Automation Platform 설치 프로그램은 설치뿐만 아니라 백업 및 복원과 같은 2일차 작업뿐만 아니라 업그레이드에도 사용됩니다. 이 가이드에서는 여기에서 설치 호스트라는 전용 외부 서버에서 설치 및 Day-two 작업을 수행할 것을 권장합니다. 이렇게 하면 이러한 기능을 실행하기 위해 인프라 서버 중 하나에 로그인할 필요가 없습니다. 설치 호스트는 Ansible Automation Platform 관리에만 사용해야 하며 다른 서비스 또는 소프트웨어를 실행하지 않아야 합니다.

설치 호스트는 Red Hat Enterprise Linux의 보안 강화 및 조직 관련 보안 프로필 요구 사항(CIS, STIG 등)에 따라 설치 및 구성된 Red Hat Enterprise Linux 서버여야 합니다. 설치 계획에 설명된 대로 Ansible Automation Platform 설치 프로그램을 가져오고 Red Hat Ansible Automation Platform 설치 프로그램 인벤토리 파일 편집에 설명된 대로 설치 프로그램 인벤토리 파일을 생성합니다. 이 인벤토리 파일은 업그레이드, 인프라 구성 요소 추가, 설치 프로그램에서 Day-two 작업 등에 사용되므로 향후 작동을 위해 설치 후 파일을 보존합니다.

설치 호스트에 대한 액세스는 Ansible Automation Platform 인프라 관리를 담당하는 인력으로만 제한되어야 합니다. 시간이 지남에 따라 설치 인벤토리(Ansible Automation Platform의 초기 로그인 인증 정보 포함), 사용자 제공 PKI 키 및 인증서, 백업 파일 등 중요한 정보가 포함됩니다. 인프라 관리 및 유지 관리에 필요한 경우 SSH를 통해 Ansible Automation Platform 인프라 서버에 로그인하는 데 설치 호스트를 사용해야 합니다.

2.2.2. 설치 인벤토리의 security-relevant 변수

설치 인벤토리 파일은 Ansible Automation Platform 인프라의 아키텍처를 정의하고 인프라 구성 요소의 초기 구성을 수정하는 데 사용할 수 있는 여러 변수를 제공합니다. 설치 프로그램 인벤토리에 대한 자세한 내용은 설치 프로그램 인벤토리 파일 정보를 참조하십시오.

다음 표에는 여러 보안 관련 변수와 RPM 기반 배포에 권장되는 값이 나열되어 있습니다.

표 2.2. security-relevant 인벤토리 변수
RPM 배포 변수권장 값세부 정보

postgres_use_ssl

true

설치 프로그램은 이 변수가 설정될 때 SSL 기반 연결을 수락하도록 설치 관리자 관리 Postgres 데이터베이스를 구성합니다.

이 변수의 기본값은 false입니다. 즉 PostgreSQL 연결에 SSL/TLS가 사용되지 않습니다.

true로 설정하면 플랫폼이 SSL/TLS를 사용하여 PostgreSQL에 연결됩니다.

pg_sslmode automation_gateway_pg_sslmode automationhub_pg_sslmode automationcontroller_pg_sslmode

verify-full

이러한 변수는 데이터베이스에 대한 상호 TLS(mTLS) 인증을 제어합니다. 기본적으로 각 서비스가 데이터베이스에 연결하면 암호화된 연결을 시도하지만 적용되지는 않습니다.

이 변수를 verify-full 로 설정하면 서비스와 데이터베이스 간에 mTLS 협상이 적용됩니다. 이 pg_sslmode를 적용하려면 postgres_use_ssl 변수도 true 로 설정해야 합니다.

참고: 설치 관리자 관리 데이터베이스 대신 타사 데이터베이스를 사용하는 경우 mTLS 연결을 수락하도록 타사 데이터베이스를 독립적으로 설정해야 합니다.

nginx_disable_hsts automation_gateway_disable_hsts automationhub_disable_hsts 자동화controller_disable_hsts

false

true 로 설정하면 이러한 변수는 각 구성 요소 웹 서비스에 대한 HTTPS 엄격한 전송 보안 (HSTS) 연결을 비활성화합니다.

기본값은 false입니다. 설치 프로그램 인벤토리에서 이러한 변수가 없는 경우 변수를 false 로 정의하는 것과 사실상 동일합니다.

다음 표에는 컨테이너 기반 배포에 대한 여러 보안 관련 변수와 권장 값이 나열되어 있습니다.

표 2.3. 보안 관련 컨테이너화된 인벤토리 변수
컨테이너 배포 변수권장 값세부 정보

postgresql_disable_tls

false

true 로 설정하면 이 변수는 설치 관리자 관리 PostgreSQL 데이터베이스에 대한 TLS 연결을 비활성화합니다.

기본값은 false입니다.

설치 프로그램 인벤토리에서 이 변수가 없는 경우 변수를 false 로 정의하는 것과 효과적으로 동일합니다.

controller_pg_sslmode gateway_pg_sslmode hub_pg_sslmode eda_pg_sslmode

verify-full

이러한 변수는 데이터베이스에 대한 상호 TLS(mTLS) 인증을 제어합니다.

기본적으로 각 서비스가 데이터베이스에 연결하면 암호화된 연결을 시도하지만 적용되지는 않습니다. 이 변수를 verify-full 로 설정하면 서비스와 데이터베이스 간에 mTLS 협상이 적용됩니다.

참고

설치 관리자 관리 데이터베이스 대신 타사 데이터베이스를 사용하는 경우 mTLS 연결을 수락하도록 타사 데이터베이스를 독립적으로 설정해야 합니다.

controller_nginx_disable_https gateway_nginx_disable_https hub_nginx_disable_https da_nginx_disable_https

false

true 로 설정하면 이러한 변수는 각 구성 요소 웹 서비스에 대한 HTTPS 연결을 비활성화합니다.

기본값은 false입니다.

이러한 변수가 설치 프로그램 인벤토리에 없는 경우 변수를 false 로 정의하는 것과 효과적으로 동일합니다.

controller_nginx_disable_hsts gateway_nginx_disable_hsts hub_nginx_disable_hsts eda_nginx_disable_hsts

false

'true'로 설정하면 이러한 변수는 각 구성 요소 웹 서비스에 대한 HTTPS Strict Transport Security(HSTS) 연결을 비활성화합니다.

기본값은 false입니다.

설치 프로그램 인벤토리에서 이러한 변수가 없는 경우 변수를 false 로 정의하는 것과 사실상 동일합니다.

로드 밸런서가 여러 플랫폼 게이트웨이 앞에 사용되는 엔터프라이즈 아키텍처에서는 로드 밸런서에서 SSL 클라이언트 연결을 종료하거나 개별 AAP 서버로 전달할 수 있습니다. 로드 밸런서에서 SSL을 종료하는 경우 이 가이드에서는 트래픽을 로드 밸런서에서 개별 Ansible Automation Platform 서버로 다시 암호화할 것을 권장합니다. 이렇게 하면 엔드 투 엔드 암호화를 사용할 수 있습니다. 이 시나리오에서는 나열된 *_disable_https 변수가 기본값 false 로 설정됩니다.

2.2.3. 사용자 제공 PKI 인증서로 설치

기본적으로 Ansible Automation Platform은 플랫폼의 인프라 구성 요소에 대해 자체 서명된 PKI( Public Key Infrastructure ) 인증서를 생성합니다. 기존 PKI 인프라를 사용할 수 있는 경우 자동화 컨트롤러, 프라이빗 자동화 허브, 이벤트 기반 Ansible 컨트롤러 및 사후 데이터베이스 서버에 대한 인증서를 생성해야 합니다. 인증서를 확인하는 데 사용되는 CA 인증서와 함께 인증서 파일 및 관련 키 파일을 설치 프로그램 디렉터리에 복사합니다.

다음 인벤토리 변수를 사용하여 새 인증서로 인프라 구성 요소를 구성합니다.

표 2.4. PKI 인증서 인벤토리 변수

RPM 변수

컨테이너화된 변수

세부 정보

custom_ca_cert

custom_ca_cert

사용자 정의 CA 인증서 파일의 경로입니다.

설정된 경우 사용자 정의 CA 인증서가 시스템 신뢰 저장소에 설치됩니다.

web_server_ssl_cert

controller_tls_cert

설치 프로그램 디렉터리에 있는 자동화 컨트롤러 PKI 인증서의 파일 이름입니다.

web_server_ssl_key

controller_tls_key

설치 프로그램 디렉터리에 있는 자동화 컨트롤러 PKI 키의 파일 이름입니다.

automationhub_ssl_cert

hub_tls_cert

설치 프로그램 디렉터리에 있는 프라이빗 자동화 허브 PKI 인증서의 파일 이름입니다.

automationhub_ssl_key

hub_tls_key

설치 프로그램 디렉터리에 있는 개인 자동화 허브 PKI 키의 파일 이름입니다.

postgres_ssl_cert

postgresql_tls_cert

설치 프로그램 디렉터리에 있는 데이터베이스 서버 PKI 인증서의 파일 이름입니다. 이 변수는 타사 데이터베이스가 사용되는 경우가 아니라 설치 관리자 관리 데이터베이스 서버에만 필요합니다.

postgres_ssl_key

postgresql_tls_key

설치 프로그램 디렉터리에 있는 데이터베이스 서버 PKI 키의 파일 이름입니다. 이 변수는 타사 데이터베이스가 사용되는 경우가 아니라 설치 관리자 관리 데이터베이스 서버에만 필요합니다.

automationedacontroller_ssl_cert

eda_tls_cert

설치 프로그램 디렉터리에 있는 이벤트 기반 Ansible 컨트롤러 PKI 인증서의 파일 이름입니다.

automationedacontroller_ssl_key

eda_tls_key

설치 프로그램 디렉터리에 있는 이벤트 기반 Ansible 컨트롤러 PKI 키의 파일 이름입니다.

-

gateway_tls_cert

설치 프로그램 디렉터리에 있는 플랫폼 게이트웨이 PKI 인증서의 파일 이름입니다.

-

gateway_tls_key

설치 프로그램 디렉터리에 있는 플랫폼 게이트웨이 PKI 키의 파일 이름입니다.

로드 밸런서와 함께 여러 플랫폼 게이트웨이가 배포되면 gateway_tls_cert 및 gateway_tls_key 는 각 플랫폼 게이트웨이에서 공유합니다. 호스트 이름이 일치하지 않도록 하려면 인증서의 CN( 일반 이름 )이 로드 밸런서에서 사용하는 DNS FQDN과 일치해야 합니다. 조직 정책에 각 서비스에 대한 고유한 인증서가 필요한 경우 각 인증서에 로드 밸런싱 서비스에 사용되는 DNS FQDN과 일치하는 SAN( 주체 대체 이름 )이 필요합니다. 각 플랫폼 게이트웨이에 고유한 인증서와 키를 설치하려면 설치 인벤토리 파일의 인증서 및 키 변수를 [all:vars] 섹션 대신 호스트별 변수로 정의해야 합니다. 예를 들면 다음과 같습니다.

Copy to Clipboard Toggle word wrap 
[automationgateway]
gateway0.example.com gateway_tls_cert=/path/to/cert0 gateway_tls_key=/path/to/key0
gateway1.example.com gateway_tls_cert=/path/to/cert1 gateway_tls_key=/path/to/key1

[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2

[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key2

2.2.4. 설치 인벤토리의 중요한 변수

설치 인벤토리 파일에는 주로 Ansible Automation Platform에서 사용하는 초기 암호를 설정하는 데 사용되는 여러 중요한 변수가 포함되어 있으며 일반적으로 인벤토리 파일의 일반 텍스트로 유지됩니다. 이러한 변수를 무단으로 보지 못하도록 이러한 변수를 암호화된 Ansible 자격 증명 모음에 유지할 수 있습니다. 이렇게 하려면 설치 프로그램 디렉터리로 이동하여 자격 증명 모음 파일을 생성합니다.

  • cd /path/to/ansible-automation-platform-setup-bundle-2.5-1-x86_64
  • ansible-vault create vault.yml

새 Ansible 자격 증명 모음에 대한 암호를 입력하라는 메시지가 표시됩니다. 2일차 작업 및 백업 프로시저를 포함하여 자격 증명 모음 파일에 액세스해야 할 때마다 자격 증명 모음 암호를 손실하지 마십시오. 암호화된 암호 관리자에 저장하거나 암호를 안전하게 저장하기 위한 조직 정책에 따라 vault 암호를 보호할 수 있습니다.

중요한 변수를 자격 증명 모음에 추가합니다. 예를 들면 다음과 같습니다.

Copy to Clipboard Toggle word wrap 
admin_password/controller_admin_password: <secure_controller_password>
pg_password/controller_pg_password: <secure_db_password>
automationhub_admin_password/hub_admin_password: <secure_hub_password>
automationhub_pg_password/hub_pg_password: <secure_hub_db_password>
automationedacontroller_admin_password/eda_admin_password: <secure_eda_password>
automationedacontroller_pg_password/eda_pg_password: <secure_eda_db_password>
-/gateway_admin_password: <secure_gateway_password>
-/gateway_pg_password:<secure_gateway_db_password>

이러한 변수가 설치 인벤토리 파일에도 표시되지 않는지 확인합니다. 새 Ansible 자격 증명 모음을 설치 프로그램과 함께 사용하려면 ./setup.sh -e @vault.ymlEngine-listener--ask-vault-pass 명령으로 실행합니다.

2.2.5. 컴플라이언스 프로필 고려 사항

대부분의 환경에서는 CIS Critical Security Controls, PCI/DSS( Payment Card Industry/Data Security Standard ), DISA STIG 또는 유사한 프로필과 같은 규정 준수 프로필의 요구 사항을 충족하기 위해 보안 제어가 적용된 Red Hat Enterprise Linux 시스템에 Ansible Automation Platform을 설치해야 할 수 있습니다. 이러한 환경에는 Ansible Automation Platform이 올바르게 실행되도록 수정해야 하는 특정 보안 제어 세트가 있습니다. 설치 전에 Ansible Automation Platform에 사용되는 Red Hat Enterprise Linux 서버에 규정 준수 프로필 제어를 적용한 다음 필요에 따라 다음 보안 제어를 수정합니다.

이러한 제어가 필요한 환경에서는 보안 감사자와의 제어를 포기합니다.

2.2.5.1. fapolicyd

규정 준수 정책에서 fapolicyd 데몬을 실행해야 할 수 있습니다. 그러나 Ansible Automation Platform은 현재 fapolicyd 정책을 강제할 때 지원되지 않습니다. 이로 인해 Ansible Automation Platform 설치 및 작동 중 오류가 발생합니다. 이로 인해 설치 프로그램은 fapolicyd 가 강제 정책인 경우 설치를 중지하는 pre-flight 검사를 실행합니다. 이 가이드에서는 다음 단계를 사용하여 fapolicyd 를 Ansible Automation Platform에서 허용 모드로 설정하는 것이 좋습니다.

  1. /etc/fapolicyd/fapolicyd.conf 파일을 편집하고 "permissive = 1"을 설정합니다.

  2. 명령을 사용하여 서비스를 다시 시작

    sudo systemctl restart fapolicyd.service

참고

이 보안 제어도 설치 호스트에 적용되면 기본 fapolicyd 구성으로 Ansible Automation Platform 설치 프로그램이 실패합니다. 이 경우 설치 호스트에서 fapolicyd 를 허용 모드로 설정하는 것이 좋습니다.

2.2.5.2. "noexec"로 마운트된 파일 시스템

규정 준수 프로필에서는 이러한 파일 시스템에 있는 바이너리 실행을 방지하기 위해 noexec 옵션으로 특정 파일 시스템을 마운트해야 할 수 있습니다. Ansible Automation Platform RPM 기반 설치 프로그램은 다음 파일 시스템 중 하나가 noexec 옵션으로 마운트된 경우 실패하는 전등 검사를 실행합니다.

  • /tmp
  • /var
  • /var/tmp

Ansible Automation Platform을 설치하려면 noexec 옵션을 제거한 상태로 이러한 파일 시스템을 다시 마운트해야 합니다. 설치가 완료되면 다음 단계를 진행합니다.

  1. noexec 옵션을 /tmp 및 /var/tmp 파일 시스템에 다시 적용합니다.
  2. 자동화 컨트롤러 작업 실행 경로를 /tmp 에서 noexec 옵션이 활성화되어 있지 않은 대체 디렉터리로 변경합니다.
  3. 이 변경을 수행하려면 관리자로 자동화 컨트롤러 UI에 로그인하고 설정으로 이동한 다음 작업 설정을 선택합니다.
  4. "작업 실행 경로" 설정을 대체 디렉터리로 변경합니다.

일반적인 작업 중에 /var/lib/awx 하위 디렉터리(일반적으로 /var)가 포함된 파일 시스템은 noexec 옵션을 사용하여 마운트하지 않아야 합니다. 그렇지 않으면 자동화 컨트롤러에서 실행 환경에서 자동화 작업을 실행할 수 없습니다.

STIG 제어가 정기적으로 감사되는 환경에서는 보안 감사자와 함께 noexec 와 관련된 STIG 제어를 포기합니다.

2.2.5.3. 사용자 네임스페이스

Linux 컨테이너의 시작을 방지하려면 규정 준수 프로필에서 커널 설정 user.max_user_namespaces 를 "0"으로 설정해야 할 수 있습니다. 예를 들어 DISA STIG는 특히 Linux 컨테이너가 필요하지 않은 경우에만 이 제어가 필요합니다. Ansible Automation Platform은 컨테이너에서 설치 및 작동할 수 있으며 컨테이너를 실행 환경 기능의 일부로 사용하므로 Linux 컨테이너를 비활성화해야 합니다.

user.max_user_namespaces 커널 설정을 확인하려면 설치 인벤토리의 각 Ansible Automation Platform 구성 요소에서 다음 단계를 완료합니다.

  1. 명령줄에서 자동화 컨트롤러에 로그인합니다.
  2. sudo sysctl user.max_user_namespaces 명령을 실행합니다.
  3. 출력에 값이 0임을 나타내는 경우 /etc/sysctl.conf 파일의 내용과 /etc/sysctl.d/ 아래의 모든 파일을 살펴보고 user.max_user_namespaces 설정을 포함하는 파일을 편집하고 값을 "65535"로 설정합니다.
  4. 이 새 값을 적용하려면 sudo sysctl -p <file > 명령을 실행합니다. 여기서 < file >은 방금 수정된 파일입니다.
  5. sudo sysctl user.max_user_namespaces 명령을 다시 실행하고 값이 이제 "65535"로 설정되어 있는지 확인합니다.

2.2.5.4. 대화형 세션 시간 초과

규정 준수 프로필을 사용하려면 대화형 세션 시간 초과를 적용해야 할 수 있습니다. 예를 들어 DISA STIG에서는 모든 사용자가 15분 동안 활동이 없으면 자동으로 로그아웃해야 합니다. 설치 프로세스를 완료하는 데 1시간 이상 걸리는 경우가 많으며, 이 제어로 인해 설치가 완료되기 전에 설치 프로세스를 중지하고 사용자를 로그아웃할 수 있습니다. 이는 백업 및 복원과 같은 2일차 운영에도 적용됩니다. 이 작업에서는 프로덕션 환경에서 권장되는 대화형 세션 시간 초과보다 오래 걸리는 경우가 많습니다. 이러한 작업 중에 대화형 세션 시간 제한을 늘리면 작업이 성공적으로 수행됩니다.

쉘 시간 제한 변수, systemd-logind 에 대한 유휴 세션 시간 제한 설정, SSH 연결 시간 초과 설정 등 이 제어를 적용할 수 있는 방법은 여러 가지가 있으며, 다른 규정 준수 프로필은 이러한 방법 중 하나 이상을 사용할 수 있습니다. 설치를 가장 자주 중단하고 2일차 작업은 systemd-logind 의 유휴 세션 시간 초과로, DISA STIG 버전 V2R1 및 V2R2(Red Hat Enterprise Linux 9)에 도입된 systemd-logind의 유휴 세션 시간 초과입니다. root 사용자로 systemd-logind 의 유휴 세션 시간 초과를 늘리려면 다음을 수행합니다.

  • /etc/systemd/logind.conf 파일을 편집합니다.
  • StopIdleSessionSec 설정이 0으로 설정된 경우 변경이 필요하지 않습니다.

  • StopIdleSessionSec 설정이 0이 아닌 경우 해당 시간 후에 세션이 종료됨을 나타냅니다.

    StopIdleSessionSec=7200 을 변경하여 시간 제한을 증가한 다음 systemctl restart systemd-logind 를 실행하여 변경 사항을 적용합니다.

  • 대화형 세션에서 완전히 로그아웃하고 새 설정이 현재 로그인 세션에 적용되도록 다시 로그인합니다.
참고

이러한 변경은 설치 호스트에서만 수행하거나 설치 호스트를 사용하지 않는 경우 Ansible Automation Platform 설치 프로그램이 실행되는 호스트만 변경해야 합니다.

2.2.5.5. sudo 및 NOPASSWD

규정 준수 프로필을 사용하려면 sudo 권한이 있는 모든 사용자가 암호를 제공해야 합니다(즉, sudoers 파일에서 NOPASSWD 지시문을 사용해서는 안 됩니다). Ansible Automation Platform 설치 프로그램은 권한 있는 사용자로 많은 작업을 실행하고 기본적으로 암호 없이 권한을 승격할 수 있을 것으로 예상합니다. 권한 상승을 위해 설치 프로그램에 암호를 제공하려면 RPM 설치 프로그램 스크립트를 시작할 때 다음 옵션을 추가합니다.

./setup.sh <setup options> --ask-become-pass.

컨테이너 기반 설치 프로그램의 경우:

ansible-playbook ansible.containerized_installer.install --ask-become-pass

설치 프로그램이 실행되면 권한을 얻기 위해 사용자 암호를 입력하라는 메시지가 표시됩니다.

참고

--ask-become-pass 옵션을 사용하는 것은 백업 및 복원과 같은 day-two 작업에 대해 설치 프로그램을 실행하는 경우에도 적용됩니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat, Inc.