Secure QA プロセス

すべてはマージリクエストから始まります

私たちは、プロダクトへのすべての貢献がフォーマルなレビューを伴うマージリクエストを経ることを求め、要求しています。そのため、私たちは GitLab の開発者ドキュメントに記載されているマージリクエストワークフローとコードレビューガイドラインに従っています。ただし、これらのドキュメントからいくつかの項目を強調し、レビュアーと著者に対するいくつかの追加的な考慮事項を追加したいと思います。

マージリクエストレビュアーへの追加的な考慮事項

  • ピアやコミュニティメンバーのブロックを解除する最善の方法は、タイムリーにフィードバックを提供することです。キャパシティがいっぱいで、私たちが目指す SLO 内でレビューを行えない場合は、別のレビュアーを見つけられるようにマージリクエストでその旨を知らせてください。

マージリクエスト著者への追加的な考慮事項

  • グローバルに分散した組織であることは、人々の間のやり取りに遅延を生じさせることがあり、頻繁にそうなります。変更へのフィードバックを受け取るのが予想より長くかかっても、個人的に受け取らないでください。

Secure QA プロセス

Secure アナライザーは、サポートされる言語/フレームワークのダウンストリームテストプロジェクトに対して新しいコミットを実行することで、マージリクエストを検証します（例: Dependency Scanning の gemnasium アナライザー は php、go、およびその他いくつかのテストプロジェクトに対してテストをトリガーします）。検証は、生成されたレポート出力をアナライザーのリポジトリにコミットされた期待レポートと比較することで行われます。アナライザーの動作が変更された場合、期待レポートと生成されたレポートの内容が一致しなくなるため、パイプラインは失敗します。

Dependency Scanning、SAST、Secrets Detection アナライザーの期待値は、プロジェクトの qa/expect ディレクトリに、各フレームワーク/言語タイプのサブディレクトリとともに格納されています。

テストプロジェクト

テストプロジェクトは Secure の tests サブグループにあり、その使用方法とベストプラクティスは common README に記載されています。

アナライザーの動作変更

アナライザーへの変更がレポート出力を変更する場合、期待レポートも変更する必要があります。

SAST、Dependency Scanning、Secret Detection では、期待レポートはアナライザーとともに、言語/フレームワークのサブディレクトリ内のテストプロジェクトに対応するパスに格納されています。例えば、java-maven の依存関係をスキャンするための期待レポートは gemnasium-maven/qa/expect に格納されています。このようにして、アナライザーの動作が変更された場合、期待値を同じコミットで変更してパッケージ化できます。

License Compliance については、期待値はテストプロジェクトの qa/expect ディレクトリ（例: ruby-bundler/qa/expect）に格納されています。

詳細については、Security Products テストプロジェクトリポジトリで確認できます。

OpenShift でのテスト

現在、OpenShift の自動テストはありません。変更がアナライザーの動作に OpenShift 上でどのような影響を与えるかを確認したい場合は、OpenShift 環境をセットアップしてテストできます。これを行うには2つの方法があります。

1. 自動スクリプト

ディストリビューションチームが OpenShift クラスターをセットアップするための自動スクリプトを共有しています。私たちのグループではテストされていませんが、この方法はクラスター作成プロセスを効率化できる可能性があります。

2. 手動セットアップ

GitLab Sandbox Cloud へのアクセスがすでにある場合、以下の手順に従って OpenShift クラスターをセットアップできます。

  1. https://gitlabsandbox.cloud/ にログインします。

  2. Static Analysis Group EC2 開発マシンセットアップガイドのステップ 1 から 3 に従って、AWS サンドボックスアカウントを作成し、AWS コンソールにログインします。

  3. AWS コンソールにログインしたら、左上の検索フィールドで「OpenShift」を検索します。Services カテゴリの下に Red Hat OpenShift Service on AWS が表示されます。ROSA は AWS との統合された OpenShift エクスペリエンスを提供します。この検索結果をクリックして進みます。

    openshift-service-on-aws-search-results

  4. Red Hat OpenShift Service on AWS (ROSA) ランディングページにリダイレクトされます。左サイドバーの Get started リンク、または Get started オレンジボタンをクリックします。

    openshift-service-on-aws-landing-page

  5. Verify ROSA prerequisites ページにリダイレクトされます。

    verify-rosa-prerequisites

    ROSA enablement セクションの Enable ROSA HCP and ROSA classic ボタンをクリックし、I agree to share my AWS account number... のチェックボックスをオンにしたままにします。ROSA enablement セクションには「お客様の ROSA 有効化リクエストは保留中であり、解決に数分かかる場合があります。エラーを確認できるようにこのページを開いたままにすることをお勧めします。」と表示されます。

  6. 数分後、ROSA enablement セクションが更新され、以下のメッセージが表示されます。

    • You have agreed to share your AWS account number and email address with red hat.
    • You have enabled ROSA and HCP and ROSA classic.

    rosa-enabled

  7. 右下隅の Continue to Red Hat オレンジボタンをクリックします。これにより https://sso.redhat.com にリダイレクトされ、Log in to your Red Hat account が要求されます。

    login-to-your-redhat-account

  8. Log in with Google をクリックし、gitlab.com の Gmail アカウントを使用します。Register for a Red Hat account ページにリダイレクトされます。

    register-for-red-hat-account

    必要なフィールドに入力します。Email address には gitlab.com の Gmail アカウントを使用し、Create my account をクリックします。

  9. Complete your account connection ページにリダイレクトされます。I have read and agreed to the terms and conditions チェックボックスをオンにし、Connect accounts ボタンをクリックします。

    complete-your-account-connection

  10. 次に We need a little more information と説明する別のページにリダイレクトされます。必要なフィールドに入力します。Email address には gitlab.com の Gmail アカウントを使用し、Account type には Personal を選択します。

    we-need-a-little-more-information

  11. Terms and conditions ボックスが表示されます。View Terms and Conditions をクリックして同意します。

    terms-and-conditions

  12. Red Hat Hybrid Cloud Console Overview 画面にリダイレクトされます。Red Hat OpenShift Service on AWS (ROSA) ダイアログボックスの Create cluster をクリックして OpenShift クラスターをセットアップできます。

    redhat-overview

    テストのみにクラスターを使用する予定の場合は、2ヶ月間の無料試用期間がある OSD Trial を選択することをお勧めします。この期間後、クラスターは削除されます。無料試用期間中は2ヶ月以内に有料プランにアップグレードできます。

  13. クラスターのセットアップが完了したら、OpenShift クラスターにログインするためのユーザーを作成する必要があります。Cluster List > <your cluster> を選択し、Identity Provider に htpasswd を選択します。Cluster Roles and Access で OpenShift クラスターにアクセスするためのユーザーを作成できます。このユーザーが dedicated-admin グループと cluster-admins グループに属していることを確認してください。

  14. その後、Open console ボタンをクリックし、前のステップで作成したクラスター管理者ユーザーでログインします。

  15. OpenShift クラスターにログインしたら、Operators > Operator Hub を選択して GitLab Runner Operator をインストールできます。GitLab Runner を検索し、検索結果をクリックして、こちらで説明されているように Install ボタンをクリックします。

  16. OpenShift クラスターでランナーをセットアップするには、operator の README に含まれる手順に従ってください。

    gitlab-runner-operator README.md で参照されているランナートークンは、GitLab プロジェクトから CI/CD Settings > Runners > New Runner を選択することで取得できます。

    ランナーのセットアップには、コマンドラインツール oc（OpenShift クライアント）のインストールが必要です。oc を使用する前に、クラスターに対して認証する必要があります。OpenShift クラスター管理者ユーザー名をクリックし、Copy login command を選択することで認証情報を確認できます。デフォルトのランナーセットアップでは、コンテナが root 権限で実行されることに注意してください。root 以外のユーザーへのアクセスを制限するには、以下の設定を提供できます。

    [[runners]]
name = "gitlab-runner"
url = "https://gitlab.com"
executor = "kubernetes"
[runners.kubernetes]
    [runners.kubernetes.pod_security_context]
    run_as_non_root = true
    run_as_user = 1000

    この設定を oc create configmap my-runner-config --from-file=config.toml で適用した後、以下のようにランナー設定を更新し、oc appy -f gitlab-runner.yml で適用できます。

    apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
  name: gitlab-runner
spec:
  gitlabUrl: https://gitlab.com
  buildImage: alpine
  token: gitlab-runner-secret
  tags: openshift
  config: my-runner-config

  17. OpenShift ランナーは、GitLab プロジェクト設定の CI/CD Settings > Runners に緑色で表示されるはずです。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License