Configure local kubectl to access remote Kubernetes cluster

Kubernetes is a very popular and widely deployed container management and orchestration platform, preferred by devops engineers worldwide today.

Usually Kubernetes clusters are not exposed to the public Internet but the apps running in them are.

In this article, I’ll discuss how to configure a local kubectl to remote access your Kubernetes cluster or minikube running in a server in your lab or private cloud or public cloud (AWS, MS Azure, GCP, Digital Ocean etc.).

Prerequisites:

You are expected to have a basic understanding on:

• How to configure and setup a Kubernetes cluster or minikube
• How to run a Docker container as a Kubernetes deployment and service
• What kubectl and kubeadm tools are and how they are used for Kubernetes cluster, pod management and orchestration.
• You have a working Kubernetes Cluster or Minikube setup already.

Overall strategy — In a nutshell

The kubectl CLI utility talks to the Kubernetes cluster via the cluster’s API server. As long as we could make the cluster’s API server accessible from your laptop, we could access or manage your remote Kubernetes cluster or minikube through a local kubectl instance installed on your laptop.

Enabling secure remote access to the cluster’s API server over the public internet is key here. We’ll use SocketXP VPN solution (SSL/TLS tunnels) to provide secure remote access to the cluster’s API server. SocketXP VPN solution has a free plan for beginners.

Setup a Kubernetes cluster or Minikube

To begin with setup a Kubernetes cluster or Minikube instance on your laptop. The aim of this article is not to teach you how to setup a Kubernetes cluster or Minikube. So let’s jump straight into our task at hand, that is, configure local kubectl to remote access Kubernetes cluster or minikube.

Install, Setup and Configure Kubectl for remote access to Kubernetes cluster

Follow the below instructions to setup and configure kubectl locally on your laptop for remote access to your Kubernetes cluster or minikube.

Step #1 — Install and Setup local Kubectl

Install the kubectl CLI utility on your laptop (Mac/Windows/Linux version) from the Kubernetes project’s public repository. Instruction on how to install and setup kubectl are described here in detail.

Step #2 — Copy the kubectl config file

Now go to your Kubernetes cluster’s master node or minikube that you have setup in the previous section and copy the kubectl config file from there to your laptop.

Usually the kubectl config file is stored at: $Home/.kube/config in the master node of your remote Kubernetes cluster. This is the config file used by the kubectl utility installed in your remote cluster’s master node.

Note: kubectl is one of the utilities installed in any Kubernetes cluster or minikube during a cluster setup.

$ cat ~/.kube/config
apiVersion: v1
clusters:
- cluster:
 certificate-authority: /home/test-user/.minikube/ca.crt
 server: https://192.168.99.100:8443
 name: minikube
contexts:
- context:
 cluster: minikube
 user: minikube
 name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
 user:
 client-certificate: /home/test-user/.minikube/profiles/minikube/client.crt
 client-key: /home/test-user/.minikube/profiles/minikube/client.key

The above kubectl config file was captured from a remote server running minikube cluster.

Copy this kubectl config file to your laptop and replace any existing config file at $HOME/.kube/config in your laptop.

Step #3 — Copy the SSL certificates and private key

Next, you should copy the SSL certificates and private key used by the kubectl utility installed in the master node of your remote Kubernetes cluster, to your local laptop.

Copy the CA certificate (ca.crt), client certificate (client.crt) and client private key (client.key) files from your remote Kubernetes cluster to your local laptop.

The location of these files in the master node of your remote cluster is specified in the kubectl config file you copied in Step#2 (look for the bold text fields in the config file above).

You could download these certificate and key files to any directory in your local laptop, as long as you update their full path in the appropriate fields in your local kubectl config file (again look for the bold text fields in the config file shown above).

Step #4 — Install and setup SocketXP agent

For the locally installed kubectl instance to remote access your Kubernetes cluster’s API server running at https://cluster-ip-address:8443, you need to setup a public we URL for the API server, so that you could access and manage the cluster from anywhere in the internet.

SocketXP SSL/TLS VPN tunnels provide a secure, private and lightweight communication channel and a public URL to remote connect to your private Kubernetes cluster’s API server over the internet. Moreover, SocketXP VPN solution is free (checkout the “Tunnel Free Plan” here).

Follow the instructions here to download and install SocketXP agent docker container on your Kubernetes cluster or minikube as a standalone container deployment.

Standalone Container Deployment:

First go to SocketXP Portal. Signup for a free account and get your authtoken there. Use the authtoken to create a Kubernetes secret as shown below.

$ kubectl create secret generic socketxp-credentials --from-literal=authtoken=[your-auth-token-goes-here]

Verify that the secret socketxp-credentials got created.

$ kubectl get secrets
NAME                   TYPE                                  DATA   AGE
default-token-5skb7    kubernetes.io/service-account-token   3      4h
socketxp-credentials   Opaque                                1      4h
$

We’ll use the below config.json file to configure the SocketXP agent Docker container. In this example, we are trying to create a secure public web URL and a TLS VPN tunnel to the Kubernetes API server.

$ cat config.json
{ 
    "tunnel_enabled": true, 
    "tunnels" : [{ 
        "destination": "https://kubernetes.default", 
        "protocol": "tls", 
        "custom_domain": "", 
        "subdomain": "" 
    }], 
    "relay_enabled": false, 
}

Next create a Kubernetes configmap to store the above SocketXP agent configuration file.

kubectl create configmap socketxp-configmap --from-file=/home/test-user/config.json

Verify that the socketxp-configmap got created.

$ kubectl describe configmaps socketxp-configmap
Name:         socketxp-configmap
Namespace:    default
Labels:       <none>
Annotations:  <none>
Data
====
config.json:
----
{ "tunnel_enabled": true, "tunnels" : [{ "destination": "https://kubernetes.default", "protocol": "tls", "custom_domain": "", "subdomain": "" }], "relay_enabled": false }
Events:  <none>

Now that we have created the authtoken secret and the configmap needed by the SocketXP agent, it’s time to launch the SocketXP Docker container expresssocket/socketxp:latest as a Kubernetes Deployment.

Here is the deployment.yaml file we'll use to create a standalone SocketXP agent deployment.

$cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: socketxp
  labels:
    app: socketxp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: socketxp
  template:
    metadata:
      labels:
        app: socketxp
    spec:
      containers:
      - name: socketxp
        image: expresssocket/socketxp:latest
        env:
          - name: AUTHTOKEN
            valueFrom:
              secretKeyRef:
                name: socketxp-credentials
                key: authtoken
        volumeMounts:
        - name: config-volume
          mountPath: /data
      volumes:
        - name: config-volume
          configMap:
            # Provide the name of the ConfigMap containing the files you want
            #to add to the container
            name: socketxp-configmap

Note:
We have created a separate volume named config-volume and mounted it under /data directory inside the container, so that the socketxp-configmap will be available as a config.json file under the /data directory in the running container.

Next, check if the pods are created from the deployment and running.

$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
socketxp-75cb4dd7c9-bhxfp   1/1     Running   0          4s
$

Now you can retrieve the SocketXP Public URL created for your Kubernetes API server from the SocketXP Portal Page at: https://portal.socketxp.com/#/tunnels (opens new window) or from the pod logs as shown below.

$ kubectl logs socketxp-75cb4dd7c9-bhxfp
...
...
Login Succeeded.
User [] Email [test-user@gmail.com].
Connected.
Public URL -> https://test-user-fn4mda420.socketxp.com

Step #5 — Update the API server URL

You can now use the above SocketXP Public URL to access the Kubernetes Cluster’s API server remotely using a kubectl utility or directly using your custom application.
If you are using a locally installed kubectl utility from your laptop to remotely access the Kubernetes, then update the API server URL in the kubectl config file located at $HOME/.kube/config to use the SocketXP Public URL https://test-user-fn4mda420.socketxp.com

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/test-user/.minikube/ca.crt
    server: https://test-user-fn4mda420.socketxp.com 
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
...
...

Please ensure that you also copy the client certificate, CA certificate and private key files from your Kubernetes cluster’s master node to your laptop in the appropriate folder as specified in the kubectl config file.
Verify that the config works fine, using the following command:

kubectl config view

Step #6 — Access your Kubernetes cluster remotely from your laptop

Next, you could execute any kubectl commands such as ‘kubectl get pod’ or ‘kubectl get service’ from your laptop and the remote API server should respond back with the status of your pods running in your remote Kubernetes cluster or minikube.

$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
socketxp-75cb4dd7c9-bhxfp   1/1     Running   0          1h

Hope that was easy and straight forward to setup it up.

Advantages of SocketXP SSL/TLS VPN over other VPN solutions:

• SocketXP SSL/TLS VPN is a L4 VPN (unlike L2 or L3 VPNs such as MACsec or IPsec, respectively). So remote access to only one specific application in a private network is allowed (unlike L2 or L3 VPNs which permit access to an entire private network).

• SocketXP SSL/TLS VPN tunnels, like any VPN software, supports client authentication via TLS client authentication. So only a client application (kubectl instances in this case) with a valid TLS client certificate could access or talk to the remote server (Kubernetes cluster API server in the example above). No rogue user or app from the internet could access the server application made accessible via a SocketXP public URL.

• SocketXP TLS tunnels are extremely lightweight unlike OpenVPN or other IPsec VPN softwares in the market, but it provides the exact same level of security (using the same SSL encryption technology) provided by OpenVPN or other IPsec VPN softwares. SocketXP uses the same encryption technology (SSL encryption) used by banks, financial institutions and Governments to securely transfer confidential data over the public internet.

• SocketXP assigns you a unique public URL for your server application with random strings in it, that eliminates any guess work for the random Public URL uniquely assigned to you. This adds an additional level of security, in the first place.

• SocketXP TLS VPN solution enables app-to-app communication only and not network-to-network communication. This drastically reduces the scope for any attack surface. The traffic from the internet over the VPN cannot go beyond the private IP:port boundary.

• Moreover, SocketXP VPN Cloud Gateway is an online SaaS service that eliminates the need to run any VPN server in your private cloud or the need to run a VPN client software on your access devices such as laptops.

• And it’s free. Can it get any better than this? Checkout the “Tunnel Free Plan” here.

Have a question or comment, leave it below. Alternatively, you could write to us at: support@socketxp.com

Note: This article was originally published at: https://www.socketxp.com/blog