Minishift and the Enterprise: Proxies

Posted: March 8th, 2018 | Author: | Filed under: Technology | Tags: , , , | 3 Comments »

Cross Transport

In part 1 of this series, an overview was provided on how to install and configure Minishift/Container Development Kit (CDK) for use in an enterprise environment. During this discussion, the primary concern focused on the preparation of the host with the proper prerequisite software and to confirm the user executing the tool has the appropriate access to execute the required commands for operation. For those who have spent any amount of time in an enterprise environment, one of the primary challenges is how to manage resources that have a dependency on communicating with external resources.

Most organizations have some form of security or filtering layer that all ingress and egress traffic must traverse through before reaching the intended destination. These types of systems are commonplace and take the form of a software or hardware proxy and are implemented for security and compliance reasons. Computers on a corporate network are preconfigured to redirect all traffic (typically at an Operating System level) through the proxy before being allowed on the public Internet.

Unfortunately for developers (and in reality all users), proxy servers tend to cause the most distress and can negatively affect their productivity. Users must be cognizant of the transport mechanisms involved in any tool they are working with and any reliance on external systems. In addition, they must have the knowledge and understanding of whether the tool supports proxying connections, and if so, how to complete the configuration. With an understanding of the vital role proxies play in an enterprise setting, the remainder of this discussion will provide an overview on the support Minishift has for proxy servers and the various ways the various included components can be configured.

Determine required external resources

Minishift is one of those tools that makes requests to external resources. Over the course of normal operation, several different external resources are accessed by the various components within not only Minishift’s architecture, but also the underlying OpenShift ecosystem. When working a proxy in any corporate environment, one of the first questions before determining how to configure the tool for proxy support is to pinpoint the list of resources that the tool will need access to and if access is currently allowed. This step is akin to the process that was completed in the prior blog post for determining any prerequisite software Minishift needed. In addition, having a list prepared upfront aids in any discussion with security teams or as part of a site exemption process.

The following is a high level list of sites that Minishift requires access to for minimal operation.

  • Docker Images (From DockerHub)
    • docker.io – Authentication and registry
    • cloudfront.net – Image content is served through the CloudFront CDN
  • Red Hat Container Catalog
    • registry.access.redhat.com
    • access.redhat.com
  • Red Hat Subscription Manager (CDK)
    • subscription.rhsm.redhat.com
  • Build assets
    • If external resources are being leveraged such as source code from github.com or build artifacts from the Maven public repository.

OpenShift and Proxies

With an understanding of the different types of external resources that are accessed during the normal operation of Minishift, how are they used by the various included components? I would be flat out lying if I were to say that the proxy configuration in OpenShift and its components are straightforward. In fact, there is an entire document dedicated to detailing the components that have proxy support and the mechanisms in which they can be configured. These include:

  • Master and node services
  • Docker
  • Image builds
  • Usage in running containers

As you can see, the number of components is not trivial and each has their own set of configuration files and rules that can be applied. At times, it can be dizzying.

Configuring Minishift for Proxies

Fortunately, Minishift takes away the majority of the pain involved with managing proxies by supporting the auto configuration of many of the items presented in the prior section through a set of startup flags and options. Since proxies are typically targeted at managing HTTP traffic, there are three primary considerations:

  • How to manage insecure traffic (HTTP)
  • How to manage secure traffic (HTTPS)
  • Which type of traffic should not be routed through the proxy

Most operating systems provide support for these items through a set of configurable variables:

  • http_proxy
  • https_proxy
  • no_proxy
  • (Along with their all uppercase counterparts).

Likewise, proxy support in Minishift is facilitated by making use of these types of variables. Let’s see how to configure Minishift to make use of a proxy.

The most declarative method for managing proxy connections is to specify the options as parameters when starting Minishift with the minishift start command. As indicated previously, three command line options are available: The –http-proxy option is used for insecure communication while –https-proxy for secure communication. Finally, –no-proxy allows for a list of addresses to be provided which will not make use of a proxy.

For example, to start Minishift and to configure the instance to make use of a proxy server listening at http://corporate-proxy:8080 and to avoid using the proxy for a resource located at internal-resource.mycorp.com, the following command can be executed:

minishift start --http-proxy=http://corporate-proxy:8080 --https-proxy=http://corporate-proxy:8080 --no-proxy=internal-resource.mycorp.com

Note: If authentication is required to communicate with the proxy, it can be provided using the format “http://<user>:<password>@<ip_addr>:<port>”

You can verify Minishift is being configured with proxy support when the following appears during startup:

-- Setting proxy information ... .OK

Instead of specifying the proxy parameters each time Minishift is started, the values can be persistently set using the minishift config command as shown below using the aforementioned example values:

minishift config set http-proxy http://corporate-proxy:8080
minishift config set https-proxy http://corporate-proxy:8080
minishift config set no-proxy internal-resource.mycorp.com

So What Did Minishift Configure?

While an overview was provided that described the various ways proxies can be configured in OpenShift, which areas in particular did Minishift implement with regards to proxies?

  • Preflight checks to verify connectivity prior to launch
  • Host level operating system environment variables
  • Subscription manager to support registering the CDK
  • Docker daemon of the underlying host running the containerized version of OpenShift
  • Global build defaults to support accessing source code and build dependencies

If Only It Were That Easy….

Recall previously where I had mentioned that proxies cause the most heartache of all other obstacles in an enterprise environment? Well, even after Minishift is configured to make use of a proxy server, there are a number of gotcha’s that trip up even the most seasoned developer. Let’s discuss some of the areas that have been known to cause issues when working with Minishift and proxies.

Running Containers

Even though the docker daemon of the underlying host is configured with proxy support, these values are not inherited by the underlying containers. Instead, the container (or more accurately Pod), must be defined with values which the included components can make use of. These typically take the form of the aforementioned proxy values. The following is an example of how to define proxy values within a pod specification.

containers:
- env:
  - name: "HTTP_PROXY"
    value: "http://corporate-proxy:8080”
  - name: "HTTPS_PROXY"
    value: "http://corporate-proxy:8080”
  - name: "NO_PROXY"
    value: "internal-resource.mycorp.com”

As previously mentioned, it is up to the underlying application on how and whether it supports proxies.

Command Line

The most common method when interacting with Minishift is through the executable using the command line. Once Minishift is up and running, focus shifts to the running OpenShift cluster and management through the Command Line Interface (even though the web console is also available). While the majority of CLI commands specifically target the OpenShift cluster, there are several commands that have the potential to fail within an environment containing proxies. As part of the “oc new-app” and “oc new-build” commands, the target images and source code repositories are inspected in order to satisfy the actions of the command. If the target location requires the traversal through the proxy server and the proxy details are not within the command line environment, the query and subsequent commands will fail.

Fortunately, since most organizations configure proxies at an Operating System level, these values are inherited within the command line session. If they are not defined, set the HTTP_PROXY and HTTPS_PROXY environment variables accordingly. However, this does cause a problem with communicating with OpenShift along with Minishift itself. If the IP address of Minishift is not specified in the list of NO_PROXY values, traffic intended for Minishift will instead be bound for the proxy and in most cases terminate at that point as the proxy has no knowledge of the networking on an individual developers machine.

To add Minishift to the list of addresses that should bypass proxies, utilize the following steps:

Find the IP address of Minishift:

minishift ip

Take the address provided by the previous command and add it to the list of addresses:

export NO_PROXY=$NO_PROXY,<minishift ip>

OpenShift CLI commands should once again return valid results

Final thoughts

As has been described, Minishift provides a number of solutions for utilizing the tool within an environment that contains a proxy server. While the majority of the most common scenarios were addressed within this article, it is almost certain that there will be other situations depending on the environment for which the tool is deployed within. Fortunately, as a result of its core architecture for supporting proxies, Minishift has the capabilities to be leveraged successfully in an enterprise environment.