gitlab部署密钥是只读的吗？

Question

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

Answer 1

Edit2:此更改目前有副作用，因为部署密钥上没有用户。所以你会发现一些丑陋的消息，比如ERROR -> POST-RECEIVE: Triggered hook for non-existing user。因此，缓存无效(和可能的其他事情)没有通过部署键在写入推送上处理，这有点丑陋。在我找到解决这个问题的方法(参见下面的GitHub链接)之前，Redis一直是你的朋友--请记住，清除Redis缓存也会注销所有用户。

以下是一个简短的解决方法，用于按键归档以下内容：

• 将My SSH keys设为只读。这允许添加对帐户的所有repos具有只读访问权限的计算机。如果您在开发人员级别上使用git subprojects.
• Make Deploy-Key的训练负载，则很好。
• 在主级别上使Deploy-Key可读写。

这是通过在密钥的标题前加上一些特殊字符来归档的：

• * to make a Deploy readonly
• ! to make Deploy-Key read-write
• !! to make Deploy-Keys My SSH keys (写入受保护分支)

因此，不是将键命名为"My global key“，而是将其命名为"* 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

Edit1:此修补程序现已在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

仍然存在一些问题：

次要密钥，不能同时在帐户级和部署级使用相同的密钥。因此，对于仅具有全局只读访问权限的密钥(可能是使用的默认密钥)，您需要第二个特殊的"push only“密钥，它允许对repos的推送访问。

Edit3:和主要的那个部署密钥没有用户附加，让所有方便的东西都不工作。如果这对您来说是一个问题，唯一的方法是为每个SSH密钥创建一个虚拟用户，并将其添加到组/项目中，并为该虚拟用户提供正确的权限。

在Linux下的完整示例，以获取git@gitlab.example.com:root/test.git上的测试存储库。

将上述补丁程序应用于GitLab

• Restart

• 以读取新代码GitLab

• 将您的~/.ssh/id_rsa.pub添加到GitLab My SSH keys下的* my readonly key，并将其命名为* my readonly key(或以*).

• Verify，开头的其他名称，如下所示)：git clone git@gitlab.example.com:root/test.git

• Verify，My SSH keys* my readonly key on the git push step：

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

• 创建第二个ssh-keygen -b 4096 -f ~/.ssh/id_push

• Add密钥~/.ssh/id_push：DATE.tmp ~/.ssh/id_push.pub as Deploy-Key to repo root/test.git。将其命名为! my push key (或者其他名称，从!)

• Add开始，跟随到~/.ssh/config

Host gitlab-push Hostname gitlab.example.com User git IdentityFile将此目标推送到您的克隆存储库：git remote add to gitlab-push:root/test.git

• Verify以下工作：git push to master

备注：

我使用copy+paste插入补丁。它很可能不会干净地应用。抱歉的。

是的，这真的是一个非常原始的黑客攻击，不应该进入主线。正确的实现应该是在数据库中有一个这样做的标志，这样您就可以通过GUI对其进行编辑。

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

不幸的是，我自己不能正确地实现这一点，因为我缺乏如何将必要的元素添加到GUI的知识，对不起。;(

Answer 2

更新2017

GitLab 8.16 (January 2017)确实引入了带有写访问的部署密钥！

Merge Request 5807

现在有了在deploy key上添加写访问权限的能力，我们可以构建像release这样的包，生成标签(通过CI)并准备下一个版本，当然还可以将它们都提交到git存储库

更新2021年2月和GitLab 13.9

允许将部署密钥推送到受保护的分支

在GitLab 12.0之前，具有写访问权限的部署密钥可以将提交推送到受保护的分支。

出于安全考虑，对此的支持被移除，但许多用户仍然请求它，因为他们使用它来确保只有拥有Deploy Keys的用户才能推送到他们的存储库。

它还消除了使用服务用户或机器用户的需要，这为任何希望允许Deploy Keys仅针对此用例推送到受保护分支的团队捆绑了许可证。

我们很高兴地宣布，我们解决了这个问题，现在部署密钥可以再次推送到受保护的分支，同时遵守安全最佳实践。通过移动到Deploy Key的隔离权限模型，用户现在可以选择Deploy Keys以直接从受保护分支上的设置页面链接到受保护分支。

参见Documentation和Issue。

2013年的原始答案：

上次我检查过(在"Push to GitLab repository within CI server (deploy keys)"，no中，你没有使用部署密钥推送到存储库的权限。

我认为给部署密钥推送访问权限是被误导的。它在错误的一端解决了问题。

当您必须对生产系统进行热补丁时(在运行时？)并将更改推回，您可能做错了。

更改应该始终从开发流向生产系统(这应该是自动化的！)。

使您的dev环境尽可能类似于您的production环境(使用VM或专用的开发/临时服务器)并编写测试(真的是这样！)。

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

不仅仅在GitLab中，甚至在Bitbucket、Github等上也是如此：部署密钥是只读的。

鉴于deploy密钥用于在生产环境中部署，因此它应该是单向流。代码应该从DVCS转移到生产环境中，但绝不能从另一个方向转移到生产环境中。

另外，生产服务器应该拥有尽可能少的特权……这是一种安全的最佳实践。

CI在测试环境中运行。

不要在生产和测试中使用相同的密钥。那将是一场灾难

Curt J. Sampson提到了in the comments

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

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

注，来自GitLab 13.5 (2020年10月)：

允许部署密钥推送到受保护分支的

配置选项

在版本12.0中，我们更新了Deploy Keys，因此具有写访问权限的密钥不再能够将提交推送到受保护的分支。作为此限制的解决方法，一些用户取消了对master分支的访问限制，使其不受保护，并允许所有开发人员推送到master。

这增加了安全风险，因此为了提供更好的选择，我们决定通过配置设置重新启用以前的行为。

参见Documentation和Issue。

Answer 3

不仅仅是在GitLab中，甚至在Bitbucket、Github等平台上，部署密钥都是只读的。

鉴于deploy密钥用于在production上部署，它应该是一个单向流。代码应该从DVCS流向production，但绝不能从另一个方向流向DVCS。

此外，production服务器应该具有尽可能少的权限...这是一种安全的最佳实践。

最常见的情况是需要与非开发人员或自动化工具共享部署密钥。将它们设为只读(至少)可以确保未经授权的人不会搞砸代码库(当然，git可以让您恢复几乎所有内容，但预防不是比治疗更好吗？)

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