이 문서는 Kerberos 인증 지원과 함께 모니터를 실행하도록 신세틱스 작업 관리자 (SJM)를 설정하는 방법을 설명합니다. 또한 작업 관리자를 자체 영역에 연결하기 전에 설정을 검증할 수 있도록 Amazon Linux 2023 EC2 인스턴스에 Kerberos KDC(Key Distribution Center) 및 SPNEGO로 보호되는 웹 애플리케이션을 구축하는 선택적 가이드가 포함되어 있습니다.
플레이스홀더 값
시작하기 전에 환경에 대한 다음 값을 확인하십시오. 이 문서에 나타나는 모든 플레이스홀더를 고유한 값으로 교체하십시오.
플레이스홀더
설명
예시
<REALM_NAME>
Kerberos 영역(대문자여야 함)
KERBTEST.LOCAL
<EC2_PRIVATE_IP>
EC2 인스턴스의 프라이빗 IPv4 주소
10.8.9.172
<EC2_INTERNAL_HOSTNAME>
웹 앱의 정규화된 도메인 이름(FQDN)
ip-X-X-X-X.ec2.internal
<CLIENT_PRINCIPAL>
신세틱스 워커에 할당된 Kerberos ID
synthetics-test
<CLIENT_KEYTAB_PATH>
클라이언트 키탭이 저장된 호스트의 전체 경로
/home/ec2-user/kerb-test/synthetics-test.keytab
<PRIVATE_LOCATION_KEY>
뉴렐릭 프라이빗 로케이션 키
NRSP-us...
요구 사항 및 호환성
Kerberos 인증은 KDC(Key Distribution Center)에 대한 직접적인 네트워크 액세스, 내부 DNS 확인 및 긴밀하게 동기화된 시계에 의존합니다. 이러한 제약 조건은 실행할 수 있는 위치를 제한하므로 시작하기 전에 다음 요구 사항을 검토하십시오.
다음 환경에서는 Kerberos 인증을 지원합니다:
도커 컨테이너 환경에서 신세틱스 작업 관리자를 실행하는 프라이빗 로케이션
Podman 컨테이너 환경에서 신세틱스 작업 관리자를 실행하는 프라이빗 로케이션
다음 환경에서는 Kerberos 인증을 지원하지 않습니다:
내부 KDC로의 네트워크 경로가 없는 공개 위치
Kubernetes 및 OpenShift 작업 관리자 환경
작업 관리자는 브라우저 모니터 작업에만 Kerberos 자격 증명을 제공합니다. 스크립팅된 API 모니터 및 핑 모니터는 Kerberos 인증 없이 실행됩니다.
각 브라우저 런타임 컨테이너는 자체 Kerberos 지원 티켓을 획득하므로(kinit을(를) 통해, Chrome이 출시되기 전에), 프라이빗 로케이션도 다음 요구 사항을 충족해야 합니다:
런타임 컨테이너 내부에서 TCP 및 UDP 포트 88을 통해 KDC에 연결하십시오.
런타임 컨테이너 내부에서 KDC 및 타겟 애플리케이션 호스트명을 확인하십시오. 도커 배포에서 내부 DNS가 이를 확인하지 못하는 경우, RUNTIME_EXTRA_HOSTS (으)로 매핑하십시오 ― 이 변수는 도커 전용입니다. Podman 배포는 내부 DNS에 의존합니다.
chrony과(와) 같은 서비스를 사용하여 프라이빗 로케이션 호스트의 시계를 KDC 시계와 5분 이내로 유지하십시오. 런타임 컨테이너는 호스트의 커널 시계를 공유하므로 호스트를 동기화하는 것으로 충분합니다.
1부: Kerberos 테스트 랩 설정(선택 사항)
팁
1부에서는 작업 관리자 설정을 처음부터 끝까지 검증할 수 있도록 독립적인 Kerberos 영역과 보호된 테스트 애플리케이션을 구축합니다. 이는 프로덕션 경로가 아니며, 뉴렐릭은 사용자의 KDC를 관리하지 않습니다. 이미 Kerberos KDC 또는 Active Directory 도메인을 실행 중인 경우, 관리자로부터 영역 이름, KDC 주소 및 클라이언트 키탭을 가져온 다음 2부로 건너뛰십시오.
클라이언트 키탭의 파일 모드는 보기보다 덜 중요합니다: 여기서 주요 신뢰 경계는 도커 소켓 액세스입니다 ― SJM 자체는 -v /var/run/docker.sock:/var/run/docker.sock:rw을(를) 요구하며, 해당 액세스 권한이 있는 사람은 권한 비트와 관계없이 이미 호스트의 모든 파일을 루트로 읽을 수 있습니다. 위에서 생성한 대로 클라이언트 키탭을 루트 소유로 유지하고 권한을 644 (으)로 설정하십시오 ― 이는 그룹 읽기 비트를 통해 브라우저 런타임 컨테이너의 실행 ID(UID 2000, GID 0)와 일치합니다. 다른 사용자로 chown하지 마십시오. 그렇게 하면 해당 그룹 일치가 깨지고 액세스가 전적으로 전체 읽기 비트에 의존하게 될 수 있습니다. HTTP 서비스 키탭은 테스트 웹 서버 자체의 ID입니다: 6단계의 컨테이너 내부에서 아파치가 실행되는 UID 및 GID를 부여하고 ― Debian의 www-data 사용자인 33 ― 권한도 644 (으)로 유지하십시오. 작업 관리자를 설정하는 데 HTTP 키탭은 필요하지 않습니다.
팁
설정을 검증하기 위해 동일한 호스트에서 테스트 웹 서버를 실행하려는 경우에만 이 단계가 필요합니다. SJM을 구성하는 데는 필요하지 않습니다.
테스트에 성공하면 HTTP/1.1 200 OK (으)로 응답하고 보호된 웹 페이지 콘텐츠를 표시합니다.
파트 2: Kerberos용 신세틱스 작업 관리자 구성
신세틱스 브라우저 러너 컨테이너가 자동으로 KDC를 확인하고, Kerberos 지원 티켓을 획득하며, 보호된 엔드포인트에 대해 인증할 수 있도록 하려면 작업 관리자를 시작하는 명령에 다음 Kerberos 환경 변수 및 keytab 볼륨 마운트를 추가하십시오.
주의
프라이빗 로케이션에서 Kerberos를 활성화하면 해당 위치의 모든 브라우저 모니터 작업이 키탭 마운트 및 Kerberos 환경 변수를 수신합니다. 작업 관리자는 모니터 또는 URL별로 자격 증명을 필터링하지 않습니다. Chrome은 KERBEROS_HOST_ALLOWLIST에만 기반하여 Kerberos 지원 티켓을 수신할 호스트를 결정하므로 해당 허용 목록을 가능한 한 좁게 유지하십시오.
중요
4개의 KERBEROS_* 변수를 모두 설정하거나 아무것도 설정하지 마십시오. 일부만 설정하면 신세틱스 작업 관리자가 시작되지 않고 불완전한 Kerberos 설정 오류를 로그에 기록합니다.
표준 명령(Kerberos 제외)
bash
$
docker run -ePRIVATE_LOCATION_KEY=<PRIVATE_LOCATION_KEY>\
>
-d--restart unless-stopped \
>
-v /var/run/docker.sock:/var/run/docker.sock:rw \
>
newrelic/synthetics-job-manager
필수 명령(Kerberos 지원 활성화됨)
작업 관리자를 시작하기 위해 이미 사용하는 명령에 4개의 KERBEROS_* 환경 변수(-e) 및 키탭 볼륨 마운트(-v)를 추가하십시오.
작업 관리자 설치의 podman run 명령에 동일한 Kerberos 변수 및 keytab 마운트를 추가하십시오. Podman은 도커 소켓을 마운트하는 대신 파드에서 작업 관리자를 실행하므로 기존 CONTAINER_ENGINE, PODMAN_API_SERVICE_PORT 및 PODMAN_POD_NAME 설정을 유지하십시오.
SELinux 호스트에서 컨테이너가 키탭을 읽을 수 있도록 레이블 재지정 플래그를 추가하십시오. 작업 관리자와 작업 관리자가 출시하는 모든 브라우저 런타임 컨테이너는 동일한 파드(PODMAN_POD_NAME) 내에서 실행되며, Podman은 파드의 모든 컨테이너에서 하나의 SELinux 레이블을 공유합니다 ― 따라서 여러 컨테이너가 키탭을 읽더라도 여기서는 :ro,Z이(가) 작동합니다. 키탭을 이 파드 외부의 컨테이너와 공유할 필요가 없으므로 :ro,Z 대신 :Z을(를) 사용하십시오. 자세한 내용은 Podman 볼륨 문서를 참조하십시오.
3부: Kerberos 인증 문제 해결
런타임 컨테이너 내부에서 Kerberos 초기화가 실패하더라도, 컨테이너의 시작 파이프라인은 여전히 브라우저를 출시하고 모니터를 실행합니다. 그런 다음 모니터는 HTTP 401 챌린지 또는 탐색 시간 초과와 함께 보호된 엔드포인트에 대해 실패하며, 결과에 KerberosInitWarning 근본 원인으로 태그를 지정합니다. 실패가 일반적인 시간 초과처럼 보이기 때문에, 모니터 스크립트를 조사하기 전에 작업 로그에서 다음 오류 코드를 확인하십시오.
이 코드는 2부의 시작 유효성 검사와 별개입니다 ― KERBEROS_* 변수 중 일부만 설정하면 작업 관리자가 아예 시작되지 않으며, 이러한 코드는 작업의 로그에 전혀 나타나지 않습니다.
에러 코드
원인
수행할 작업
KERBEROS_KDC_UNREACHABLE
런타임 컨테이너가 네트워크를 통해 KDC에 도달할 수 없습니다.
프라이빗 로케이션 호스트와 KDC 간의 TCP 및 UDP 포트 88에 대한 방화벽 규칙을 확인하십시오.
KERBEROS_BAD_CREDENTIAL
주체가 키탭과 일치하지 않거나 키탭이 손상되었습니다.
klist -kt <CLIENT_KEYTAB_PATH>
을(를) 실행하여 호스트에서 키탭을 확인하십시오.
KERBEROS_CLOCK_SKEW
호스트 시계가 KDC 시계와 5분 이상 차이가 납니다.
chrony
과(와) 같은 서비스를 사용하여 호스트 시계를 NTP와 동기화하십시오.
KERBEROS_DNS_LOOKUP_FAILED
컨테이너가 KDC 호스트명 또는 영역을 확인할 수 없습니다.
작업 관리자 컨테이너의 내부 DNS 확인자 설정을 확인하거나
RUNTIME_EXTRA_HOSTS
(으)로 호스트를 매핑하십시오.
KERBEROS_CONFIG_INVALID
런타임 컨테이너가 마운트된 키탭을 읽을 수 없거나, 해당 키탭에서 주체를 구문 분석할 수 없습니다(비어 있거나 형식이 잘못된 키탭).
런타임 컨테이너 내부에서 키탭을 읽을 수 있고 하나 이상의 주체가 포함되어 있는지 확인하십시오:
klist -kt <CLIENT_KEYTAB_PATH>
.
KERBEROS_UNKNOWN_FAILURE
시스템 수준의 GSSAPI 또는 암호화 오류로 인해 핸드셰이크가 중지되었습니다.
클라이언트 키탭의 암호화 유형(
klist -kt -e <CLIENT_KEYTAB_PATH>
은(는) 각 항목의 enctype을 나열함)을 3단계에서 KDC에 구성된
supported_enctypes
값과 비교하십시오. 키탭이 제공하는 것과 KDC가 허용하는 것 사이의 불일치로 인해 이러한 오류의 대부분이 발생합니다.