Kubernetes REST API

Amit Cohen
5 min readDec 31, 2022

--

As your Kubernetes cluster is in production and used by developers you may want to create scripts for different purposes like how many resources were made, which resources are not used anymore, cleaning up resources plus some developers wishing to automate pulling information. Still, they don't remember all kubectl commands or some even don't have kubectl installed on their machines. To address these issues you may want to use Kubernetes REST API.

First, you need to know the location of the cluster and its credentials. With: the kubectl config view we can view the location and credentials that kubectl knows and uses to access or connect to the cluster. The question is what to do when you want to access using: curl, wget, or browser? How do we provide credentials for them? There are two ways to do that:

  1. kubectl proxy- we can use kubectl proxy mode, what it does is it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. For example: executing kubectl proxy — port=8080 & will start a reverse proxy 127.0.0.1:8080 on the local host. If we run curl HTTP://localhost:8080/api which is the API server endpoint. we will get the below screenshot. Using the api endpoint we can access namespaces and versions. That's the simplest way to use and access Kubernetes REST api.
Using localhost, we know the location and kubectl handles credentials

2. Direct use of Kubernetes REST api without kubectl proxy — using this method we will have to pass credentials ourselves to the client so it can connect to the cluster, it has to be assigned to a user and authenticate him into a user in Kubernetes. With kubectl you have it configured in /kube/config file. In our case, it is the admin that can access anything. Let's say we want to create a script that clears old services and deployments that are not being used, and we want to run the script with a user that has limited permissions. We don't want to run it as an admin user but rather have a specific user for such tasks to limit security risks. As you remember from my previous posts for not user operations for executing scripts or applications we have a service account in Kubernetes.

Creating ServiceAccount with permissions

I will use an example to explain the creation and management. First, to create a service account you will need to: kubectl create serviceaccount [name], once it is created you need to create a service- role YAML for it, see the example below:

First, apiGroup is the core services which pod and services belong, and the second is for apps, created in the default namespace

After applying the above YAML we must create a binding between the role and the service account, see below the command:

kubectl create rolebinding [name]— role=script-role — serviceaccount=default:[serviceaccount name]

Now we have a service account with respective permissions.

ServiceAccount Token

To connect to Kubernetes api using a service account we will need the credentials which is the service account token. To get it you need to look for the secret name that we can find in the service account YAML we created. The secret includes the token init. To get it type:

kubectl get secret [secret name] -o yaml

Remember tokens are 64-encoded so you will need to decode it first: echo [token] | base64 — decode | tr -d “\n”

You may want to reference the result into a variable to simplify its usage of it. Another thing you need is the cluster location and you can get it via kubectl get view. You may want to reference it to variables as well.

Connecting with Kubernetes REST API

There are several API calls you can use:

  1. GET — querying data
  2. POST — creating resources
  3. PATCH — partially updating resources
  4. PUT — replacing resources
  5. DELETE — deleting resources

An example of a GET call will look like this:

curl -X GET [cluster]/api — header “Authorization: Bearer [token]”

In secure communication when the client talks to the server, the client needs to know that server is legit. Fo that the client needs to validate the CA who signed the certificate of the server. In our case curl is the client so we need to add the following:

curl -X GET [cluster]/api — header “Authorization: Bearer [token]” — cacert /etc/kubernetes/pki/ca.crt

In case you don't have the CA and you know it is your server Kubernetes REST api allows you to skip that part and not required certificate validation from the server. The syntax looks like this:

curl -X GET [cluster]/api — header “Authorization: Bearer [token]” — insecure

Interacting with Kubernetes REST API

You may be wondering how I know what is the endpoint of any information that you want to get from the cluster. How to get information about pods, or services, logs of a specific pod, or creation date from the rest api. The good thing is that you don't need to know it by heart it is all documented in Kubernetes documentation. API Groups are part of Kubernetes and different Kubernetes resources belong to API Groups, pods and services belong to the core (also called legacy) API Group which deployments and statFullSet belong to API Group called apps, so whenever we need a component or its data we just need to specify the API Group in the request

Programmatic Access to the API

You may also want to use and write applications using programs like JS, GO, Java, and Python instead of writing bash scripts you want to write actual programs that work with Kubernetes, that's going to be the third way of interacting with Kubernetes. For that Kubernetes has client libraries that Kubernetes officially support

Join my Linkedin

--

--

Amit Cohen
Amit Cohen

Written by Amit Cohen

A product leader with exceptional skills and strategic acumen, possessing vast expertise in cloud orchestration, cloud security, and networking.

No responses yet