ツールチェーンでのシークレットの管理

CIやCDツールチェーンのツール統合には、パスワード、APIキー、証明書、その他のトークンなどの秘密が必要です。例えば、 IBM Cloud® API キーは、 IBM Cloud へのログインなど、基本的なパイプラインタスクを実行します。同様に、サービス ID の API キーは、Cloud Object Store インスタンス内のバケットにエビデンスを書き込みます。

セキュリティー上の理由から、これらのシークレットは、個人の ID やアカウントを明らかにしてはなりません。多くの場合、ユーザーは実際のツールチェーン自動化要件よりも多くのアクセス許可を持っているためです。個人の ID またはアカウントとの関連付けも、「最小特権」のセキュリティー原則に違反します。また、人はしばしば役割を変えたり、会社を変えたりするものであり、そのような場合には資格情報を削除しなければならない。自動化のために特別に提携されたIDを使用することで、自動化と自動化を使用する人々との間の職務の分離を提供する。

その代わりに、 IBM Cloud 以外のリソース（ GitHub Enterprise など）に使用される秘密は、ツールチェーンが必要とする適切なアクセスのみを持つ、企業内の機能IDに関連付けられなければなりません。同様に、 IBM Cloud リソースの秘密は、 IAMサービスID と提携している IAMサービスID APIキーと提携していなければならない。 IAMサービスIDのアクセス許可は、ツールチェーンが必要とする最小権限にスコープされる必要がある。

このような資格情報の管理は、シークレット管理のベスト・プラクティスに従って安全に行う必要があります。具体的には、 IBM Cloud® Secrets Manager、 IBM® Key Protect、または以下のような承認されたバウンダリ内保管庫プロバイダを使用して、必要な秘密を保管することを意味します。 HashiCorp Vault などを使用して必要な秘密を保管し、ツールチェーンの秘密をそれらのリソースにリンクすることです。

ツールチェーンのセットアップとパイプラインのユーザーインターフェースで提供される秘密管理機能は、 IBM Cloud® Secrets Manager、 IBM® Key Protect、または HashiCorp Vault の秘密統合を使用することで、保管されている秘密を選択することができます。ツールチェーン・エディターまたはパイプライン・エディターは、「シークレット・ピッカー (Secrets Picker)」ダイアログを使用して、 CRN によって (クラウド・リソース名) または 名前によって構成されたバインド済みシークレット統合から名前付きシークレットを選択できます。これらは、ツールチェーンおよびパイプライン内で実行時に参照によって解決されます。シークレットが選択されると、対応するツールチェーンまたはパイプラインのセキュア・プロパティーに CRN または正規シークレット参照が注入されます。フォーマットは、 crn:v1:...secret:<secret-guid> ( CRN によって構成されている Secrets Manager 統合の場合)、または {vault::integration-name.secret-name} (サポートされている任意のプロバイダーを使用し、名前で構成されているボールト統合の場合) のいずれかです。

現在、 名前による 正規参照形式では、シークレット名にピリオド文字が含まれているシークレットは解決されません。これは、この文字が正規パスの各セクションを区切るために使用されるためです。

どのタイプのシークレット参照が使用されているかに関係なく、フロントエンド・ユーザー・インターフェース・コンポーネントとシークレット・ピッカー・ダイアログは、 CRN または名前のいずれかによって、シークレット参照のみを使用します。 CRN または という名前の シークレット参照によって解決された値は、フロントエンドに公開されることはなく、許可された許可が使用可能である (IAM 許可およびアクセス・ポリシーを使用して構成されている) ことに基づいて、実行時に常にツールチェーンおよびパイプライン内で動的に解決されます。

IBM Cloud® 内で、ツールチェーンとパイプラインの CRNによる と 名前で シークレット参照を解決する動的なプロセスは、すべてのリージョンのすべての IBM Cloud® Secrets Manager と IBM® Key Protect プロバイダーインスタンスへの内部仮想プライベートエンドポイント（VPE）を使用して実行される。これにより、ツールチェーン、パイプライン、 IBM Cloud® Secrets Manager および IBM® Key Protect プロバイダーインスタンス間のすべてのリクエストおよびレスポンスデータは、境界内のプライベート IBM Cloud ネットワーク内に保持され、パブリックネットワークチャネルを経由しないことが保証される。

ツールチェーン内のバインドされたシークレットの統合から、選択したシークレットを 1 つずつ手動で選択することに加えて、 Secret Hint を使用するオプションも使用できます。このオプションにより、短い形式のシークレット参照である推奨シークレット名 ( Hints とも呼ばれます) を使用してツールチェーン・テンプレートを事前定義できます。シークレット・ヒントの形式は {vault::secret-name} です。この場合、シークレット統合名は含まれません。これにより、必要なすべてのシークレット名を toolchain.yml に事前に取り込むことができ、それらの名前はツールチェーン用に構成されているシークレット統合に対して自動的に解決されるという柔軟性がツールチェーン作成者に提供されます。

前述のように、 CRN によってシークレットを参照するように Secrets Manager を構成できます。詳しくは、クラウド・リソース名（CRN ）を参照。正しい許可が設定されている場合は、別のアカウントで Secrets Manager インスタンスからシークレットを参照できるため、このフォーマットにより柔軟性が向上します。詳しくは、 Secrets Manager を参照してください。

CIとCDの両方で使われる秘密の概要は以下の通りである：

Hint は、ツールチェーンにバインドされている利用可能な by name secrets統合のいずれにおいても、同じ名前で最初にマッチするシークレットに対して自動的に解決される、推奨されるデフォルト名である。

DevSecOps パイプラインのシークレット

DevSecOpsの秘密
シークレット	ヒント	情報
IBM Cloud の API キー	`ibmcloud-api-key`	必須：CI & CD IBM パブリッククラウドとの認証と幅広い操作の実行に使用する。
GPG 秘密鍵	`signing_key`	必要です：CIのみ CIパイプラインによってビルドされたイメージに署名するために使用される証明書です。
IBM プライベート・ワーカー・サービス API キー	`private-worker-service-api-key`	必要です：CI のみ A Service ID API Key Tekton Private Worker Service 上でデリバリーパイプラインのワークロードを実行するために使用される。
GitHub アクセス・トークン	`git-token`	オプション：CI & CD GitHub で認証し、リポジトリへのアクセスを提供するために使用する。
Artifactory API トークン	`artifactory-token`	必須: CI & CD パイプライン・タスクによって使用されるイメージにアクセスするために使用されます
Slack Webhook	`slack-webhook`	オプションです：CI & CD このウェブフックは、ツールチェーンのステータス通知を投稿するためにSlackツール統合を使用する場合に必要です。
ServiceNow API トークン	`servicenow-api-token`	必須: CD のみ変更管理操作のために Service Now にアクセスするために使用されます
HashiCorp Vault 役割 ID	`role-id`	必須：CI & CD HashiCorp Vault サーバーとの認証に使用。
HashiCorp Vault シークレット ID	`secret-id`	必須：CI & CD HashiCorp Vault サーバーとの認証に使用。
IBM Cloud Object Storage ライター API キー	`cos-api-key`	必須: CI & CD Object Storage サービスでの認証に使用されます。この鍵には `writer` 許可が必要です。
IBM Cloud Object Storage リーダーAPIキー	`backup-cos-api-key`	必須: CI & CD Object Storage サービスでの認証に使用されます。この鍵には `Reader` 許可が必要です。
SonarQube パスワードまたは認証トークン	`sonarqube-password`	オプション：CI SonarQube ソースコードアナライザでの認証に使用する。

HashiCorp Vault サーバーを使用している場合、 HashiCorp Vault ツール統合が AppRole Auth Method メソッドを使用していることを確認してください。 AppRole 認証方法を使用する場合、 HashiCorp Vault サーバーとツールチェインを正常に統合するには、 role-id と secret-id が必要です。 role-id と secret-id はそれ自体が秘密であるため、 IBM Key Protect ツール統合を使用して、ツールチェーンワークフローで安全に検索および適用できるように保存することが推奨される。その他のツールチェーン・シークレットはすべて、 HashiCorp Vault ツール統合を使用して保存および取得する必要があります。

パイプライン環境プロパティ git-token が設定されていない場合、デフォルトで Git Repos and Issue Tracking アクセストークンを取得するために ibmcloud-api-key が使用されます。ただし、ibmcloud-api-key に git へのアクセス権限がない場合は、git-token を設定する必要があります。

シークレット・ストアの構成

IBM Cloud では、機密データの保護と秘密の一元化を支援するさまざまな秘密管理およびデータ保護サービスを選択できます。 IBM Cloud シークレットの管理で説明されているように、要件に応じてボールト統合を選択できます。この文書では、前提条件や、ヒントとして知られている秘密の名前のリストの使用方法についての情報を提供します。テンプレートでヒントを使用すると、事前構成されたシークレットをツールチェーンに自動的に取り込めるので、ツールチェーンに接続したさまざまなボールト統合から手動でシークレットを選択する必要がありません。

使用方法 IBM Cloud® Secrets Manager を使用して、API キー、画像署名、 HashiCorp Vault 認証情報のような、ツールチェーンの一部である秘密を安全に保存し、適用します。

Secrets Managerツール統合フォーム — IBM Secrets Managerツール統合

テンプレートには、次の例のように、 HashiCorp Vault ツールの統合も付属しています：

HashiCorp Vault ツール・インテグレーション・フォーム（必須フィールドと値の例） — HashiCorp Vault ツール・インテグレーション

HashiCorp Vault をご利用いただくには、以下の情報が必要です：

名前: このツール統合の名前。この名前はツールチェーンに表示されます。
サーバー URL: HashiCorp Vault インスタンスのサーバー URL。例えば、https://<vault-service>.<org>.com:8200 です。
統合 URL: HashiCorp Vault 統合タイルをクリックした時のナビゲート先の URL。
シークレット・パス: HashiCorp Vault インスタンスでシークレットが保管されるマウント・パス。
認証方式: HashiCorp Vault インスタンスの認証方式。使用AppRole
役割 ID: 他の資格情報の評価に使用する AppRole を選択する ID。
シークレット ID ：secret_idを持つ）すべてのログインにデフォルトで必要で、常に秘密であることを意図するクレデンシャル。

これらのテンプレートには、 IBM® Key Protect for IBM Cloud® ツール統合も付属しています。

Key Protectツール統合フォーム（必須フィールドと値の例） — IBM Key Protectツール統合

role id と secret id を Key Protect に事前に保管している場合は、図 2 に示すように、ツール・カードにこれらのシークレットが含まれている Key Protect インスタンスを選択できます。それが終わったら、 HashiCorp Vault ツールカードのロール IDとシークレットID フィールドのキーアイコンをクリックし、ピッカーを使ってこれらのフィールドにシークレットを適用することができる。

同様に、ツールチェインで使用されるその他のシークレットにも、テキストフィールドに付随するキーアイコンがある。同じピッカーコントロールを使用して、残りのすべてのインスタンスに HashiCorp Vault シークレットを適用できます。

秘密を取り戻す IBM Cloud Secrets Manager

シークレットに安全にアクセスするには、 get_env コマンドを使用する。この方法は、秘密をログに残すことなく取得する。

サポート対象シークレット・タイプ

現在のところ、 Secrets Manager の環境プロパティから、以下の種類の秘密の取得をサポートしています：

任意
IAM 資格情報
キー値

使用方法：

  export SECRET_VALUE=$(get_env "secret_key" "")

この例では、次のようになっています。

secret_key は秘密の保存に使われる名前である。
SECRET_VALUE は、後で使用するために、取得した秘密値を保持する。

秘密のタイプに応じて、get_envは特定の値を取得する：

任意のシークレットの取得

  {
    "name": "my-secret",
    "secret_type": "arbitrary",
    ...
    "payload": "The quick brown fox jumped over the lazy dog."
  }

get_env が my-secret とともに使用された場合、 payload の値が取得される。

iam_credentials シークレットの取得

  {
    "name": "my-iam-credentials",
    "secret_type": "iam_credentials",
    ...
    "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
    "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
    "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be"
  }

get_env が my-iam-credentials と共に使われた場合、 api_key を検索する。

キー・バリューの取得シークレット

  {
    "name": "my-kv-secret",
    "secret_type": "key-value",
    ...
    "data": "{\"key\":\"value\"}"
  }

get_env が my-kv-secret と共に使われた場合、キーと値のペアの中にある value を検索する

ツールチェーンでのシークレットの管理

ツールチェーンでのシークレットの管理

DevSecOps パイプラインのシークレット

シークレット・ストアの構成

秘密を取り戻す IBM Cloud Secrets Manager

サポート対象シークレット・タイプ

使用方法：

任意のシークレットの取得

iam_credentials シークレットの取得

キー・バリューの取得 シークレット

キー・バリューの取得シークレット