{"meta":{"title":"シークレット","intro":"GitHub Actionsワークフローで使用されるシークレットについて説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/concepts","title":"概念"},{"href":"/ja/actions/concepts/security","title":"セキュリティ"},{"href":"/ja/actions/concepts/security/secrets","title":"シークレット"}],"documentType":"article"},"body":"# シークレット\n\nGitHub Actionsワークフローで使用されるシークレットについて説明します。\n\n## シークレットについて\n\nシークレットは、機密情報を組織、リポジトリ、リポジトリ環境に格納できるようにします。 シークレットは、組織、リポジトリ、またはリポジトリ環境 GitHub Actions ワークフローで使用するために作成する変数です。\n\nGitHub Actions は、ワークフローにシークレットを明示的に含める場合にのみシークレットを読み取ることができます。\n\n## シークレットのしくみ\n\nシークレット [Libsodium シール ボックス](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes)を使用するため、 GitHubに到達する前に暗号化されます。 これは、シークレットが [UI](/ja/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets#creating-secrets-for-a-repository) または [REST API](/ja/rest/actions/secrets) を使って送信されるときに行われます。 このクライアント側の暗号化は、 GitHubのインフラストラクチャ内の誤ったログ (例外ログや要求ログなど) に関連するリスクを最小限に抑えるのに役立ちます。 シークレットがアップロードされると、 GitHub は暗号化を解除して、ワークフロー ランタイムに挿入できるようになります。\n\n## 組織レベルの機密情報\n\nOrganizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。\n\nOrganization のシークレットを作成する場合、ポリシーを使用して、リポジトリによるアクセスを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。\n\n環境シークレットの場合、必要なレビュー担当者がシークレットへのアクセスを制御できるようにすることができます。 必須の承認者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。\n\nアクションにシークレットを使用できるようにするには、ワークフロー ファイルに入力変数または環境変数としてシークレットを設定する必要があります。 アクションに必要な入力および環境変数については、アクションのREADMEファイルを確認します。 「[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsenv)」を参照してください。\n\n## 認証情報のアクセス許可を制限する\n\n認証情報を生成する際には、可能な限り最小限の権限だけを許可することをおすすめします。 たとえば、個人の資格情報を使用する代わりに、[デプロイ キー](/ja/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys)またはサービス アカウントを使用します。 必要なのが読み取りだけであれば、読み取りのみの権限を許可すること、そしてアクセスをできるかぎり限定することを考慮してください。\n\npersonal access token (classic)を生成するときは、必要なスコープを最も少なく選択します。\nfine-grained personal access tokenを生成するときに、必要な最小限のアクセス許可とリポジトリ アクセスを選択します。\n\npersonal access tokenを使用する代わりに、GitHub Appと同様に、きめ細かいアクセス許可と有効期間の短いトークンを使用するfine-grained personal access tokenの使用を検討してください。\npersonal access tokenとは異なり、GitHub Appはユーザーに関連付けられていないため、アプリをインストールしたユーザーが組織を離れた場合でもワークフローは引き続き機能します。 詳しくは、「[GitHub Actions ワークフローでGitHub アプリを使用して認証済み API 要求を作成する](/ja/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)」をご覧ください。\n\n## 自動的にリダクトされたシークレット\n\nGitHub Actions は、ワークフロー ログに出力されるすべての GitHub シークレットの内容を自動的に編集します。\n\nGitHub Actions また、機密性の高い情報として認識されるが、シークレットとして格納されていない情報も編集します。 自動的にリダクトされたシークレットの一覧については、「[シークレット リファレンス](/ja/actions/reference/security/secrets#automatically-redacted-secrets)」を参照してください。\n\nシークレットの値を変換する方法は複数あるため、このリダクトは保証されません。 さらに、ランナーは、現在のジョブ内で使用されるシークレットのみを編集できます。 そのため、シークレットを確実にリダクトし、シークレットに関連する他のリスクを制限するために従う必要がある、特定のセキュリティ予防手順があります。 シークレットに関するセキュリティのベスト プラクティスの参照リストについては、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/reference/security/secure-use#use-secrets-for-sensitive-information)」をご覧ください。\n\n## 参考資料\n\n* [GitHub Actions でのシークレットの使用](/ja/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)\n* [GitHub Actions シークレットの REST API エンドポイント](/ja/rest/actions/secrets)"}