このドキュメントでは、Kerberos認証をサポートした状態でモニターを実行するように外形監視ジョブマネージャー (SJM)を設定する方法について説明します。また、ジョブマネージャーを独自のレルムに向ける前に設定を検証できるように、Amazon Linux 2023 EC2インスタンス上でKerberosキー配布センター(KDC)とSPNEGOで保護されたWebアプリケーションを構築するためのオプションのウォークスルーも含まれています。
プレースホルダーの値 始める前に、ご使用の環境の以下の値を確認してください。このドキュメントに表示されるプレースホルダーはすべて、ご自身の値に置き換えてください。
プレースホルダー
説明
例
<REALM_NAME>
Kerberosレルム(大文字である必要があります)
KERBTEST.LOCAL
<EC2_PRIVATE_IP>
EC2インスタンスのプライベートIPv4アドレス
10.8.9.172
<EC2_INTERNAL_HOSTNAME>
Webアプリの完全修飾ドメイン名(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>
New Relic プライベートロケーションキー
NRSP-us...
要件と互換性 Kerberos認証は、キー配布センター(KDC)への直接ネットワークアクセス、内部DNS解決、および厳密に同期された時計に依存します。これらの制約により実行できる場所が制限されるため、開始する前に以下の要件を確認してください。
以下の環境でKerberos認証をサポートしています:
Dockerコンテナ環境で外形監視ジョブマネージャーを実行するプライベートロケーション Podmanコンテナ環境で外形監視ジョブマネージャーを実行するプライベートロケーション これらの環境では、Kerberos認証をサポートしていません:
内部KDCへのネットワークルートを持たないパブリックロケーション KubernetesおよびOpenShiftのジョブマネージャー環境 ジョブマネージャーは、ブラウザモニタージョブにのみKerberos認証情報を提供します。スクリプト化されたAPIモニターおよびpingモニターは、Kerberos認証なしで実行されます。
各ブラウザランタイムコンテナは(Chromeがリリースされる前に、kinit経由で)独自のKerberosチケットを取得するため、プライベートロケーションもこれらの要件を満たす必要があります:
ランタイムコンテナ内からTCPおよびUDPポート88でKDCにアクセスできるようにしてください。 ランタイムコンテナ内からKDCおよびターゲットアプリケーションのホスト名を解決してください。Dockerデプロイメントで、内部DNSがそれらを解決しない場合は、RUNTIME_EXTRA_HOSTS でマッピングしてください — この変数はDocker専用です。Podmanデプロイメントは内部DNSに依存します。 chronyなどのサービスを使用して、プライベートロケーションホストのクロックとKDCのクロックの差を5分以内に保ってください。ランタイムコンテナはホストのカーネルクロックを共有するため、ホストを同期するだけで十分です。パート1:Kerberosテストラボのセットアップ(オプション) ヒント パート1では、ジョブ・マネージャーの設定をエンド・ツー・エンドで検証できるように、自己完結型のKerberosレルムと保護されたテスト・アプリケーションを構築します。これは本番環境のパスではなく、New Relicはお客様のKDCを管理しません。すでにKerberos KDCまたはActive Directoryドメインを実行している場合は、管理者にレルム名、KDCアドレス、およびクライアント・キータブを取得してもらい、パート2 に進んでください。
ステップ1:Kerberosパッケージをインストールする ホストEC2インスタンスにKerberos KDCサーバーと管理ツールをインストールしてください:
$ sudo dnf install -y krb5-server krb5-workstation
ステップ2:システムKerberosの構成(/etc/krb5.conf) レルムのrequestsをKDCに転送するように/etc/krb5.confを設定します:
$ sudo tee /etc/krb5.conf > /dev/null << 'EOF'
$ default_realm = <REALM_NAME>
$ dns_lookup_realm = false
$ admin_server = <EC2_PRIVATE_IP>
$ <EC2_INTERNAL_HOSTNAME> = <REALM_NAME>
ステップ3:KDCデーモン(kdc.conf)を構成する KDCサービスのポートと暗号化ルールを定義します:
$ sudo tee /var/kerberos/krb5kdc/kdc.conf > /dev/null << 'EOF'
$ acl_file = /var/kerberos/krb5kdc/kadm5.acl
$ dict_file = /usr/share/dict/words
$ admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
$ supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
ステップ4:マスターデータベースとKDCデーモンを初期化する データベースを作成し、KDCバックグラウンドサービスを開始します:
$ sudo kdb5_util create -r < REALM_NAME > -s
$ echo "*/admin@<REALM_NAME> *" | sudo tee /var/kerberos/krb5kdc/kadm5.acl
$ sudo systemctl enable --now krb5kdc kadmin
ステップ5:クライアントとサーバーのキータブの生成 クライアント(外形監視ワーカー)とターゲットWebサーバーのサービスプリンシパル名(SPN)の両方の非対話型資格情報を保持するキータブファイルを生成します:
$ mkdir -p /home/ec2-user/kerb-test
$ sudo kadmin.local -q "addprinc -randkey <CLIENT_PRINCIPAL>@<REALM_NAME>"
$ sudo kadmin.local -q "ktadd -k <CLIENT_KEYTAB_PATH> <CLIENT_PRINCIPAL>@<REALM_NAME>"
$ sudo chmod 644 < CLIENT_KEYTAB_PATH >
$ sudo kadmin.local -q "addprinc -randkey HTTP/<EC2_INTERNAL_HOSTNAME>@<REALM_NAME>"
$ sudo kadmin.local -q "ktadd -k /home/ec2-user/kerb-test/http.keytab HTTP/<EC2_INTERNAL_HOSTNAME>@<REALM_NAME>"
$ sudo chown 33 :33 /home/ec2-user/kerb-test/http.keytab
$ sudo chmod 644 /home/ec2-user/kerb-test/http.keytab
重要 クライアント・キータブのファイル・モードは見た目ほど重要ではありません:ここでの主な信頼境界はDockerソケット・アクセスです — SJM自体が-v /var/run/docker.sock:/var/run/docker.sock:rwを必要とし、そのアクセス権を持つ人は誰でも、パーミッション・ビットに関係なく、ホスト上の任意のファイルをrootとして読み取ることができます。上記で作成したように、クライアント・キータブはroot所有のままにし、パーミッションを644に保ちます — これにより、グループ読み取りビットを介してブラウザ・ランタイム・コンテナの実行ID(UID 2000、GID 0)と一致します。別のユーザーにchownしないでください。そうすると、そのグループの一致が壊れ、アクセスが完全にワールド読み取りビットに依存する可能性があります。HTTPサービス・キータブは、テストWebサーバー自身のIDです:ステップ6のコンテナ内でApacheが実行されるUIDとGID — 33、Debian上のwww-dataユーザー — を付与し、そのパーミッションも644に保ちます。ジョブ・マネージャーを設定するためにHTTPキータブは必要ありません。
(オプション)ステップ6:テストWebコンテナのデプロイ ヒント この手順は、セットアップを検証するために同じホスト上でテストWebサーバーを実行する場合にのみ必要です。SJMの設定には必要ありません。
mod_auth_gssapiで構成されたApacheコンテナをデプロイします:
$ mkdir -p ~/kerb-test/httpd-image && cd ~/kerb-test/httpd-image
$ cat > kerb-test.conf << 'EOF'
$ AuthName "Kerberos Login"
$ GssapiCredStore keytab:/etc/krb5-http.keytab
$ cat > Dockerfile << 'EOF'
$ FROM debian:bookworm-slim
> apt-get install -y --no-install-recommends apache2 libapache2-mod-auth-gssapi krb5-user && \
> a2enmod auth_gssapi && \
> mkdir -p /var/www/html/kerb-test && \
> echo '<h1>Kerberos SSO worked</h1>' > /var/www/html/kerb-test/index.html && \
> rm -rf /var/lib/apt/lists/*
$ COPY kerb-test.conf /etc/apache2/conf-enabled/kerb-test.conf
$ CMD ["apache2ctl", "-D", "FOREGROUND"]
$ docker build -t kerb-test-httpd .
$ docker run -d --name kerb-test-httpd \
> -v /etc/krb5.conf:/etc/krb5.conf:ro \
> -v /home/ec2-user/kerb-test/http.keytab:/etc/krb5-http.keytab:ro \
ステップ7:ローカルDNSとKerberosハンドシェイクの検証 内部ドメインがホスト上でローカルに解決されることを確認し、Kerberos認証が正常に完了することを検証します:
$ echo "<EC2_PRIVATE_IP> <EC2_INTERNAL_HOSTNAME>" | sudo tee -a /etc/hosts
$ curl -i http:// < EC2_INTERNAL_HOSTNAME > :8080/kerb-test/
$ kinit -kt < CLIENT_KEYTAB_PATH > < CLIENT_PRINCIPAL > @ < REALM_NAME >
$ curl --negotiate -u : -i http:// < EC2_INTERNAL_HOSTNAME > :8080/kerb-test/
テストが成功すると、HTTP/1.1 200 OK で応答し、保護されたWebページのコンテンツが表示されます。
パート2:Kerberos用に外形監視ジョブマネージャーを設定する 外形監視ブラウザランナーコンテナがKDCを自動的に解決し、Kerberosチケットを取得し、保護されたエンドポイントに対して認証できるようにするには、ジョブマネージャーを起動するコマンドに以下のKerberos環境変数とキータブボリュームマウントを追加してください。
注意 プライベートロケーションでKerberosを有効にすると、そのロケーションのすべてのブラウザーモニタージョブがキータブマウントとKerberos環境変数を受け取ります。ジョブマネージャーは、モニターごとやURLごとに認証情報をフィルタリングしません。ChromeはKERBEROS_HOST_ALLOWLISTのみに基づいてどのホストがKerberosチケットを受け取るかを決定するため、その許可リストはできるだけ絞り込んでください。
重要 4つのKERBEROS_*変数をすべて設定するか、どれも設定しないかのいずれかにしてください。一部のみを設定した場合、外形監視ジョブマネージャーは起動に失敗し、不完全なKerberos設定エラーをログに記録します。
標準コマンド(Kerberosなし) $ docker run -e PRIVATE_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)を、ジョブ・マネージャーを起動するためにすでに使用しているコマンドに追加します。
Docker > --restart unless-stopped \
> -e PRIVATE_LOCATION_KEY = < PRIVATE_LOCATION_KEY > \
> -e KERBEROS_REALM = < REALM_NAME > \
> -e KERBEROS_KDC = < EC2_PRIVATE_IP > \
> -e KERBEROS_HOST_ALLOWLIST = < EC2_INTERNAL_HOSTNAME > \
> -e KERBEROS_KEYTAB_HOST_PATH = < CLIENT_KEYTAB_PATH > \
> -e RUNTIME_EXTRA_HOSTS = < EC2_INTERNAL_HOSTNAME > : < EC2_PRIVATE_IP > \
> -v /var/run/docker.sock:/var/run/docker.sock:rw \
> -v < CLIENT_KEYTAB_PATH > : < CLIENT_KEYTAB_PATH > :ro \
> newrelic/synthetics-job-manager
ポッドマン 「ジョブマネージャーのインストール」 のpodman runコマンドに、同じKerberos変数とキータブマウントを追加してください。PodmanはDockerソケットをマウントするのではなく、ポッドでジョブマネージャーを実行するため、既存のCONTAINER_ENGINE、PODMAN_API_SERVICE_PORT、およびPODMAN_POD_NAMEの設定を維持してください。
> --restart unless-stopped \
> -e PRIVATE_LOCATION_KEY = < PRIVATE_LOCATION_KEY > \
> -e CONTAINER_ENGINE = PODMAN \
> -e PODMAN_API_SERVICE_PORT = 8000 \
> -e PODMAN_POD_NAME = SYNTHETICS \
> -e KERBEROS_REALM = < REALM_NAME > \
> -e KERBEROS_KDC = < EC2_PRIVATE_IP > \
> -e KERBEROS_HOST_ALLOWLIST = < EC2_INTERNAL_HOSTNAME > \
> -e KERBEROS_KEYTAB_HOST_PATH = < CLIENT_KEYTAB_PATH > \
> -v < CLIENT_KEYTAB_PATH > : < CLIENT_KEYTAB_PATH > :ro,Z \
> newrelic/synthetics-job-manager
ヒント SELinuxホストでは、コンテナがキータブを読み取れるようにrelabelフラグを追加してください。ジョブマネージャーとそれがリリースするすべてのブラウザランタイムコンテナは同じポッド(PODMAN_POD_NAME)内で実行され、Podmanはポッド内のすべてのコンテナで1つの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
ランタイムコンテナがマウントされたキータブを読み取れないか、そこからプリンシパルを解析できませんでした(空の、または不正な形式のキータブ)。
キータブがランタイムコンテナ内で読み取り可能であり、少なくとも1つのプリンシパルが含まれていることを確認してください:
klist -kt <CLIENT_KEYTAB_PATH>
。
KERBEROS_UNKNOWN_FAILURE
システム・レベルのGSSAPIまたは暗号化の失敗により、ハンドシェイクが停止しました。
クライアントキータブの暗号化タイプ(
klist -kt -e <CLIENT_KEYTAB_PATH>
には各エントリのenctypeがリストされています)を、ステップ3でKDCに設定された
supported_enctypes
の値と比較してください。キータブが提供するものとKDCが受け入れるものとの間の不一致が、これらのエラーのほとんどの原因となります。