이 문서에서는 |RHAT|에서 비밀과 연결을 안전한 방식으로 처리하는 방법을 설명합니다.
|at|에서는 다음 3가지 비밀을 관리합니다.
로컬 automation controller 사용자의 사용자 암호
automation controller 운영에 사용되는 비밀(데이터베이스 암호, 메시지 버스 암호 등)
자동화에 사용되는 비밀(SSH 키, 클라우드 인증 정보, 외부 암호의 자격 증명 모음 인증 정보 등)
|at|에서는 SHA256 해시를 사용하여 PBKDF2 알고리즘으로 로컬 |at| 사용자 암호를 해시합니다. 외부 계정 메커니즘(LDAP, SAML, OAuth 등)을 통해 인증하는 사용자는 암호나 비밀이 저장되어 있지 않습니다.
|at|에는 운영에 사용되는 다음 비밀이 포함되어 있습니다.
/etc/tower/SECRET_KEY
데이터베이스에서 자동화 비밀을 암호화하는 데 사용되는 비밀 키입니다(아래 참조). SECRET_KEY가 변경되거나 알 수 없는 경우에는 데이터베이스의 암호화된 필드에 액세스할 수 없습니다.
/etc/tower/tower.{cert,key}
automation controller 웹 서비스에 사용하는 SSL 인증서와 키입니다. 자체 서명된 인증서/키가 기본적으로 설치되며, 고객이 로컬에 맞는 인증서와 키를 제공할 수 있습니다.
/etc/tower/conf.d/postgres.py의 데이터베이스 암호 및 /etc/tower/conf.d/channels.py의 메시지 버스 암호
automation controller 구성 요소 서비스에 연결하기 위한 암호
이러한 비밀은 automation controller 서비스가 시작 시 자동화된 방식으로 모두 읽어야 하므로 automation controller 서버에 암호화되지 않은 상태로 모두 저장됩니다. 모든 비밀은 Unix 권한으로 보호되며, root와 automation controller 서비스 사용자 awx로 제한됩니다.
이러한 비밀을 숨겨야 하는 경우 비밀을 읽는 파일이 Python으로 해석됩니다. 서비스를 다시 시작할 때마다 다른 메커니즘을 통해 비밀을 검색하도록 해당 파일을 조정할 수 있습니다. 이 작업은 고객이 제공하는 수정 사항으로, 업그레이드할 때마다 다시 적용해야 할 수 있습니다. Red Hat Support와 Red Hat Consulting에서 이러한 수정 사항의 예를 제공합니다.
참고
비밀 시스템이 다운되면 컨트롤러가 정보를 가져올 수 없으며 실패할 수 있습니다. 실패할 경우 서비스가 복원되어야 복구할 수 있습니다. 해당 시스템에서는 중복성을 사용하는 것이 좋습니다.
컨트롤러에서 자동으로 생성된 ``SECRET_KEY``가 어떤 이유로든 손상되어 다시 생성해야 하는 경우 컨트롤러 백업 및 복원 툴과 비슷하게 작동하는 툴을 설치 프로그램에서 실행할 수 있습니다. 새 비밀 키를 생성하려면 다음을 수행합니다.
다른 작업을 수행하기 전에 컨트롤러 데이터베이스를 백업하십시오! 이 가이드의 Backing Up and Restoring 섹션에 설명된 절차를 따르십시오.
설치된 인벤토리(백업/복원을 실행할 때 사용하는 인벤토리)를 사용하여 ``setup.sh -k``를 실행합니다.
이전 키의 백업 복사본은 ``/etc/tower/``에 저장됩니다.
|at|에서는 자동화에 사용되거나 자동화 결과인 다양한 비밀을 데이터베이스에 저장합니다. 이러한 비밀에는 다음이 포함됩니다.
모든 인증 정보 유형의 전체 비밀 필드(암호, 비밀 키, 인증 토큰, 비밀 클라우드 인증 정보)
automation controller 설정에 정의된 외부 서비스의 비밀 토큰 및 암호
“암호” 유형의 설문 조사 필드 항목
비밀 필드를 암호화하기 위해 컨트롤러는 암호화에 256비트 키를 이용하여 CBC 모드로 AES를 사용하고, PKCS7 패딩을 사용하며, 인증에 SHA256을 이용하여 HMAC를 사용합니다. 암호화/암호 해독 프로세스는 SECRET_KEY(위에서 설명), 모델 필드의 필드 이름, 데이터베이스에서 할당된 자동 증가 레코드 ID를 통해 AES-256비트 암호화 키를 얻습니다. 따라서 키 생성 프로세스에서 사용된 속성이 변경되면 컨트롤러가 비밀을 올바르게 해독하지 못합니다. |at|는 |at|에서 시작하는 플레이북의 SECRET_KEY를 읽을 수 없고, 컨트롤러 사용자가 이러한 비밀을 읽을 수 없으며, |at| REST API를 통해 비밀 필드 값을 사용할 수 없도록 설계되었습니다. 비밀 값이 플레이북에 사용되는 경우 실수로 로깅되지 않도록 작업에서 `no_log`를 사용하는 것이 좋습니다.
|at|는 내부 작업 중 다음 서비스에 연결합니다.
PostgreSQL 데이터베이스
Redis 키/값 저장소
Redis 연결은 로컬 Unix 소켓을 통해 이루어지며, awx 서비스 사용자로 제한됩니다.
PostgreSQL 데이터베이스 연결은 localhost 또는 원격으로(외부 데이터베이스) TCP를 통한 암호 인증을 사용하여 이루어집니다. 이 연결은 설치 프로그램 지원을 통해 기본적으로 구성되는 PostgreSQL의 기본 SSL/TLS 지원을 사용할 수 있습니다. SSL/TLS 프로토콜은 기본 OpenSSL 구성을 통해 구성됩니다.
|at|는 nginx가 제공하는 표준 포트에서 표준 HTTP/HTTPS를 통해 액세스할 수 있습니다. 자체 서명된 인증서/키가 기본적으로 설치되며, 고객이 로컬에 맞는 인증서와 키를 제공할 수 있습니다. SSL/TLS 알고리즘 지원은 /etc/nginx/nginx.conf 구성 파일에서 구성됩니다. “중간” 프로필이 기본적으로 사용되며, 고객이 이 프로필을 구성할 수 있습니다. 고객 변경 사항은 업데이트할 때마다 다시 적용해야 합니다.
|at|는 자동화 중 관리형 머신과 서비스에도 연결합니다. 관리형 머신 연결은 모두 SSH, WinRM, SSL/TLS 등의 지정된 표준 보안 메커니즘을 통해 이루어집니다. 각 메커니즘은 해당 기능의 시스템 구성(예: 시스템 OpenSSL 구성)에서 구성을 가져옵니다.