Chapter 1: Understanding Kubernetes API Accessibility

The Kubernetes API serves as the central nervous system of K8s, enabling communication between its components and external requests. All interactions are managed through the K8s API, where every element in Kubernetes is treated as an API object with a corresponding entry in the API server.

When a client, such as kubectl, sends a request to the Kubernetes API, it must pass through three critical layers: Authentication, Authorization, and Admission Control (if configured). In this guide, we will focus on enabling authentication and authorization to allow access to the API from our local terminal, while skipping admission control for simplicity.

Article Workflow:

The article consists of three primary steps:

1. Alter the Kubernetes service type from ClusterIP to NodePort.
2. Implement the authentication process.
3. Set up the authorization process.

Demo Requirements:

• Intermediate knowledge of Kubernetes.
• A functional Kubernetes cluster with at least one master and one worker node. For this demonstration, I am using two Ubuntu machines running on Google Cloud. Refer to my previous article for guidance on setting up a fresh cluster.

Note: Kubernetes services from cloud providers like EKS, AKS, and GKE are not applicable here, as they restrict access to the master node, which is essential for our task.

Section 1.2: Changing the Kubernetes Service Type

@ Master Node: SSH into the master node, switch to the root user, and list the primary Kubernetes services.

$ sudo su -

# kubectl get svc

Next, modify the service type to NodePort.

# kubectl edit svc kubernetes

spec:

clusterIP: 10.96.0.1

clusterIPs:

• 10.96.0.1

internalTrafficPolicy: Cluster

ipFamilies:

• IPv4

ipFamilyPolicy: SingleStack

ports:

• name: https

  port: 443

  protocol: TCP

  targetPort: 8443

sessionAffinity: None

type: NodePort

Check the new port added to the service.

@ Local Terminal: Use curl to access the external node IP on the newly assigned port. First, navigate to the Compute Engine service, list the Kubernetes cluster nodes, and copy the external IP of the master node for the following command.

This command should return an error indicating that the Kubernetes API server cannot verify the client certificate, which is expected at this stage.

Important: To curl the NodePort, create a firewall rule to allow access to this port.

$ gcloud compute firewall-rules create nodeports --allow tcp:30000-40000

Now, let’s bypass the SSL error by adding the -k option to allow insecure server connections when using SSL.

You should receive an error indicating you are authenticated but not yet authorized. Let’s return to the master node to set up the necessary authorization.

@ Master Node: Switch to root, list the Kubernetes configuration file, and copy its content.

$ sudo su -

# kubectl config view --raw

This configuration file contains the required key and certificate for a Kubernetes admin, which will be used in the next steps to access the Kubernetes API.

@ Local Terminal: Create a new file and paste the copied content.

$ vi config

Attempt to communicate with the cluster, specifying the configuration file.

$ kubectl --kubeconfig config get ns

Initially, you may receive no response because the IP in the configuration file is set to the internal IP of the master node. We will correct this in the next step.

Change the IP in the config file to the external IP of the master node.

Save the file and retry the command to communicate with the cluster.

$ kubectl --kubeconfig config get ns

You will likely encounter another error indicating that the certificate is only valid for certain internal IPs.

Unable to connect to the server: x509: certificate is valid for 10.96.0.1, 10.156.0.11

Next, we need to inspect the API certificate and adapt it for our local environment, which we will cover in the following section.

Chapter 2: Inspecting the API Certificate

@ Master Node: Navigate to the directory containing the Kubernetes certificates.

$ cd /etc/kubernetes/pki

Use the following command to inspect the API certificate.

$ openssl x509 -in apiserver.crt -text

The output will reveal that the certificate is only valid for specific IPs and domain names, which need to be configured locally for proper access.

@ Local Terminal: Modify your hosts file to add an entry for the Kubernetes master node's external IP.

$ vi /etc/hosts

The entry should look like this (the IP will differ in your case):

34.141.104.113 kubernetes

Next, change the server address in the configuration file to use the hostname instead of the external IP.

Try the previous command again, and you should be able to list the namespaces from your local terminal.

$ kubectl --kubeconfig config get ns

Happy Kubernetes! :)

Conclusion

In this guide, we explored how to access a Kubernetes cluster and examined the K8s API certificate for use in your local terminal. The Kubernetes API is a crucial component, so it's vital to proceed with caution when exposing it.

Feel free to share your thoughts or feedback, and connect with me on LinkedIn!

Chapter 3: How Does Kube API-Server Work?

In this next section, we will delve deeper into the workings of the Kube API-Server and its interaction with the Controller-Manager.

Chapter 4: Simplifying Kubernetes with Cluster API

Finally, we will explore how the Cluster API can simplify working with Kubernetes, making it easier for developers and operators alike.