よくある質問 DevSecOps

DevSecOps の使用に関するよくある質問への回答をご覧ください。

CIパイプラインとCCパイプラインの違いは？

CIパイプラインとCCパイプラインには共通のステップがあることにお気づきだろうか。 実行されるスキャンとチェックは、性質も内容も似ている。 次の表は、CIとCCパイプラインの違いを示している。

CIパイプラインとCCパイプラインの違い
CI パイプライン CCパイプライン
CIツールチェーンの一部である。 CCツールチェーンの一部である。
これは、マージ要求が master ブランチにマージされた後に発生します 手動でトリガーすることも、配備スケジュールとは無関係にあらかじめ定義された間隔でトリガーすることもできる。
アプリケーション URL およびアプリケーションコードリポジトリの詳細は、セットアッププロセスの一部として入力されます。 アプリケーション URL とアプリケーションコードのレポジトリの詳細は、CCツールチェーンが設定された後、最初のパイプライン実行が開始される前に提供されます。
コンプライアンス・チェック中のさまざまなスキャンやチェックの一環として作成されるインシデント問題には、期限はない。 コンプライアンス・チェック中のさまざまなスキャンやチェックの一環として作成されるインシデント問題には、期限があります。
作成されたインシデント問題は、ビルド中に発見される。 作成されたインシデント問題は、ステージング環境または本番環境の定期的なスキャン中に発見される。
summary.json ファイルは、各CIパイプラインの実行の最後には生成されません。 summary.json ファイルは、各CIパイプラインの実行の最後には生成されません。
これには、アプリケーションのアーティファクト作成、アーティファクトの署名、開発クラスタへのデプロイといったステップが含まれる。 これがCDパイプラインへのインプットを生み出す。 コンプライアンス・テストに必要なスキャンとチェックのみを実行する。

ユーザーがパイプラインをカスタマイズする方法は？

パイプラインは、カスタムスクリプトを使用してカスタマイズされます。 カスタムスクリプトは、採用者、チーム、ユーザーが、CI/CD戦略のカスタムタスクを実行するスクリプトを提供できるパイプラインの拡張ポイントである。

カスタム・スクリプトは、パイプラインのステージを制御します。 設定ファイル (pipeline-config.yaml) を使用して、各ステージの動作、スクリプトの内容、およびスクリプトを実行するベースアーティファクトを設定することができます。 パイプラインステージのスクリプトと設定は、.travis.yml や Jenkinsfile と同様のアプリケーションリポジトリ、またはカスタムリポジトリからロードされます。

詳細については、カスタムスクリプトを使用してパイプラインをカスタマイズする を参照してください。

s390x および Power プラットフォーム用のマルチ・アーキテクチャ・イメージの制限

One-Pipelineは、One-Pipelineコンフィギュレーション・ファイルの runtimeClassName （ランタイム・プロファイルを示す文字列）を使用して、 s390x およびPowerプラットフォームのネイティブ・サポートを提供します。 しかし、このネイティブ・サポートにはいくつかの 制限と推奨事項がある：

  • 制限事項
    • この機能は v11。
    • ポッドの開始時間は、 x86 ランタイムクラスよりも長い。
    • s390x または Power ワークロードで podman を使用する必要があります。 Docker 利用できません。
      • dockerコマンドの代わりにpodmanコマンドで動作するようにユーザースクリプトを更新する必要がある
      • ステージイメージにはpodmanがインストールされているはずだ。
  • 推奨： x86 のランタイムクラスを使用する
    • 様々なスキャンツールのイメージはマルチアーチをサポートしていない可能性があるからだ。
    • マルチ・アーチ・サポートは利用できないため、イメージ署名が必要である（作業中）。

カスタムなマルチアーキテクチャのベースイメージを作成するにはどうすればよいですか？

One Pipeline は、以下のプラットフォームをサポートする公式のマルチアーキテクチャベースイメージを提供しています：

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

ほとんどのユースケースでは、公式のベースイメージを直接使用することをお勧めします：

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

アプリケーションに追加のオペレーティングシステムパッケージ、言語ランタイム、またはその他のカスタム依存関係が必要な場合は、CIパイプラインの一環として、独自のマルチアーキテクチャ対応のベースイメージをビルドすることができます。

build-artifact ステップで、 --platform オプションを指定して Docker Buildxを使用してください：

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

これにより、アーキテクチャ固有のイメージが構築され、単一のマルチアーキテクチャ・イメージ・マニフェストとして公開されます。 コンテナランタイムは、ターゲットプラットフォームに適したイメージを自動的に取得します。

推奨されるアプローチ

  1. Dockerfile 内で、 FROM イメージとして「One Pipeline」ベースイメージを使用してください。
  2. アプリケーションに必要な追加のパッケージや依存関係のみを追加してください。
  3. CIパイプライン内で、 Docker のBuildxを使用してイメージをビルドし、公開します。
  4. docker buildx imagetools inspect または skopeo inspect を使用して、公開された画像を確認してください。

マルチアーキテクチャのサポートおよび制限事項に関する詳細については、「 s390x およびPowerプラットフォーム向けマルチアーキテクチャイメージの制限事項 」を参照してください。

CLIを使ってパイプラインをトリガーする

パイプラインは、 IBM Cloud CLIまたはAPIを使用してトリガーすることができます。 CLIでは、ツールチェーンとパイプラインIDを指定することで、パイプラインを開始できる。 APIを使用して、正しい認証とヘッダーでPOSTリクエストを送信し、パイプラインをトリガーすることができます。

詳細については、 トリガーを使用するを 参照してください

Git リポジトリのクローン作成には、どの環境プロパティが使用されますか？

DevSecOps のパイプラインでは、クローン作成を含む Git リポジトリの操作を認証するために、階層型トークンシステムが使用されています。 git-token 環境プロパティはデフォルトのトークンとして機能しますが、セキュリティとアクセス制御を強化するために、より具体的なトークンで上書きすることができます。

トークンの優先順位

パイプラインは、 Git の認証トークンを以下の優先順位（高い順）で解決します：

  1. 特定のリポジトリのツールチェーン統合で指定されたパーソナルアクセストークン（PAT）
  2. リポジトリ固有のトークン ： git-token-[repo_name]-[repo_org]
  3. 組織固有のトークン ： git-token-[repo_org]
  4. デフォルトのトークン ： git-token
  5. OAuth トークン ツールチェーンの統合（PATの代わりに OAuth を使用する場合）

トークンの命名例

https://github.com/my-org/my-app にあるリポジトリの場合：

  • リポジトリ固有： git-token-my-app-my-org
  • 組織固有の： git-token-my-org

重要な考慮事項

  • リポジトリの読み取り（クローン作成）と書き込み操作（プルリクエストやCIステータスの設定、インベントリの更新）の両方に同じ git-token を使用する場合、 読み取り専用アクセス権限では不十分です。 トークンには書き込み権限が必要です。
  • リポジトリまたは組織固有のトークンを使用することで、各リポジトリに必要な権限のみを付与し、最小権限の原則を適用することができます。

リポジトリ・トークン機能の詳細については、「 リポジトリ情報とトークンの取得 」を参照してください。

OnePipeline の設定変更をテストするにはどうすればよいですか？

OnePipeline の設定変更をテストする際は、カスタマイズ内容の検証を行う一方で本番環境のパイプラインに支障をきたさないよう、体系的なアプローチが必要です。

OnePipeline のコンポーネントについて

OnePipeline 主に2つのカスタマイズ可能なコンポーネントで構成されています：

  • Tekton パイプライン定義 ：PR、CI、CD、および CC ワークフロー向けに一元管理されるパイプライン定義（ compliance-pipelines リポジトリ で利用可能）。 新しいバージョンは2週間ごとのスプリントでリリースされます。

    • v10: 同時実行数が制限された安定版
    • v11 ：最大限のカスタマイズ性と並行処理能力を備えた次世代バージョン

  • パイプライン構成 (.pipeline-config.yaml) ：パイプラインのイメージ、スクリプト、アーキテクチャ、プロパティなど、デフォルトのパイプライン動作を上書きするカスタム構成ファイル。 このファイルは、アプリケーションのリポジトリまたは一元化された設定リポジトリに保存できます。

テスト手法 1：テスト設定ファイルの使用

これは、本番環境のパイプラインに影響を与えることなく、構成の変更をテストするための推奨される方法です。

  1. テストブランチを作成する

    • .pipeline-config.yaml ファイルが含まれるリポジトリにブランチを作成します
    • 設定の変更はこのブランチで行ってください

  2. テストトリガーを設定する

    • ツールチェーン内の既存のパイプライントリガーを複製する
    • わかりやすい名前を付けてください（例： Manual-Test-Config ）
    • トリガーのプロパティを更新し、テスト構成を指定してください：
      • pipeline-config: 設定ファイルの名前
      • pipeline-config-branch: テストブランチ名
      • pipeline-config-repo: 設定が含まれるリポジトリ URL

  3. 開発モードでのテスト

    • トリガーのプロパティで 開発モードを 有効にする
    • パイプラインを実行して、カスタムスクリプトを検証してください
    • 開発モードでは、証拠の収集、コンプライアンス問題の作成、およびインベントリの更新が省略されるため、迅速な反復開発に最適です
    • 重要 ：開発モードは本番環境での運用には適していません

  4. コンプライアンスチェックを含むテスト

    • 開発モードでスクリプトの検証を行った後、無効にしてください dev-mode
    • テスト中は在庫情報の更新を無効にしておく
    • 証拠収集と課題管理を含むパイプライン全体を実行する
    • すべてのコンプライアンスチェックが想定通りに通過することを確認する

  5. 実動にレベル上げ

    • テストの結果が良好であれば、プルリクエストを作成して変更内容をメインブランチにマージしてください
    • 変更は本番環境のトリガーに自動的に反映されます
    • 問題が発生した場合は、変更をすぐに元に戻すことができます

テスト手法 2：パイプラインのレイアウト変更

パイプライン定義の分岐 （上級編）

  • ( compliance-pipelines リポジトリ をフォークする)
  • フォークでの変更内容を開発・テストする
  • フォークしたリポジトリを、ツールチェーンの Git 統合として追加します
  • パイプライン定義を一時的に更新し、自分のフォークを参照するように設定してください
  • 新しいパイプライン定義をテストするために、 開発モードの トリガーを設定します
  • アプローチ1の手順に従ってテストを行ってください

ベスト・プラクティス

  • スクリプトのエラーを素早く見つけるために、必ず最初に開発モードでテストを行ってください
  • 混乱を避けるため、テストトリガーにはわかりやすい名前を付けてください
  • 設定の変更内容はコミットメッセージに記録してください
  • 誤った実行を防ぐため、テストトリガーは無効にしたままにするか、テスト終了後に削除してください
  • パイプラインの大幅な変更を行う際は、専用のテストツールチェーンの構築を検討してください
  • パイプラインのログを注意深く確認し、すべてのステージが想定通りに実行されていることを確認してください

パイプラインのカスタマイズに関する詳細については、「 カスタムスクリプト 」および