GitHub Actions
の外部ストレージについて
GitHub Actions は、外部 BLOB ストレージを使って、ワークフローの実行によって生成されたデータを格納します。 格納されるデータには、ワークフローのログ、キャッシュ、およびユーザーがアップロードしたビルド成果物が含まれます。 詳細については、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。
外部ストレージ プロバイダーに接続するように GitHub Enterprise Server を構成するには、次の 2 つのオプションがあります。
- OpenID Connect (OIDC)
- シークレットを使った従来の資格情報ベースの認証
機密性が高く有効期間が長い資格情報シークレットを作成または管理したり、公開してリスクを発生させたりする必要がないため、可能であれば OIDC を使うことをお勧めします。 OIDC で信頼を定義すると、クラウド ストレージ プロバイダーによって、お使いの GitHub Enterprise Server インスタンス へのアクセス トークンが自動的に発行されます。このアクセス トークンは、有効期間が短く、自動的に期限が切れます。
前提条件
Note
GitHub でサポートされている S3 ストレージ プロバイダーは、Amazon S3 と MinIO Gateway for NAS のみです。
GitHub パートナーが GitHub Enterprise Server 上で GitHub Actions を操作していると自己検証している S3 API 互換ストレージ製品は他にもあります。 詳細については、GHES ストレージ パートナー リポジトリを参照してください。
GitHub テクノロジ パートナーシップ プログラムを通じて検証されたストレージ製品の場合、ストレージ プロバイダーは、GitHub Actions でストレージ製品を使用するためのサポートとドキュメントを担当します。
GitHub Actions を有効化する前に、次のステップを完了していることを確認してください。
-
ワークフローの実行によって生成されるデータを保存するための Amazon S3 バケットを作成します。
-
GitHub Actionsのためのハードウェア要件をレビューしてください。 詳しくは、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。
-
TLS は、GitHub Enterprise Server のドメインに構成されている必要があります。 詳しくは、「TLSの設定」を参照してください。
Note
信頼された認証局によって署名された証明書でGitHub Enterprise Server上のTLSを設定することを強くおすすめします。 自己署名証明書でも動作はしますが、セルフホストランナーに追加の設定が必要になり、プロダクションの環境では推奨されません。
-
GitHub に HTTP プロキシ サーバーが構成されている場合
-
HTTP プロキシ除外リストに
.localhost
、127.0.0.1
、::1
を追加 (この順序で) する必要があります。 -
ご利用の外部ストレージの場所がルーティング不可能である場合は、該当する外部ストレージ URL も、除外リストに追加する必要があります。
プロキシ設定の変更については、「アウトバウンドの Web プロキシ サーバーの設定」を参照してください。
-
ストレージ プロバイダーへの接続に OIDC を使っている場合は、お使いの GitHub Enterprise Server インスタンス 上の次の OIDC トークン サービス URL をパブリック インターネットに公開する必要があります。
https://HOSTNAME/_services/token/.well-known/openid-configuration https://HOSTNAME/_services/token/.well-known/jwks
これにより、ストレージ プロバイダーは、認証のために お使いの GitHub Enterprise Server インスタンス に接続できるようになります。
OIDC を使用する Amazon S3 での GitHub Actions の有効化 (推奨)
Amazon S3 バケットで OIDC を使うように GitHub Enterprise Server を構成するには、まず Amazon OIDC プロバイダーを作成してから、ID およびアクセス管理 (IAM) ロールを作成し、最後にそのプロバイダーとロールを使って S3 バケットにアクセスするように GitHub Enterprise Server を構成する必要があります。
1. Amazon OIDC プロバイダーを作成する
-
お使いの GitHub Enterprise Server インスタンス の拇印を取得します。
-
次の OpenSSL コマンドを使って お使いの GitHub Enterprise Server インスタンス の SHA1 拇印を取得します。
HOSTNAME
は お使いの GitHub Enterprise Server インスタンス のパブリック ホスト名に置き換えますShell openssl s_client -connect HOSTNAME:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -sha1 -in /dev/stdin
openssl s_client -connect HOSTNAME:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -sha1 -in /dev/stdin
次に例を示します。
openssl s_client -connect my-ghes-host.example.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -sha1 -in /dev/stdin
コマンドからは、次の形式で拇印が返されます。
SHA1 Fingerprint=AB:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56
-
拇印の値からコロン (
:
) を削除し、後で使うために値を保存しておきます。たとえば、前の手順で返された値の拇印は次のようになります。
AB1234567890ABCDEF1234567890ABCDEF123456
-
-
AWS CLI を使い、次のコマンドを使用して お使いの GitHub Enterprise Server インスタンス の OIDC プロバイダーを作成します。
HOSTNAME
を お使いの GitHub Enterprise Server インスタンス のパブリック ホスト名に置き換え、THUMBPRINT
を前の手順の拇印の値に置き換えてください。Shell aws iam create-open-id-connect-provider \ --url https://HOSTNAME/_services/token \ --client-id-list "sts.amazonaws.com" \ --thumbprint-list "THUMBPRINT"
aws iam create-open-id-connect-provider \ --url https://HOSTNAME/_services/token \ --client-id-list "sts.amazonaws.com" \ --thumbprint-list "THUMBPRINT"
次に例を示します。
Shell aws iam create-open-id-connect-provider \ --url https://my-ghes-host.example.com/_services/token \ --client-id-list "sts.amazonaws.com" \ --thumbprint-list "AB1234567890ABCDEF1234567890ABCDEF123456"
aws iam create-open-id-connect-provider \ --url https://my-ghes-host.example.com/_services/token \ --client-id-list "sts.amazonaws.com" \ --thumbprint-list "AB1234567890ABCDEF1234567890ABCDEF123456"
AWS CLI のインストールについて詳しくは、Amazon のドキュメントを参照してください。
Warning
お使いの GitHub Enterprise Server インスタンス の証明書が今後変更される場合、OIDC の信頼を引き続き機能させるには、Amazon OIDC プロバイダーで拇印の値を更新する必要があります。
2. IAM ロールを作成する
-
AWS コンソールを開き、ID およびアクセス管理 (IAM) サービスに移動します。
-
左側のメニューで、[アクセス管理] の下にある [ロール] をクリックし、 [ロールの作成] をクリックします。
-
[信頼されたエンティティの選択] ページで、次のオプションを選択します。
- [信頼されたエンティティの種類] で、 [ウェブ ID] をクリックします。
- [ID プロバイダー] で、 [プロバイダーの選択] ドロップダウン メニューを使用し、前の手順で作成した OIDC プロバイダーを選択します。
HOSTNAME/_services/token
という名前が付いているはずです。ここで、HOSTNAME
は お使いの GitHub Enterprise Server インスタンス のパブリック ホスト名です。 - [対象者] で、
sts.amazonaws.com
を選択します。
-
[次へ] をクリックします。
-
[Add permissions] ページで、フィルターを使って
AmazonS3FullAccess
ポリシーを検索し、選択します。 -
[次へ] をクリックします。
-
[名前、確認、および作成] ページで、ロールの名前を入力し、 [ロールを作成] をクリックします。
-
IAM の [ロール] ページで、先ほど作成したロールを選択します。
-
[概要] で、ロールの ARN 値をメモしておきます。これは後で必要になります。
-
[信頼関係] タブをクリックし、 [信頼ポリシーの編集] をクリックします。
-
信頼ポリシーを編集して、新しい
sub
クレームを追加します。Condition
の値は次の例と一致している必要があります。HOSTNAME
は お使いの GitHub Enterprise Server インスタンス のパブリック ホスト名に置き換えてください。... "Condition": { "StringEquals": { "HOSTNAME/_services/token:aud": "sts.amazonaws.com", "HOSTNAME/_services/token:sub": "HOSTNAME" } } ...
次に例を示します。
... "Condition": { "StringEquals": { "my-ghes-host.example.com/_services/token:aud": "sts.amazonaws.com", "my-ghes-host.example.com/_services/token:sub": "my-ghes-host.example.com" } } ...
-
[ポリシーの更新] をクリックします。
3. OIDC を使って Amazon S3 に接続するように GitHub Enterprise Server を構成する
-
GitHub Enterprise Server の管理アカウントから、任意のページの右上隅で をクリックします。
-
[サイト管理者] ページにまだ表示されていない場合は、左上隅の [サイト管理者] をクリックします。
-
[ サイト管理者] サイドバーで [Management Console] をクリックします。
-
[設定] サイドバーで [Actions] をクリックします。
-
[GitHub Actions] で、 [GitHub Actions を有効にする] を選びます。
-
[Amazon S3] の横にある [成果物とログ ストレージ] で、 [セットアップ] をクリックします。
-
[認証] で、 [OpenID Connect (OIDC)] を選び、ストレージの値を入力します。
- [AWS S3 Bucket](AWS S3 バケット) : S3 バケットの名前。
- [AWS ロール] : 前の手順で作成したロールの ARN。 たとえば、「
arn:aws:iam::123456789:role/my-role-name
」のように入力します。 - [AWS リージョン] : バケットの AWS リージョン。 たとえば、「
us-east-1
」のように入力します。
-
[ストレージ設定のテスト] ボタンをクリックして、ストレージ設定を検証します。
ストレージ設定の検証でエラーが発生した場合は、ストレージ プロバイダーで設定を確認し、もう一度やり直してください。
-
[設定] サイドバーで [設定の保存] をクリックします。
Note
[Management Console] で設定を保存すると、システム サービスが再起動され、ユーザーにわかるダウンタイムが発生する可能性があります。
-
設定の実行が完了するのを待ってください。
アクセス キーを使って Amazon S3 ストレージで GitHub Actions を有効にする
-
AWS コンソールまたは CLI を使って、ストレージ バケット用のアクセス キーを作成します。 GitHub Actionsは、バケットにアクセスするアクセスキーのために以下の権限を必要とします。
s3:PutObject
s3:GetObject
s3:ListBucketMultipartUploads
s3:ListMultipartUploadParts
s3:AbortMultipartUpload
s3:DeleteObject
s3:ListBucket
kms:GenerateDataKey
(キー管理サービス (KMS) の暗号化が有効な場合)kms:Decrypt
(キー管理サービス (KMS) の暗号化が有効な場合)
AWS アクセス キーの管理について詳しくは、「AWS Identity and Access Management のドキュメント」をご覧ください。
-
GitHub Enterprise Server の管理アカウントから、任意のページの右上隅で をクリックします。
-
[サイト管理者] ページにまだ表示されていない場合は、左上隅の [サイト管理者] をクリックします。
-
[ サイト管理者] サイドバーで [Management Console] をクリックします。
-
[設定] サイドバーで [Actions] をクリックします。
-
[GitHub Actions] で、 [GitHub Actions を有効にする] を選びます。
-
[Amazon S3] の横にある [成果物とログ ストレージ] で、 [セットアップ] をクリックします。
-
[認証] で、 [資格情報ベース] を選び、次のようにストレージ バケットの詳細を入力します。
-
AWS サービス URL: バケットのサービス URL。 たとえば、S3 バケットが
us-west-2
領域で作成された場合、この値はhttps://s3.us-west-2.amazonaws.com
になるはずです。詳細については、AWS ドキュメントの「AWS サービス エンドポイント」を参照してください。
-
[AWS S3 Bucket](AWS S3 バケット) : S3 バケットの名前。
-
AWS S3 Access Key and AWS S3 Secret Key: バケットのための AWS アクセス キー ID とシークレット キー。
-
-
[ストレージ設定のテスト] ボタンをクリックして、ストレージ設定を検証します。
ストレージ設定の検証でエラーが発生した場合は、ストレージ プロバイダーで設定を確認し、もう一度やり直してください。
-
[設定] サイドバーで [設定の保存] をクリックします。
Note
[Management Console] で設定を保存すると、システム サービスが再起動され、ユーザーにわかるダウンタイムが発生する可能性があります。
-
設定の実行が完了するのを待ってください。
次のステップ
設定の実行が正常に完了すると、GitHub Actions は GitHub 上で有効になります。 次の手順 (GitHub Actionsのアクセス許可の管理、セルフホステッド ランナーの追加など) については、「GitHub Enterprise Server の GitHub Actions を使い始める」に戻ります。