gitlab部署密钥是只读的吗? [英] Are gitlab deployment keys read only?

问题描述

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

Are gitlab deployment keys read only? I need to clone on ci server using a deployment key and then push the tag created by the ci process. is that possible using a deployment key?

推荐答案

Edit2 :由于部署密钥上没有用户，因此此更改当前具有副作用.因此，您会发现一些丑陋的消息，例如ERROR -> POST-RECEIVE: Triggered hook for non-existing user.因此，在通过部署键进行写入推送时未处理缓存无效(可能还有其他事情)，这有点难看. bundle exec rake cache:clear RAILS_ENV=production是您的朋友，直到我找到解决该问题的方法(请参阅下面的GitHub链接)，并且请记住，清除Redis缓存也会注销所有用户.

This change currently has a sideeffect, as there are no users on deployment keys. So you will find some ugly messages like ERROR -> POST-RECEIVE: Triggered hook for non-existing user. The cache-invalidation (and possibly other things) are therefor not handled on write pushes through deployment-keys, which is a bit ugly. bundle exec rake cache:clear RAILS_ENV=production is your friend until I can find a way to fix that (see link to GitHub below) - and please remember, that clearing the Redis-cache logs out all users, too.

这里有一个简短的解决方法，可以按密钥对以下内容进行存档:

Here is a short workaround to archive following on a per-key basis:

• 将My SSH keys设为只读.这允许添加对帐户的所有存储库具有只读访问权限的计算机.如果您要处理git子项目的训练量，那就很好了.

• Make My SSH keys readonly. This allows to add machines with readonly access to all repos of an account. Good if you work with trainloads of git subprojects.

使部署键在开发人员级别上可读写.

Make Deploy-Keys read-write on developer level.

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

This is archived by prepending the key's title with some special characters:

• *使My SSH keys只读
• !使Deploy-Keys可读写
• !!使Deploy-Keys成为主密钥(写入受保护的分支)

• * to make a My SSH keys readonly
• ! to make Deploy-Keys read-write
• !! to make Deploy-Keys master (write to protected branches)

因此，将其命名为我的全局密钥"，而不是命名为"*我的全局只读密钥"等.

So instead naming the key "My global key" you name it "* my global readonly key" etc.

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

This patch now is available as cherry-pick on GitHub, see https://github.com/hilbix/gitlabhq/wiki

Edit3 :您可能还希望遵循以下解决方法，以防您按下部署密钥.这并不完美，因为它不会触发所有这些钩子，但是会使缓存无效，从而使网页不再显示过时的数据:

You probably want following workaround, too, in case you push through a deployment key. This is not perfect, as it does not trigger all those hooks, but it invalidates the caches such that the web pages no more show stale data:

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

仍然存在一些问题:

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

A minor one, you cannot use the same key on the account level and on the deploy level at the same time. So for keys which only have read-only access on a global basis (which probably is the default key used), you need a second special "push only" key, which allows push access to the repos.

Edit3 :主要的问题是部署密钥没有附加用户，因此所有方便的事情都不起作用.如果您遇到问题，唯一的办法是，为每个SSH密钥创建一个虚拟用户，并将其添加到组/项目中，并为该虚拟用户提供正确的权限.

And the major one that deployment keys do not have a user attached, so that all the convenience things do not work. If this is a problem for you the only way is, for each SSH key create a dummy-user, and add it to the group/project and give this dummy-users the correct permissions.

在Linux下完成[e-mail]:root/test.git

• 将上述补丁应用于GitLab

• Apply above patch to GitLab

重新启动GitLab以读取新代码

Restart GitLab to read in the new code

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

Add your ~/.ssh/id_rsa.pub to GitLab Admin under My SSH keys and name it * my readonly key (or something different, starting with *).

验证，可以正常工作:git clone [e-mail]:root/test.git

Verify, that following works: git clone [e-mail]:root/test.git

验证，以下操作在git push步骤上失败:

Verify, that following fails on the git push step:

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添加为部署密钥以回购root/test.git.将其命名为! my push key(或其他名称，以!开头)

Add ~/.ssh/id_push.pub as Deploy-Key to repo root/test.git. Name it ! my push key (or something different, starting with !)

在~/.ssh/config

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

将此目标添加到克隆的仓库中: git remote add to gitlab-push:root/test.git

Add this target to your cloned repo: git remote add to gitlab-push:root/test.git

验证以下作品:git push to master

我使用了复制+粘贴来插入补丁.可能不会完全适用.抱歉.

I used copy+paste to insert the patch. It is likely it will not apply cleanly. Sorry.

是的，这确实是一个非常粗糙的技巧，不应使它成为主线.正确的实现是在数据库中执行此操作的标志，以便您可以通过GUI对其进行编辑.

Yes, this is really a very crude hack which should not make it into the mainline. The correct implementation would be to have a flag in the database which does this, such that you can edit it through the GUI.

对于部署密钥，此密钥级别"标志应位于密钥和项目之间的交叉表中.在非部署密钥变体中，它应该位于密钥本身上.在将部署密钥添加到另一个项目并记录该密钥的最后用法时，此字段然后可以用作default值.

For deploy keys this "key-level"-flag should be in the interesection table between key and project. And in the non-deploy-key variant it should be on the key itself. Perhaps this field can then act as a default value when adding a deploy key to another project and record the last usage of such key.

很遗憾，我自己无法正确实现此功能，因为我不知道如何向GUI添加必要的元素. ;(

Unfortunately I am not able to implement this properly myself as I lack the knowledge how to add the necessary elements to the GUI, sorry. ;(

这篇关于gitlab部署密钥是只读的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！