デプロイキーの管理

デプロイメントのスクリプトを自動化する際にサーバー上のSSHキーを管理する様々な方法と、どれが最適な方法かを学んでください。

この記事で

SSHエージェントのフォワーディング、OAuthトークンでのHTTPS、デプロイキー、マシンユーザを使ってデプロイメントスクリプトを自動化する際に、サーバー上のSSHキーを管理できます。

SSHエージェントの転送

多くの場合、特にプロジェクトの開始時には、SSHエージェントのフォワーディングが最も素早くシンプルに使える方法です。 エージェントのフォワーディングでは、ローカルの開発コンピュータで使うのと同じSSHキーを使います。

SSH エージェント転送の長所

  • 新しいキーを生成したり追跡したりしなくていい。
  • キーの管理は不要。ユーザはローカルと同じ権限をサーバーでも持つ。
  • サーバーにキーは保存されないので、サーバーが侵害を受けた場合でも、侵害されたキーを追跡して削除する必要はない。

SSH エージェント転送の短所

  • ユーザーは、デプロイに SSH 接続する必要があります。自動デプロイ プロセスは使用できません。
  • SSH エージェントの転送は、Windows ユーザーに対して実行するのが面倒な場合があります。

SSH エージェント転送を設定する

  1. エージェントのフォワーディングをローカルでオンにしてください。 詳細については、SSH エージェントの転送に関するガイドを参照してください。
  2. エージェントフォワーディングを使用するように、デプロイスクリプトを設定してください。 たとえば、bash スクリプトでは、エージェントの転送を有効にすると、次のようになります: ssh -A serverA 'bash -s' < deploy.sh

OAuthトークンを使ったHTTPSでのクローニング

SSH キーを使用しない場合は、OAuth トークンで HTTPS を使用できます。

OAuth トークンを使った HTTPS でのクローニングの長所

  • サーバーにアクセスできる人なら、リポジトリをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • 複数のトークン（ユーザごと）が必要ない。サーバーごとに1つのトークンで十分。
  • トークンはいつでも取り消しできるので、本質的には使い捨てのパスワードにすることができる。

OAuth トークンを使った HTTPS でのクローニングの短所

  • トークンを確実に正しいアクセススコープで設定しなければならない。
  • トークンは本質的にはパスワードであり、パスワードと同じように保護しなければならない。

OAuth トークンを使った HTTPS でのクローニングを設定する

          [弊社のpersonal access token作成に関するガイドを参照してください。](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)

デプロイ キー

デプロイ キーを使用すると、GitHub.com のリポジトリからサーバーにプロジェクトを起動できます。デプロイ キーは、単一のリポジトリへのアクセス権を付与する SSH キーです。 GitHub は個人アカウントの代わりに、リポジトリに直接キーのパブリックな部分をアタッチし、キーのプライベートな部分はサーバーに残ります。 詳しくは、「デプロイメントを配信する」をご覧ください。

書き込みアクセス権を持つキーをデプロイすれば、管理アクセス権を持つOrganizationのメンバー、あるいは個人リポジトリのコラボレータと同じアクションを行えます。 詳細については、「Organizationのリポジトリロール」および「個人アカウントのリポジトリの権限レベル」を参照してください。

セキュリティを強化し、リポジトリのアクセスとアクセス許可をきめ細かく制御するために、代わりに GitHub アプリを使用することをお勧めします。 「GitHub アプリをビルドするタイミングを決定する」を参照してください。

デプロイ キーの長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • デプロイ キーは既定では読み取り専用ですが、リポジトリに追加するときに書き込みアクセス権を付与することができます。

デプロイ キーの短所

  • デプロイキーは単一のリポジトリに対するアクセスだけを許可できる。 より複雑なプロジェクトは、同じサーバーからプルする多くのリポジトリを持っていることがある。
  • デプロイキーは通常パスフレーズで保護されていないので、サーバーが侵害されると簡単にキーにアクセスされることになる。
  • デプロイ キーは、有効期限のない資格情報です。
  • デプロイ キーは、Organization のメンバーシップに直接リンクされません。 デプロイ キーは、特定のユーザーではなくリポジトリに関連付けられているため、デプロイ キーを作成したユーザーがリポジトリから削除されても、引き続きアクティブです。

デプロイ キーを設定する

メモ

Organization が Enterprise によって所有されていて、Enterprise 所有者がリポジトリ内のデプロイ キーの使用を制限している場合、Organization 内のポリシーをオーバーライドしてデプロイ キーを作成することはできません。 詳しくは、「Enterprise でリポジトリ管理ポリシーを適用する」をご覧ください。

  1. サーバーで ssh-keygen 手順を実行し、生成された公開キーと秘密 RSA キーのペアを保存する場所を覚えておいてください。

  2. GitHub で、リポジトリのメイン ページに移動します。

  3. リポジトリ名の下にある [Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  4. サイドバーにある [Deploy Keys] (キーのデプロイ) をクリックします。

  5.        **[Add deploy key]&nbsp;(デプロイ キーの追加)** をクリックします。

  6. [タイトル] フィールドにタイトルを入力します。

  7. [キー] フィールドに公開キーを貼り付けます。

  8. このキーにリポジトリへの書き込みアクセス権を付与する場合は、 [書き込みアクセスを許可する] を選択します。 書き込みアクセス権を持つデプロイキーを使うと、リポジトリにデプロイメントのプッシュができるようになります。

  9.        **[キーの追加]** をクリックします。

REST API を使用して、デプロイ キーを作成することもできます。 詳しくは、「デプロイ キー用の REST API エンドポイント」をご覧ください。

その後、SSH を使用してリポジトリを操作できます。 次に例を示します。

git clone git@github.com:OWNER/REPO.git

メモ

GitHubなどの別のドメインでoctocorp.ghe.comにアクセスする場合は、git@github.comをoctocorp@octocorp.ghe.comに置き換える必要があります。

git clone octocorp@octocorp.ghe.com:OWNER/REPO.git

1つのサーバー上で複数のリポジトリを利用する

1つのサーバー上で複数のリポジトリを使うなら、それぞれのリポジトリに対して専用のキーペアを生成しなければなりません。 複数のリポジトリでデプロイキーを再利用することはできません。

サーバーの SSH 構成ファイル (通常 ~/.ssh/config) に、各リポジトリのエイリアス エントリを追加します。 次に例を示します。

Host github.com-repo-0
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host github.com-repo-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

  •         `Host github.com-repo-0` - リポジトリのエイリアス。

  •         `Hostname github.com` - エイリアスで使用するホスト名を構成します。

  •         `IdentityFile=/home/user/.ssh/repo-0_deploy_key` - 秘密キーをエイリアスに割り当てます。

こうすれば、ホスト名のエイリアスを使ってSSHでリポジトリとやりとりできます。この場合、このエイリアスに割り当てられたユニークなデプロイキーが使われます。 次に例を示します。

git clone git@github.com-repo-1:OWNER/repo-1.git


          GitHub App インストール アクセス トークン

サーバーが 1 つ以上の組織のリポジトリにアクセスする必要がある場合は、GitHub Appを使用して必要なアクセスを定義し、その__ からGitHub Appのインストール アクセス トークンを生成できます。 インストール アクセス トークンは単一または複数のリポジトリをスコープとすることができ、アクセス許可を細かく設定できます。 たとえば、リポジトリのコンテンツへの読み取り専用アクセス権を持つトークンを生成できます。

          GitHub AppsはGitHubのファースト クラス アクターであるため、インストール アクセス トークンは任意のGitHub ユーザーから切り離されるため、"サービス トークン" に相当します。 さらに、インストール アクセス トークンには、実行される組織の規模に応じてスケーリングされる専用のレート制限があります。 詳細については、「[GitHub Appsのレート制限」を](/apps/creating-github-apps/setting-up-a-github-app/rate-limits-for-github-apps)参照してください。

インストール アクセス トークンの長所

  • 権限設定と有効期限 (1時間、またはAPIで手動で取り消された場合にはそれ以下) が明確に定義された、スコープが厳格なトークン。
  • 組織の規模に従って拡大する、独自のレート制限。
  •         GitHubユーザー ID から切り離されているため、ライセンス
  • パスワードが付与されないので、直接サインインされない。

インストール アクセス トークンの短所

  •         GitHub Appを作成するには、追加のセットアップが必要です。
  • インストール アクセス トークンは 1 時間後に期限切れになるので、再生成する必要がある (通常はコードを使用して、オンデマンドで行う)。

インストール アクセス トークンを設定する

  1.        GitHub Appをパブリックとプライベートのどちらにするかを決定します。 
       GitHub Appが組織内のリポジトリでのみ動作する場合は、プライベートにする必要があります。
  2. リポジトリの内容への読み取り専用アクセスなど、 GitHub App に必要なアクセス許可を決定します。
  3. 組織の設定ページで GitHub App を作成します。 詳細については、「GitHub Appの作成」を参照してください。
  4.        GitHub App
       `id`をメモします。

  5.        GitHub Appの秘密キーを生成してダウンロードし、安全に保存します。 詳細については、「[秘密キーを生成する](/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps)」を参照してください。
  6. 操作する必要があるリポジトリに GitHub App をインストールします。必要に応じて、組織内のすべてのリポジトリに GitHub App をインストールできます。
  7.        `installation_id`とアクセスできる組織リポジトリの間の接続を表すGitHub Appを特定します。 各 GitHub App と組織のペアには、最大で 1 つの `installation_id`があります。 「`installation_id`」を通じて[](/rest/apps/apps#get-an-organization-installation-for-the-authenticated-app)を識別できます。 これには、JWT を使用したGitHub Appとしての認証が必要です。詳細については、「[GitHub Appとしての認証](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app)」を参照してください。
  8. 対応する REST API エンドポイントを使用して、インストール アクセス トークンを生成します。「アプリのインストール アクセス トークンを作成する」を参照してください。 これには、JWT を使用したGitHub Appとしての認証が必要です。詳細については、「GitHub Appとしての認証」および「インストールとしての認証」を参照してください。
  9. このインストール アクセス トークンを使用して、REST または GraphQL API、あるいは Git クライアント経由でリポジトリとやり取りします。

詳しくは、「GitHub アプリのインストール アクセス トークンの生成」をご覧ください。

マシンユーザ

サーバーが複数のリポジトリにアクセスする必要がある場合は、 GitHub.com に新しいアカウントを作成し、自動化専用に使用される SSH キーをアタッチできます。 GitHub.comのこのアカウントは人間によって使用されないため、_マシン ユーザー_と呼ばれます。 マシン ユーザーを個人リポジトリの コラボレーター (読み取りと書き込みアクセス権の付与)、組織リポジトリの 外部コラボレーター (読み取り、書き込み、または管理者アクセス権の付与)、または自動化する必要があるリポジトリへのアクセス権を持つ チーム (チームのアクセス許可の付与) として追加できます。

ヒント

          [サービス使用条件][tos]の状態:

          _"ボット" またはその他の自動化された手段で "アカウント" を登録することは許可されていません。_

これは、アカウントの生成を自動化することはできないということです。 しかし、プロジェクトや組織内でデプロイスクリプトのような自動化タスクのために1つのマシンユーザを作成したいなら、それはまったく素晴らしいことです。

マシン ユーザーの長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • （人間の）ユーザがローカルのSSH設定を変更する必要がない。
  • 複数のキーは必要ない。サーバーごとに1つでよい。

マシン ユーザーの短所

  • 組織だけがマシンユーザをリードオンリーのアクセスにできる。 個人リポジトリは、常にコラボレータの読み書きアクセスを許可する。
  • マシンユーザのキーは、デプロイキーのように、通常パスフレーズで保護されない。

マシン ユーザーを設定する

  1. サーバーで ssh-keygen 手順を実行し、公開キーをマシン ユーザー アカウントにアタッチします。
  2. マシンユーザアカウントに自動化したいリポジトリへのアクセスを付与してください。 これを行うには、アカウントを コラボレーター として、外部コラボレーター として、または組織内の チーム に追加します。

参考資料

  •         [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/github-credential-types)

  •         [通知の構成](/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#organization-alerts-notification-options)