[Jenkins-infra] Jenkins infrastructure vpn

R. Tyler Croy tyler at monkeypox.org
Tue Feb 19 17:06:06 UTC 2019


(replies inline)

On Tue, 19 Feb 2019, Olblak wrote:

> Initially I though to have only one vpn network for simplicity but in the end I don't think it would be a biggest effort to maintain multiple vpn, even though I still have multiple changes that I need to do to reflect this.
> 
> To give you a big picture before you go deeper:
> 
> The first part is the machine provisioning <https://github.com/jenkins-infra/azure/blob/master/plans/machine_vpn.tf>, basically we use Terraform to provision a virtual machine inside the correct network with as many network interface as we need to access the different sub network and then we use puppet to configure <https://github.com/jenkins-infra/jenkins-infra/blob/staging/dist/profile/manifests/openvpn.pp> that machine. 
>  
> The Docker Image <https://github.com/jenkins-infra/openvpn> used for the vpn service is design to use two level of authentication, one with client certificates and then we use Ldap group membership to ensure that the right person has access to the right network. Another advantage, if one of the two authentication method is compromised, we can still rely on the other method as an additional protection.
>  
> Client certificate are managed from this repository <https://github.com/olblak/jenkins-vpn-keys>, the main idea is they are two kind of person, "client" who create a private key and a signing certificate request and then submit PR with their csr. Then administrators can sign csr once the PR is merged on master. The ca private key used to sign is encrypted with sops and store on the git repository so we have everything needed in one place. This approach allow us to have multiple administrators for different vpn network with great visibility on who can access what.


Overall this looks like really great work olblak, thanks for driving it.

This key signing dance is something I've seen at multiple companies, so seems
reasonable.


What I'm not understanding right now is how you would solve for "group
membership" here? Let's take Daniel Beck for example, I would expect him to be
in all three "groups". Does that meant he has to have three different sets of
keys and three different sets of .ovpn configurations? Would he then
effectively only be able to work in one of these silos at once?


I'm not sure that multiple VPN networks is actually necessary since we will
also have application level access controls. For example, evne with cert.ci and
trusted.ci, there will still be application-layer authentication and
authorization. I am personally comfortable with the trust expectation that
everybody with VPN access is more trusted than the public internet, and will
not act maliciously agaisnt internal services which they might not otherwise
have access to.

Basically, I don't think we should be more complicated than our respective
corporate VPN setups unless we have a really really really damn good reason for
it.



Cheers

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2


More information about the Jenkins-infra mailing list