Before we head into authorization it is necessary to understand about API groups in kubernetes.
But first, what is the Kubernetes API?
We learned about the Kube API server. Whatever operations we have done so far with the cluster,
we have been interacting with the API server one way or the other. Either through the kubectl utility
or directly. Say we want to check the version, we can access the api server at the master nodes
address followed by the port which is 6443 by default and the API version.
It returns the version. Similarly to get the list of pods, you would access the url api/v1/pods.
Our focus in this lecture is about these API paths. The /version and /api. The Kubernetes API is grouped
into multiple such groups based on their purpose. Such as one for apis, one for healthz, metrics
and logs etc. The version API is for viewing the version of the cluster as we just saw The Matrix and
healthz api are used to monitor the health of the cluster. The logs for integrating with third
party logging applications.
In this video we will focus on the API is responsible for the cluster of functionality
These APIs are categorized into two. The core group and the named group. The core group is where all core
functionality exists. Such as namespaces, pods, replication controllers, events, endpoints, nodes, bindings,
Persistent volumes, persistent volume claims, configmaps, secrets, services etc. The named group API is
are more organized and going forward all the newer features are going to be made available to these
named groups.
It has groups under it for apps, extensions, networking, storage, authentication, authorization certificates etc. Shown
here are just a few. Within apps, you have deployments, replicasets, statefulsets. within networking
you have network policies certificates have these certificates sign requests that we talked about earlier
in the section so the ones at the top are API groups and the ones at the bottom are resources in those
groups.
Each resource in this has a set of actions associated with them.
Things that you can do with these resources such as list the deployments get information about one of
these deployments create a deployment delete a deployment update a deployment watch a deployment etc.
These are known as verbs. The Kubernetes API reference page can tell you what the API group is for each
object select an object and the first section in the documentation page shows its group details .
v1/core is just v1.
You can also view these on your Kubernetes cluster. Access your kube-api server at port 6443, without
any path and it will list you the available api groups. And then within the named api groups it returns
all supported groups. A quick note on accessing the cluster API like that.
If you were to access the API directly through curl as shown here,
then you will not be allowed access except for certain APIs like version, as you have not specified
any authentication mechanisms. So you have to authenticate to the API using your certificate files by passing
them in the command line like this. An alternate option is to start a kubectl proxy client.The
kubectl proxy command, launches a proxy service locally on port 8001 and uses credentials and
certificates from your kubeconfig file to access the cluster.
That way you don’t have to specify those in the curl command.
Now you can access the kubectl proxy service at port 8001 and the proxy will use the credentials
from kube-config file to forward your request to the kube api server.
This will list all available APIs at root. so hear are 2 terms that kind of sound the same.
The Kube proxy and kubectl proxy well they are not the same.
We discussed about kube-proxy earlier in this course.
It is used to enable connectivity between parts and services across different nodes in the cluster.
We discuss about kube-proxy in much more detail later in this course.
Whereas kubectl proxy is an HTTP proxy service created by kubectl utility to access the
kube-api server.
So what to take away from this.
All resources in Kubernetes are grouped into different api groups. At the top level
you have core api group and named api group. Under the named api group
You have one for each section under this API group.
You have the different resources and each resource has a set of associated actions known as verbs in
the next section on authorization.
We can see how we use these to allow or deny access to users.
Well that’s it for this lecture. I will see you in the next.