シークレットについて
シークレットは、機密情報を組織、リポジトリ、リポジトリ環境に格納できるようにします。 シークレットは、組織、リポジトリ、またはリポジトリ環境 GitHub Actions ワークフローで使用するために作成する変数です。
GitHub Actions は、ワークフローにシークレットを明示的に含める場合にのみシークレットを読み取ることができます。
シークレットのしくみ
シークレット Libsodium シール ボックスを使用するため、 GitHubに到達する前に暗号化されます。 これは、シークレットが UI または REST API を使って送信されるときに行われます。 このクライアント側の暗号化は、 GitHubのインフラストラクチャ内の誤ったログ (例外ログや要求ログなど) に関連するリスクを最小限に抑えるのに役立ちます。 シークレットがアップロードされると、 GitHub は暗号化を解除して、ワークフロー ランタイムに挿入できるようになります。
組織レベルの機密情報
Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。
Organization のシークレットを作成する場合、ポリシーを使用して、リポジトリによるアクセスを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。
環境シークレットの場合、必要なレビュー担当者がシークレットへのアクセスを制御できるようにすることができます。 必須の承認者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。
アクションにシークレットを使用できるようにするには、ワークフロー ファイルに入力変数または環境変数としてシークレットを設定する必要があります。 アクションに必要な入力および環境変数については、アクションのREADMEファイルを確認します。 「GitHub Actions のワークフロー構文」を参照してください。
認証情報のアクセス許可を制限する
認証情報を生成する際には、可能な限り最小限の権限だけを許可することをおすすめします。 たとえば、個人の資格情報を使用する代わりに、デプロイ キーまたはサービス アカウントを使用します。 必要なのが読み取りだけであれば、読み取りのみの権限を許可すること、そしてアクセスをできるかぎり限定することを考慮してください。
personal access token (classic)を生成するときは、必要なスコープを最も少なく選択します。 fine-grained personal access tokenを生成するときに、必要な最小限のアクセス許可とリポジトリ アクセスを選択します。
personal access tokenを使用する代わりに、GitHub Appと同様に、きめ細かいアクセス許可と有効期間の短いトークンを使用するfine-grained personal access tokenの使用を検討してください。 personal access tokenとは異なり、GitHub Appはユーザーに関連付けられていないため、アプリをインストールしたユーザーが組織を離れた場合でもワークフローは引き続き機能します。 詳しくは、「GitHub Actions ワークフローでGitHub アプリを使用して認証済み API 要求を作成する」をご覧ください。
自動的にリダクトされたシークレット
GitHub Actions は、ワークフロー ログに出力されるすべての GitHub シークレットの内容を自動的に編集します。
GitHub Actions また、機密性の高い情報として認識されるが、シークレットとして格納されていない情報も編集します。 自動的にリダクトされたシークレットの一覧については、「シークレット リファレンス」を参照してください。
シークレットの値を変換する方法は複数あるため、このリダクトは保証されません。 さらに、ランナーは、現在のジョブ内で使用されるシークレットのみを編集できます。 そのため、シークレットを確実にリダクトし、シークレットに関連する他のリスクを制限するために従う必要がある、特定のセキュリティ予防手順があります。 シークレットに関するセキュリティのベスト プラクティスの参照リストについては、「シークレット リファレンス」をご覧ください。