シークレットについて
シークレットは、機密情報を組織、リポジトリ、リポジトリ環境に格納できるようにします。 シークレットは、organization、リポジトリ、またはリポジトリ環境の GitHub Actions ワークフローで使うために作成する変数です。
GitHub Actions でシークレットを読み取ることができるのは、シークレットをワークフローに明示的に含める場合のみです。
Organization レベルのシークレット
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 App を使用して認証済み API 要求を作成する」をご覧ください。
自動的にリダクトされたシークレット
GitHub Actions は、ワークフロー ログに出力されるすべての GitHub シークレットの内容を自動的に編集します。
GitHub Actions は、機密性の高い情報として認識されますが、シークレットとして格納されていない情報も編集します。 自動的にリダクトされたシークレットの一覧については、「Secrets reference」を参照してください。
シークレットの値を変換する方法は複数あるため、このリダクトは保証されません。 さらに、ランナーは、現在のジョブ内で使用されるシークレットのみを編集できます。 そのため、シークレットを確実にリダクトし、シークレットに関連する他のリスクを制限するために従う必要がある、特定のセキュリティ予防手順があります。 シークレットに関するセキュリティのベスト プラクティスの参照リストについては、「Secrets reference」をご覧ください。