キーのデプロイ

GitLabでホストされているリポジトリにアクセスするには、デプロイキーを使用します。ほとんどの場合、ビルドサーバーや Continuous Integration(CI) サーバーのような内部ホストからリポジトリにアクセスするためにデプロイキーを使います。

ニーズによっては、デプロイトークンを使ってリポジトリにアクセスすることもできます。

属性デプロイキーデプロイトークン
共有複数のプロジェクト間、異なるグループ間でも共有可能。プロジェクトやグループに所属。
出典外部ホストで生成された公開SSHキー。GitLabインスタンス上で生成され、作成時のみユーザーに提供されます。
アクセス可能なリソースSSH経由のGitリポジトリHTTP経由のGitリポジトリ、パッケージレジストリ、コンテナレジストリ。

外部認証が有効になっている場合は、デプロイキーを Git のオペレーションに使用することはできません。

スコープ

デプロイキーには、作成時に定義されたスコープがあります：

  • プロジェクト・デプロイ・キー：プロジェクト配備キー：選択したプロジェクトに限定されます。
  • 公開デプロイキー：GitLabインスタンス内の_どの_プロジェクトにもアクセスを許可することができます。各プロジェクトへのアクセスは、少なくともメンテナーのロールを持つユーザーによって付与されなければなりません。

作成後にデプロイキーのスコープを変更することはできません。

権限

デプロイキーには、作成時に権限レベルが与えられます：

  • 読み取り専用：読み取り専用：読み取り専用のデプロイキーは、リポジトリからの読み取りしかできません。
  • 読み書き：読み書き可能なデプロイキーは、リポジトリからの読み込みとリポジトリへの書き込みができます。

デプロイキーの権限レベルは、作成後に変更できます。プロジェクトのデプロイキーの権限を変更することは、現在のプロジェクトにのみ適用されます。

Git-commandが追加の処理をトリガーする場合、GitLabはデプロイキーの作成者に権限を与えます。例えば

  • デプロイキーを使って保護されたブランチにコミットをプッシュする場合、デプロイキーの_作成_者はそのブランチにアクセスできなければなりません。
  • デプロイキーがCI/CDパイプラインをトリガーするコミットをプッシュするために使用される場合、デプロイキーの_作成_者は、保護された環境や秘密変数を含むCI/CDリソースへのアクセス権を持っていなければなりません。

セキュリティの意味

デプロイ鍵の想定されるユースケースは、GitLabと人間以外がやりとりする場合です。例えば、組織内のサーバーで実行される自動化スクリプトなどです。すべての機密情報と同様に、その秘密にアクセスする必要がある人だけがそれを読めるようにしなければなりません。人間同士のやり取りには、Personal Access Token のようなユーザーに紐づいた認証情報を使いましょう。

秘密漏えいの可能性を検出するには、監査イベント機能を使用します。

caution
デプロイ キーは、作成したユーザーがグループやプロジェクトから削除されても機能します。

デプロイキーを見る

プロジェクトで利用可能なデプロイキーを表示します：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定] > [リポジトリ]を選択します。
  3. デプロイキーを展開します。

利用可能なデプロイキーが一覧表示されます：

  • 有効なデプロイ キー：プロジェクトにアクセスできるデプロイキー。
  • 非公開のデプロイ鍵：プロジェクトにアクセスできないプロジェクトデプロイキー。
  • 公開アクセス可能なデプロイ鍵：プロジェクトにアクセスできない公開デプロイ鍵。

プロジェクトデプロイキーの作成

前提条件：

  • 少なくともプロジェクトのメンテナーのロールを持っている必要があります。
  • SSH キーペアを生成します。リポジトリへのアクセスが必要なホストに SSH 秘密鍵を置きます。
  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定] > [リポジトリ]を選択します。
  3. デプロイキーを展開します。
  4. Add new keyを選択します。
  5. 各項目を入力してください。
  6. オプション。read-write 権限を付与するには、［このキーに書き込み権限を付与する］チェックボックスを選択します。
  7. オプション。有効期限を更新します。

プロジェクト デプロイ キーは、作成時に有効になります。プロジェクト デプロイ キーの名前と権限のみを変更できます。

公開デプロイ鍵の作成

前提条件：

  • インスタンスへの管理者アクセス権が必要です。
  • SSHキー・ペアを生成する必要があります。
  • リポジトリへのアクセスが必要なホストに SSH 秘密鍵を置く必要があります。

公開デプロイキーを作成するには：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. キーのデプロイを選択します。
  4. 新しいデプロイキーを選択します。
  5. 各項目を入力してください。
    • 名前］には意味のある説明を使用します。たとえば、公開デプロイ鍵を使用する外部ホストまたはアプリケーションの名前を含めます。

公開デプロイ鍵の名前のみを変更できます。

公開デプロイ鍵へのプロジェクト・アクセスの許可

前提条件：

  • 少なくともプロジェクトのメンテナーのロールを持っている必要があります。

公開デプロイ鍵をプロジェクトにアクセスできるようにするには、以下の手順に従います：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定] > [リポジトリ]を選択します。
  3. デプロイキーを展開します。
  4. 公開アクセス可能なデプロイ鍵を選択します。
  5. キーの行で、［Enable］を選択します。
  6. 公開デプロイ鍵に読み取り/書き込み権限を付与します：
    1. キーの行で「編集」（{pencil}）を選択します。
    2. このキーに書き込み権限を与える］チェックボックスをオンにします。

デプロイ・キーのプロジェクト・アクセス権限の編集

前提条件：

  • 少なくともプロジェクトのメンテナーのロールを持っている必要があります。

デプロイキーのプロジェクトアクセス権限を編集するには

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定] > [リポジトリ]を選択します。
  3. デプロイキーを展開します。
  4. キーの行で「編集」（{pencil}）を選択します。
  5. このキーに書き込み権限を与える］チェックボックスをオンまたはオフにします。

デプロイ キーのプロジェクト アクセスを取り消します。

プロジェクトに対するデプロイキーのアクセス権を取り消すには、そのキーを無効にします。キーを無効にすると、デプロイ キーに依存するサービスはすべて機能しなくなります。

前提条件：

  • 少なくともプロジェクトのメンテナーのロールを持っている必要があります。

デプロイキーを無効にするには

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定] > [リポジトリ]を選択します。
  3. デプロイキーを展開します。
  4. Disable({cancel})を選択します。

デプロイキーが無効化されるとどうなるかは、以下によって異なります：

  • キーが公開されている場合、プロジェクトからは削除されますが、[Publicly accessible deploy keys]タブでは引き続き使用できます。
  • 秘密鍵が非公開で、このプロジェクトでのみ使用されている場合は、削除されます。
  • 秘密鍵が非公開で他のプロジェクトでも使用されている場合、その鍵はプロジェクトから削除されますが、[Privately accessible deploy keys]タブではまだ使用できます。

トラブルシューティング

デプロイキーを保護ブランチにプッシュできません

デプロイキーを保護ブランチにプッシュできない場合があります。

すべてのデプロイキーはアカウントに関連付けられています。アカウントの権限が変更される可能性があるため、これまで動作していたデプロイキーが突然保護ブランチにプッシュできなくなる可能性があります。

デプロイキーを使用するプロジェクトでは、サービスアカウントを作成し、デプロイキーをサービスアカウントに関連付けることをお勧めします。

非会員およびブロックされたユーザーに関連付けられたデプロイ キーの確認

非会員またはブロックされたユーザーのキーを見つける必要がある場合は、Railsコンソールを使用して、次のようなスクリプトを使用して使用できないデプロイキーを特定できます：

ghost_user_id = Users::Internal.ghost.id

DeployKeysProject.with_write_access.find_each do |deploy_key_mapping|
  project = deploy_key_mapping.project
  deploy_key = deploy_key_mapping.deploy_key
  user = deploy_key.user

  access_checker = Gitlab::DeployKeyAccess.new(deploy_key, container: project)

  # can_push_for_ref? tests if deploy_key can push to default branch, which is likely to be protected
  can_push = access_checker.can_do_action?(:push_code)
  can_push_to_default = access_checker.can_push_for_ref?(project.repository.root_ref)

  next if access_checker.allowed? && can_push && can_push_to_default

  if user.nil? || user.id == ghost_user_id
    username = 'none'
    state = '-'
  else
    username = user.username
    user_state = user.state
  end

  puts "Deploy key: #{deploy_key.id}, Project: #{project.full_path}, Can push?: " + (can_push ? 'YES' : 'NO') +
       ", Can push to default branch #{project.repository.root_ref}?: " + (can_push_to_default ? 'YES' : 'NO') +
       ", User: #{username}, User state: #{user_state}"
end