ISC/VA: no_proxy set incorrectly

What problem are you observing?

Excluding multiple hosts from the proxy configuration is done incorrectly.
If you add the following line to the VA /home/sailpoint/proxy.yaml (values separated by the pipe char | as requested by SailPoint’s documentation):

no_proxy: web1.example.com|web2.example.com

this setting will be added to /etc/systemd/system.conf.d/10-default-env.conf and /etc/profile.env like this:

DefaultEnvironment=HTTP_PROXY=http://10.10.10.10:8080/ http_proxy=http://10.10.10.10:8080/ \
   HTTPS_PROXY=http://10.10.10.10:8080/ \
   https_proxy=http://10.10.10.10:8080/ \
   NO_PROXY=web1.example.com|web2.example.com \
   no_proxy=web1.example.com|web2.example.com

These lines will be added to /home/sailpoint/docker.env:

NO_PROXY=web1.example.com|web2.example.com
no_proxy=web1.example.com|web2.example.com

Only Java mandates using the | character as a separator for it’s non-proxy system property http.nonProxyHosts (https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html). Take note that this is a command line parameter to the java application, not the no_proxy environment variable.

More than this, every time you log onto the VA and the profile is loaded you get this error messages as the | is used to separate commands:

------------------------------------------------------------------------

   _|_|_|            _|  _|  _|_|_|              _|              _|
 _|          _|_|_|      _|  _|    _|    _|_|        _|_|_|    _|_|_|_|
   _|_|    _|    _|  _|  _|  _|_|_|    _|    _|  _|  _|    _|    _|
       _|  _|    _|  _|  _|  _|        _|    _|  _|  _|    _|    _|
 _|_|_|      _|_|_|  _|  _|  _|          _|_|    _|  _|    _|      _|_|

------------------------------------------------------------------------
----------     VA - .....                                           -----------
------------------------------------------------------------------------
-bash: web2.example.com: command not found
-bash: web2.example.com: command not found

What is the correct behavior?

Setting one value for one application (Java) using a specific format should not be used for another application (no_proxy env variable) without converting it to the correct format.

When setting the no_proxy / NO_PROXY environment variables, the | should not be used and it should be replaced with a comma ,.

What product feature is this related to?

From Configuring Virtual Appliances - SailPoint Identity Services

no_proxy: <host1>|<host2>

Where <hostN> can either be a domain or an IP address. This can contain any number of hosts separate by pipe (|) symbols.

I couldn’t find a piece of documentation who shows that | should be used for the no_proxy environment variables, so I am unsure why SailPoint does it.

What are the steps to reproduce the issue?

  • Add/replace the following line in /home/sailpoint/proxy.yaml. Add a proxy as well:
no_proxy: web1.example.com|web2.example.com
  • sudo reboot
  • log into the system as sailpoint
  • check the error message
  • using curl check if the web2.example.com is excluded from the proxy configuration

Do you have any other information about your environment that may help?

No.

Thank you for taking the time to submit this bug. Is the issue with our VA documentation, or the VA itself? If it is an issue with the documentation, can you please provide a link to the problematic docs?

Hi @colin_mckibben , this is a problem with the VA.

The VA should continue passing the setting to the CCG service, but replace the | with a , before setting the string in the different files (profile.env, docker.env).

Thank you for clarifying. An engineering ticket has been created to investigate this issue (SAASVA-239).

@adamian - Thank you for pointing this issue out. A fix for this should be shipping out soon.

2 Likes

So, it’s going to be soon, but VA infra releases are slower by design.

The code is in final testing stages. Releases of VA infrastructure code have to be heavily validated since there is always a risk that a release could break in a way that requires manual intervention by customers to resolve the issue.

If you have a support case, you can ask that they check with the engineering team/DevOps about an early release of this fix to your environment(s).