What’s the best practice to solve the following situation with Gitlab?
We have a repository that contains company-internal code that is getting used as a dependency in a lot of our projects. Based on the nature of the contained code, we don’t intend to make this repository public.
So far, we created an SSH private/public key-pair for each installation, and added the public key as a deployment-key for that central library-code repository. This worked fine, wile the number of projects was small and thus that overhead was acceptable.
Since our developers can now kickstart development environments on their own within minutes, the amount of development instances has grown quite quickly. Through that fact, the overhead is now becoming disturbing…
So we’re seeking for a way, that allows to access that particular repository without having to “grant access” to the repository on a per-new-development-instance level.
We thought about
- having a user-account and distribute the user/pass within the composer.json manifest of each project, but considered that a bad solution because of readable user credentials and the amount of work that would arise if that password once in a while should get changed
- having a global ssh-keypair used for all project-instances (on DEV at least), so they would all authorize with the exact same key instead of a user@server specific keypair - not sure if that is recommendable
- having a permission that is IP-based, so we could e.g. whitelist our development server(s) for this project and whoever requests to clone/pull from that repository from a whitelisted IP-Address/Range will be able to do so
What’s the best practice for that use-case? (is there any?)