2.7. 고급 구성 옵션
컨테이너화된 Ansible Automation Platform을 보다 복잡한 배포에는 외부 데이터베이스 설정 및 사용자 지정 TLS 인증서 사용과 같은 고급 구성 옵션을 사용할 수 있습니다.
이러한 고급 구성 옵션을 사용하지 않는 경우 컨테이너화된 Ansible Automation Platform 설치 로 이동하여 설치를 계속합니다.
2.7.1. 이벤트 기반 Ansible 컨트롤러에 안전한 플러그인 변수 추가 링크 복사링크가 클립보드에 복사되었습니다!
이벤트 기반 Ansible 컨트롤러에서 룰북 활성화를 실행하는 redhat.insights_eda 또는 유사한 플러그인을 사용하는 경우 Ansible Automation Platform의 디렉터리에 보안 플러그인 변수를 추가해야 합니다. 이렇게 하면 이벤트 기반 Ansible 컨트롤러와 소스 플러그인 간의 연결이 보장되고 포트 매핑이 올바르게 표시됩니다.
프로세스
안전한 플러그인 변수에 사용할 디렉터리를 생성합니다.
mkdir -p ./group_vars/automationeda-
새 설정에 대한 해당 디렉터리에 파일을 만듭니다(예:
./group_vars/automationeda/custom.yml) 활성화할 플러그인 목록과 함께 변수
eda_safe_plugins를 추가합니다. 예를 들면 다음과 같습니다.eda_safe_plugins: ['ansible.eda.webhook', 'ansible.eda.alertmanager']
2.7.2. 실행 노드 추가 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너화된 Ansible Automation Platform은 원격 실행 노드를 배포할 수 있습니다.
인벤토리 파일의 [execution_nodes] 그룹에서 원격 실행 노드를 정의할 수 있습니다.
[execution_nodes]
<fqdn_of_your_execution_host>
기본적으로 실행 노드는 필요에 따라 수정할 수 있는 다음 설정으로 구성됩니다.
receptor_port=27199
receptor_protocol=tcp
receptor_type=execution
-
receiver_port- 수신기가 다른 수신기 노드에서 들어오는 연결을 수신 대기하는 포트 번호입니다. -
receiver_type- 노드의 역할입니다. 유효한 옵션에는실행또는홉이 포함됩니다. -
receiver_protocol- 통신에 사용되는 프로토콜입니다. 유효한 옵션에는tcp또는udp가 있습니다.
기본적으로 [execution_nodes] 그룹의 모든 노드가 컨트롤러 노드의 피어로 추가됩니다. 피어 구성을 변경하려면 수신기 _peers 변수를 사용합니다.
receiver _peers 의 값은 쉼표로 구분된 호스트 이름 목록이어야 합니다. 인벤토리 그룹 이름을 사용하지 마십시오.
설정 예:
[execution_nodes]
# Execution nodes
exec1.example.com
exec2.example.com
# Hop node that peers with the two execution nodes above
hop1.example.com receptor_type=hop receptor_peers='["exec1.example.com","exec2.example.com"]'
2.7.3. 자동화 허브용 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
Amazon S3, Azure Blob Storage 및 NFS(Network File System) 스토리지를 포함한 자동화 허브에 대한 스토리지 백엔드를 구성합니다.
2.7.3.1. 자동화 허브를 위한 Amazon S3 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
Amazon S3 스토리지는 컨테이너화된 설치에서 지원되는 오브젝트 스토리지 유형입니다. AWS S3 스토리지 백엔드를 사용하는 경우 hub_storage_backend 를 s3 로 설정합니다. 설치 프로그램을 실행하기 전에 AWS S3 버킷이 있어야 합니다.
프로세스
- 설치를 진행하기 전에 AWS S3 버킷이 있는지 확인합니다.
S3 스토리지를 구성하려면
[all:vars]그룹의 인벤토리 파일에 다음 변수를 추가합니다.-
hub_s3_access_key -
hub_s3_secret_key -
hub_s3_bucket_name hub_s3_extra_settingsAnsible
hub_s3_extra_settings사전을 통해 추가 매개변수를 전달할 수 있습니다. 예를 들면 다음과 같습니다.hub_s3_extra_settings: AWS_S3_MAX_MEMORY_SIZE: 4096 AWS_S3_REGION_NAME: eu-central-1 AWS_S3_USE_SSL: True
-
2.7.3.2. 자동화 허브를 위한 Azure Blob 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
Azure Blob 스토리지는 컨테이너화된 설치에서 지원되는 오브젝트 스토리지 유형입니다. Azure Blob 스토리지 백엔드를 사용하는 경우 hub_storage_backend 를 azure 로 설정합니다. 설치 프로그램을 실행하기 전에 Azure 컨테이너가 있어야 합니다.
프로세스
- 설치를 진행하기 전에 Azure 컨테이너가 있는지 확인합니다.
[all:vars]그룹의 인벤토리 파일에 다음 변수를 추가하여 Azure Blob 스토리지를 구성합니다.-
hub_azure_account_key -
hub_azure_account_name -
hub_azure_container hub_azure_extra_settingsAnsible
hub_azure_extra_settings사전을 통해 추가 매개변수를 전달할 수 있습니다. 예를 들면 다음과 같습니다.hub_azure_extra_settings: AZURE_LOCATION: foo AZURE_SSL: True AZURE_URL_EXPIRATION_SECS: 60
-
2.7.3.3. 자동화 허브를 위한 NFS(네트워크 파일 시스템) 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
NFS는 컨테이너화된 설치에서 지원되는 공유 스토리지의 유형입니다. 파일 스토리지 백엔드와 함께 자동화 허브의 인스턴스를 두 개 이상 설치할 때는 공유 스토리지가 필요합니다. 자동화 허브의 단일 인스턴스를 설치할 때 공유 스토리지는 선택 사항입니다.
프로세스
자동화 허브를 위해 공유 스토리지를 구성하려면 인벤토리 파일에서
hub_shared_data_path변수를 설정합니다.hub_shared_data_path=<path_to_nfs_share>값은
host:dir형식과 일치해야 합니다(예:nfs-server.example.com:/exports/hub).-
(선택 사항) NFS 공유의 마운트 옵션을 변경하려면
hub_shared_data_mount_opts변수를 사용합니다. 기본값은rw,sync,hard입니다.
2.7.4. HAProxy 로드 밸런서 구성 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 CA 인증서를 사용하여 플랫폼 게이트웨이 앞에 HAProxy 로드 밸런서를 구성하려면 [all:vars] 그룹에 다음 인벤토리 파일 변수를 설정합니다.
custom_ca_cert=<path_to_cert_crt>
gateway_main_url=<https://load_balancer_url>
HAProxy SSL passthrough 모드는 플랫폼 게이트웨이에서 지원되지 않습니다.
2.7.5. 자동화 콘텐츠 수집 및 컨테이너 서명 활성화 링크 복사링크가 클립보드에 복사되었습니다!
자동화 콘텐츠 서명은 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 인벤토리 파일에 다음 설치 변수가 필요합니다.
# Collection signing
hub_collection_signing=true
hub_collection_signing_key=<full_path_to_collection_gpg_key>
# Container signing
hub_container_signing=true
hub_container_signing_key=<full_path_to_container_gpg_key>
키가 암호로 보호되는 경우 다음 변수가 필요합니다.
# Collection signing
hub_collection_signing_pass=<gpg_key_passphrase>
# Container signing
hub_container_signing_pass=<gpg_key_passphrase>
hub_collection_signing_key 및 hub_container_signing_key 변수에는 설치를 실행하기 전에 키를 설정해야 합니다.
자동화 콘텐츠 서명은 현재 GnuPG(GPG) 기반 서명 키만 지원합니다. GPG에 대한 자세한 내용은 GnuPG 도움말 페이지를 참조하십시오.
사용되는 알고리즘과 암호는 고객의 책임이다.
프로세스
RHEL9 서버에서 다음 명령을 실행하여 컬렉션 서명에 사용할 새 키 쌍을 생성합니다.
gpg --gen-key"실명" 및 "Email address"에 대한 정보를 입력합니다.
출력 예:
gpg --gen-key gpg (GnuPG) 2.3.3; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Joe Bloggs Email address: jbloggs@example.com You selected this USER-ID: "Joe Bloggs <jbloggs@example.com>" Change (N)ame, (E)mail, or (O)kay/(Q)uit? O이 방법이 실패하면 환경에 GPG에 필요한 사전 요구 사항 패키지가 설치되어 있지 않습니다. 계속 진행하기 위해 필요한 패키지를 설치합니다.
- 대화 상자가 표시되고 암호를 묻는 메시지가 표시됩니다. 이는 선택 사항이지만 권장됩니다.
그런 다음 키가 생성되고 다음과 유사한 출력을 생성합니다.
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: key 022E4FBFB650F1C4 marked as ultimately trusted gpg: revocation certificate stored as '/home/aapuser/.gnupg/openpgp-revocs.d/F001B037976969DD3E17A829022E4FBFB650F1C4.rev' public and secret key created and signed. pub rsa3072 2024-10-25 [SC] [expires: 2026-10-25] F001B037976969DD3E17A829022E4FBFB650F1C4 uid Joe Bloggs <jbloggs@example.com> sub rsa3072 2024-10-25 [E] [expires: 2026-10-25]회사 표준 및 요구 사항에 따라 설정할 수 있는 만료 날짜를 참고하십시오.
다음 명령을 실행하여 모든 GPG 키를 볼 수 있습니다.
gpg --list-secret-keys --keyid-format=long공개 키를 내보내려면 다음 명령을 실행합니다.
gpg --export -a --output collection-signing-key.pub <email_address_used_to_generate_key>개인 키를 내보내려면 다음 명령을 실행합니다.
gpg -a --export-secret-keys <email_address_used_to_generate_key> > collection-signing-key.priv- 암호가 감지되면 암호를 입력하라는 메시지가 표시됩니다.
개인 키 파일 콘텐츠를 보려면 다음 명령을 실행합니다.
cat collection-signing-key.priv출력 예:
-----BEGIN PGP PRIVATE KEY BLOCK----- lQWFBGcbN14BDADTg5BsZGbSGMHypUJMuzmIffzzz4LULrZA8L/I616lzpBHJvEs sSN6KuKY1TcIwIDCCa/U5Obm46kurpP2Y+vNA1YSEtMJoSeHeamWMDd99f49ItBp <snippet> j920hRy/3wJGRDBMFa4mlQg= =uYEF -----END PGP PRIVATE KEY BLOCK------ 1~9단계를 반복하여 컨테이너 서명의 키 쌍을 만듭니다.
인벤토리 파일에 다음 변수를 추가하고 설치를 실행하여 서명 서비스를 생성합니다.
# Collection signing hub_collection_signing=true hub_collection_signing_key=/home/aapuser/aap/ansible-automation-platform-containerized-setup-<version_number>/collection-signing-key.priv # This variable is required if the key is protected by a passphrase hub_collection_signing_pass=<password> # Container signing hub_container_signing=true hub_container_signing_key=/home/aapuser/aap/ansible-automation-platform-containerized-setup-<version_number>/container-signing-key.priv # This variable is required if the key is protected by a passphrase hub_container_signing_pass=<password>
2.7.6. 고객 제공(외부) 데이터베이스 설정 링크 복사링크가 클립보드에 복사되었습니다!
외부 데이터베이스를 설정하는 데 사용할 수 있는 두 가지 시나리오가 있습니다.
- PostgreSQL 관리자 인증 정보가 있는 외부 데이터베이스
- PostgreSQL 관리자 인증 정보가 없는 외부 데이터베이스
- Ansible Automation Platform에서 외부 데이터베이스를 사용하는 경우 해당 데이터베이스를 생성하고 유지 관리해야 합니다. Ansible Automation Platform을 제거할 때 외부 데이터베이스를 지웁니다.
- ICU를 지원하기 위해 Red Hat Ansible Automation Platform을 사용하려면 고객 제공(외부) 데이터베이스가 필요합니다.
- 외부 데이터베이스를 구성하는 동안 외부 데이터베이스 범위를 확인해야 합니다. 자세한 내용은 Red Hat Ansible Automation Platform Database 지원 범위를 참조하십시오.
2.7.6.1. PostgreSQL 관리자 자격 증명을 사용하여 외부 데이터베이스 설정 링크 복사링크가 클립보드에 복사되었습니다!
PostgreSQL 관리자 인증 정보가 있는 경우 인벤토리 파일에 제공할 수 있으며 설치 프로그램은 각 구성 요소에 대해 PostgreSQL 사용자 및 데이터베이스를 생성합니다. PostgreSQL admin 계정에는 SUPERUSER 권한이 있어야 합니다.
프로세스
PostgreSQL 관리자 인증 정보를 구성하려면
[all:vars]그룹의 인벤토리 파일에 다음 변수를 추가합니다.postgresql_admin_username=<set your own> postgresql_admin_password=<set your own>
2.7.6.2. PostgreSQL 관리자 인증 정보가 없는 외부 데이터베이스 설정 링크 복사링크가 클립보드에 복사되었습니다!
PostgreSQL 관리자 인증 정보가 없는 경우 설치 프로그램을 실행하기 전에 각 구성 요소(플랫폼 게이트웨이, 자동화 컨트롤러, 자동화 허브, 이벤트 기반 Ansible)에 대해 PostgreSQL 사용자 및 데이터베이스를 생성해야 합니다.
프로세스
SUPERUSER권한이 있는 사용자로 PostgreSQL 호환 데이터베이스 서버에 연결합니다.# psql -h <hostname> -U <username> -p <port_number>예를 들면 다음과 같습니다.
# psql -h db.example.com -U superuser -p 5432암호를 사용하여 사용자를 생성하고
CREATEDB역할이 사용자에게 할당되었는지 확인합니다. 자세한 내용은 데이터베이스 역할을 참조하십시오.CREATE USER <username> WITH PASSWORD <password> CREATEDB;데이터베이스를 생성하고 소유자로 생성한 사용자를 추가합니다.
CREATE DATABASE <database_name> OWNER <username>;각 구성 요소에 대해 PostgreSQL 사용자 및 데이터베이스를 생성한 경우
[all:vars]그룹의 인벤토리 파일에 제공할 수 있습니다.# Platform gateway gateway_pg_host=aap.example.org gateway_pg_database=<set your own> gateway_pg_username=<set your own> gateway_pg_password=<set your own> # Automation controller controller_pg_host=aap.example.org controller_pg_database=<set your own> controller_pg_username=<set your own> controller_pg_password=<set your own> # Automation hub hub_pg_host=aap.example.org hub_pg_database=<set your own> hub_pg_username=<set your own> hub_pg_password=<set your own> # Event-Driven Ansible eda_pg_host=aap.example.org eda_pg_database=<set your own> eda_pg_username=<set your own> eda_pg_password=<set your own>
2.7.6.3. 자동화 허브 PostgreSQL 데이터베이스의 hstore 확장 활성화 링크 복사링크가 클립보드에 복사되었습니다!
데이터베이스 마이그레이션 스크립트는 hstore 필드를 사용하여 정보를 저장하므로 자동화 허브 PostgreSQL 데이터베이스에서 hstore 확장을 활성화해야 합니다.
이 프로세스는 Ansible Automation Platform 설치 프로그램 및 관리형 PostgreSQL 서버를 사용할 때 자동으로 수행됩니다.
PostgreSQL 데이터베이스가 외부인 경우 설치 전에 자동화 허브 PostgreSQL 데이터베이스에서 hstore 확장을 수동으로 활성화해야 합니다.
설치 전에 hstore 확장 기능을 활성화하지 않으면 데이터베이스 마이그레이션 중에 오류가 발생합니다.
프로세스
PostgreSQL 서버(자동화 허브 데이터베이스)에서 확장을 사용할 수 있는지 확인합니다.
$ psql -d <automation hub database> -c "SELECT * FROM pg_available_extensions WHERE name='hstore'"여기서 <
automation hub database>의 기본값은automationhub입니다.hstore를 사용할 수 있는 출력 예:name | default_version | installed_version |comment ------+-----------------+-------------------+--------------------------------------------------- hstore | 1.7 | | data type for storing sets of (key, value) pairs (1 row)hstore를 사용할 수 없는 출력 예:name | default_version | installed_version | comment ------+-----------------+-------------------+--------- (0 rows)RHEL 기반 서버에서
hstore확장은postgresql-contribRPM 패키지에 포함되어 있으며 PostgreSQL 서버 RPM 패키지를 설치할 때 자동으로 설치되지 않습니다.RPM 패키지를 설치하려면 다음 명령을 사용하십시오.
dnf install postgresql-contrib다음 명령을 사용하여
hstorePostgreSQL 확장을 자동화 허브 데이터베이스에 로드합니다.$ psql -d <automation hub database> -c "CREATE EXTENSION hstore;"다음 출력에서
installed_version필드에는hstore가 활성화되었음을 나타내는hstore확장이 나열됩니다.name | default_version | installed_version | comment -----+-----------------+-------------------+------------------------------------------------------ hstore | 1.7 | 1.7 | data type for storing sets of (key, value) pairs (1 row)
2.7.6.4. 선택 사항: 외부 데이터베이스에 대한 상호 TLS(mTLS) 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
mTLS 인증은 기본적으로 비활성화되어 있습니다. mTLS 인증을 사용하여 각 구성 요소의 데이터베이스를 구성하려면 [all:vars] 그룹의 인벤토리 파일에 다음 변수를 추가하고 각 구성 요소에 다른 TLS 인증서 및 키가 있는지 확인합니다.
프로세스
[all:vars]그룹의 인벤토리 파일에 다음 변수를 추가합니다.# Platform gateway gateway_pg_cert_auth=true gateway_pg_tls_cert=/path/to/gateway.cert gateway_pg_tls_key=/path/to/gateway.key gateway_pg_sslmode=verify-full # Automation controller controller_pg_cert_auth=true controller_pg_tls_cert=/path/to/awx.cert controller_pg_tls_key=/path/to/awx.key controller_pg_sslmode=verify-full # Automation hub hub_pg_cert_auth=true hub_pg_tls_cert=/path/to/pulp.cert hub_pg_tls_key=/path/to/pulp.key hub_pg_sslmode=verify-full # Event-Driven Ansible eda_pg_cert_auth=true eda_pg_tls_cert=/path/to/eda.cert eda_pg_tls_key=/path/to/eda.key eda_pg_sslmode=verify-full
2.7.7. 사용자 정의 TLS 인증서 사용 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Ansible Automation Platform은 X.509 인증서와 키 쌍을 사용하여 Ansible Automation Platform 구성 요소 간에 내부적으로 트래픽을 보호하고 공용 UI 및 API 연결에 대해 외부적으로 트래픽을 보호합니다.
Ansible Automation Platform 배포를 위한 TLS 인증서를 관리하는 두 가지 기본 방법이 있습니다.
- Ansible Automation Platform 생성된 인증서(기본값)
- 사용자 제공 인증서
2.7.7.1. Ansible Automation Platform에서 생성된 인증서 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 설치 프로그램은 자체 서명된 CA(인증 기관)를 생성하고 이를 사용하여 모든 Ansible Automation Platform 서비스에 대한 자체 서명된 TLS 인증서를 생성합니다. 자체 서명된 CA 인증서 및 키는 ~/aap/tls/ 디렉터리 아래에 하나의 노드에 생성되고 다른 모든 노드의 동일한 위치에 복사됩니다. 이 CA는 초기 생성 날짜 이후 10년 동안 유효합니다.
자체 서명된 인증서는 공개 신뢰 체인의 일부가 아닙니다. 설치 프로그램은 ~/aap/tls/extracted/ 아래에 자체 서명된 CA 인증서를 포함하는 인증서 신뢰 저장소를 생성하고 /etc/pki/ca-trust/extracted/ 아래의 각 Ansible Automation Platform 서비스 컨테이너에 해당 디렉터리를 바인딩 마운트합니다. 이를 통해 각 Ansible Automation Platform 구성 요소에서 다른 Ansible Automation Platform 서비스의 자체 서명된 인증서의 유효성을 확인할 수 있습니다. 필요에 따라 다른 시스템 또는 브라우저의 신뢰 저장소에 CA 인증서를 추가할 수도 있습니다.
2.7.7.2. 사용자 제공 인증서 링크 복사링크가 클립보드에 복사되었습니다!
고유한 TLS 인증서와 키를 사용하여 설치 중에 생성된 자체 서명 인증서의 일부 또는 모두를 교체하려면 인벤토리 파일에서 특정 변수를 설정할 수 있습니다. 이러한 인증서와 키는 설치 프로세스 중에 사용할 수 있도록 공용 또는 조직 CA에서 사전에 생성해야 합니다.
2.7.7.2.1. 사용자 정의 CA를 사용하여 모든 TLS 인증서 생성 링크 복사링크가 클립보드에 복사되었습니다!
Ansible Automation Platform에서 모든 인증서를 생성하지만 기본 자체 서명된 인증서 대신 사용자 정의 CA에서 서명하려면 이 방법을 사용합니다.
프로세스
사용자 정의 CA(인증 기관)를 사용하여 모든 Ansible Automation Platform 서비스에 대한 TLS 인증서를 생성하려면 인벤토리 파일에서 다음 변수를 설정합니다.
ca_tls_cert=<path_to_ca_tls_certificate> ca_tls_key=<path_to_ca_tls_key>
2.7.7.2.2. 각 서비스에 대한 사용자 정의 TLS 인증서 제공 링크 복사링크가 클립보드에 복사되었습니다!
조직에서 Ansible Automation Platform 외부에서 TLS 인증서를 관리하고 수동 프로비저닝이 필요한 경우 이 방법을 사용합니다.
프로세스
각 개별 서비스(예: 자동화 컨트롤러, 자동화 허브, 이벤트 기반 Ansible)에 대한 TLS 인증서를 수동으로 제공하려면 인벤토리 파일에서 다음 변수를 설정합니다.
# Platform gateway gateway_tls_cert=<path_to_tls_certificate> gateway_tls_key=<path_to_tls_key> gateway_pg_tls_cert=<path_to_tls_certificate> gateway_pg_tls_key=<path_to_tls_key> gateway_redis_tls_cert=<path_to_tls_certificate> gateway_redis_tls_key=<path_to_tls_key> # Automation controller controller_tls_cert=<path_to_tls_certificate> controller_tls_key=<path_to_tls_key> controller_pg_tls_cert=<path_to_tls_certificate> controller_pg_tls_key=<path_to_tls_key> # Automation hub hub_tls_cert=<path_to_tls_certificate> hub_tls_key=<path_to_tls_key> hub_pg_tls_cert=<path_to_tls_certificate> hub_pg_tls_key=<path_to_tls_key> # Event-Driven Ansible eda_tls_cert=<path_to_tls_certificate> eda_tls_key=<path_to_tls_key> eda_pg_tls_cert=<path_to_tls_certificate> eda_pg_tls_key=<path_to_tls_key> eda_redis_tls_cert=<path_to_tls_certificate> eda_redis_tls_key=<path_to_tls_key> # PostgreSQL postgresql_tls_cert=<path_to_tls_certificate> postgresql_tls_key=<path_to_tls_key> # Receptor receptor_tls_cert=<path_to_tls_certificate> receptor_tls_key=<path_to_tls_key> # Redis redis_tls_cert=<path_to_tls_certificate> redis_tls_key=<path_to_tls_key>
2.7.7.2.3. 서비스당 제공되는 인증서 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
각 개별 서비스에 사용자 정의 TLS 인증서를 제공할 때 다음을 고려하십시오.
-
호스트당 고유 인증서를 제공할 수 있습니다. 이를 위해서는 이전 인벤토리 파일 예제에 표시된 것처럼 인벤토리 파일에서 특정
_tls_cert및_tls_key변수를 정의해야 합니다. - 많은 노드에 배포된 서비스(예: 엔터프라이즈 토폴로지를 따를 때) 서비스의 경우 해당 서비스에 제공된 인증서에는 연결된 모든 노드의 FQDN이 SAN(Subject Alternative Name) 필드에 포함되어야 합니다.
- SSL/TLS 오프로드를 수행하는 로드 밸런서 뒤에 외부 연결 서비스(예: 자동화 컨트롤러 또는 플랫폼 게이트웨이)를 배포하는 경우 개별 서비스 노드의 FQDN 외에도 서비스의 인증서가 SAN 필드에 로드 밸런서의 FQDN을 포함해야 합니다.
2.7.7.2.4. 사용자 정의 CA 인증서 제공 링크 복사링크가 클립보드에 복사되었습니다!
TLS 인증서를 수동으로 제공하면 사용자 정의 CA에서 해당 인증서에 서명할 수 있습니다. 사용자 정의 CA 인증서를 제공하여 사용자 환경 내에서 적절한 인증 및 보안 통신을 보장합니다. 사용자 정의 CA 인증서가 여러 개 있는 경우 단일 파일에 병합해야 합니다.
프로세스
수동으로 제공한 TLS 인증서가 사용자 정의 CA에서 서명한 경우 인벤토리 파일에서 다음 변수를 사용하여 CA 인증서를 지정해야 합니다.
custom_ca_cert=<path_to_custom_ca_certificate>둘 이상의 CA 인증서가 있는 경우 단일 파일로 결합하고
custom_ca_cert변수와 결합된 인증서를 참조합니다.
2.7.7.3. 수신기 인증서 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
Receptor 노드에 사용자 정의 인증서를 사용하는 경우 인증서에는 1.3.6.1.4.1.2312.19.1 인 인증서의 SAN(주체 대체 이름)에 지정된 otherName 필드가 필요합니다. 자세한 내용은 메시 TLS 표시 를 참조하십시오.
수신기는 와일드카드 인증서 사용을 지원하지 않습니다. 또한 TLS 호스트 이름 검증을 올바르게 수행하려면 각 수신기 인증서의 호스트 FQDN이 SAN에 지정되어 있어야 합니다.
2.7.7.4. Redis 인증서 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
Redis 관련 서비스에 사용자 정의 TLS 인증서를 사용하는 경우 EKU(Extended Key Usage)를 지정하는 경우 상호 TLS(mTLS) 통신에 대해 다음을 고려하십시오.
-
Redis 서버 인증서(
redis_tls_cert)에는serverAuth(웹 서버 인증) 및clientAuth(클라이언트 인증) EKU가 포함되어야 합니다. -
Redis 클라이언트 인증서(
gateway_redis_tls_cert,eda_redis_tls_cert)에는clientAuth(클라이언트 인증) EKU가 포함되어야 합니다.
2.7.8. 사용자 정의 수신기 서명 키 사용 링크 복사링크가 클립보드에 복사되었습니다!
수신기 서명은 수신기 _disable_signing=true 가 설정되어 있고 설치 프로그램에서 RSA 키 쌍(공용 및 개인)이 생성되지 않는 한 기본적으로 활성화됩니다. 그러나 다음 변수를 사용하여 사용자 지정 RSA 공개 및 개인 키를 설정할 수 있습니다.
receptor_signing_private_key=<full_path_to_private_key>
receptor_signing_public_key=<full_path_to_public_key>