globocom / huskyCI

Performing security tests inside your CI
https://huskyci.opensource.globo.com
BSD 3-Clause "New" or "Revised" License
572 stars 137 forks source link

Add logic to support cloning method change from HTTPS to SSH #496

Closed Krlier closed 4 years ago

Krlier commented 4 years ago

Motivation

We have received some reports that Golang repositories without a vendor folder and using internal dependencies are having some issues running huskyCI. We have opened an issue in gosec's project because we were facing the following error:

$ docker run -v ~/go/src/internalRemote/internalteam/internalproject/:/go/src/code -it huskyci/gosec:v2.3.0 sh
/go/src # cd code
/go/src/code # gosec ./...
[gosec] 2020/07/09 13:41:18 Including rules: default
[gosec] 2020/07/09 13:41:18 Excluding rules: default
[gosec] 2020/07/09 13:41:18 Import directory: /go/src/code/measures
The authenticity of host 'internalRemote (10.0.0.10)' can't be established.
ECDSA key fingerprint is SHA256:uanaXunASUnausaunANXuASuxnasu.
The authenticity of host 'internalRemote (10.0.0.10)' can't be established.
ECDSA key fingerprint is SHA256:uanaXunASUnausaunANXuASuxnasu.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
root@internalRemote's password:

After that, we realized that gosec scans rely on go build (thanks for the tips, @ccojocar) and we should handle this case inside our huskyCI's gosec container commands. An internal discussion resulted in having huskyCI forcing the cloning method to be SSH, rather than HTTPS, to avoid go build prompting the internalRemote password.

Proposed Changes

This PR will add the possibility to add two environment variables in huskyCI_API to substitute the standard cloning URL from HTTPS to SSH. This can be done by setting values such as:

HUSKYCI_API_GIT_SSH_URL=gitlab@gitlab.example.com
HUSKYCI_API_GIT_URL_TO_SUBSTITUTE=https://gitlab.example.com/

Testing

Initially, tests should be working:

make test

After that, we need to run huskyCI with an internal remote's ssh key. Since we already have an internal development environment with a ssh key set, the best and quickest way to properly test these changes would be through it.

Note

It's important to mention that this PR addresses the issue of needing only 1 internal remote access. For information on how the support for multiple internal remotes is, be sure to check this issue.

rafaveira3 commented 4 years ago

Great, @Krlier! Thanks a lot for working on this one. Let's put this branch on hold and test it inside our DEV environment!