RSInfoMinds

  In this post, we will see how user and group works. Technically, there is no concept of user and group management in K8s.  But, K8s has something called "Service Account" . When K8s is installed from scratch, every namespace has "default" service account and it has admin access to perform actions. It is not practically possible to use " default " service account for every actions. From security point of view, we need to give fine grained and required access.  K8s has 2 important things in the space of "Access Management". Role and RoleBinding [Namespace Scoped] Role : Create a role with actions allowed actions on the resources. Let's say I want to create a readonly role. Using the role users can only view the resource and cannot perform actions like create, modify, delete. Rolebinding : Attaching the role to a user, group and service account is called "Role Binding". apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata :...

  Finalizers  are conditions that must be satisfied before a resource can be deleted. When a delete is ordered on a finalized resource, the resource is locked in changes until the conditions are met. Finalizers are used to signal to the control plane, or to custom controllers like Operators, to clean up for a resource before completely and finally removing it. Some common finalizers you’ve likely encountered are: kubernetes.io/pv-protection kubernetes.io/pvc-protection kubernetes.io/pv-protection, ensures that PVs are not removed while still bound to PVCs. Similarly, the kubernetes.io/pvc-protection finalizer on PVCs blocks the deletion of a PVC that is still in use by a pod. Let's try to implement finalizer on a pod.  Below is my pod YAML: Verifying the finalizer tag on my pod. Let's trigger a delete call on the pod. We can see the pod is in " Terminating " state. What the pod log shows? We see the kubelet has stopped the container, but the pod is in " T...