注意：

Question

gitlab部署密钥是否只读？我需要使用部署密钥在ci服务器上克隆，然后推送由ci进程创建的标记。可以使用部署密钥吗？

Answer 1

Edit2：此更改目前有副作用，因为部署密钥上没有用户。所以你会发现一些丑陋的消息，如ERROR -> POST-RECEIVE: Triggered hook for non-existing user。因此，在通过部署密钥进行写入推送时不会处理缓存失效（以及可能的其他事情），这有点难看。 bundle exec rake cache:clear RAILS_ENV=production是您的朋友，直到我找到解决方法（请参阅下面的GitHub链接） - 请记住，清除Redis缓存也会注销所有用户。

以下是基于每个键进行归档的简短解决方法：

只读My SSH keys。这允许添加具有对帐户的所有存储库的只读访问权限的计算机。如果您使用git子项目的火车，那就很好。
在开发人员级别上对Deploy-Keys进行读写。
在主级别上进行Deploy-Keys读写。

这是通过在键的标题前添加一些特殊字符来存档的：

*只能My SSH keys只读
!使Deploy-Keys读写
!!使Deploy-Keys成为主（写入受保护的分支）

因此，将密钥命名为“我的全局密钥”，将其命名为“* my global readonly key”等。

diff --git a/lib/api/internal.rb b/lib/api/internal.rb
index ed6b50c..ce350b1 100644
--- a/lib/api/internal.rb
+++ b/lib/api/internal.rb
@@ -30,7 +30,11 @@ module API


         if key.is_a? DeployKey
-          key.projects.include?(project) && DOWNLOAD_COMMANDS.include?(git_cmd)
+return false unless key.projects.include?(project)
+return true if DOWNLOAD_COMMANDS.include?(git_cmd)
+return true if key.title.start_with? '!!'
+return false if project.protected_branch?(params[:ref])
+key.title.start_with? '!'
         else
           user = key.user

@@ -42,6 +46,7 @@ module API
                      then :download_code
                    when *PUSH_COMMANDS
                      then
+return false if key.title.start_with? '*' # VAHI 2014-02-09
                      if project.protected_branch?(params[:ref])
                        :push_code_to_protected_branches
                      else

修改1：此修补程序现已在GitHub上以cherry-pick格式提供，请参阅https://github.com/hilbix/gitlabhq/wiki

Edit3 ：如果您推送部署密钥，也可能需要以下解决方法。这并不完美，因为它不会触发所有这些钩子，但它使缓存失效，使得网页不再显示陈旧数据：

diff --git a/app/workers/post_receive.rb b/app/workers/post_receive.rb
index 6416aa6..2fe98d4 100644
--- a/app/workers/post_receive.rb
+++ b/app/workers/post_receive.rb
@@ -26,6 +26,8 @@ class PostReceive

     unless user
       log("Triggered hook for non-existing user \"#{identifier} \"")
+      project.ensure_satellite_exists
+      project.repository.expire_cache
       return false
     end

仍然存在一些问题：

次要的，您不能同时在帐户级别和部署级别使用相同的密钥。因此，对于仅在全局范围内具有只读访问权限的密钥（可能是使用的默认密钥），您需要第二个特殊的“仅推送”密钥，该密钥允许推送访问存储库。

编辑3：部署密钥没有附加用户的主要部分，因此所有便利工作都不起作用。如果这对您来说是个问题，唯一的方法是，为每个SSH密钥创建一个虚拟用户，并将其添加到组/项目中，并为这个虚拟用户提供正确的权限。

Linux下的完整示例，用于git@gitlab.example.com:root/test.git

的测试存储库

将以上补丁应用于GitLab
重新启动GitLab以读入新代码
将您的~/.ssh/id_rsa.pub添加到My SSH keys下的GitLab管理员，并将其命名为* my readonly key（或其他内容，以*开头）。
确认以下内容有效：git clone git@gitlab.example.com:root/test.git

验证git push步骤中的关注失败：

cd test
date > DATE.tmp
git add DATE.tmp
git commit -m testing
git push

创建第二个SSH密钥~/.ssh/id_push：ssh-keygen -b 4096 -f ~/.ssh/id_push
将~/.ssh/id_push.pub作为Deploy-Key添加到repo root/test.git。将其命名为! my push key（或其他不同的内容，以!开头）

将以下内容添加到~/.ssh/config

Host gitlab-push
        Hostname gitlab.example.com
        User git
        IdentityFile ~/.ssh/id_push

将此目标添加到克隆的回购站： git remote add to gitlab-push:root/test.git
验证以下效果：git push to master

注意：

我使用了copy + paste来插入补丁。它很可能不会干净利落。遗憾。

是的，这真是一个非常粗糙的黑客，不应该进入主线。正确的实现是在数据库中有一个标志来执行此操作，以便您可以通过GUI对其进行编辑。

对于部署密钥，此“密钥级”标志应位于密钥和项目之间的部分表中。在非部署密钥变体中，它应该在密钥本身上。或许，在将部署密钥添加到另一个项目时，此字段可以充当default值，并记录此密钥的最后使用情况。

不幸的是我自己无法正确实现这一点，因为我缺乏如何向GUI添加必要元素的知识，抱歉。 ;（

Answer 2

2017年更新

GitLab 8.16 (January 2017)会引入带有写访问权限的部署密钥！
Merge Request 5807

现在能够在部署密钥上添加写访问权限，我们可以构建像发布一样的包，制作标签（通过CI）并准备下一个版本，当然也可以将它们都提交到git存储库

2013年原始答案：

上次检查时（在“Push to GitLab repository within CI server (deploy keys)”中，否，您无权使用部署密钥推送回购。

我认为提供部署密钥推送访问是错误的。它解决了错误的问题。

当您需要热补丁生产系统（运行时？）并推回更改时，您可能做错了   变化应始终从开发流向生产系统（这应该是自动化的！）   使您的dev env尽可能与您的production env相似（使用虚拟机或专用的开发/暂存服务器）并编写测试（确实如此！）。

Litmus添加了in the comments，我同意他的观点：

不仅仅是在GitLab，甚至在Bitbucket，Github等上：部署密钥只读。
鉴于部署密钥用于生产部署，它应该是单向流。代码应该从DVCS到生产，但从不相反生产服务器也应该具有尽可能少的权限......这是一种安全性最佳实践 CI在测试环境中运行切勿使用相同的按键进行生产和测试。那将是一场灾难

Curt J. Sampson提及in the comments：

与部署无关的部署密钥还有其他用途。

例如，如果您需要将来自其他地方的repo镜像到您自己的GitLab中，您可能希望镜像脚本使用部署密钥而不是某人的个人密钥推送到您的GitLab。

Answer 3

不仅在GitLab中，即使在Bitbucket，Github等，部署密钥也是只读的。

鉴于部署密钥用于部署production，它应该是单向流。代码应该从DVCS流向production但从不相反。

同样production服务器应具有尽可能少的权限......这是一种安全性最佳实践。

大多数情况下，需要与非开发人员或自动化工具共享部署密钥。让它们只读（至少）确保未经授权的人不会搞砸代码库（当然git可以让你恢复几乎所有东西，但是预防不比治疗好吗？）

CI在test环境中运行。切勿对production和test使用相同的密钥。那将是一场灾难。

gitlab部署密钥是否只读？

3 个答案:

注意：