シークレットについて
シークレットは、機密情報を組織、リポジトリ、リポジトリ環境に格納できるようにします。 シークレットは、organization、リポジトリ、またはリポジトリ環境の GitHub Actions ワークフローで使うために作成する変数です。
GitHub Actions でシークレットを読み取ることができるのは、シークレットをワークフローに明示的に含める場合のみです。
Organization レベルのシークレット
Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。
Organization のシークレットを作成する場合、ポリシーを使用して、リポジトリによるアクセスを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。
環境シークレットの場合、必要なレビュー担当者がシークレットへのアクセスを制御できるようにすることができます。 必須の承認者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。
アクションにシークレットを使用できるようにするには、ワークフロー ファイルに入力変数または環境変数としてシークレットを設定する必要があります。 アクションに必要な入力および環境変数については、アクションのREADMEファイルを確認します。 「Workflow syntax for 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」を参照してください。
メモ
他の種類の機密情報を自動的に編集する場合は、に関するディスカッションで Microsoft にお問い合わせください。
ベスト プラクティスの習慣として、::add-mask::VALUEを使用して、GitHub シークレットではないすべての機密情報をマスクする必要があります。 これにより、値がシークレットとして扱われ、ログから編集されます。 データのマスキングの詳細については、「Workflow commands for GitHub Actions」を参照してください。
シークレットの編集は、ワークフロー ランナーによって実行されます。 つまり、シークレットはジョブ内で使用され、実行者によりアクセス可能である場合のみ編集されます。 未変換のシークレットがワークフロー実行ログに送信される場合は、ログを削除してシークレットをローテーションする必要があります。 ログの削除の詳細については、「Using workflow run logs」を参照してください。