Kubernetes Authentication and Authorization with X509 client certificates

Suresh Palemoni
2 min readMar 17, 2019

--

The flow of K8S Authentication and Authorization

The access to the kubernetes have to go through four stages:

  1. TLS Connectivity
  2. Authentication
  3. Authorization
  4. Admission Controllers

This article would give an outline, how the access and authorisation can be provided for a particular user.

Authentication:

There are two types of users in kubernetes: Service Accounts and Normal users.

Service accounts can be added as k8s objects, but there are no objects to represent the normal users. Normal users must be managed by an outside service.

  1. Create a namespace:
kubectl create ns medium
  1. Create the user and generate a password:
sudo useradd suresh
sudo passwd suresh

2. Generate a private key and CSR for the user suresh.

openssl genrsa -out suresh.key 2048
openssl req -new -key suresh.key -out suresh.csr -subj "/CN=suresh/O=medium"

3. Using the CSR, Key files and the CA keys of the k8s cluster generate a self-signed certificate using x509 protocol.

sudo openssl x509 -req -in suresh.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out suresh.crt -days 30

4. Update the config file to use the newly created key and certificate.

kubectl config set-credentials suresh --client-certificate=suresh.crt --client-key=suresh.key

5. Create a context using the cluster name, Namespace and CN of the user used in the certificate.

kubectl config set-context suresh-context --cluster=kubernetes --namespace=medium --user=suresh

Now, you are all set with the authentication: If you try to access the objects in the clster you may get the error because you are not authorized.

Authorization:

  1. Create a role and associate the role with the namespace we have created in the earlier steps and few RBAC rights.
cat <<EOF | kubectl create -f -
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: medium
name: medium-role
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["deployments", "replicasets", "pods"]
verbs: ["get", "create", "update", "patch", "delete"]
EOF

2. Create the rolebinding object to associate the user with the above created role.

cat <<EOF | kubectl create -f -
kind: RoleBinding
metadata:
name: medium-role-binding
namespace: medium
subjects:
- kind: User
name: suresh
apiGroup: ""
roleRef:
kind: role
name: medium-role
apiGroup: ""
EOF

3. Now try to fetch the pods or create one if you do not have any.

kubectl --context=suresh-context get podsor kubectl --context=suresh-context create deploy nginx --image=nginx

There you go !! Cheers :)

Oh we also have Admission Controllers:

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.

Many advanced features in Kubernetes require an admission controller to be enabled in order to properly support the feature. As a result, a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server and will not support all the features you expect.

Reference to admission controllers: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

--

--