WhiteSource for GitLab:インストール

 

概要

インストールプロセスを開始する前に、インストールの前提条件で説明されているガイドラインが満たされていることを確認してください。

GitLab Integration のインストール

WhiteSource へのシステムフックの構成  

  1. GitLab インスタンスに移動し、 Admin Area > System Hooks をクリックします  。

  2. 次のガイドラインに従ってフィールドに入力します。

    • URL: WhiteSource Webhook ハンドラーの URL。URL は /payload で終わる必要があります。
      例:http://example-url.com/payload

    • Secret Token:ペイロード検証用のシークレットトークン

    • Trigger:[Tag push events] を除くすべてのチェックボックスをオンにする必要があります

    • Enable SSL Verification: はい

  3. [Add system hook] をクリックします。システムフックが画面下部の [System Hooks] セクションに表示されます。

新しいユーザーのパーソナルアクセストークンの作成

  1. 新しい GitLab の一般ユーザーを作成し、@whitesource という名前を付けます。このユーザーは管理者である必要はありません。
    注: このユーザーは実際のメールアドレスを必要としません。次のステップのパーソナルアクセストークンは、@whitesource ユーザーとして管理者が作成できます。

  2. @whitesource の Settings > Access Tokens を表示します。

  3. 次のガイドラインに従ってフィールドに入力します。

    • Name:  トークンの名前。例:WhiteSourceToken

    • Expires at(オプション):  トークンの有効期限

    • Scopes:  すべてのチェックボックスをオンにする必要があります。

  4. [Create personal access token] をクリックします。生成されたパーソナルアクセストークンをクリップボードにコピーし、次のセクションで使用します。

アクティベーションキーの作成

  1. 別のブラウザータブまたはウィンドウを開き、WhiteSourceにログインします。

  2. WhiteSourceアプリケーションの [Integrate] ページに移動し、 [WhiteSource GitLab Server] を展開します。次のフィールドが表示されます:

    • GitLab Server API URL: GitLab サーバーインスタンスの API URL。
      例:https://GitLabDevServer.com/api/v4

    • GitLab Webhook URL:  WhiteSource Webhook ハンドラーのURL(ステップ1のシステムフックと同じURL)。
      Webhook URLは、WhiteSource Integration がインストールされているGitLabプロジェクトからwebhook を作成するために使用され、WhiteSource Remediate がイシューに関連するイベントを受信できるようにします。
      注:このWebhook URL がローカルサーバー上にある場合は、GitLab サーバーが Admin Area > Settings > Network > Outbound Requests でローカルサーバーへの送信リクエストを許可するように設定されていることを確認してください。ローカルネットワーク全体への送信リクエストを許可することも、単に WhiteSource Webhook URL をホワイトリストに登録することもできます。

    • GitLab Webhook Secret: ステップ1でシステムフックを作成するときに入力した Webhook シークレット。

    • GitLab Personal Access Token:  @whitesource の前のステップで作成したユーザーのパーソナルアクセストークン。

  3. [Get Activation Key]クリックして、アクティベーションキーを生成します。WS接頭辞が付いたWhiteSourceアプリケーション内のこの統合用に新しいサービスユーザーが作成されます。 :このサービスユーザーを削除せず、このユーザーが管理者グループの一部であることを確認してください。

  4. 新しく生成されたアクティベーションキーをコピーします(次項で必要とします)

  5. WhiteSource Remediate が特定のシナリオでのみ自動で修正マージリクエストを作成するようにしたければ、[Manage Workflow Rules] をクリックすることで、Remediate がマージリクエストを作成するタイミングに関するカスタムルールを構成できます。

UI configuration tool(UI 構成ツール)の実行

UI configuration tool(UI 構成ツール)を使用すると、特定の構成要件に従ってデプロイメントファイルを構成できます。 

  1. Chrome または Firefox Web ブラウザーを使用して 、wss-configuration ディレクトリー内にあるindex.html を開きます。 [WhiteSource Configuration Editor] ページが表示されます。

  2. [Choose File] をクリックし、wss-configuration/config/prop.json にあるファイルを選択して、テンプレート JSON 構成ファイルをロードします。[General] タブがエディターに表示されます。

  3. [General] タブをクリックし、前のセクションでコピーしたアクティベーションキーを入力します。

  4. 組織のすべてのリポジトリで GitLab の課題またはコミットステータスの作成をグローバルに管理するには、[Issues] タブをクリックします。このタブのパラメーターは次のとおりです。

    • Should Create Issues(課題の作成を必須にする):組織のすべてのリポジトリで課題の作成をグローバルに無効にする機能(注:バージョン20.5.1.3からのみサポート)。

    • Should Update Commit Status(課題の作成を必須にする):組織のすべてのリポジトリのステータスをグローバルにコミットする機能(注:バージョン20.5.1.3からのみサポートされます)。

  5.  [Proxy] タブを表示するには、[Home] タブの [Advanced Properties] チェックボックスをクリックします。すべてのパラメーターのデフォルト値は空です。無効にするには、パラメーターを空白のままにします。プロキシタブのパラメータは次のとおりです。
    Proxy Host: HTTP プロキシホスト。
    Proxy Port: HTTP プロキシポート。
    Proxy Username:プロキシユーザー名(該当する場合)。
    Proxy Password:プロキシパスワード(該当する場合)。

  6. [Export] をクリックし、JSON ファイルを prop.jsonという名前で保存します。このファイルは、次のセクションで使用されます。
    注:いつでも JSON ファイルをエクスポートして、組織の関連した専門家が特定のセクションを構成できるようにすることができます。

GitLab Security Dashboard へのスキャン結果のアップロード(GitLab Ultimateユーザーのみに関連)。

  1. WhiteSource スキャン結果を GitLab セキュリティダッシュボードにアップロードするには、次の YAML を .gitlab-ci.yml ファイルに追加します。

    1 2 3 4 5 6 7 8 9 10 11 12 whitesource-security-publisher: image: openjdk:8-jdk when: manual script: - curl "{{WEBHOOK_URL}}/securityReport?repoId=$CI_PROJECT_ID&repoName=$CI_PROJECT_NAME&ownerName=$CI_PROJECT_NAMESPACE&branchName=$CI_COMMIT_REF_NAME&defaultBranchName=$CI_DEFAULT_BRANCH&commitId=$CI_COMMIT_SHA" -o gl-dependency-scanning-report-ws.json artifacts: paths: - gl-dependency-scanning-report-ws.json reports: dependency_scanning: - gl-dependency-scanning-report-ws.json expire_in: 30 days

    {{WEBHOOK_URL}}を前のステップの GitLab Webhook URL に置き換えます( payload 部分なし)。

    注:WhiteSource が CI ジョブを認識してトリガーするには、CI ジョブの名前が whitesource-security-publisher である必要があります。

コンテナの実行

Docker を使用してデプロイ

ネットワークブリッジを作成します(すべてのコンテナーが同じネットワーク内で実行される必要があるため、異なるコンテナー間にプライベートネットワークが作成されます)。

1 docker network create -d bridge my_bridge

wss-gls-app  アプリコンテナを実行します。

1 2 3 4 docker run --name wss-gls-app --network my_bridge -p 9494:9494 -p 5678:5678 -v <path/to/config/directory>:/etc/usr/local/whitesource/conf wss-gls-app:<version> # For example: docker run --name wss-gls-app --network my_bridge -p 9494:9494 -p 5678:5678 -v c:/tmp/gls/:/etc/usr/local/whitesource/conf/ wss-gls-app:19.9.1.1

wss-scanner  スキャナコンテナを実行します。

1 2 3 4 docker run --name wss-scanner-gls --restart=always --network my_bridge -p 9393:9393 -v <path/to/config/directory>:/etc/usr/local/whitesource/conf/ wss-scanner:<version> # For example: docker run --name wss-scanner-gls --restart=always --network my_bridge -p 9393:9393 -v c:/tmp/gls/:/etc/usr/local/whitesource/conf/ wss-scanner:19.9.1.1

wss-remediate  サーバコンテナを実行します。

1 2 3 4 5 6 7 8 docker run --name remediate-server --restart=always --network my_bridge -e LOG_LEVEL=debug -p 8080:8080 -v <path/to/config/directory>/prop.json:/etc/usr/local/whitesource/conf/prop.json -v /tmp:/tmp wss-remediate:<version> # For example: docker run --name remediate-server --restart=always --network my_bridge -e LOG_LEVEL=debug -p 8080:8080 -v c:/tmp/gls/prop.json:/etc/usr/local/whitesource/conf/prop.json -v /tmp:/tmp wss-remediate:19.8.1 # NOTE: If port 8080 isn't available, you can use a different port by modifying the first port entry in the 'docker run' command. For example: # docker run --name remediate-server --network my_bridge -e LOG_LEVEL=debug -p 8082:8080 -v c:/tmp/gls/prop.json:/etc/usr/local/whitesource/conf/prop.json -v /tmp:/tmp wss-remediate:19.8.1

Helm Charts を使用してデプロイ

wss-deployment ディレクトリは、次の構造で構成されています。

  • helm

    • configs

    • templates

      • config.yaml

      • wssScmIntegration.yaml

    • Chart.yaml

    • values.yaml

  • values.yaml

helm フォルダーを wss-deployment からターゲット環境にコピーします。helm/configs 内に前の手順で編集してエクスポートした prop.json を追加します。

Chart.yaml

このファイルには、グラフに関する情報が含まれています。

注:このファイルは編集しないでください。

Values.yaml

このファイルは、WhiteSource統合イメージの名前とバージョンを表します。

1 2 3 4 5 6 7 8 9 10 11 wsscanner:   image: {image}   version: {version} wsscontroller:   image: {image}   version: {version} wssremediate:   image: {image}   version: {version}

各イメージの宣言部分(wssscanner、wsscontroller、wssremediate)について、{image} と {version} を実際にビルドされたイメージの名前とバージョンに置き換えます。  注: wsscontroller の部分には、wss-gls-app イメージの名前とバージョンを使用します。

Docker リポジトリに認証が必要な場合は、このファイルにオプションのパラメーター imagePullSecrets を追加できます。

configs / prop.json

helm フォルダの中に configs フォルダを新たに作成し、前の手順で編集してエクスポートした、 prop.json を追加します。

templates / config.yaml

これは、configs/prop.json  ファイルを指す構成ファイルです。

注:このファイルは編集しないでください。

templates/wssScmIntegration.yaml

これは、統合をデプロイするためのすべてのパラメーターを含む構成ファイルです。

注:  このファイルには、サービスを区切る3つのダッシュ(「---」)があります。削除しないでください。

統合によって Webhook URL にパブリックにアクセスできるようにするには、ファイルにロードバランサーサービスを追加する必要があります。このようなサービスの例を以下に示します。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 apiVersion: v1 kind: Service metadata:   name: lb1   namespace: acme   annotations:     external-dns.alpha.kubernetes.io/hostname: helm.acme.io     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"     service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-7:834027593108:certificate/4720e07a-a231-4fd5-9c4a-12ab1450567d spec:   type: LoadBalancer   ports:   - port: 443     name: https     targetPort: 5678   selector:     app: wss-controller

スキャンするリポジトリを選択

  1. 複数のリポジトリを統合していて、グローバル構成を適用する場合は、この手順を続行する前にここを参照してください。

  2. スキャンしたいリポジトリに対する Maintainer 権限をもつ @whitesource のユーザー(手順2の間に作成したユーザー)を追加します。これにより、WhiteSourceがスキャンするリポジトリを見つけられるようになります。

    WhiteSource for GitLab で GitLabグループ全体をスキャンする場合は、@whitesource ユーザーをグループに追加して、そのグループ内のすべてのプロジェクトで WhiteSource for GitLab を有効にします。
    注:@whitesource ユーザーを、Maintainer よりも低い権限でリポジトリに追加してしまうと、Integration の機能に副作用が生じる可能性があります。

  3. グローバル構成を介して特に指定されていない限り、@whitesource ユーザーが追加されたリポジトリごとに受け入れのマージリクエストが作成されます。このリクエストにはマージする前にカスタマイズできる WhiteSource 構成ファイル(.whitesource)が含まれています。マージされると、WhiteSourceスキャンが開始されます。

  4. リポジトリのスキャンを無効にするには、リポジトリのメンバーから @whitesource ユーザーを削除します。

APIを介したスキャン統計へのアクセス

詳細については、 こちら をご覧ください。

ヘルスチェックAPI

詳細については、こちらをご覧ください。

.whitesource ファイル

WhiteSource 構成ファイル( .whitesource )は、スキャンが有効になっている各リポジトリーに追加される JSON ファイルです。WhiteSource スキャンの構成可能なパラメーターを提供します。.whitesource のファイルは(修正されない限り、それはマスターブランチです)リポジトリのデフォルトのブランチに追加されます。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 { "scanSettings": { "configMode": "AUTO", "configExternalURL": "", "projectToken" : "" }, "commitStatusSettings": { "vulnerableCommitStatus": "FAILED" }, "issueSettings": { "minSeverityLevel": "LOW", "openConfidentialIssues": true } }

パラメーター

全体設定

パラメータ 

タイプ

説明

必須 

デフォルト

パラメータ 

タイプ

説明

必須 

デフォルト

settingsInheritedFrom

文字列

グローバル構成が有効な場合、このパラメーターは、その構成を継承するwhitesource-config リポジトリの場所を指定します。これには、GitLabユーザー名、リポジトリ名、および repo-config.json ファイルの場所のブランチ(オプション)が含まれている必要があります。デフォルトのブランチは master ですが、whitesource-config リポジトリ内のrepo-config.jsonファイルの場所に応じて変更できます。 

注:このパラメーターの後にこれらを追加することにより、特定のリポジトリーにのみ関連する特定のパラメーターをオーバーライドできます。

例:

グローバル構成で定義された値のみを使用:

1 2 "settingsInheritedFrom":"whitesource- config / whitesource- config @ master"

グローバル構成で定義された値を使用し、スキャン設定パラメーターをオーバーライドします。

1 2 3 4 5 "settingsInheritedFrom": " whitesource-config / whitesource-config @ master"、 "scanSettings": { "projectToken": "12345", "baseBranches": ["master","integration"] }

いいえ

なし



スキャン設定(scanSettings)

パラメータ 

タイプ

説明

必須 

デフォルト

パラメータ 

タイプ

説明

必須 

デフォルト

configMode

文字列

使用する構成ファイルのモード。可能なオプションは次のとおりです。

  • AUTO:デフォルトの WhiteSource 構成 (デフォルト)

  • LOCAL:現在のリポジトリのルートフォルダーにある whitesource.config ファイルを使用。構成ファイルは、Unified Agent 設定ファイルと同じ形式である必要があります。注:グローバル構成はサポートされていません。

  • EXTERNALconfigExternalURL  パラメータに従って指定された構成ファイルを探します。

いいえ

AUTO

configExternalURL

文字列

外部構成ファイルのURL(任意のファイル名を選択できます)。
例:https://mydomain.com/whitesource-settings/wss-unified-agent.config

次のプロトコルがサポートされています:ftp:// http:// https://

注: configMode EXTERNAL のときのみ有効です。

いいえ

空文字列

projectToken 

文字列

Bitbucket リポジトリを WhiteSource プロジェクトにマップする機能を追加します。使用するパラメーターは、WhiteSource プロジェクトトークンである必要があります。

注:グローバル構成はサポートされていません。

いいえ

空文字列

baseBranches

文字列の配列

スキャン結果が新しい WhiteSource プロジェクトに送信される1つ以上のベースブランチを指定する機能を追加します。

使用例:["master”, "integration"]

これにより、master ブランチと integration ブランチの両方がベースブランチとして設定されます。

次の点に注意してください。

  • イシューは、指定されたブランチ名に対してのみ作成されます。

  • baseBranches パラメーターを含まないリポジトリでは 、すべてのブランチでイシューが生成されます。

  • 指定されたブランチごとに、WhiteSourceプロジェクトが作成されます。プロジェクトの名前には、接尾辞「_ブランチ名」が含まれます。たとえば、  MyApp_dev。このサフィックスは、デフォルトのブランチには適用されません。

注: このパラメーターは、バージョン20.7.1からのみ使用できます。

いいえ

空文字列 

この場合、基本ブランチはデフォルトブランチのみで構成されます。

コミットステータス設定(commitStatusSettings)

パラメータ 

タイプ

説明

必須 

デフォルト

パラメータ 

タイプ

説明

必須 

デフォルト

vulnerableCommitStatus

文字列

FAILED:WhiteSourceスキャンがリポジトリの脆弱性を検出すると、コミットステータスに FAILED と表示され、脆弱性が検出されたことを示します。
脆弱性が検出されなかった場合、コミットステータスは SUCCESS インジケーターを示します(デフォルト)

  • SUCCESS:スキャンでリポジトリ内の脆弱性が検出されたかどうかに関係なく、スキャンの最後にコミットステータスに成功インジケータが表示されます。

  • NONE :スキャン中の running インジケータをのぞいて、どのような状況の下でもコミットステータスは更新されません。

いいえ

AUTO

showWsInfo

ブール値

WhiteSource コミットステータス内のプロジェクトトークンなどの追加のWhiteSource 情報を表示するかどうか(スキャントークンの後)。

WhiteSource 情報は、コミットがベースブランチから発信された場合にのみ表示されます。
コミットが複数のブランチに存在する場合、表示されるWhiteSource情報は、元のベースブランチ(つまり、baseBranches パラメーターが定義された場所)のみを表し ます。

このパラメーターを有効にすると、次の非表示のJSONオブジェクトもコミットステータス内に追加されます。

1 <!-- <INFO>{"projectToken":"1cd2d2a8651145c087609e0a43f783e95f7008cb908541498348fed529572e01"}</INFO> -->

注:将来、追加の WhiteSource データがJSONオブジェクト内に追加される可能性があります。

いいえ

false

イシュー設定(issueSettings)

パラメータ 

タイプ

説明

必須 

デフォルト

パラメータ 

タイプ

説明

必須 

デフォルト

minSeverityLevel

文字列

重大度レベルが minSeverityLevel を超えた場合にのみ、新しい GitLab issue(課題)がオープンされます。

  • NONE:GitLab の issue(課題)は発生しません。

  • LOW:脆弱性が検出されたとき GitLab の issue(課題)を生成します。

  • MEDIUM:あらゆる中・高の脆弱性が検出されたとき GitLab の issue(課題)を生成します。

  • HIGH:高い脆弱性のときのみ GitLab の issue(課題)を生成します。

注: WhiteSourceセキュリティチェックの概要もこのパラメーターの影響を受けます。

いいえ

LOW

openConfidentialIssues

ブール値

WhiteSourceによって開かれた GitLab の issue(課題)が機密情報であるかどうか。

いいえ

false

Remediate 設定(remediateSettings)

パラメータ 

タイプ

説明

必須 

デフォルト

パラメータ 

タイプ

説明

必須 

デフォルト

enableRenovate

ブール値

有効にすると、Remediate は脆弱な依存関係を修正するマージリクエストに加えて、古い依存関係に対して自動化されたマージリクエストを生成します。Remediateはすべての機能を実行し、WhiteSource Renovateで利用可能なすべての構成オプションをサポートします。

すべての構成オプションについては、 Renovate の構成オプションを参照してください。

パラメータの使用法については、こちらを参照してください。

いいえ

false

プライベートレジストリ設定(hostRules)

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

matchHost

スキャン中に資格情報が適用される場所を定義します。

ホスト内のネストされたパスにのみクレデンシャルを適用する場合はmatchHost 、ベースURLとして記述 します。
例:  https://registry.company.com/nested/path/

同じ資格情報がサブドメインではなくホスト上のすべてのパスに適用される場合は、のmatchHost ようなプロトコルで構成 します https://registry.company.com

最後に、ドメイン内のすべてのホストにクレデンシャルを適用するにmatchHost は、https:// プレフィックスのない値を使用し ます 。たとえば、 company.com または registry.company.com、どちらもbeta.registry.company.com。のようなホストに適用されます 。

番号

空の

hostType

プライベートレジストリの種類。サポートされている値:npm,maven gradlepypi,go

番号

空の

ユーザー名

資格情報がユーザー名とパスワードで構成されている場合に使用されます。

番号

空の

パスワード

クレデンシャルがユーザー名とパスワードで構成されている場合に使用されますこの命令で暗号化する必要があります。

matchHostパラメータで設定されたホストへの資格情報として適用される暗号化されたシークレット。encryptedパラメータ内に含める必要があります:

1 2 3 "encrypted": { "password": "3f832f2983yf89hsd98ahadsjfasdfjaslf............" }

番号

空の

トークン

クレデンシャルがユーザー名とパスワードで構成されている場合に使用されますこの命令で暗号化する必要があります。

matchHostパラメータで設定されたホストへの資格情報として適用される暗号化されたシークレット。encryptedパラメータ内に含める必要があります:

1 2 3 "encrypted": { "token": "3f832f2983yf89hsd98ahadsjfasdfjaslf............" }

番号

空の

グローバル構成ファイルの提供

注:バージョン20.5.1.3からのみサポートされます。

カスタム.whitesource構成ファイルをwss-gls-appコンテナーの一部として提供して、組織のすべてのリポジトリーにグローバルに適用することができます。そうすることで、新しく選択されたリポジトリのすべてのオンボーディングプルリクエストにファイルが適用されます。この変更の前にすでに選択およびアクティブ化されているリポジトリは、このグローバル構成の影響を受けません。新しくオンボードされたリポジトリのみが影響を受けます。 

このグローバルな変更を適用するには、次のようにします。

  1. wss-gls-appコンテナを停止します。

  2. 「wss-gls-app / conf」フォルダーに、カスタムの「.whitesource」ファイル(prop.jsonファイルがある場所)を追加します。

  3. wss-gls-appコンテナを起動します。

構成エラーの問題

構成エラーの問題とコミットステータスを作成することにより、スキャンに影響を与える構成エラーについてユーザーに警告します。このようなエラーが発生した場合、次のことが発生します。

  1. ワークフローを停止します。スキャンまたはWhiteSourceSecurityのコミットステータスを作成しないでください。

  2. 「構成に失敗しました」コミットステータスを作成します。

  3. 解析に失敗した構成ファイルごとに、「必要なアクション:WhiteSource構成ファイルの修正-{fileName}」というタイトルの新しいタイプの問題を作成します。エラーがrepo-config.jsonまたはglobal-config.jsonファイルに起因する場合、問題はwhitesource-configリポジトリに作成されます。

処理されたエラー:

  • 構成ファイルの解析中にエラーが発生しました(.whitesource / repo-config.json / global-config.json json)

  • 継承構成にリポジトリやブランチがありません

プライベートレジストリと認証済みリポジトリの処理

現在、NPMとMavenのプライベートレジストリのみがサポートされています。

サポートされているプラ​​イベートレジストリのリスト:

  • NPM

  • Yarn

  • Maven

  • Gradle

  • PIP

  • Go

プライベートレジストリと認証されたリポジトリからの依存関係をスキャンするには、WhiteSourceにNPMトークンなどの資格情報を提供する必要があります。シークレットスコープが組織全体の場合、これらの資格情報は、リポジトリごとに、または共有グローバル構成で、暗号化されたシークレットとして.whitesourceファイルに追加する必要があります。

暗号化された秘密を作成します。暗号化する各シークレットは、GitLab組織またはリポジトリにスコープされている必要があり、その使用はアプリ内のものに制限されます。

  1. GPGを使用してPGPキーを生成します。コマンドgpg --full-generate-key を使用し、プロンプトに従ってキーを生成します。現時点では、復号化にパスフレーズを使用することはサポートされていないため、パスフレーズなしでキーを生成することをお勧めします。名前とメールアドレスは重要ではありません。

    1. 出力からキーIDをコピーするgpg --list-secret-keys か、コピーを取り忘れた場合は実行 します。これはあなたの公開鍵です。

    2. 実行 gpg --armor --export-secret-keys YOUR_NEW_KEY_ID > ws-private-key.asc して、装甲(テキストベース)秘密鍵ファイルを生成します

    3. 実行 gpg --armor --export YOUR_NEW_KEY_ID > ws-public-key.asc して、装甲(テキストベース)公開鍵ファイルを生成します

  2. コントローラー、修復およびスキャナーに環境変数を使用して秘密鍵を提供します(環境変数の詳細については、高度な技術情報のドキュメントを参照してください)。それを行う方法には2つのオプションがありますが、1つのオプションのみを使用する必要があります。

    1. WS_HOST_RULES_PRIVATE_KEY-秘密鍵自体の値。

    2. WS_HOST_RULES_PRIVATE_KEY_FILE_PATH-秘密鍵を含むファイルへのパス。このファイルは、実行中のコンテナーにマップする必要があります。

  3. お気に入りのエディターでindex-enterprise.htmlを開きます。

  4. 「COPY_YOUR_PUBLIC_PGP_KEY_HERE」というテキストを見つけて、新しく生成した公開鍵に置き換え、ファイルを保存します。
    const publicKeyString = `COPY_YOUR_PUBLIC_PGP_KEY_HERE`;

  5. シークレットを作成したら、それを.whitesourceファイルのhostRulesパラメーターに追加してください。

hostRulesの例:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 { "hostRules": [ { "matchHost": "registry.npmjs.org", "hostType": "npm", "encrypted": { "token": "3f832f2983yf89hsd98ahadsjfasdfjaslf............" } }, { "matchHost": "https://custom.registry.company.com/maven/", "hostType": "maven", "username": "bot1", "encrypted": { "password": "p278djfdsi9832jnfdshufwji2r389fdskj........." } } ] }

  • コメントを含むキージェネレータの出力全体をコピーして、文字列に貼り付けます。

    つまり、「----- BEGIN PGP PUBLIC KEYBLOCK -----...」を含めます。

  • 文字列は、引用符ではなくJavaScriptのバッククォートを使用します。これは、複数行の文字列を許可して、改行を改行文字に置き換える必要がないようにするためです。公開鍵にスペースを導入し、暗号化が失敗する可能性のあるエディターによる自動インデントに注意してください。

  • PGP方法論の非対称公開鍵暗号を使用します 。組織/グループ、リポジトリ、生の値-暗号化ページで提供するすべての情報は、このアプローチで保護されます。