Eu preciso construir um servidor git onde determinados usuários tenham acesso de leitura e gravação ao repositório e o servidor de gerenciamento executando determinados scripts usando este repositório tenha acesso somente leitura ao mesmo repositório no servidor git:
A configuração deve ser o mais segura possível. No momento eu consegui isso com o gitolite onde o devicesrepositório tem a seguinte configuração:
repo devices
RW = eng1
RW = eng2
RW = eng3
R = graphs
O par de chaves SSH para o usuário graphsé armazenado no mgmt-svrservidor no graphsdiretório inicial do usuário e a chave privada é legível e gravável apenas para o usuário graphs. Esta chave privada não é protegida por senha.
Existe uma maneira mais segura de fazer isso? Eu pensei em usar HTTPS para acessar o devicesrepositório no servidor git e autenticação de acesso básico, mas não consigo ver nenhuma vantagem sobre a configuração atual baseada em SSH - ainda preciso armazenar as credenciais de acesso em algum lugar no graphsdiretório inicial do usuário.
Você pode usar
gitlabe implantar o recurso de chave para CI. Esse recurso também está disponível para a edição da comunidade (ce).As chaves do Global Shared Deploy permitem que o acesso somente leitura ou leitura/gravação (se habilitado) seja configurado em qualquer repositório em toda a instalação do GitLab.
Isso é realmente útil para integrar repositórios a serviços de Integração Contínua (CI) compartilhados e seguros ou outros serviços compartilhados. Os administradores do GitLab podem configurar a chave Global Shared Deploy no GitLab e adicionar a chave privada a qualquer sistema compartilhado. Repositórios individuais optam por expor seu repositório usando essas chaves quando um mantenedor de projeto (ou superior) autoriza uma chave de implantação compartilhada global a ser usada com seu projeto.
As Chaves Compartilhadas Globais podem fornecer maior segurança em comparação com as Chaves de Implantação por Projeto, pois um administrador do sistema integrado de destino é o único que precisa conhecer e configurar a chave privada.
Os administradores do GitLab configuram as chaves do Global Deploy na área Admin na seção Deploy Keys. Certifique-se de que as chaves tenham um título significativo, pois essa será a principal maneira para os mantenedores e proprietários do projeto identificarem a chave de implantação global correta a ser adicionada. Por exemplo, se a chave der acesso a uma instância de CI de SaaS, use o nome desse serviço no nome da chave se for apenas para isso. Ao criar chaves de implantação compartilhada global, pense um pouco na granularidade das chaves - elas podem ser de uso muito restrito, como apenas um serviço específico, ou de uso mais amplo para algo como "Em qualquer lugar que você precise dar acesso de leitura ao seu repositório".
Depois que um administrador do GitLab adiciona a chave de implantação global, os mantenedores e proprietários do projeto podem adicioná-la na página Configurações > Repositório do projeto, expandindo a seção Deploy Keys e clicando em Enable ao lado da chave apropriada listada em Public deploy keys available to any project.
https://docs.gitlab.com/ee/ssh/#deploy-keys
EDIT :
giteaé um serviço git auto-hospedado mais leve em comparação com ogitlab. Ele tem apenas um único arquivo binário estático sem dependências - programado com go (você precisa adicionar arquivos de configuração e um serviço systemd ou similar, é claro). O site tem uma boa visão geral de seus recursos: https://docs.gitea.io/en-us/A configuração que você tem parece bastante segura. Embora os hackers sempre encontrem uma maneira com tempo suficiente. ... Não me processe se alguém hackear você. Pode ser apropriado para uma configuração pequena. Para uma grande equipe em uma grande empresa, pode ser menos apropriado (consulte "Engenharia Social" abaixo).
Existem alguns pontos positivos sobre isso e alguns pontos para você considerar para torná-lo melhor.
Pontos positivos sobre sua configuração
Considerações para melhoria
Chaves não criptografadas
Armazenar suas chaves privadas não criptografadas não é perfeito, embora seja comum. Como você diz, você tem que armazená-los em algum lugar. No entanto, isso pode ser um problema com backups ou com servidores que não são fisicamente seguros. Existem opções que exigem que você descriptografe manualmente suas chaves privadas ao reiniciar o servidor. Talvez o mais simples deles seja um agente ssh e adicione manualmente sua chave criptografada a ele quando você reiniciar.
Proteção do servidor SSH
Lembre-se que o Gitolite é executado no servidor OpenSSH. Há várias coisas que você pode fazer para proteger o próprio servidor ssh .
Você pode até considerar rodar o Gitolite em um ambiente chroot . Existem muitos tutoriais de como configurar
chrootcom o OpenSSH. Lembre-se de que o resultado precisará de acesso a programas como,pythonportanto, isso o tornará tecnicamente mais complexo de alcançar do que muitos dos tutoriais fariam você acreditar.Engenharia social
Todo administrador de sistema procura as maneiras técnicas pelas quais um hacker pode entrar, mas muitos hacks do mundo real são feitos por pessoas .
Talvez o ponto mais fraco de sua solução seja o gerenciamento de chaves ssh. Isso é amplamente considerado um problema de segurança em muitas empresas . O Gitolite coloca toda a administração de chaves SSH no administrador. Isso traz algumas grandes implicações: