CKS Exam Series #6 Users and CertificateSigningRequests

Kubernetes CKS Example Exam Question Series

CKS Exam Series | CKA Exam Series | CKAD Exam Series

#####################################

THIS CHALLENGE WON’T BE UPDATED HERE AND MOVED TO:

https://killercoda.com/killer-shell-cks

######################################

Content

1. Create Cluster & Security Best Practices
2. Pods, Secrets and ServiceAccounts
3. Immutable Pods
4. Crash that Apiserver & check logs
5. ImagePolicyWebhook / AdmissionController
6. Users and CertificateSigningRequests
7. ServiceAccount Token Mounting
8. Role Based Access Control (RBAC)
9. Role Based Access Control (RBAC) v2
10. Container Hardening
11. NetworkPolicies (Default Deny + Allowlist)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

→ Check out the FULL CKS COURSE on Udemy ←

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Rules!

1. Be fast, avoid creating yaml manually from scratch
2. Use only kubernetes.io/docs for help.
3. Check our solution after you did yours. You probably have a better one!

A bit of context before the task

CA  = Certificate Authority
CRT = Certificate
CSR = Certificate Signing Request
KEY = Private Key

Users in K8s are managed via CRTs and the CN/CommonName field in them. The cluster CA needs to sign these CRTs.

The idea today is to do the signing process once manually and once using the K8s Api. This will explain what’s happening in the background.

Manual way

Automatic way

Todays Task: Create a CertificateSigningRequest

1. Create a KEY for user named 60099@internal.users
2. Create a CSR for the KEY
3. Manual way: manually sign the CSR with the K8s CA file to generate the CRT
4. Automated way: create a CSR-K8s-resource for the CSR file, let the K8s Api sign it, then download the CRT
5. Connect to the K8s Api using the CRT+KEY from the manual and automatic way.

.

.

.

.

.

Solution

The apiserver already has access to the cluster CA, so why not let it sign it?

alias k=kubectl

1. Create KEY

openssl genrsa -out 60099.key 2048

2. Create CSR

openssl req -new -key 60099.key -out 60099.csr
# set Common Name = 60099@internal.users

3. Manual signing

find /etc/kubernetes/pki | grep ca
openssl x509 -req -in 60099.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out 60099.crt -days 500

4. Signing via API

https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: 60099@internal.users # ADD
spec:
  groups:
  - system:authenticated
  request: {{BASE_64_ENCODED_CSR}} # ADD
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

Convert CSR file content to base64:

cat 60099.csr | base64 -w 0

Create the resource, check its status and approve:

k -f csr.yaml create
k certificate approve 60099@internal.users

Now download the CRT:

k get csr 60099@internal.users -ojsonpath="{.status.certificate}" | base64 -d > 60099.crt

5. Use it to connect to K8s API

k config set-credentials 60099@internal.users --client-key=60099.key --client-certificate=60099.crt
k config set-context 60099@internal.users --cluster=kubernetes --user=60099@internal.users
k config get-contexts
k config use-context 60099@internal.users

We see the username returned from the api, just without any permissions atm

If you like you could give the user RBAC permissions to actually work with the cluster. This will follow in a next challenge.

.

.

.

.

.

Why using K8s CSR via Api?

Doing it the automatic way via Api removes the need for direct access to the CA of the cluster. The CA should be considered holy because with it it’s possible to create trusted certificates for the whole cluster.

You have a different solution?

Let us know by leaving a comment below!

— — — The END — — —

So much for this session. See you at the next one and happy learning!

Ready to join Killer Shell?

FULL CKS COURSE

LINK

…or the CKS SIMULATOR

https://killer.sh/cks