Accessing hosted Git servers via Luminate

Products

• Symantec ZTNA

Issue/Introduction

 Accessing hosted Git servers via Luminate

Resolution

Luminate Secure Access Cloud (TM) provides a Zero Trust access to corporate applications, services and workloads hosted in any physical or virtual datacenter. In this article we will explain how to provide access to hosted Git servers, allowing users to have a secure and transparent working experience, without VPNs and without exposing the servers via public networks.

Accessing hosted Git servers via Luminate can provide additional security values, such as the possibility of using Multi-Factor Authentication, benefiting from access restrictions defined in the corporate Identity/Access Management system, and more.

 

Git access with SSH protocol is built in a way that requires usage of specific SSH Key pairs for user authentication and authorization to Git repositories. In order to provision access via Luminate, we will need to establish trust with the Luminate Certificate Authority on the Git server itself (to establish the Zero Trust SSH connection) and then use this connection to establish a direct SSH connection with a Git server itself and authenticate/authorize the user.

 

Please note that if Git Large File System (LFS) extension is used in your environment, you will need additional configuration steps after completing the ones described below.

When accessing hosted Git servers via Luminate Secure Access Cloud (TM), following access scenarios are considered:

• Web access to the Web UI of the hosted git solution
• SSH access for using git repositories from cli or integrated IDEs
• (Optional) SSH access to the hosted git machines for management
• (Optional) REST API access to LFS (Large File Server) 

Below diagram describes the various connectivity flows:

 

If your hosted Git server comes with a Web Interface (such, as, but not limited to Gitlab, GitHub Enterprise, Bitbucket Enterprise), you can also define HTTPS access to its Web Interface, as described here.

 

Please note, that, while Git command-line tools allow accessing repositories via HTTPS, this method has significant security disadvantages, as advanced authentication methods are not supported. Therefore, in order to use Zero Trust access to Git repositories with Luminate, SSH should be used as a protocol for command-line operations.

 

When configuring an SSH access to hosted git servers via Luminate Secure Access Cloud (TM), three possible approaches can be implemented. The end-user experience for all access scenarios is the same, but the configuration on the administrative side (and infrastructure requirements) are different. Below table compares them, explaining the differences:

Approach	Connectivity Flow	Comments
Access via TCP Tunnel (Recommended)	SSH Tunnel to Luminate Secure Access Cloud (TM) with corporate IdP user Git SSH Connection (with user "git") directly to the git server(s) through the above tunnel	This is the recommended configuration, as it requires minimal changes in the environment. In load-balancer environments, the connections are made to the Git Proxy/LB instead of the actual host.
Access via SSH Server running on the git server host	SSH Tunnel through Luminate Secure Access Cloud (TM) corporate IdP user to the SSH Server on the git server host (with a local user) Git SSH Connection (with user "git" through this tunnel to the dedicated git port (configuration differs for different git server implementations)	This configuration should be used if, for some reason, the Luminate Connector cannot create a direct TCP connectivity to the dedicated ssh git port on the git hosts, but only to the management port. This approach requires changes to be introduced to the SSH Daemon configuration on the git server host machine(s) In load-balancer environments, the connections are made to the Git Proxy/LB instead of the actual host.
Access via Bastion SSH Server	SSH Tunnel through Luminate Secure Access Cloud (TM) corporate IdP user to a Bastion SSH Server on the git server host (with a local user) Git SSH Connection (with user "git" through this tunnel to the dedicated git ssh port on the actual gir server hosts (configuration differs for different git server implementations)	This configuration should be used if, for some reason, there is no way for the Luminate Connector to have a direct TCP (SSH) connection to the Git Server hosts, and Bastion is required. In load-balancer environments, the connections are made to the Git Proxy/LB instead of the actual host.

 

 

Configuring Luminate access to hosted Git Server via TCP Tunnel

Below diagram describes the connectivity flow of the proposed solution:

Please note, that, while the communications between the end-user workstation and the Luminate Secure Access Cloud (TM) PoD consist of an SSH Tunnel (established with the IdP user credentials or Luminate SSH Key) and the Git SSH connection, established with user "git" inside it, the communications between the Luminate Connector and the Git Server consist only of a git SSH connection.

In this configuration, the end-user's workstation should have an SSH Key allowing the user to access Git (this is the regular approach when working with Git servers). 

Additionally, the user will need to provision a Luminate SSH key (can be retrieved from the Luminate User Portal) on the machine and configure the SSH connectivity as described below.

The below procedure will describe the steps required to provision the connectivity via Luminate.

Step 1 - Define an SSH Tunnel in the Luminate Administration Portal for access to the git server(s)

In the Administration Portal, create a TCP Tunnel application in the site where Luminate Connectors have connectivity to the git server machine(s) or the load balancer proxy:

In the image above, please fill the following configuration parameters:

• Application Name - will be relevant for the client-side configuration steps below
• Target Address - a resolvable DNS or IP address that will be used by Luminate Connectors to connect to git server hosts
• Port - an SSH port for git cli access (may have different values depending on your git server brand or configuration)

Please make sure to allow access to this TCP Tunnel application to the relevant organizational users/groups and to enable key authentication (for optimization of end-user experience).

 

Step 2 - Retrieve a Luminate SSH Key for Git server users

In order to retrieve the Luminate SSH keys, each accessing user will need to perform the following procedure:

1. Using Web Browser, log in to Luminate User Portal (the address of the portal should be https://<your_company_Luminate tenant>.luminatesec.com)

2. In the portal, find the icon representing the TCP Tunnel defined in the previous step, representing the Git server and click on it. If the user cannot find the icon, this means that the access permissions defined in the previous step do not allow access to this user.

3. In the side-bar that contains the details of the SSH Application, please choose "SSH Keys" in the "Authentication Method" combo box and click on Generate. Download the resulting key.

As every user has a unique Luminate SSH key, the above procedure will need to be performed once by each user. All allocated keys are controlled centrally by the organizational Luminate Secure Access Cloud (TM) administrator, that can issue key expiration policies, as well as revoke keys for specific users.

 

Step 3 - Configure SSH Client on the machines that are accessing Git

In order to have a transparent access to the Git server, it is recommended to configure SSH client configuration. (The below is assuming Unix / Mac OS X Git and SSH clients configuration. The configuration for Windows Git client is similar).

The user's ~/.ssh/config file should contain the following lines:

Host git-server-tunnel.your_company.luminatesec.com    IdentityFile ~/luminate_ssh_key.pem   Host mygitdirect    HostName internal-git-server-address    IdentityFile ~/git_ssh_key    ProxyJump tcptunnel@tcptunnel@[email protected]_company.luminatesec.com

 

In the snippet above, please choose/fill the following variables:

• git-server-tunnel.your_company.luminatesec.com- External address of the TCP Tunnel app as defined in the previous steps in the Luminate Admin Portal.
• ~/luminate_ssh_key.pem - Path to a Luminate SSH Key retrieved by the user in Step #2.3
• mygitdirect - The name of the Git server that the user will be using when performing git commands (such as, git clone)
• ~/git_ssh_key - Path to the key provisioned for the user at the Git server
• internal-git-server-address - Has to be the same as the "target address" defined in Step 1 in the TCP Tunnel Application

Please note that the duplication of "tcptunnel@" and "git-server-tunnel" in the ProxyJump command is intentional

Upon completing the above configuration, access to Git repositories could be achieved by using the following command:

git clone git@mygitdirect:port/test/demo.git

(Where mygitdirect is the same name, as defined in the configuration file above and test/demo.git is the path to the git repository)

 

 

Configuring Luminate access to hosted Git Server, directly providing SSH access

Below diagram describes the connectivity flow of the proposed solution:

Please note, that, both the communications between the end-user workstation and the Luminate Secure Access Cloud (TM) PoD and the communications between the Luminate Connector and the git server consist of an SSH Tunnel (established with the IdP user credentials or Luminate SSH Key) and the Git SSH connection, established with user "git" inside it.

In this configuration, the end-user's workstation should have an SSH Key allowing the user to access Git (this is the regular approach when working with Git servers). 

Additionally, the user will need to provision a Luminate SSH key (can be retrieved from the Luminate User Portal) on the machine and configure the SSH connectivity as described below.

The below procedure will describe the steps required to provision the connectivity via Luminate. Please note that this will require making modifications to a configuration of an SSH Daemon on the Git Server. If you are not the administrator of the machine(s) where the Git Server is running, or if your Git product does not provide SSH access to its server, please refer to the paragraph below describing how to set up such communication via Bastion Servers (separate from the Git Server machine(s)).

Step 1 - Provision SSH Access to the Git Server machine

This step assumes that there already is a Luminate Connector deployed in the network with access to the Git server. Please refer to this article to learn how to achieve this.

1. In your Luminate Administration Portal please create a new SSH Application (in a site that has connectivity to the Git Server). Please use the internal IP address of the Git server as an internal address for the SSH Application.

2. Please define an SSH Account - a Unix user account defined on the machine, that will allow connecting via SSH. This doesn't have to be a high-privileged account, but it needs to be a generic account defined on the machine (unless every connecting user will have a personal account on the machine anyway, using LDAP or some other dynamic Linux account management tool).

3. Please allow access to the created SSH Application for the designated organizational users and groups, while allowing them to use SSH Keys and accessing with an account defined in the previous step.

4. Please establish the trust between the Luminate Certificate Authority (unique for each Luminate customer) and the OpenSSH server running on the Git server machine, by either running a one-liner script snippet presented in the UI or performing the manual operations described there).

5. Please test the SSH connectivity to the Git server machine, by connecting as described in this article.

 

 

Step 2 - Retrieve a Luminate SSH Key for Git server users

In order to retrieve the Luminate SSH keys, each accessing user will need to perform the following procedure:

1. Using Web Browser, log in to Luminate User Portal (the address of the portal should be https://<your_company_Luminate tenant>.luminatesec.com)

2. In the portal, find the icon representing the SSH application defined in the previous step, representing the Git server and click on it. If the user cannot find the icon, this means that the access permissions defined in Step #1.4 do not allow access to this user.

3. In the side-bar that contains the details of the SSH Application, please choose "SSH Keys" in the "Authentication Method" combo box and click on Generate. Download the resulting key.

As every user has a unique Luminate SSH key, the above procedure will need to be performed once by each user. All allocated keys are controlled centrally by the organizational Luminate Secure Access Cloud (TM) administrator, that can issue key expiration policies, as well as revoke keys for specific users.

 

Step 3 - Configure SSH Client on the machines that are accessing Git

In order to have a transparent access to the Git server, it is recommended to configure SSH client configuration. (The below is assuming Unix / Mac OS X Git and SSH clients configuration. The configuration for Windows Git client is similar).

The user's ~/.ssh/config file should contain the following lines:

Host luminategit    HostName git_machine.company_tenant.luminatesec.com    IdentityFile ~/luminate_ssh_key.pem   Host mygitdirect    HostName mygitdirect    IdentityFile ~/git_ssh_key    ProxyCommand ssh git_machine_user@git_machine@luminategit nc internal_ip %p

 

In the snippet above, please choose/fill the following variables:

• luminategit - Just an internal name for connecting to the Git Server via Luminate. You can choose any name, as long is you use it in the ProxyCommand setting in the config file.
• git_machine - An external name of the SSH Application defined in the Step #1.1 above
• company_tenant - A name of the company tenant in Luminate Secure Access Cloud (TM). Should be the same as in the address of your Luminate User Portals (https://<your_company_tenant.luminatesec.com)
• ~/luminate_ssh_key.pem - Path to a Luminate SSH Key retrieved by the user in Step #2.3
• mygitdirect - The name of the Git server that the user will be using when performing git commands (such as, git clone)
• ~/git_ssh_key - Path to the key provisioned for the user at the Git server
• git_machine_user - Generic (or personal) user account defined at the Git server machine in Step #2.2 above
• internal_ip - Internal IP Address of the Git server. Can be, potentially, localhost, if the Git server's SSH daemon is listening to this interface. Alternatively, can be an internal address of the Git server in the network.

Upon completing the above configuration, access to Git repositories could be achieved by using the following command:

git clone git@mygitdirect:root/demo.git

(Where mygitdirect is the same name, as defined in the configuration file above and root/demo.git is the path to the git repository)

 

Connecting to Git Server via a Bastion Server

In this solution, we will not modify the configuration of the Git server machine(s) at all, and, in order to provision secure connectivity to them via Luminate, we will use another Linux machine(s), serving as a Bastion.

Below diagram describes the overall topology of the proposed solution:

In this diagram, the Git server is hosted in an internal network and is never exposed. It should be accessible from the SSH Bastion. The Bastion is also hosted in an internal network and is only accessible via the Luminate Connector. The Bastion host is defined within Luminate Administration Portal as an SSH Application.

The end users will not feel any difference, the connectivity from their perspective will be as transparent as in the previous solution. Following steps describe the changes in the configuration that need to be performed to allow this connectivity:

1. Perform the "Step 1 - Provision SSH Access to the Git Server machine" described above, but, instead of configuring the access to the Git server, do this for the Bastion server. 

2. Perform the "Step 2 - Retrieve a Luminate SSH Key for Git Server users" described above, doing this for the Bastion server instead of the Git server

3. Perform the "Step 3 - Configure SSH Client" with the following changes in the SSH client configuration:

Host luminatebastion    HostName luminate_bastion_name.company_tenant.luminatesec.com    IdentityFile ~/luminate_ssh_key.pem   Host mygit    HostName mygit    IdentityFile ~/git_ssh_key    ProxyCommand ssh bastion_machine_user@luminate_bastion_name@luminatebastion nc git_machine_ip %p

In the snippet above, please choose/fill the following variables:

• luminatebastion - Just an internal name for connecting to the Bastion via Luminate. You can choose any name, as long is you use it in the ProxyCommand setting in the config file.
• luminate_bastion_name - An external name of the SSH Application defined in the Step #1.1 above
• company_tenant - A name of the company tenant in Luminate Secure Access Cloud (TM). Should be the same as in the address of your Luminate User Portals (https://<your_company_tenant.luminatesec.com)
• ~/luminate_ssh_key.pem - Path to a Luminate SSH Key retrieved by the user in Step #2.3
• mygit - The name of the Git server that the user will be using when performing git commands (such as, git clone)
• ~/git_ssh_key - Path to the key provisioned for the user at the Git server
• bastion_machine_user - Generic (or personal) user account defined at the Bastion server machine in Step #2.2 above
• git_machine_ip - Internal IP Address of the Git server, as accessible from the Bastion