企業向け GitHub Actions について
GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。
GitHub Actionsを使用すると、企業はテストやデプロイなどのソフトウェア開発ワークフローを自動化、カスタマイズ、実行できます。 詳しくは、「[AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)」をご覧ください。
大規模な企業に GitHub Actions を導入する前に、まず導入を計画し、企業が独自のニーズを最適にサポートするために GitHub Actions をどのように使用するかを決定する必要があります。
ガバナンスとコンプライアンス
企業の GitHub Actions の使用を管理し、コンプライアンスの義務を満たす計画を作成する必要があります。
開発者が使用 許可されるアクションと再利用可能なワークフロー 決定します。 First、によって作成されなかったサードパーティのアクションおよび再利用可能なワークフローGitHubを許可するかどうかを決定します。 リポジトリ、組織、およびエンタープライズ レベルで実行できるアクション と再利用可能なワークフロー を構成でき、 GitHubによって作成されたアクションのみを許可するように選択できます。 サードパーティのアクション 再利用可能なワークフローを許可する場合は、許可されたアクションを、検証済みの作成者によって作成されたもの、または特定のアクション 再利用可能なワークフローの一覧に制限できます。
詳細については、「リポジトリのGitHub Actions設定の管理」、「組織のGitHub Actionsの無効化または制限」、「企業でGitHub Actionsのポリシーを適用する」を参照してください。
再利用可能なワークフローを OpenID Connect (OIDC) と組み合わせて、リポジトリ、Organization、または Enterprise 全体で一貫したデプロイを実施することを検討します。 これを行うには、再利用可能なワークフローに基づいてクラウド ロールの信頼条件を定義します。 詳しくは、「再利用可能なワークフローでの OpenID Connect の使用」をご覧ください。
企業の監査ログの GitHub Actions に関連するアクティビティに関する情報にアクセスできます。 ビジネス ニーズで監査ログ データが保持されるよりも長くこの情報を保持する必要がある場合は、 GitHubの外部でこのデータをエクスポートして格納する方法を計画します。 詳細については、「エンタープライズの監査ログ活動のエクスポート と 企業の監査ログのストリーミング.
GitHub Actions CI/CD パイプラインの設定にアクセスするためのカスタム組織ロールを管理することで、最小限の特権の原則を実践できます。 カスタム組織の役割の詳細については、「 [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)」を参照してください。
セキュリティ
GitHub Actionsのセキュリティ強化へのアプローチを計画する必要があります。
個々のワークフローとリポジトリのセキュリティ強化
企業内で GitHub Actions 機能を使用するユーザーに適切なセキュリティ プラクティスを適用する計画を立てる。 これらのプラクティスについて詳しくは、「セキュリティで保護された使用に関するリファレンス」を参照してください。
また、セキュリティについて既に評価済みのワークフローの再利用を推奨することもできます。 詳細については、「インナーソーシング」を参照してください。
シークレットとデプロイ リソースへのアクセスのセキュリティ保護
シークレットを保存する場所を計画する必要があります。 シークレットは GitHubに格納することをお勧めしますが、クラウド プロバイダーにシークレットを格納することもできます。
GitHubでは、リポジトリまたは組織レベルでシークレットを格納できます。 リポジトリ レベルのシークレットは、運用環境やテストなど、特定の環境のワークフローに限定できます。 詳しくは、「[AUTOTITLE](/actions/security-guides/encrypted-secrets)」をご覧ください。
機密性の高い環境については、手動の承認による保護の追加を検討する必要があります。そうすることで、ワークフローは環境のシークレットにアクセスする前に承認を受けることが必要になります。 詳しくは、「デプロイメント用の環境管理」をご覧ください。
サード パーティのアクションのセキュリティに関する考慮事項
GitHub上のサードパーティ リポジトリからアクションをソーシングする場合、重大なリスクがあります。 サード パーティのアクションを許可する場合は、アクションを完全なコミット SHA にピン止めするなどのベスト プラクティスに従うことをチームに促す内部ガイドラインを作成する必要があります。 詳しくは、「[AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)」をご覧ください。
GitHubホストランナーを使用したプライベート ネットワーク
Azure VNET での GitHub ホストランナーを使用できます。 これにより、ランナーのネットワーク ポリシーを完全に制御しながら、CI/CD の GitHub マネージド インフラストラクチャを利用することができます。 Azure VNET の詳細については、Azure ドキュメントの「[Azure Virtual Network とは](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview)」を参照してください。 詳細については、 [AUTOTITLE を](/admin/configuration/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise)参照してください。
インナーソーシング
企業が GitHub Actions の機能を使用して内部ソースの自動化を行う方法について考えてみましょう。 Innersourcing は、open source手法の利点を内部ソフトウェア開発サイクルに組み込む方法です。 詳細については、「 リソースの GitHub」を参照してください。
アクションを公開せずにエンタープライズ全体でアクションを共有するには、内部リポジトリにアクションを格納し、同じ組織またはエンタープライズ内の任意の組織が所有する他のリポジトリ内の GitHub Actions ワークフローへのアクセスを許可するようにリポジトリを構成します。 詳しくは、「アクションとワークフローを企業と共有する」をご覧ください。
再利用可能なワークフローを使用すると、チームはあるワークフローを別のワークフローから呼び出すことができ、完全な重複を回避できます。 再利用可能なワークフローは、適切に設計され、既にテスト済みのワークフローをチームが使用できるようにすることで、ベスト プラクティスを促進します。 詳しくは、「ワークフローを再利用する」をご覧ください。
新しいワークフローを構築するための出発点を開発者に提供するには、ワークフロー テンプレートを使用できます。 これにより、開発者の時間を節約できるだけでなく、企業全体の一貫性とベスト プラクティスが促進されます。 詳しくは、「組織のワークフロー テンプレートを作成する」をご覧ください。
リソースの管理
GitHub Actionsを使用するために必要なリソースを管理する方法を計画する必要があります。
ランナー
GitHub Actions ワークフローにはランナーが必要です。
GitHubホストランナーまたはセルフホステッド ランナーの使用を選択できます。
GitHub は、 GitHubホストランナーのメンテナンスとアップグレードを管理します。 詳しくは、「[AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners)」をご覧ください。
ランナー マシンの独自のリソース、構成、地域の場所を管理するには、セルフホステッド ランナーを使用します。 詳しくは、「セルフホステッド ランナー」をご覧ください。
ランナーのネットワーク ポリシーをより詳細に制御する場合は、セルフホステッド ランナーまたはプライベート ネットワーク オプションを GitHubホストランナーに使用します。 プライベート ネットワーク オプションの詳細については、「 GitHubホストランナーを使用したプライベート ネットワーク」を参照してください。
セルフホステッド ランナーを使用している場合は、物理マシン、仮想マシン、コンテナーのどちらを使用するかを決定する必要があります ジョブごとに新しいイメージを使うか、各ジョブの実行後にマシンをクリーンアップしない限り、物理マシンには以前のジョブの残存物が残りますが、仮想マシンも同様です。 コンテナーを選択した場合、ランナーの自動更新によってコンテナーがシャットダウンされ、ワークフローが失敗する可能性があることに注意する必要があります。 自動更新ができないようにするか、コンテナーを強制終了するコマンドをスキップすることで、これに対する解決策を考案する必要があります。
また、各ランナーを追加する場所も決定する必要があります。 セルフホステッド ランナーを個々のリポジトリに追加することも、Organization 全体または Enterprise 全体でランナーを使用可能にすることもできます。 Organization レベルまたは Enterprise レベルでランナーを追加すると、ランナーの共有が可能になります。これにより、ランナー インフラストラクチャのサイズが小さくなる可能性があります。 ポリシーを使用して、Organization および Enterprise レベルのセルフホステッド ランナーへのアクセスを制限できます。そのためには、特定のリポジトリまたは Organization にランナーのグループを割り当てます。 詳細については、「自己ホストランナーの追加」および「グループを使用してセルフホストランナーへのアクセスを管理する」を参照してください。 また、ポリシーを使用して、ユーザーがリポジトリレベルのセルフホステッド ランナーを使用するのを禁止することもできます。 詳しくは、「企業でGitHub Actionsのポリシーを適用する」をご覧ください。
自動スケールを使って、使用可能なセルフホステッド ランナーの数を自動的に増減することを検討する必要があります。 詳しくは、「セルフホステッド ランナー リファレンス」をご覧ください。
最後に、セルフホステッド ランナーのセキュリティ強化を検討する必要があります。 詳しくは、「セキュリティで保護された使用に関するリファレンス」をご覧ください。
Storage
成果物を使うと、ワークフロー内のジョブ間でデータを共有し、ワークフローが完了したときに、そのワークフローのデータを保存できるようになります。 詳細については、 [AUTOTITLE を](/actions/using-workflows/storing-workflow-data-as-artifacts)参照してください。
GitHub Actions には、依存関係をキャッシュしてワークフローの実行を高速化するために使用できるキャッシュ システムもあります。 詳しくは、「[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)」をご覧ください。
GitHub Actionsのポリシー設定を使用して、ワークフロー成果物、キャッシュ、およびログ保持のストレージをカスタマイズできます。 詳しくは、「[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)」をご覧ください。
一定のストレージがサブスクリプションに含まれていますが、追加のストレージは課金に影響します。 このコストについて計画する必要があります。 詳しくは、「GitHub Actions の課金」をご覧ください。
使用状況の追跡
ワークフローの実行頻度、それらの実行の成功と失敗の数、どのリポジトリがどのワークフローを使用しているかなど、企業の GitHub Actionsの使用状況を追跡する計画を立てる必要があります。
課金設定を使用して、企業内の各組織の GitHub Actions のストレージとデータ転送の使用状況の基本的な詳細を確認できます。 詳しくは、「従量制課金製品とライセンスの使用状況の表示」をご覧ください。
メモ
GitHub Actionsのエンタープライズ レベルのメトリックはパブリック プレビューであり、変更される可能性があります。
[Insights] タブで、企業の使用状況とパフォーマンス データの両方を表示できます。これらのメトリックは、リポジトリと組織レベルで使用できるのと同じ GitHub Actions データを提供しますが、企業全体に対して集計されます。 詳細な分析情報が必要な場合は、「 組織の GitHub Actions メトリックの表示 」または 「リポジトリの GitHub Actions メトリックの表示」を参照してください。
ジョブ単位またはワークフロー レベルごとの詳細な使用状況データについては Webhook を使用して、ワークフロー ジョブとワークフロー実行に関する情報をサブスクライブできます。 詳しくは、「webhook について」をご覧ください。
企業がこれらの Webhook からデータ アーカイブ システムに情報を渡す方法を計画し、チームがアーカイブ システムから必要なデータを取得できるようにする方法を計画します。