Starting with version 10.1 for Linux and 10.2 for Windows, RightLink is capable of routing all its traffic through an
external proxy for both all workflows (
install at boot,
The proxy server must support the HTTPS CONNECT protocol. SOCKS is currently not supported, and no HTTP requests are made by the RightLink client. Basic authentication is also supported by passing the username and password in the url itself. Digest and more advanced authentication schemes such as NTLM or Kerberos are not currently supported.
http_proxy, https_proxy, HTTP_PROXY, and HTTPS_PROXY will also be set in the execution environment of your scripts/recipes if RightLink is proxied. no_proxy and NO_PROXY will also be set if the no_proxy parameter is passed. Many unix programs (apt-get, yum, curl, rsc) will honor these parameters if set.
Configuring your proxy
RightLink communicates back with the RightScale platform in 4 ways:
- HTTPS requests to the RightScale API servers, such as us-3.rightscale.com
- HTTPS requests to the island load balancers (such as island1.rightscale.com) to download attachments and cookbooks.
- Websocket requests to the RightScale routers.
- HTTPS requests to the RightScale TSS servers, such as tss-3.rightscale.com.
The websockets protocol is built on top of HTTPS and from the perspective of the proxy server it is an HTTPS connection that is kept open indefinitely. Requests are periodically sent on the websocket (every 5 minutes). In order to accommodate the websocket connection, make sure the inactivity timeout is at least 15 minutes and read timeouts are as high as possible.
SSL/TLS Intercept Proxy Notes:
SSL/TLS interception proxy works by negotiating two sessions:
- Acts as the client on the server side
- Acts as server on the client side
- Generates new server key pair on client side
When properly configured the SSL/TLS intercept proxy should be somewhat transparent to RightLink and should not impact RightLink communication. The details for properly implementing and configuring SSL/TLS intercept proxies vary by manufacturer and as such these details are beyond the scope of this brief document -please refer to your manufacturer's specific documents on implementation and configuration. In general, the best practice guidelines for implementing and configuring SSL/TLS intercept proxies are outlined below.
- Transitive root/x.509 trusts should be established without any certificate validation flaws
- Key pair caching and indexing should be working correctly for both first visit and subsequent visits
- Websockets should be supported
- Failure modes should be properly planned and accounted for such as passthrough in the case that the proxy goes down. If not passthrough then the intercept proxy becomes the single point of failure. Each failure mode: passthrough, fail close, friendly error has some trade offs.
- Updating/Patching procedures should be planned and defined, and should include using a test ssl intercept proxy appliance when applying patches and updates vs. applying updates and patches to a live production proxy appliance.
- All Testing passes e.g. Qualys SSL/TLS security scanner or others
Enabling a Running Instance
To use a proxy when enabling a running instance, pass the
-x proxy_url and
-y no_proxy options to the
rightlink.enable.sh script on Linux or to the
script on Windows as shown in the following example. For further details, see Enable Running Instances
for Linux or Windows.
curl -s https://rightlink.rightscale.com/rll/10.5.2/rightlink.enable.sh | sudo bash -s -- -l -k "e22f8d37...456" -t "RightLink 10.5.2 Linux Base" -n "Test Server" -d "RightLink Enabled Test" -c "amazon" -x "http://basicuser:email@example.com:3126" -y "dontproxy.com"
$wc = New-Object System.Net.WebClient $wc.DownloadFile("https://rightlink.rightscale.com/rll/10.5.2/rightlink.enable.ps1", "$pwd\rightlink.enable.ps1") Powershell -ExecutionPolicy Unrestricted -File rightlink.enable.ps1 -refreshToken "e22f8d37...456" -serverTemplateName "RightLink 10.5.2 Windows Base" -serverName "Test Server" -deploymentName "RightLink Enabled Test" -cloudType "amazon" -Proxy "http://basicuser:firstname.lastname@example.org:3126" -NoProxy "dontproxy.com"
Installing at Boot and Custom Image
To use a proxy for a RightLink agent installed at boot via cloud-init for Linux, you may set tags on your RightScale Server of the form
rs_agent:http_no_proxy=url list. For example, set these tags on your Server before launch:
Alternatively, user and password can be specified as separate tags which allows the use of Credentials:
rs_agent:http_proxy_user=<user>|cred:<CRED>-- Allows setting the user to use along with the
rs_agent:http_proxy_passwordtags. Its value can be either a plain text user or a reference to a Credential. It must be specified along with
rs_agent:http_proxy_passwordand may only be specified when
rs_agent:http_proxyis specified as well.
rs_agent:http_proxy_password=cred:<CRED>-- Allows setting the password to use along with the
rs_agent:http_proxy_usertags. Its value can be a reference to a Credential which allows hiding the sensitive password value when viewing server or server array tags. It must be specified along with
rs_agent:http_proxy_userand may only specified when
rs_agent:http_proxyis specified as well.
rs_agent:http_proxy=10.0.0.0:3128 rs_agent:http_proxy_user=basicuser rs_agent:http_proxy_password=cred:BASIC_PASS
These tags will also work for images with Cloud-init and RightLink pre-installed for Linux or RightLink pre-installed for Windows.
In a VPC or Private Network
In a network with very limited outbound access, install-at-boot scenarios become a bit more complicated. Bootstrapping relies on cloud-init downloading and running an install script. This can be done two ways, one of which is proxy friendly and one of which isn't.
- If a proxy server must be used in the VPC or private network to gain access to the URL containing the rightlink install script, then use the
rs_agent:mime_shellscripttag. This tag is set to the URL for downloading the rightlink install script, exactly like
mime_include_url. However, this tag will add the proxy information from the
rs_agent:http_proxytag into the runtime environment used to download and execute the shell script specified in the URL. This is needed because cloud-init by default in not proxy aware (https://bugs.launchpad.net/cloud-init/+bug/1089405?comments=all).
- If the VPC or private network has direct or NATed outbound access, one can use the
rs_agent:mime_include_urltag on your MCI. This tag will leverage cloud-init's native x-include-url functionality to try and directly download the shell script specified. Since cloud-init is not proxy aware this tag can NOT be used in combination with the
rs_agent:http_proxytag or a manually configured proxy server. If a proxy server is required for access to the shell script URL specified the script will fail to download.
If not sure which of the above rs_agent tags to use, the
rs_agent:mime_shellscript tag works in either situation.
In addition to the above solutions, there are a number of network level solutions to allow outbound access:
- Create a rule to allow outbound access to
rightlink.rightscale.comfor your network.
- Create a custom image with RightLink 10 pre-installed. The
x-mime-include-urltag can be left off as RightLink will already be installed.
- Create a proxy to
rightlink.rightscale.comin your private network and have the
rs_agent:x-mime-include-urlreference that instead.