December 19, 2017 By John Kasperski 2 min read

Connecting your Kubernetes cluster to on-premises resources

Writing microservices in containers and deploying them to a Kubernetes cluster running on IBM Cloud is a great way to create greenfield applications. Frequently you’ll also have mountains of useful data hosted by on-premises systems.  What if you can’t migrate this data to the cloud due to compliance reasons, but you still want to allow your new microservice application to leverage it?

In the IBM Cloud Container Service you can use a Vyatta Gateway Appliance or Fortigate Appliance as an IPSec VPN endpoint to connect your Kubernetes cluster to your on-premise datacenter. This allows your services running in Kubernetes to communicate with on-premise applications and resources through a secure encrypted tunnel.  Information on how to configure the IPSec VPN endpoint with a Vyatta Gateway Appliance can be found here.

Setting up a Vyatta Gateway Appliance or Fortigate Appliance as an IPSec VPN endpoint is not a simple, straight forward task.   The complexity and cost of both of these appliances makes them unattractive solutions when you have a single small Kubernetes cluster or multiple small clusters located in different IBM Cloud regions. The IBM Cloud Container Service now supports a third IPSec VPN method, the Strongswan IPSec VPN service, which resolves these concerns.

Strongswan IPSec VPN service

Unlike the Vyatta Gateway Appliance or Fortigate Appliance solutions which sit outside of your cluster, the Strongswan IPSec VPN service is completely integrated within your Kubernetes cluster. The IPSec VPN endpoint is provided as a Kubernetes pod. Configuration, deployment, and management of the Strongswan IPSec VPN service is also much easier since the normal Kubernetes commands can be utilized. Better yet, there is no additional charge for using the Strongswan IPSec VPN service.

The Strongswan IPSec VPN service consists of a Kubernetes service, a deployment, a daemon set, and multiple config maps. All of these resources and bundled together and delivered as a single Kubernetes Helm chart:

  • Configuration of the VPN service is provided by setting a handful of fields in a config yaml file. If unique VPN settings are required, a complete IPSec configuration file can be specified.

  • A single Helm install command deploys the Strongswan IPSec VPN configuration and automatically creates all the required Kubernetes resources.

  • Once VPN connectivity is established with the on-premises data center, a Kubernetes daemon setconfigures routing on each of the worker nodes.

  • Helm provides additional commands that allow: statusupgrade , rollback , and deletion of the VPN service after it has been deployed.

For more information on how you can use the Strongswan IPsec VPN service to securely connect your worker nodes to your on-premises data center, see Setting up VPN connectivity with the Strongswan IPSec VPN service in the IBM Cloud Container Service documentation.

More from Open source

Cultivating Careers, Communities and Companies with Open Source

6 min read - The soft skills you need to succeed in open source. I've had the privilege of working in open source for the last 20+ years. I started off as a volunteer, as most do in open source, attempting to learn something new. Even though I didn't fully understand what open source was at the time, I really involved myself in the community and got so much in return. While running small projects, I learned an incredible amount about the skills needed…

How to Use an Ansible Playbook to Manage Secrets for Infrastructure Provisioned on IBM Cloud

6 min read - Instructions and code that show you how to use Ansible playbooks to manage the lifecycle of a secret in IBM Secret Manager. IBM Cloud Secrets Manager is built on open-source HashiCorp Vault, and it allows you to dynamically create and manage secrets. For infrastructure or services provisioned from IBM Cloud, you need to rotate the secrets on a timely basis. What is an Ansible playbook? Many IT teams have a common requirement to manage the configuration for systems in an…

Kubernetes Audit Logs: Answering the Who, When and What

3 min read - Learn how to set up log forwarding and collect audit logs that are passed through the Kubernetes API server to IBM Log Analysis to check who initiated a request and when they did so. As a cluster administrator, by following the simple steps in this blog post, you should be able to answer questions about Kubernetes audit logs, like who initiated a request to delete a Kubernetes resource? When did it happen? On what did it happen? What are audit…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters