TIL: The path to CKA Week 3.

TIL: The path to CKA Week 3.

Helm

The helm tool packages a Kubernetes application using a series of YAML files into a chart, or package. This allows for simple sharing between users, tuning using a templating scheme, as well as provenance tracking, among other things.

Helm v2 consists of two components.

• A server call tiller, which runs inside the k8s cluster.
• A client call Helm, which runs on the local machine or any machine that is able to talk to tiller server.

In helm version 2, uses Tiller pod to call k8s api to deploy the pods. The new Helm v3 does not deploy a tiller pod.

Chart Contents

A chart is an archived set of kubernetes resource manifests that make up a distributed application.

├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── pvc.yaml
│   ├── secrets.yaml
│   └── svc.yaml
└── values.yaml

1. Chart.yaml
   The Chart.yaml file contains some metadata about the Chart, like name version, and so on.

2. values.yaml
   The values.yaml contains keys and values that used to generate the release in your cluster. These values are replaced in the resource manifests using the GO templationg syntax.

3. templates
   The templates directory containes the resource manifests that make up the application.

Security

Accessing the API
To perform any action in a Kubernetes cluster, you need to access the API and go through three main steps:

• Authentication:
• Authorization (ABAC or RBAC):
• Admission Control.

Once a request reaches the API server securely, it will first go through any authentication module that has been configured. The request can be rejected if authentication fails or it gets authenticated and passed to the authorization step.

At the authorization step, the request will be checked against existing policies. It will be authorized if the user has the permissions to perform the requested actions. Then, the requests will go through the last step of admission. In general, admission controllers will check the actual content of the objects being created and validate them before admitting the request.

In addition to these steps, the requests reaching the API server over the network are encrypted using TLS. This needs to be properly configured using SSL certificates. If you use kubeadm, this configuration is done for you.

ABAC, BRAC and Webhook

ABAC

ABAC stands for Attribute Based Access Control. It was the first authorization model in Kubernetes that allowed administrators to implement the right policies. Today, RBAC is becoming the default authorization mode.

For example, the policy file shown below authorizes user Bob to read pods in the namespace foobar:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "foobar",
        "resource": "pods",
        "readonly": true     
    }
}

RBAC

RBAC stands for Role Based Access Control.

All resources are modeled API objects in Kubernetes, from Pods to Namespaces. They also belong to API Groups, such as core and apps.These resources allow operations such as Create, Read, Update, and Delete (CRUD), which we have been working with so far. Operations are called verbs inside YAML files. Adding to these basic components, we will add more elements of the API, which can then be managed via RBAC.

Rules are operations which can act upon an API group. Roles are a group of rules which affect, or scope, a single namespace, whereas ClusterRoles have a scope of the entire cluster.

Each operation can act upon one of three subjects, which are User Accounts which don't exist as API objects, Service Accounts, and Groups which are known as clusterrolebinding when using kubectl.

RBAC is then writing rules to allow or deny operations by users, roles or groups upon resources.

While RBAC can be complex, the basic flow is to create a certificate for a user. As a user is not an API object of Kubernetes, we are requiring outside authentication, such as OpenSSL certificates. After generating the certificate against the cluster certificate authority, we can set that credential for the user using a context.

Roles can then be used to configure an association of apiGroups, resources, and the verbs allowed to them. The user can then be bound to a role limiting what and where they can work in the cluster.

Here is a summary of the RBAC process:

• Determine or create namespace
• Create certificate credentials for user
• Set the credentials for the user to the namespace using a context
• Create a role for the expected task set
• Bind the user to the role
• Verify the user has limited access

Finally, the last quiz at the end of this course.😂