Installing packs from multiple private repos using Deploy keys...how to do more than one?

(note I already looked here and here and did not see a resolution)

I am creating some proprietary workflows and actions along with some colleagues and we’re storing them in our organization’s GitHub in separate repos.

In order to use the st2 pack install ssh://[email protected]:_GHUSER_/_REPO_ convention, for a Private repository, it requires a valid SSH key pair with access to the repo stored in the root user’s SSH config.

This works great for a single repo using a Deploy Key. Or for multiple repos using an actual GH user account with an SSH key that you also install on the ST2 server instance.

In cases where you don’t want to use a personal SSH key on a shared server running the ST2 instance, it appears there is no way to support multiple Private repo’s using Deploy Keys without needing to comment out all other Deploy keys in the ~/.ssh/config file before running the st2 pack install command.

The problem is that SSH will offer up all the keys it knows about, and github.com will happily accept the very first key that works, and thus will only be able to install from a private repo that uses that specific key. And for the record, you can only use a Deploy key on one specific repo in all of github land.

I was hoping to find a way to pass an IdentityFIle parameter to the packs.download action step of the packs.install workflow, but no dice.

Anyone have thoughts on this? I’m going to look at using SSL tokens instead, but that’s a bit less secure since it will show up in logs since it becomes part of the URL.

To manage multiple deploy keys you can use git credentials Git - Config Username & Password - Store Credentials - ShellHacks

Thanks Carlos. That would certainly help if I wanted to create a user to acces these private repos, which I was rather hoping to avoid by using Deploy keys. This is analogous to using personal access tokens also. Either way this method or PAT will end up storing the un/pw in plaintext in a file, as well as on every URL call which will expose it in the logs.

The git credentials method does not require the username/password to be sent as part of the URL when it is stored in the git credentials file, so there’s no risk of having it show up in the st2 logs.

By enabling the useHttpPath option, multiple private repos with independent deploy keys can be defined, no need to mess around with commenting things out, git just does the right thing.

The point about username/password being stored in plaintext is true. This is the .git_credentials file and will be situated in the home directory of whichever system account executes the pack installation, which is root or stanley in general.

It should be reasonably straight forward to protect this file from unauthorised viewing. The deployment keys should only allow read access to the repo so they don’t pose a great risk since the pack contents will be viewable in the st2/packs directory anyway, anyone gaining unauthorised access to these keys will be able to view the code but not change it.

All that is said as food for thought, I’m not telling you run your infrastructure or what security risks to accept. I used this approach with gitlab and it works well.

I totally appreciate the input. That’s a good point about fit using it from the stored credentials if using ssh. Still requires a use account vs deploy keys but I think that might be my only option, we’ll just need to provision a service user for this.