Symantec Secure Access Cloud (TM) enables Zero Trust access with SSH protocol to hosted environments based on Linux / Unix servers or appliances supporting SSH. Modern organizations using Software-Define Datacenters often face a challenge of providing access to virtual machines that are spun-off and terminated dynamically and serve their purpose for a restricted period of time.
| Please note that for accessing dynamically created EC2 Instances in Amazon Web Service, Symantec Secure Access Cloud (TM) provides a special functionality in the SSH Gateway feature. |
This article explains 3 different architectural approaches provided by Secure Access Cloud (SAC) (TM) that allow secure connectivity for development and operations teams to hyper dynamic environments. Each of the below approaches has its own unique advantages and should be chosen based on the best fit to the organizational processes or requirements. Multiple approaches can be combined for access to different resources (or by different role-players) to provide a better fit.
The user experience for all 3 approaches is: the user runs a single SSH command / connection on his/her personal computer that connects to an selected Internal Server. The goal is to be able to connect to servers that appear dynamically in the environment without performing any configuration steps per server.
When describing the solution architectures, this article will refer to the following components:
- SSH Client - SSH client application running on the endpoint device of the user, such as, but not limited to: OpenSSH, Putty, MobaXterm, SecureCRT, ...
- SAC Connector - Deployed as a Docker Container in the datacenter / subnet hosting the below servers. Should be capable of outbound communication via TCP Port 443 to the SAC cloud infrastructure and Port 22 communication to the Zero Trust Bastion SSH Server.
- Zero Trust Bastion SSH Server - an SSH Server process, running either on a Linux server or in a Docker Container, capable of terminating SSH connections as well as opening ssh connections to internal resources. The user doesn't ever need to connect to this server explicitly, all SSH connections to Internal Servers are dynamically passed through this server.
- Internal Servers - dynamically allocated and de-allocated servers running an SSH Daemon. The end-user should be able to use either their internal IP address or a dynamic node name in the connection string provided to the SSH Client in order to be able to connect to them.
Brief comparison table of various approaches:
Transparent SSH Bastion with TTY Redirection
This solution allows users to connect with SSH Client directly to Internal Servers by using their internal IP address (or internal DNS name), while transparently "jumping over" a Zero Trust Bastion and authenticating to SAC.
As a pre-condition to using this method, the Zero Trust Bastion should be registered with the SAC as an SSH Application with access permissions for the relevant IdP accounts.
Main advantage of this approach is its simplicity (besides configuring the bastion host there are no additional preconditions and full transparency of authentication accompanied by governance of user activity during the SSH sessions.
The structure of the SSH connection (depicted below with an OpenSSH client command below) is:
The SSH connectivity using this method works in the following way:
- The SSH Client running on the user's endpoint connects through SAC to the Zero Trust Bastion. This connection is authenticated either via One-Time token or SAC SSH Key and has the user's IdP identity associated with it.
- Upon establishing a connection to the Zero Trust Bastion, an ssh client is automatically launched, opening an SSH connection to an Internal Server. Stdin/Stdout of two connections are joined. The authentication to an Internal Server is performed using the Transparent Agent Forwarding functionality of the SAC (TM). In order for this authentication to work, the server needs to be provisioned with a Public CA key of the SAC Certificate Authority.
- Every command executed by the user during the session gets inspected and audited by the SAC (TM)
Example:
Assuming that our company name is ACME, our Zero Trust Bastion is configured with SAC under the name of Bastion1 and has a local user account named bastion-account. Additionally, we have a number of internal servers in the 10.10.1.X network, each and every one of them has a local account called internal-account.
The user will be able to run the following commands to connect to internal servers:
For hands-on evaluation, please copy this command-line template:
ssh -t [email protected]@bastion1.company_name.luminatesec.com ssh [email protected]
|
Usability Tip: when using a command-line ssh client, defining a shell alias can simplify the above connection string even further. Connecting to internal servers via this alias will look like: lum-ssh 10.10.10.2 |
Transparent Confidential SSH Proxy
This solution allows users to connect with SSH Client directly to Internal Servers by using their internal IP address (or internal DNS name), while creating a secure TCP tunnel through the Zero Trust Bastion server and SAC (TM). With this approach, the SSH connection is established end-to-end between the SSH Client and the Internal Server, while SAC Cloud and the Zero Trust Bastion are authenticating the user and are providing a "pipe" for the secure connection. Using this approach, if allowed by the administrator, users can execute commands confidentially on internal servers, not allowing any external inspection.
Additionally, as an SSH connection is opened directly from the SSH Client to the internal server, the SSH client should take care of authentication to the internal servers, either using passwords or other authentication schemes, such as RSA Keys, Certificates, etc...
Main advantage of this approach is its relative simplicity (establishing the connections is not very complex and can be further simplified by taking configuration steps) accompanied by full confidentiality of the connections, that are encrypted end-to-end from the end-users' clients to the actual server. The disadvantages that should be considered are the fact that the end-user remains responsible for the authentication to the server and lack of ability to inspect the activity that takes place during the session, due to the end-to-end encryption. For environments where inspection of activity inside the connection is imperative, one can disable the users' ability to use this access by hardening the sshd_config file settings.
As a pre-condition to using this method, the Zero Trust Bastion should be registered with the SAC as an SSH Application with access permissions for the relevant IdP accounts.
The structure of the SSH connections (depicted below with an OpenSSH client commands below) is:
Using ProxyJump SSH option:
or, using the -o argument:
Please note the additional "[email protected]" prefix before the [email protected]@bastion.customer_name connection string it is required due to a particular implementation of user name parsing/tokenization in the OpenSSH client and will not be required when using other SSH clients.
Same command-line options or configuration files can be used with scp command as well.
Using ProxyJump SSH option with ~/.ssh/config configuration file:
Add the following lines to the ~/.ssh/config configuration file:
Host
ProxyJump [email protected]@[email protected]_name.luminatesec.com
and then run the following command:
Using ProxyCommand SSH option:
Same command-line options or configuration files can be used with scp command as well.
Using ProxyCommand SSH option with ~/.ssh/config configuration file:
Add the following lines to the ~/.ssh/config configuration file:
Host
ProxyCommand ssh -W %h:%p [email protected]@bastion.customer_name.luminatesite.com
and then run the following command:
Example:
Assuming that our company name is ACME, our Zero Trust Bastion is configured with SAC under the name of Bastion1 and has a local user account named bastion-account. Additionally, we have a number of internal servers in the 10.10.1.X network, each and every one of them has a local account called internal-account.
The user will be able to run the following commands to connect to internal servers:
ssh -J [email protected]@[email protected]_name.luminatesec.com [email protected]
ssh -o ProxyCommand="ssh - W %h:%p [email protected]
Automatic Registration of Dynamic Hosts with SAC Management API
This solution allows users to connect with SSH Client directly to Internal Servers by registering (and, if needed, deregistering) each and every one of them as a separate "SSH Application" with SAC (TM). The registration can happen automatically by using SAC Management API. The API Client can be executed either on the internal server itself (will require connectivity to SAC Management HTTPS Endpoints via port 443) or by an external mechanism, such as, but not limited to, Configuration Automation Mechanism or a mechanism that responds to changes in the environment, such as Amazon Web Services (AWS) Lambda that can execute custom login upon spinning-off a dynamic Internal Host.
As access to SSH Servers with the SAC (TM) is based on Domain Names, rather than IP addresses, the mechanism registering dynamically created Internal Hosts should generate a dynamic name that should either include a descriptive identification of a host, or should create a pseudo-name (similar to the way AWS is handling this) that represents the IP address, like internal_host_10_10_10_1.company_name.luminatesec.com
Main advantage of this approach is the ability to define a granular access control for each dynamic host, based on its properties. Along with registration of the host with the SAC Management API, it can be associated with particular users or groups in the enterprise IdP, as well as with additional properties, such as ability to create SSH sessions with certain high-privileged or low-privileged local SSH accounts, etc...
In order to benefit from these capabilities, the organization needs to implement a registration/de-registration of dynamically created hosts. Up-to-date documentation of the high-level API can be found at: https://api.luminate.io
