특정 사용자가 저장소에 대한 읽기 및 쓰기 액세스 권한을 갖고 이 저장소를 사용하여 일부 스크립트를 실행하는 관리 서버가 git 서버의 동일한 저장소에 대한 읽기 전용 액세스 권한을 갖는 git 서버를 구축해야 합니다.
설정은 최대한 안전해야 합니다. 지금까지 나는 이것을 해왔습니다.규조토devices저장소의 구성은 다음과 같습니다 .
repo devices
RW = eng1
RW = eng2
RW = eng3
R = graphs
사용자의 SSH 키 쌍은 서버의 사용자 홈 디렉터리에 graphs저장되며 개인 키는 해당 사용자만 읽고 쓸 수 있습니다 . 이 개인 키는 비밀번호로 보호되지 않습니다.mgmt-svrgraphsgraphs
이를 달성하는 더 안전한 방법이 있습니까? HTTPS를 사용하여 git 서버 및 기본 액세스 인증의 리포지토리에 액세스하는 것을 고려했지만 devices현재 SSH 기반 설정에 비해 아무런 이점이 없습니다. 여전히 graphs사용자의 홈 디렉터리 어딘가에 액세스 자격 증명을 저장해야 합니다. .
답변1
gitlabCI의 배포에 중요한 기능을 사용할 수 있습니다 . 이 기능은 Community Edition(ce)에서도 사용할 수 있습니다.
전역적으로 공유되는 배포 키를 사용하면 GitLab 설치 전체에서 모든 저장소에 대한 읽기 전용 또는 읽기-쓰기(활성화된 경우) 액세스를 구성할 수 있습니다.
이는 저장소를 안전한 공유 CI(지속적 통합) 서비스 또는 기타 공유 서비스에 통합하는 데 유용합니다. GitLab 관리자는 GitLab에서 전역 공유 배포 키를 설정하고 모든 공유 시스템에 개인 키를 추가할 수 있습니다. 프로젝트 관리자(또는 그 이상)가 프로젝트에 사용할 전역 공유 배포 키를 승인하면 개별 저장소는 이러한 키를 사용하여 저장소를 노출하도록 선택합니다.
전역 공유 키는 대상 통합 시스템의 관리자만이 개인 키를 알고 구성해야 하기 때문에 프로젝트별로 키를 배포하는 것보다 더 강력한 보안을 제공합니다.
GitLab 관리자는 관리 영역의 배포 키 섹션에서 전역 배포 키를 설정합니다. 키에 의미 있는 제목이 있는지 확인하세요. 이는 프로젝트 유지 관리 담당자와 소유자가 추가할 올바른 Global Deploy 키를 식별하는 주요 방법이 되기 때문입니다. 예를 들어 키가 SaaS CI 인스턴스에 대한 액세스를 허용하는 경우 키 이름에 서비스 이름을 사용합니다(그게 전부인 경우). 전역 공유 배포 키를 생성할 때 키의 세분성을 고려하세요. 키의 목적은 특정 서비스에만 적용되는 것처럼 매우 좁을 수도 있고, "읽기 액세스 권한이 필요한 모든 곳"과 같이 좀 더 일반적인 용도일 수도 있습니다. 저장소에 " ".
GitLab 관리자가 전역 배포 키를 추가하면 프로젝트 유지관리자와 소유자는 배포 키 섹션을 확장하고 "공개 배포 키" 아래에 나열된 해당 키 옆에 있는 "활성화"를 클릭하여 이를 프로젝트의 설정 > 리포지토리 페이지에 추가할 수 있습니다. 모든 프로젝트에 사용됩니다."
https://docs.gitlab.com/ee/ssh/#deploy-keys
편집하다:
gitea.에 비해 더 가벼운 자체 호스팅 Git 서비스입니다 gitlab. 종속성이 없는 정적 단일 바이너리만 있습니다. go를 사용하여 프로그래밍되었습니다(물론 구성 파일과 시스템 서비스 또는 유사한 서비스를 추가해야 합니다). 웹사이트에는 해당 기능에 대한 좋은 개요가 있습니다.
https://docs.gitea.io/en-us/
답변2
설정이 안전한 것 같습니다. 그러나 충분한 시간이 주어지면 해커는 항상 방법을 찾을 것입니다. ...누군가가 당신을 공격한다면, 저를 고소하지 마세요. 소규모 설정에 적합할 수 있습니다. 이는 대기업의 대규모 팀에는 적합하지 않을 수 있습니다(아래 "사회 공학" 참조).
더 나은 제품을 만들기 위해 고려해야 할 몇 가지 장점과 몇 가지 사항이 있습니다.
설정에 대한 긍정적인 점
- Gitolite 자체는 가볍고 충분히 잘 작동하며 지속적으로 업데이트됩니다. (이 글을 쓰는 시점에서 마지막 커밋은 23일 전이었습니다.) 꽤 안전합니다.
- Gitolite는 잘 지원되고 매우 안전한 OpenSSH 서버와 함께 제공됩니다.
- 공개 개인 키(예: SSH 키)는 비밀번호보다 훨씬 더 안전합니다.
- 설정이 매우 간단하고 오류 가능성이 줄어들며 저렴한 솔루션입니다.
개선을 위한 고려사항
암호화되지 않은 키
일반적이지만 개인 키를 암호화되지 않은 상태로 저장하는 것은 완벽하지 않습니다. 말씀하신 대로 어딘가에 보관해야 합니다. 그러나 이는 백업이나 물리적으로 보안되지 않은 서버에 문제가 될 수 있습니다. 일부 옵션에서는 서버를 다시 시작할 때 개인 키를 수동으로 해독해야 합니다. 아마도 그 중 가장 간단한 것은SSH 에이전트재부팅 시 암호화 키를 수동으로 추가합니다.
SSH 서버 강화
Gitolite는 OpenSSH 서버에서 실행된다는 점을 기억하세요. 당신이 할 수 있는 일이 많이 있습니다SSH 서버 강화그 자체.
다음과 같이 Gitolite를 실행하는 것을 고려할 수도 있습니다.chroot환경. OpenSSH를 설정하는 방법에 대한 많은 튜토리얼이 있습니다 chroot. 결과를 얻으려면 해당 프로그램에 대한 액세스가 필요하므로 python많은 튜토리얼에서 믿게 되는 것보다 기술적으로 더 복잡해집니다.
사회공학
모든 시스템 관리자는 해커가 침입할 수 있는 기술적인 방법을 찾고 있지만 실제 해킹은 대부분누군가에게 도착하다.
아마도 솔루션의 가장 약한 점은 SSH 키 관리일 것입니다. 이는 많은 기업에서 보안 문제로 널리 인식되고 있습니다.. Gitolite는 SSH 키의 모든 관리를 관리자에게 맡깁니다. 이는 다음과 같은 몇 가지 중요한 의미를 갖습니다.
- Single Sign-On은 지원되지 않으므로 시스템 관리자는 누군가 떠날 때 이 특정 상자에 대한 액세스를 제거해야 한다는 사실을 알지 못할 수도 있습니다. 예: 팀에서 이 상자를 직접 실행하는 경우 직원이 해고될 때 알림을 받나요?
- Gitolite 구성의 명명 규칙은 그리 좋지 않습니다. 실수를 해서 잘못된 키를 삭제하거나 교체하는 것은 쉽습니다. 자신이 하고 있는 일을 명확하게 해주는 디렉토리 구조를 스스로에게 제공해야 합니다.
- 사용자는 언제 키 사용을 중단했는지 알려주지 않을 수 있습니다. 그들은 이 열쇠로 무엇을 합니까?다음안전하지 않을 수 있습니다. Github Enterprise와 같은 다른 대규모 소프트웨어에는 실제로 다음과 같은 기능이 내장되어 있습니다.SSH 키 감사일괄적으로 비활성화하고 사용자에게 다시 승인하도록 요구합니다.