認証

合成テストには、Splunk Synthetic Monitoring がそのテストタイプでサポートしている認証方法を組み込むことができます。

Syntheticsテストでは、以下の認証方法を設定に利用可能です:

HTMLログインフォームによる基本認証

注: この認証方法は、ブラウザテストにのみ適用されます。

テスト対象がユーザー名とパスワードを入力するためのHTMLフォームを提供している場合は、ブラウザテストを以下のように設定します。

HTMLフォームを使った基本認証による合成テストの設定方法を示すスクリーンショット。
  1. このテスト対象のユーザー名とパスワード用にグローバル変数を作成します。ベストプラクティスは、 パスワード用に作成したグローバル変数を非表示にすることです。詳細については、「グローバル変数」を参照してください。

  2. ブラウザテストの設定ページで、[Simple] トグルを選択します。

  3. Edit steps or synthetic transactions を選択します。

  4. Fill in fieldというタイプのステップを追加し、以下のように設定します:

    1. [Selector] に、ターゲットページのユーザー名フィールドの ID、名前、XPath、 CSS 、リンク、または JS パスを入力します。Chrome の要素セレクタの詳細については、「Chrome DevTools」を参照してください。

    2. [Value] には、ユーザー名を格納したグローバル変数名を、env. を先頭につけて二重中括弧で囲んで入力します。たとえば、{{env.test1_username}} のようになります。

  5. Fill in fieldというタイプのステップを追加し、以下のように設定します:

    1. [Selector] に、ターゲットページのパスワードフィールドの ID を入力します。

    2. [Value] には、パスワードを格納したグローバル変数名を、env. を先頭につけて二重中括弧で囲んで入力します。たとえば、{{env.test1_password}} のようになります。

  6. Clickというタイプのステップを追加し、以下のように設定します:

    1. [Selector] に、ターゲットページのログインボタンの ID を入力します。

    2. (オプション)Wait for navigation**を待機するミリ秒数に設定します。

  7. ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:

    1. Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。

    2. (オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。

  8. Submit を選択します。

ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。

HTTPヘッダーによる基本認証

注: この認証方法は、ブラウザテストにのみ適用されます。

テスト対象がHTTPヘッダーにログイン認証情報が含まれることを期待している場合、ブラウザテストを以下のように設定します。

  1. このテスト対象のユーザー名とパスワード用にグローバル変数を作成します。ベストプラクティスは、 パスワード用に作成したグローバル変数を非表示にすることです。詳細については、「グローバル変数」を参照してください。

  2. ブラウザテストの設定ページで、[Advanced] トグルを選択します。

  3. [Security] セクションまで下にスクロールします。

  4. Authenticationの行で、以下のように値を設定します:

    1. 左のフィールド(ヒントのテキストUsername)に、ターゲットページのユーザー名を入力します。

    2. 右のフィールドには、このターゲットページのパスワードを格納したグローバル変数名を、env. を先頭につけて二重中括弧で囲んで入力します。たとえば、{{env.test1_password}} のようになります。使用可能なグローバル変数のリストを表示するには、右側のペインを展開します。

  5. ブラウザテストの設定ページで、[Simple] トグルを選択します。

  6. Edit steps or synthetic transactionsを選択します。

  7. [Go to url] というタイプのステップを追加し、[URL] にターゲットの認証ページの URL を入力します。

  8. ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:

    1. Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。

    2. (オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。

  9. Submitを選択します。

ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。

APIリクエストヘッダーによる基本認証

注: この認証方法は、API テストにのみ適用されます。以下の手順は「基本認証」、つまり curl -G https://api.twilio.com/2010-04-01/Accounts.json -u <YOUR_ACCOUNT_SID>:<YOUR_AUTH_TOKEN> などの API メソッドをサポートするターゲット用です。ベアラートークンをサポートするターゲットに対して、これらの手順を変更できます。

テスト対象がAPIリクエストヘッダーにログイン認証情報が含まれることを期待している場合、ブラウザテストを以下のように設定します。

APIリクエストヘッダーによる基本認証で合成テストをセットアップする方法を示すスクリーンショット。
  1. テストターゲットのユーザー名とパスワードの組み合わせを base64 エンコードした文字列を取得します。base64 エンコードされた文字列を取得する方法はいくつかあります。例:

    • ブラウザのコンソールから JavaScript 関数 btoa を実行します:btoa("myusername:mypassword")

    • Linuxのターミナルでこのコマンドを実行します:echo -n 'myusername:mypassword' | base64

  2. base64 値を隠されたグローバル変数に格納します。詳細については、「グローバル変数」を参照してください。

  3. API テストの設定ページで、テスト内の既存のリクエストを選択するか、[Add requests] を選択します。

  4. Requestセクションを展開し、以下の情報を入力します:

    1. [URL] に、テストターゲットの URL を入力します。

    2. Add request header を選択します。

    3. [Authorization] ヘッダーを選択し、その値として [Basic] という単語を入力してから半角スペースを入れ、base64 でエンコードされたユーザー名とパスワードを結合したグローバル変数の名前を入力します。変数には、先頭に env. を付け、二重中括弧で囲む必要があります。たとえば、{{env.est1_base64_auth}} のようになります。使用可能なグローバル変数のリストを表示するには、右側のペインを展開します。

  5. Submit を選択します。

ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。

SMSによる多要素認証

注: この認証方法は、ブラウザテストにのみ適用されます。

テストターゲットが多要素認証のために SMS を通じてワンタイムパスコード(OTP)を送信する場合、ブラウザテストは SMS メッセージから OTP を取得し、テストターゲットのページの入力フィールドに入力する必要があります。これを行うには、ブラウザテストを次のように設定します。

前提条件

  • 仮想電話番号

    SMS を介して認証に行うには、 SMS を介してワンタイムパスコードを受信できる仮想電話番号が必要です。複数のサービスが仮想電話番号を提供しており、Sinch サービス のように API を介して SMS の内容を取得できます。 このサービスを介してメッセージを受信する方法については、「Sinch API」を参照してください。

    Twilio などの特定のサービスでは、OTP を含む着信 SMS メッセージがブロックされる場合があります。詳細については、Twilio の「OTP Message Body Filtered」ドキュメントを参照してください。

  • SMS通知

    認証プロセスを強化するには、GitHubのような、SMS 通知を送信するサービスが必要です。

制限事項

コンテンツ セキュリティ ポリシー(CSP)の違反により、合成テスト中に一部のサービスにアクセスできない場合があります。このような場合の回避策は、サーバーにサードパーティサービスを実装し、connect-src を許可するように CSP で設定されたエンドポイントを提供することです。

  1. ブラウザテストの設定ページで、[Simple] トグルを選択します。

  2. Edit steps or synthetic transactions を選択します。

  3. [Go to url] というタイプのステップを追加し、[URL] にターゲットの認証ページの URL を入力します。

  4. [Save return value from JavaScript] というタイプのステップを追加し、[code] フィールドに、次の JavaScript を貼り付けます。このスクリプトは、XMLHttpRequest を使用して指定された URL からデータを取得し、そのデータから OTP を抽出します。この OTP を otp という名前のグローバル変数に保存するようにテストを設定します。

    注: スクリプトの中で、変数 url に自分の仮想電話番号の SMS サービスの URL を設定します。
    JAVASCRIPT
    function getOtp() {
      const url = "https://your-page.example.com/sms";
      var request = new XMLHttpRequest();
      request.open("GET", url, false);
      request.send();
      if (request.status == 200) {
        return parseOtp(JSON.parse(request.responseText));
      }
    return;
    }
    
    function parseOtp(jsonResponse) {
      const firstInbound = jsonResponse.inbounds[0];
      if (firstInbound && firstInbound.body) {
        // Extract the number using a regular expression
        const match = firstInbound.body.match(/\\b\\d{6}\\b/);
        if (match) {
          return match[0]; // Return the first matched number
        }
       }
       return;
    }
    return getOtp();
  5. [Wait] というタイプのステップを追加し、待ち時間をミリ秒単位で指定します。この時間は、ターゲットが仮想電話番号に OTP コードを送信し、JavaScript が OTP を処理するのに十分な時間である必要があります。

  6. Fill in fieldというタイプのステップを追加し、以下のように設定します:

    1. Selectorには、ユーザーがOTPを入力するターゲットページのエレメントのIDを入力します。

    2. [Value] には、JavaScript が OTP を格納したカスタム変数名に、custom. を先頭に付け、二重中括弧で囲んで入力します。たとえば、{{custom.otp}} のようになります。

    「フィールドに入力する」ステップを示すスクリーンショット
  7. ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:

    1. Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。

    2. (オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。

  8. Submit を選択します。

ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。

メールによる多要素認証

注: この認証方法は、ブラウザテストにのみ適用されます。

テストターゲットが多要素認証のために電子メールを通じてワンタイムパスコード(OTP)を送信する場合、ブラウザテストは電子メールのメッセージから OTP を取得し、テストターゲットのページの入力フィールドに入力する必要があります。これを行うには、ブラウザテストを次のように設定します。

前提条件

電子メールアカウントへの接続および API を介した電子メールの管理をサポートする電子メールサービスが必要です。以下の手順では、Nylas サービス を使用する例を示します。このサービスからメッセージを取得する方法の詳細については、「API ドキュメント」を参照してください。

さらに、以下のステップでは、GitHub を使用して認証メールを送信することを示します。この認証メールは、認証メールから OTP を抽出するために不可欠です。

制限事項

電子メールサービスは API を介してアクセスできる必要があります。コンテンツ セキュリティ ポリシー(CSP)の違反により、合成テスト中に一部のサービスにアクセスできない場合があります。このような場合の回避策は、サードパーティのサービスをサーバーに実装し、connect-src を許可するように CSP で設定されたエンドポイントを提供することです。

  1. ブラウザテストの設定ページで、[Simple] トグルを選択します。

  2. Edit steps or synthetic transactions を選択します。

  3. [Go to url] というタイプのステップを追加し、[URL] にターゲットの認証ページの URL を入力します。

  4. [Save return value from JavaScript] というタイプのステップを追加し、[code] フィールドに、次の JavaScript を貼り付けます。このスクリプトは、XMLHttpRequest を使用して指定された URL からデータを取得し、そのデータから OTP を抽出します。この OTP をotpというカスタム変数に保存するようにテストを設定します。

    注: スクリプトの中で、変数urlを自分のメール受信箱APIエンドポイントのURLに設定します。
    注: Nylas サービスを利用している場合、件名やその他のパラメータで特定のテキストを検索することで、未読メールを見つけることができます。詳細については、「Nylas API documentation for messages」を参照してください。
    JAVASCRIPT
    function getOtp() {
      const grantId = "<NYLAS_GRANT_ID>";
      const jwToken = "<NYLAS_API_KEY>";
      const from = "noreply@github.com";
      const subject = "Your GitHub launch code";
      const unread = "true";
      const url = "https://api.us.nylas.com/v3/grants/" + grantId + "/messages?limit=1&unread=" + unread + "from=" + from + "&subject=" + subject;
      var request = new XMLHttpRequest();
      request.open("GET", url, false);
      request.setRequestHeader('Authorization', 'Bearer ' + jwToken)
      request.send();
      if (request.status == 200) {
        return parseOtp(JSON.parse(request.responseText));
      }
      return "ERR";
    }
    
    function parseOtp(jsonResponse) {
      const firstInbound = jsonResponse. data[0];
      if (firstInbound && firstInbound.snippet) {
        // Extract the number using a regular expression
        const match = firstInbound.snippet.match(/\\b\\d{8}\\b/);
        if (match) {
          return match[0]; // Return the first matched number
        }
      }
      return "NO-OTP";
    }
    return getOtp();
  5. [Wait] というタイプのステップを追加し、待ち時間をミリ秒単位で指定します。この時間は、ターゲットが電子メールサービスに OTP コードを送信し、JavaScript が OTP を処理するのに十分な時間である必要があります。

  6. Fill in fieldというタイプのステップを追加し、以下のように設定します:

    1. Selectorには、ユーザーがOTPを入力するターゲットページのエレメントのIDを入力します。

    2. [Value] には、JavaScript が OTP を格納したカスタム変数名に、custom. を先頭に付け、二重中括弧で囲んで入力します。たとえば、{{custom.otp}} のようになります。

    「フィールドに入力する」ステップを示すスクリーンショット
  7. ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:

    1. Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。

    2. (オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。

  8. Submit を選択します。

ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。

SSOとActive Directoryによる多要素認証

シングルサインオン(SSO)による認証は、基本認証に似ています。SSO または Active Directory(AD)を使用するテストを作成するには、 Web ページを開き、SSO 認証リンクを選択して、SSO 認証に必要な情報を入力する一連の手順を設定する必要があります。このプロセス中に追加の Web ページがロードされる可能性があるため、次の手順に進む前に、各 Web ページのすべてのコンポーネントが完全にロードされたことを確認する手順を含めることが重要です。

SSO 認証では、追加の認証要素が必要になることがよくあります。ID プロバイダー(Google、Microsoft、Okta、Duo など)が追加のログイン要素を義務付けていない場合、テストは以下の例で示される認証ステップだけで済む可能性があります。

SSOまたはActive Directoryで認証する合成テストの作成手順を示すスクリーンショット。

制限事項

ID プロバイダーは、電子メール、 SMS 、TOTP を介した検証など、ログインに対してさまざまな追加の要因を必要とすることがよくあります。このような場合、これらの追加のログイン要素に対応するために手順を変更または追加することが重要です。

TOTPによる多要素認証

注: この認証方法は、ブラウザテストにのみ適用されます。

テストターゲットに時間ベースのワンタイムパスコード(TOTP)を送信する必要がある場合は、以下のように設定します。

TOTPを生成するための秘密鍵を取得します。

秘密鍵は、テストターゲットとテスト認証アプリ(Okta など)の両方が、同じ一意の TOTP を生成するために使用する共有値です。この秘密鍵は、次の場所から取得できます。

  • テストターゲットの QR コード(画像)。

  • プレーンテキストの秘密鍵。QR コードを URL 文字列として表示したときに、テストターゲットの QR コードに埋め込まれた文字列として表示されます。たとえば、QR コードが otpauth://totp/Slack:<username>@<somedomain>?secret=<long-string>&issuer=<app-name>&algorithm=SHA1&digits=6&period=30 の場合、秘密鍵は <long-string> になります。

秘密鍵をタイプTOTPのグローバル変数に保存します。

グローバル変数を作成するには2つの方法があります:

  • Splunk Synthetic Monitoringランディングページから:

    1. Splunk Synthetic Monitoringランディングページから、設定アイコンを選択し、Global variablesを選択します。

    2. Create variable を選択します。

  • 既存のテストのページから:

    1. Edit test を選択します。

    2. 右側のVariablesパネルを展開し、Global variablesまでスクロールして、Addを選択します。

Add variableダイアログボックスで、次のように入力します:

グローバル変数の作成方法を示すスクリーンショット。
  1. [Variable type] プルダウンメニューで、[TOTP] を選択します。

  2. [Variable name] フィールドに変数の名前を入力します。この名前を使用して、テスト内で変数にアクセスします。

  3. 秘密鍵は以下のいずれかの方法で保存します:

    • QR codeタブを選択し、そこにQRコード画像をドラッグします。

    • Manual inputタブを選択し、QRコードから取得した<long-string>を貼り付けます。

  4. (オプション)[Description] フィールドに、後で参照するために変数の目的を説明する文を入力します。説明は、変数を隠してその値を明らかにできない場合に特に役立ちます。

  5. (オプション)Advanced Settingsを展開し、オプション設定を指定します:

    • (オプション)[digits] に、生成される TOTP の桁数を設定します。有効な値:4 ~ 8。デフォルト: 6。

    • (オプション)[TOTP expiration] に、TOTP の有効期間を秒単位で設定します。有効な値:10 秒 ~ 90 秒。デフォルト:30 秒。

  6. (オプション)入力した秘密鍵を検証するには、Generate TOTPを選択します。

  7. Add を選択します。

注: Splunk Synthetic MonitoringはTOTP型の変数の値を自動的に隠します。

TOTP を使用してブラウザテストを設定

  1. ブラウザテストの設定ページで、[Simple] トグルを選択します。

  2. Edit steps or synthetic transactions を選択します。

  3. [Fill in field] というタイプのステップを追加し、[Value] で、[TOTP] セクションまでスクロールダウンし(または検索フィールドに totp と入力し)、作成した TOTP 変数の名前を選択します。{{totp.<variable-name>}} としてこの変数名を直接入力することもできます。

    「フィールドに入力する」ステップを示すスクリーンショット
  4. ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:

    1. Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。

    2. (オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。

  5. Submit を選択します。

ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。

「今すぐ試す」ステップを示すスクリーンショット

mTLS 認証

注: mTLS 認証は、ブラウザ、アップタイム、および API テストで設定できます。

相互 TLS(mTLS)認証は、クライアント(プライベートランナーまたはパブリックランナー)と Web サーバー(テストターゲット)の両方が接続を検証するための方法です。mTLS では、クライアントとサーバーの両方に証明書があり、双方がその証明書の公開キー/秘密キーのペアを使用して認証を行います。mTLS 認証を成功させるには、次の手順を実行します。

  1. クライアント証明書を CERT タイプのグローバル変数に保存します

  2. クライアント証明書をプライベートランナーにアップロードします

  3. ブラウザアップタイム、または API テストでCERT変数を参照するように設定します。

クライアント証明書を CERT タイプのグローバル変数に保存

これらの手順は、テストターゲットのクライアント証明書がすでにダウンロードされていることを前提としています。

グローバル変数を作成するには2つの方法があります:

  • Splunk Synthetic Monitoringランディングページから:

    1. Splunk Synthetic Monitoringランディングページから、設定アイコンを選択し、Global variablesを選択します。

    2. Create variable を選択します。

  • 既存のテストのページから:

    1. Edit test を選択します。

    2. 右側のVariablesパネルを展開し、Certificatesまでスクロールして、Addを選択します。

Add variableダイアログボックスで、次のように入力します:

グローバル変数の作成方法を示すスクリーンショット。
  1. [Variable type] プルダウンメニューで、[CERT] を選択します。

  2. [Variable name] フィールドに変数の名前を入力します。この名前を使用して、テスト内で変数にアクセスします。

  3. [Domain] フィールドに、テストターゲットの正確なドメインを入力します。たとえば、テストターゲットがclient.badssl.comの場合は、[Domain] をclient.badssl.comに設定します。[Domain] をbadssl.comに設定すると、ブラウザテストで mTLS 認証がタイムアウトエラーで失敗します。エラーが表示されるまでに最大 2 分かかる場合があります。

    [Domain] では、次のようなワイルドカードを使用できます。

    • *.example.com
    • example.*
    • *.example.*
    • *.*.*
    • *.*.*.example/*
    • *.*.*/*
  4. クライアント証明書が PCKS#12 形式の場合は、まず、.pem 形式に変換します

  5. 証明書と一致する方法を使用して、クライアント証明書をアップロードします。

    • 証明書の公開キーと秘密キーが別々のファイルになっている場合は、[Upload Public Key] タブを選択し、ウィジェットに公開キーファイルをドラッグします。次に、[Upload Private Key] を選択し、秘密キーファイルをウィジェットにドラッグします。

    • 証明書が、公開キーと秘密キーの両方を含む結合ファイルの場合は、[Upload Combined Key] タブを選択し、結合ファイルをウィジェットにドラッグします。

  6. 前の手順でアップロードした結合ファイルまたは秘密キーが暗号化されている場合は、その復号パスワードを [Private key password] フィールドに貼り付ける必要があります。Splunk Synthetics はこのパスワードを使用してファイルを 1 回開きますが、復号パスワードは保持されません。

  7. (オプション)[Description] フィールドに、後で参照するために変数の目的を説明する文を入力します。説明は、変数を非表示にする場合に特に役立ちます。

  8. Add を選択します。

クライアント証明書は、暗号化された形式で Splunk Synthetics データベースに安全に保存されます。

.p12 を .pem に変換

  1. システムに OpenSSL をインストールします。

    • Linux では、通常、事前にインストールされています。インストールされていない場合は、パッケージマネージャを使用してインストールします。たとえば、Ubuntu では、apt install openssl というコマンドを実行します。

    • macOS では、brew install openssl というコマンドを実行します。

    • Windows では、OpenSSL バイナリをダウンロードするか、Chocolatey などのパッケージマネージャを使用します。

  2. 証明書の暗号化アルゴリズムと一致する次のコマンドを実行します。

    • 証明書が標準規格(レガシー以外)のアルゴリズムで暗号化されている場合は、次のコマンドを実行します。

      CODE
      openssl pkcs12 -in input.p12 -out output.pem -aes256 -passin pass:your-p12-password

      値は次のとおりです。

      • input.p12 は、入力となる PKCS#12 ファイルです。
      • output.pem は、出力される PEM ファイルです。
      • new-password は、.p12 ファイルの作成時に生成したパスワードです。

      例:

      CODE
      openssl pkcs12 -in in-cert.p12 -out out-cert.pem -aes256 -passin pass:ABC123@GL
    • OpenSSL 3.0+ を使用していて、証明書が RC2-40-CBC などのレガシーアルゴリズムで暗号化されている場合は、openssl コマンドを -legacy オプションを付けて実行します。このオプションは、OpenSSL 3.0 以降でデフォルトでは非アクティブ化されている古い暗号化アルゴリズムのサポートを有効にします。

      CODE
      openssl pkcs12 -legacy -in input.p12 -out output.pem -nodes

      値は次のとおりです。

      • input.p12 は、入力となる PEM ファイルです。
      • output.pem は、出力される PEM ファイルです。

    結果として得られる .pem ファイルには、秘密キーと証明書の両方が含まれています。

  3. 秘密キーと証明書を個別に保存する必要がある場合は、次のコマンドを実行して抽出します。

    • 秘密キーを抽出するには:

      CODE
      openssl pkey -in output.pem -out private-key.pem
    • 証明書を抽出するには:

      CODE
      openssl x509 -in output.pem -out certificate.pem

プライベートランナーの設定

  1. tmpfs mount コマンド(または同様のコマンド)を使用して、プライベートランナーがテストの実行中にクライアント証明書を一時的に保存するために使用する次のフォルダをマウントします。

    • /tmpfs/certificates(アップタイムおよび API テストで使用)

    • /home/geppetto/.pki(ブラウザのテストで使用)

    これらのフォルダに tmpfs ファイルシステムを使用すると、クライアント証明書をインスタンスディスクに保存せずに済みます。証明書をディスクに保存しないことで、テストの実行中に証明書をディスクドライブのバックアップに誤って含めるリスクを回避できます。

  2. プライベートランナーが Docker 上にある 場合は、次の環境変数を docker run コマンドに追加します。

    CODE
    -e "ENABLE_CLIENT_CERTS=true"
  3. プライベートランナーが Docker Compose 上にある 場合は、次の環境変数を docker-compose.yml コマンドに追加します。

    CODE
    environment:
        ...
        ENABLE_CLIENT_CERTS: true

mTLS を使用してブラウザテストを設定

ブラウザテストでクライアント証明書を指定する方法を示すスクリーンショット

注: 選択した証明書のドメインが、テストターゲットのページのドメインと一致することを確認します
  1. ブラウザテストの設定ページで、[Advanced] トグルを選択します。

  2. [Security] セクションまで下にスクロールします。

  3. [TLS/SSL validation] トグルを [On] に設定します。

  4. [Certificate] プルダウンメニューで、クライアント証明書用に作成した CERT グローバル変数を選択します。たとえば、{{cert.Badssl_com-test2}} のようになります。

mTLS を使用したアップタイム(HTTP)テストの設定

アップタイムテストでクライアント証明書を指定する方法を示すスクリーンショット

  1. HTTP テストの設定ページで、[Security] セクションまで下にスクロールします。

  2. [TLS/SSL validation] トグルを [On] に設定します。

  3. [Certificate] プルダウンメニューで、クライアント証明書用に作成した CERT グローバル変数を選択します。たとえば、{{env.est1_base64_auth}} のようになります。すべての CERT 変数の一覧を表示するには、右側のペインを展開します。

  4. Submit を選択します。

mTLS を使用した API テストの設定

API テストでクライアント証明書を指定する方法を示すスクリーンショット

クライアント証明書を必要とする各 API リクエストに、証明書を追加できます。その場合は次の手順に従ってください。

  1. API テストの設定ページで、テスト内の既存のリクエストを選択するか、[Add requests] を選択します。

  2. [Request] セクションを展開します。

  3. Add request header を選択します。

  4. [Select certificate] ドロップダウンメニューで、作成済みの CERT変数を選択します。たとえば、{{env.est1_base64_auth}} のようになります。すべての CERT 変数の一覧を表示するには、右側のペインを展開します。

  5. [Submit] を選択します。

Basic authentication through HTML login forms

Configure your browser test with basic authentication through an HTML login form.

ヒント: Supported test type: browser.

If your test target provides an HTML form for entering username and password, configure your browser test as follows.

Screenshot showing how to set up a synthetic test with basic authentication through an HTML form.

  1. Create global variables for this test target’s username and password.

    Best practice is to conceal the global variable you create for the password. For more information, see Global variables.

  2. On the browser test’s configuration page, select the Simple toggle.
  3. Select Edit steps or synthetic transactions.
  4. Add a step of type Fill in field, and set it up as follows:
    1. In Selector, enter the ID, name, XPath, CSS, link, or JS path of the target page’s username field.

      For more information on element selectors on Chrome, see Chrome DevTools .

    2. In Value, enter the name of the global variable you stored the username in, prefixed with env. and enclosed in double curly braces.

      For example, {{env.test1_username}}.

  5. Add a step of type Fill in field, and set it up as follows:
    1. In Selector, enter the ID of the target page’s password field.
    2. In Value, enter the name of the global variable you stored the password in, prefixed with env. and enclosed in double curly braces.

      For example, {{env.test1_password}}.

  6. Add a step of type Click, and set it up as follows:
    1. In Selector, enter the ID of the target page’s login button.
    2. (Optional) Set Wait for navigation to the number of milliseconds to wait.
  7. To verify that the login succeeded, add a step of type Assert text present, and set it up as follows:
    1. In Text, enter a string that should be visible on the test target page only when login is successful.
    2. (Optional) Set Wait for up to to a large enough value, in milliseconds, to ensure that the page loads.
  8. Select Submit.

To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.

Basic authentication through HTTP headers

Configure your browser test with basic authentication through an HTTP header.

ヒント: Supported test type: browser.

If your test target expects login credentials to be included in an HTTP header, configure your browser test as follows.

  1. Create global variables for this test target’s username and password.

    Best practice is to conceal the global variable you create for the password. For more information, see Global variables.

  2. On the browser test’s configuration page, select the Advanced toggle.
  3. Scroll down to the Security section.
  4. On the row for Authentication, set values as follows:
    1. In the left field (with hint text Username), enter the username for the target page.
    2. In the right field, enter the name of the global variable in which you stored the password for this target page, prefixed with env. and enclosed in double curly braces.

      For example, {{env.test1_password}}. To see the list of available global variables, expand the pane on the right.

  5. On the browser test’s configuration page, select the Simple toggle.
  6. Select Edit steps or synthetic transactions.
  7. Add a step of type Go to url, and in URL, enter the URL of the target’s authentication page.
  8. To verify that the login succeeded, add a step of type Assert text present, and set it up as follows:
    1. In Text, enter a string that should be visible on the test target page only when login is successful.
    2. (Optional) Set Wait for up to to a large enough value, in milliseconds, to ensure that the page loads.
  9. Select Submit.

To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.

Basic authentication through API request headers

Configure your API test with basic authentication through an API request header.

ヒント: Supported test type: API.
注: The steps below are for targets that support "Basic auth", in other words, API methods like curl -G https://api.twilio.com/2010-04-01/Accounts.json -u <YOUR_ACCOUNT_SID>:<YOUR_AUTH_TOKEN>. You can modify these steps for targets that support a bearer token.

If your test target expects login credentials to be included in an an API request header, configure your browser test as follows.

Screenshot showing how to set up a synthetic test with basic authentication through API request headers.

  1. Get the base64-encoded string of the username and password combination for your test target.

    There are several ways to get a base64-encoded string. For example:

    • Run the JavaScript function btoa from your browser’s console: btoa("myusername:mypassword")

    • Run this command in a Linux terminal: echo -n 'myusername:mypassword' | base64

  2. Store the base64 value in a concealed global variable.

    For more information, see Global variables.

  3. On the API test’s configuration page, select an existing request in the test or select Add requests.
  4. Expand the Request section, and enter the following information:
    1. In URL, enter the test target’s URL.
    2. Select Add request header.
    3. Select the Authorization header, and for its value, enter the word Basic followed by a space and then the name of the global variable containing your base64-encoded combined username and password.

      The variable must be prefixed with env. and enclosed in double curly braces. For example, {{env.est1_base64_auth}}. To see the list of available global variables, expand the pane on the right.

  5. Select Submit.

To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.

Multifactor authentication through SMS

Configure your browser test with multifactor authentication through SMS.

ヒント: Supported test type: browser.

If your test target sends a one time passcode (OTP) through SMS for multifactor authentication, your browser test must retrieve the OTP from the SMS message and enter it into the input field on the target’s page. To do this, configure your browser test as follows.

  • Virtual phone number

    To authenticate through SMS, you must have a virtual phone number that can receive one time passcodes through SMS. Several services offer virtual phone numbers and provide SMS content through an API, such as the Sinch service . For instructions on receiving messages through this service, see the Sinch API .

    Certain services, such as Twilio, may block incoming SMS messages containing OTPs. For more information, see Twilio's OTP Message Body Filtered documentation.

  • SMS notifications

    To enhance the authorization process, you must have a service that sends SMS notifications, such as GitHub .

Limitations

Some services may not be accessible during Synthetics tests due to violations of Content-Security-Policy (CSP). In such instances, a workaround is to implement third-party services on your server and provide an endpoint configured with CSP to allow connect-src.

  1. On the browser test’s configuration page, select the Simple toggle.
  2. Select Edit steps or synthetic transactions.
  3. Add a step of type Go to url, and in URL, enter the URL of the target’s authentication page.
  4. Add a step of type Save return value from JavaScript, and in the code field, paste the following JavaScript.

    This script retrieves data from a specified URL using XMLHttpRequest and extracts the OTP from that data. You configure your test to save this OTP in a global variable named otp.

    注: In the script, set the variable url to the URL of your own virtual phone number’s SMS service.
    JAVASCRIPT
    function getOtp() {
      const url = "https://your-page.example.com/sms";
      var request = new XMLHttpRequest();
      request.open("GET", url, false);
      request.send();
      if (request.status == 200) {
        return parseOtp(JSON.parse(request.responseText));
      }
    return;
    }
    
    function parseOtp(jsonResponse) {
      const firstInbound = jsonResponse.inbounds[0];
      if (firstInbound && firstInbound.body) {
        // Extract the number using a regular expression
        const match = firstInbound.body.match(/\\b\\d{6}\\b/);
        if (match) {
          return match[0]; // Return the first matched number
        }
       }
       return;
    }
    return getOtp();
  5. Add a step of type Wait, and specify a wait time in milliseconds.

    This time needs to be long enough for the target to send the OTP code to your virtual phone number, and for your JavaScript to process the OTP.

  6. Add a step of type Fill in field, and set it up as follows:
    1. In Selector, enter the ID of the element on the target page where the user must enter the OTP.
    2. In Value, enter the name of the custom variable your JavaScript stored the OTP in, prefixed with custom. and enclosed in double curly braces. For example, {{custom.otp}}.
    Screenshot showing the "Fill in field" step
  7. To verify that the login succeeded, add a step of type Assert text present, and set it up as follows:
    1. In Text, enter a string that should be visible on the test target page only when login is successful.
    2. (Optional) Set Wait for up to to a large enough value, in milliseconds, to ensure that the page loads.
  8. Select Submit.

To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.

Multifactor authentication through email

Configure your browser test with multifactor authentication through email.

ヒント: Supported test type: browser.

If your test target sends a one-time passcode (OTP) through email for multifactor authentication, your browser test must retrieve the OTP from the email message and enter it into the input field on the target’s page. To do this, configure your browser test as follows.

You must have an email service that supports connecting to your email account and managing your emails through an API. The steps below feature an example using the Nylas service . For detailed information on how to retrieve messages from this service, refer to its API documentation .

Additionally, the steps below demonstrate the use of GitHub to send an authorization email, which is essential for extracting the OTP from it.

Limitations

Your email service must be accessible through an API. Some services may not be accessible during Synthetics tests due to violations of Content-Security-Policy (CSP). In such instances, a workaround is to implement third-party services on your server and provide an endpoint configured with CSP to allow connect-src.

  1. On the browser test’s configuration page, select the Simple toggle.
  2. Select Edit steps or synthetic transactions.
  3. Add a step of type Go to url, and in URL, enter the URL of the target’s authentication page.
  4. Add a step of type Save return value from JavaScript, and in the code field, paste the following JavaScript.

    This script retrieves data from a specified URL using XMLHttpRequest and extracts the OTP from that data. You configure your test to save this OTP in a custom variable named otp.

    注: In the script, set the variable url to the URL of your own email inbox API endpoint.
    注: If you are utilizing the Nylas service, you can locate unread emails by searching for specific text in the subject line or other parameters. For more information, please refer to the Nylas API documentation for messages .
    JAVASCRIPT
    function getOtp() {
      const grantId = "NYLAS_GRANT_ID";
      const jwToken = "NYLAS_API_KEY";
      const from = "noreply@github.com";
      const subject = "Your GitHub launch code";
      const unread = "true";
      const url = "https://api.us.nylas.com/v3/grants/" + grantId + "/messages?limit=1&unread=" + unread + "from=" + from + "&subject=" + subject;
      var request = new XMLHttpRequest();
      request.open("GET", url, false);
      request.setRequestHeader('Authorization', 'Bearer ' + jwToken)
      request.send();
      if (request.status == 200) {
        return parseOtp(JSON.parse(request.responseText));
      }
      return "ERR";
    }
    
    function parseOtp(jsonResponse) {
      const firstInbound = jsonResponse. data[0];
      if (firstInbound && firstInbound.snippet) {
        // Extract the number using a regular expression
        const match = firstInbound.snippet.match(/\\b\\d{8}\\b/);
        if (match) {
          return match[0]; // Return the first matched number
        }
      }
      return "NO-OTP";
    }
    return getOtp();
  5. Add a step of type Wait, and specify a wait time in milliseconds.

    This time needs to be long enough for the target to send the OTP code to your email service, and for your JavaScript to process the OTP.

  6. Add a step of type Fill in field, and set it up as follows:
    1. In Selector, enter the ID of the element on the target page where the user must enter the OTP.
    2. In Value, enter the name of the custom variable your JavaScript stored the OTP in, prefixed with custom. and enclosed in double curly braces. For example, {{custom.otp}}.
    Screenshot showing the "Fill in field" step
  7. To verify that the login succeeded, add a step of type Assert text present, and set it up as follows:
    1. In Text, enter a string that should be visible on the test target page only when login is successful.
    2. (Optional) Set Wait for up to to a large enough value, in milliseconds, to ensure that the page loads.
  8. Select Submit.

To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.

Multifactor authentication through SSO and Active Directory

Configure your test with multifactor authentication through SSO and Active Directory.

Authentication through Single Sign-On (SSO) is similar to basic authentication. To create a test that uses SSO or Active Directory (AD), you must configure a series of steps that include opening the webpage, selecting the SSO authentication link, and entering the required information for SSO authentication. Additional webpages may load during this process, so it’s crucial that you include steps to confirm that all of the components of each webpage have fully loaded before proceeding.

SSO authentication frequently involves additional authentication factors. If the identity provider (such as Google, Microsoft, Okta, Duo, and so on) does not mandate an extra login factor, your test might only need the authentication steps that are illustrated in the example below.

Limitations

Identity providers often require various additional factors for login, such as verification via email, SMS, or TOTP. In such cases, it is essential to modify or add steps to accommodate these additional login factors.

Screenshot showing steps to create in a synthetic test that authenicates with SSO or Active Directory.

  1. Add a step for selecting the webpage.
  2. Add a step for selecting the SSO authentication link.
  3. Enter the required information for SSO authentication.
  4. Add steps to confirm that all of the components of each webpage have fully loaded before proceeding.

Multifactor authentication through TOTP

Configure your browser test with multifactor authentication through TOTP.

ヒント: Supported test type: browser.

If your test needs to send a time-based one-time passcode (TOTP) to its test target, configure your test as follows.

  1. Step 1: Get the secret key for generating a TOTP

    The secret key is a shared value which both your test target and your test’s authenticator app (such as Okta) will use to generate the same unique TOTP. You can get this secret key from:

    • The test target’s QR code (an image).

    • The plain-text secret key, which is visible as an embedded string in the test target’s QR code when you view the QR code as a URL string. For example, if the QR code is otpauth://totp/Slack:username@somedomain?secret=long-string&issuer=app-name&algorithm=SHA1&digits=6&period=30, the secret key is long-string.

  2. Step 2: Save the secret key in a global variable of type TOTP

    There are two ways to create a global variable:

    • From the Splunk Synthetic Monitoring landing page:

      1. From the Splunk Synthetic Monitoring landing page, select the settings icon, and then select Global variables.

      2. Select Create variable.

    • From an existing test’s page:

      1. Select Edit test.

      2. Expand the Variables panel on the right, scroll to Global variables and select Add.

    In the Add variable dialog box, enter the following:

    Screenshot showing how to create a global variable.
    1. In the Variable type pull-down menu, select TOTP.
    2. In the Variable name field, enter the name of the variable. You will use this name to access your variable within a test.
    3. Save the secret key either by:
      • Selecting the QR code tab and dragging the QR code image to it.

      • Selecting the Manual input tab and pasting the long-string you retrieved from the QR code.

    4. (Optional) In the Description field, enter a description to explain the purpose of the variable for future reference. A description is particularly helpful when you conceal the variable and cannot reveal its value.
    5. (Optional) Expand Advanced Settings and specify optional settings:
      • (Optional) Set digits to the number of digits in the generated TOTP. Valid values: 4-8. Default: 6.

      • (Optional) Set TOTP expiration to the the duration of the validity of the TOTP, in seconds. Valid values: 10s-90s. Default: 30s.

    6. (Optional) To validate the secret key you entered, select Generate TOTP.
    7. Select Add.
      注: Splunk Synthetic Monitoring automatically conceals the value of variables of type TOTP.
  3. Step 3: Configure a browser test with TOTP
    1. On the browser test’s configuration page, select the Simple toggle.
    2. Select Edit steps or synthetic transactions.
    3. Add a step of type Fill in field, and in Value, scroll down to the TOTP section (or type totp into the search field) and select the name of the TOTP variable you created. You can also enter this variable name directly as {{totp.variable-name}}.

      Screenshot showing the "Fill in field" step

    4. To verify that the login succeeded, add a step of type Assert text present, and set it up as follows:
      1. In Text, enter a string that should be visible on the test target page only when login is successful.

      2. (Optional) Set Wait for up to to a large enough value, in milliseconds, to ensure that the page loads.

    5. Select Submit.
    6. To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.

      Screenshot showing the "Try now" step

mTLS authentication

Configure your test for mTLS authentication.

Tip: Supported test types: browser, uptime, API.

Mutual TLS (mTLS) authentication is a method for a client (your private or public runner) and a web server (your test target) to both validate their connection. In mTLS, both the client and the server have a certificate, and both sides authenticate using their certificate's public/private key pair. Follow these steps to make sure that the mTLS authentication succeeds:

  1. Save the client certificate in a global variable of type CERT.

  2. Upload the client certificate to your private runner.

  3. Configure your test to reference the CERT variable.

Step 1: Save the client certificate in a global variable of type CERT

These steps assume that you've already downloaded the client certificate that matches the one on the test target.

There are two ways to create a global variable:

  • From the Splunk Synthetic Monitoring landing page:

    1. From the Splunk Synthetic Monitoring landing page, select the settings icon, and then select Global variables.

    2. Select Create variable.

  • From an existing test’s page:

    1. Select Edit test.

    2. Expand the Variables panel on the right, scroll to Certificates and select Add.

In the Add variable dialog box, enter the following:

Screenshot showing how to create a global variable.
  1. In the Variable type pull-down menu, select CERT.

  2. In the Variable name field, enter the name of the variable. You will use this name to access your variable within a test.

  3. In the Domain field, enter the exact domain of the test target. For example, if the test target is client.badssl.com, set Domain to client.badssl.com. If you set Domain to badssl.com the mTLS authentication will fail with a timeout error in browser tests. The error might take up to two minutes to appear.

    You can use wildcards in Domain, such as:

    • *.example.com
    • example.*
    • *.example.*
    • *.*.*
    • *.*.*.example/*
    • *.*.*/*
  4. If your client certificate is in PCKS#12 format, convert it into .pem format first:

    1. Install OpenSSL on your system:

      • On Linux, it's typically pre-installed. If not, use your package manager to install it. For example, on Ubuntu, run the command apt install openssl

      • On macOS, run the command brew install openssl

      • On Windows, download the OpenSSL binary or use a package manager like Chocolatey.

    2. Run the command below that matches your certificate's encryption algorithm:

      • If your certificate was encrypted with a standard (non-legacy) algorithm, run this command:

        CODE
        openssl pkcs12 -in input.p12 -out output.pem -aes256 -passin pass:your-p12-password

        where:

        • input.p12 is the input PKCS#12 file.
        • output.pem is the output PEM file.
        • new-password is the password that was generated when the .p12 file was created.

        For example:

        CODE
        openssl pkcs12 -in in-cert.p12 -out out-cert.pem -aes256 -passin pass:ABC123@GL
      • If you're using OpenSSL 3.0+ but your certificate was encrypted with a legacy algorithm such as RC2-40-CBC, run the openssl command with the -legacy option. This option enables support for older encryption algorithms which are deactivated by default in OpenSSL 3.0 and later:

        CODE
        openssl pkcs12 -legacy -in input.p12 -out output.pem -nodes

        where:

        • input.p12 is the input PEM file.
        • output.pem is the output PEM file.

      The resulting .pem file contains both the private key and the certificate.

    3. If you need to save the private key and the certificate separately, run these commands to extract them:

      • To extract the private key:

        CODE
        openssl pkey -in output.pem -out private-key.pem
      • To extract the certificate:

        CODE
        openssl x509 -in output.pem -out certificate.pem
  5. Upload the client certificate using the method that matches your certificate:

    • If your certificate has separate files for its public key and private key, select the Upload Public Key tab and drag the public key file into the widget. Then select Upload Private Key and drag the private key file into the widget.

    • If your certificate is a combined file containing both its public and private keys, select the Upload Combined Key tab and drag the combined file into the widget.

  6. If the combined file or private key that you uploaded in the previous step was encrypted, you must paste its decryption password into the Private key password field. Splunk Synthetics uses this password to open the file once; it does not retain your decryption password.

  7. (Optional) In the Description field, enter a description to explain the purpose of the variable for future reference. A description is particularly helpful when you conceal the variable.

  8. Select Add.

The client certificate is securely stored in the Splunk Synthetics database in an encrypted format.

Step 2: Configure your private runner

  1. Use the tmpfs mount command (or similar) to mount the following folders which are used by the private runner to store the client certificate temporarily while it's running a test:

    • /tmpfs/certificates (used during uptime and API tests)

    • /home/geppetto/.pki (used during browser tests)

    Using the tmpfs file system for these folders helps you to avoid storing the client certificates on the instance disk. By not storing the certificates on disk you avoid accidentally including them in a disk drive backup if one were to occur while a test is running.

  2. If your private runner is on Docker, add the following environment variable to your docker run command:

    CODE
    -e "ENABLE_CLIENT_CERTS=true"
  3. If your private runner is on Docker Compose, add the following environment variable to your docker-compose.yml:

    CODE
    environment:
        ...
        ENABLE_CLIENT_CERTS: true

Step 3: Configure your test to reference the CERT variable

Browser

Screenshot showing how to specify a client certificate in a browser test

Note: Make sure that the domain of the selected certificate matches the domain of the page being tested
  1. On the browser test’s configuration page, select the Advanced toggle.

  2. Scroll down to the Security section.

  3. Set the TLS/SSL validation toggle to On.

  4. In the Certificate pull-down menu, select the CERT global variable you created for the client certificate. For example, {{cert.Badssl_com-test2}}.

Uptime (HTTP)

Screenshot showing how to specify a client certificate in an uptime test

  1. On the HTTP test’s configuration page, scroll down to the Security section.

  2. Set the TLS/SSL validation toggle to On.

  3. In the Certificate pull-down menu, select the CERT global variable you created for the client certificate. For example, {{env.est1_base64_auth}}. To see the list of all CERT variables, expand the pane on the right.

  4. Select Submit.

API

Screenshot showing how to specify a client certificate in an API test

You can add a client certificate to each API request that needs one. To do this, follow these steps:

  1. On the API test’s configuration page, select an existing request in the test or select Add requests.

  2. Expand the Request section.

  3. Select Add request header.

  4. In the Select certificate drop-down menu, select a CERT variable you've already created. For example, {{env.est1_base64_auth}}. To see the list of all CERT variables, expand the pane on the right.

  5. Select Submit.

NTLM authentication

Configure your browser test with NTLM authentication.

ヒント: Supported test type: browser.

NTLM (NT LAN Manager) is a challenge-response authentication protocol used in Windows environments. It allows browser tests to authenticate against web servers that require Windows credentials without needing special infrastructure.

NTLM authentication is supported on both public runners and private runners.

Limitations
  • HTTP/2 not supported: NTLM requires a persistent TCP connection for the multi-step handshake. HTTP/2 multiplexing breaks this requirement. If your web server uses HTTP/2, NTLM authentication will fail. Ensure your server supports HTTP/1.1 fallback.

  • Browser tests only: NTLM authentication is not available for API or Uptime (HTTP) tests.

  • HAR capture: The initial 401 authentication response may not appear in the HAR file. The final authenticated response is captured normally.

  • A concealed global variable containing the username

  • A concealed global variable containing the password

  • The target website must use HTTP/1.1 (NTLM is not compatible with HTTP/2)

To configure a browser test with NTLM authentication:

  1. Create or edit a browser test.
  2. In the Advanced section, find the Authentication configuration.
  3. Enter your username in the format DOMAIN\username or username@domain.com
  4. Enter your password.
  5. Use concealed global variables for both username and password to keep credentials secure.

The Synthetics runner automatically passes these credentials to the Chromium browser, which handles the NTLM challenge-response handshake transparently.

Kerberos authentication

Configure your browser test with Kerberos authentication.

ヒント: Supported test type: browser tests on private runners only.

Kerberos is a ticket-based authentication protocol that uses a central key distribution center (KDC) to issue authentication tickets. It provides stronger security than NTLM but requires more infrastructure.

Why Kerberos requires a private runner
Kerberos authentication requires network access to your organization's Key Distribution Center (KDC), typically an Active Directory domain controller. Since the KDC is inside your organization's network and not accessible from the internet, public runners cannot reach it. Only private runners deployed within your network can access the KDC.
Limitations
  • Private runner only: Kerberos cannot work on public runners because the KDC is not accessible from the internet.

  • Custom Docker image required: The standard Synthetics runner image does not include Kerberos client libraries.

  • Browser tests only: Kerberos authentication is not available for API or uptime (HTTP) tests.

  • Ticket expiration: Kerberos tickets expire (typically 8-24 hours). Ensure your runner has a mechanism to renew tickets before they expire.

  • Time synchronization: Clock skew between the runner and KDC must be less than 5 minutes. Configure NTP on your runner host.

  • Not officially supported as a custom build: Splunk supports the standard runner image. Custom images with Kerberos are a customer-managed configuration.

To use Kerberos authentication with a private runner, you need:

  • A private runner deployed within your network, with access to:

    • Your KDC (typically port 88/TCP and 88/UDP)

    • DNS servers that can resolve your Kerberos realm

  • A custom runner Docker image with Kerberos client libraries installed

  • A krb5.conf configuration file mapping your Kerberos realm to your KDC

  • Credentials for obtaining Kerberos tickets:

    • A keytab file (recommended for automated use), or

    • A username and password for kinit

  • NTP synchronization: The runner's clock must be synchronized within 5 minutes of the KDC's clock

  1. Create a custom runner image.

    Create a Dockerfile based on the official Splunk Synthetics private runner image:

    CODE
    FROM quay.io/signalfx/splunk-synthetics-runner:latest
    
    USER root
    
    # Install Kerberos client libraries
    RUN apt-get update && apt-get install -y \
        krb5-user \
        libkrb5-dev \
        && rm -rf /var/lib/apt/lists/*
    
    # Copy your Kerberos configuration
    COPY krb5.conf /etc/krb5.conf
    
    # Copy your keytab file
    COPY your-service.keytab /etc/krb5.keytab
    RUN chmod 600 /etc/krb5.keytab
    
    USER synthetics
  2. Create a krb5.conf file for your environment:
    CODE
    [libdefaults]
        default_realm = YOUR-REALM.COM
        dns_lookup_realm = false
        dns_lookup_kdc = false
        ticket_lifetime = 24h
        renew_lifetime = 7d
        forwardable = true
    
    [realms]
        YOUR-REALM.COM = {
            kdc = your-kdc-hostname.your-realm.com
            admin_server = your-kdc-hostname.your-realm.com
        }
    
    [domain_realm]
        .your-realm.com = YOUR-REALM.COM
        your-realm.com = YOUR-REALM.COM
    Replace:
    • YOUR-REALM.COM with your Kerberos realm (typically your AD domain in uppercase)

    • your-kdc-hostname.your-realm.com with your KDC's hostname

  3. Obtain Kerberos tickets

    Before tests run, the runner must have a valid Kerberos ticket.

    1. Use a startup script that runs kinit:
      Use a keytab (recommended)
      BASH
      kinit -kt /etc/krb5.keytab serviceaccount@YOUR-REALM.COM
      Use a password
      BASH
      echo "your-password" | kinit serviceaccount@YOUR-REALM.COM
    2. Verify the ticket:
      BASH
      klist
  4. Run the custom runner
    BASH
    docker run \
      --name synthetics-runner \
      -e RUNNER_TOKEN=your-runner-token \
      your-custom-runner-image:latest

    Ensure the container can reach:

    • Your KDC (port 88)

    • Your DNS servers

    • An NTP server for time synchronization