シークレットについて

シークレットについて

シークレットは、機密情報を組織、リポジトリ、リポジトリ環境に格納できるようにします。 シークレットは、organization、リポジトリ、またはリポジトリ環境の GitHub Actions ワークフローで使うために作成する変数です。

GitHub Actions でシークレットを読み取ることができるのは、シークレットをワークフローに明示的に含める場合のみです。

シークレットに名前を付ける

シークレットの名前には次のルールが適用されます。

• 英数字 ([a-z]、[A-Z]、[0-9]) またはアンダースコア (_) のみを含めることができます。 スペースは使用できません。
• GITHUB_ プレフィックスで始めることはできません。
• 最初を数字にすることはできません。
• 大文字と小文字の区別はされません。
• 作成されたリポジトリ、organization、または Enterprise に固有のものにする必要があります。

複数のレベルで同じ名前のシークレットが存在する場合、最も低いレベルのシークレットが優先されます。 たとえば、Organization レベルのシークレット名がリポジトリレベルのシークレット名と同じ場合、リポジトリレベルのシークレット名が優先されます。 同様に、組織、リポジトリ、環境がすべて同じ名前のシークレットを持つ場合、環境レベルのシークレットが優先されます。

ワークフローでシークレットを使う

Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。

環境シークレットの場合、必要なレビュー担当者がシークレットへのアクセスを制御できるようにすることができます。 必須の承認者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。

アクションにシークレットを使用できるようにするには、ワークフロー ファイルに入力変数または環境変数としてシークレットを設定する必要があります。 アクションに必要な入力および環境変数については、アクションのREADMEファイルを確認します。 「GitHub Actions　のワークフロー構文」を参照してください。

Organization及びリポジトリのシークレットはワークフローの実行がキューイングされた時点で読まれ、環境のシークレットは環境を参照しているジョブが開始された時点で読まれます。

認証情報のアクセス許可を制限する

認証情報を生成する際には、可能な限り最小限の権限だけを許可することをおすすめします。 たとえば、個人の資格情報を使用する代わりに、デプロイ キーまたはサービス アカウントを使用します。 必要なのが読み取りだけであれば、読み取りのみの権限を許可すること、そしてアクセスをできるかぎり限定することを考慮してください。

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 Actions シークレットの REST API エンドポイント