~ cka prep

Exam Details

• 25% Cluster Arch, Installation and Configuration
  • Demonstrate the process of installing a cluster from scratch, upgrading a cluster version, and backing up restoring etcd database.
  • Also RBAC
• 15% Workloads and Scheduling
  • Understand the effect of Pod resource limits on scheduling.
• 20% Services and Networking
  • Knowledge of Service and Ingress.
• 10% Storage
  • Volumes
• 30% Troubleshooting
  • Confronted with typical scenarios that you need to fix.

It is essential that you become one with `kubectl`, `kubeadm`, and `etcdctl`

When killing objects you may want to not wait for it to be shut down gracefully, you can use `--force` to kill the object.

Cluster Architecture, Installation and Configuration

Typical tasks you would expect a k8s admin to know, understanding the architectural components, setting up a cluster from scratch, and maintaining a cluster going forward

Role-Based Access Control (RBAC)

To control who can access what on the cluster we need to establish certain policies

RBAC defines policies for users, groups and processes, by letting them (or disallowing them) to manage certain API resources.

RBAC has 3 building blocks:

• Subject
  • The user or process that want to access a resource
  • E.g. Group, Users, SA (Service Accounts)
• Resource
  • The k8s API object
  • E.g. pods, deployments, services, etc..
• Verb
  • The operation that can be executed on the resource.
  • E.g. create, list, watch

Creating a Subject

Users and groups are not stored in `etcd` (the k8s db), they are meant for processes running outside of the cluster. On the other hand, service accounts are k8s objects and are used by processes running inside of the cluster.

User accounts and groups

As stated before there is no k8s object for user, instead the job of creating the credential and distributing to the users is done externally by the admin.

There are different ways k8s can authenticate a user:

• X.508 client certificate
  • Uses OpenSSL cert
• Basic Auth
  • Uses username and password
• Bearer tokens
  • Uses OpenID or webhooks as auth

You wont have to create a user in the exam, but here are the steps for creating one using the OpenSSL method.

1. Go to k8s control plane node and create a temporary dir that will have the keys.

   mkdir cert && cd cert

2. Create a private key using openssl (username.key)

   openssl genrsa -out johndoe.key 2048

3. Create a cerficiate sign request (a .csr file) with the key from the previous step

   openssl req -new -key johndoe.key -out johndoe.csr -subj "/CN=johndoe/O=cka-study-guide"

4. Sign the .csr with the k8s CA (it usually is under /etc/kubernetes/pki)

   openssl x509 -req -in johndoe.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out johndoe.crt -days 364

5. Add it to your kubeconfig file

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

ServiceAccount

The users we created in the last paragraphs are meant to be used by humans, if a pod or a svc needs to authenticate against the k8s cluster we need to create a service account.

A k8s cluster already comes with a `sa` called default. Any pod that does not explicitly assign a service account uses the default service account

It is super simple to create one with the imperative approach

$ k create sa build-bot

When creating a service account a secret holding the API token will be created too. The Secret and token names use the Service Account name as a prefix.

To assing a service account to a pod you can do it imperatively by:

Or add it to the manifest under `spec.serviceAccountName`.

Roles and RoleBindings

We have these two primitives:

• Role

  Declares the api resources, and their operations. E.g. Allow listing and deleting pods

• RoleBinding

  Connects or binds the roles to a Subject

There are some default roles:

• cluster-admin

  rw access to resources across all namespaces

• admin

  rw access to resources in namespaces including roles and rolebinding

• edit

  rw access to resources in namespace except roles and rolebindings.

• view

  ro access to resources in namespace except roles, rolebindings and secrets.

Creating Roles and RoleBindings

Imperative mode for roles.

There is also `--resource-name` as a flag, where you can specify names of pods.

Imperative mode for rolebindings.

If then you do a `get` you wont see the subject, you need to render the details to see that.

You can of course use `describe` and so on to check each of the primitives once created, but there is also this little neat command: $ k auth can-i this will give specific info on user permissions

$ kubectl auth can-i --list --as johndoe

$ kubectl auth can-i list pods --as johndoe

Yes

Cluster Role

Roles and RoleBinding are namespace specific. If we want to define the same but for the whole cluster we need to use ClusterRole and ClusterRoleBinding. The configuration elements are the same.

Aggregating RBAC Rules

Finally, we can aggregate different roles with label selection. Say you have one role that lets you list pods, and other that lets you delete pods.

You can aggregate them with an `aggregationRule`

Here is an example from Benjamin Muschko's Oreilly's Certified Kubernetes Administrator (CKA) Study Guide.

YAML manifest for listing pods

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: list-pods
  namespace: rbac-example
  labels:
    rbac-pod-list: "true"
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list

YAML manifest for deleting svc's

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: delete-services
  namespace: rbac-example
  labels:
    rbac-service-delete: "true"
rules:
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - delete

YAML manifest aggregating them.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pods-services-aggregation-rules
  namespace: rbac-example
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac-pod-list: "true"
  - matchLabels:
      rbac-service-delete: "true"
rules: []