Posts

Showing posts from 2025

Docker - RUN vs ENTRYPOINT vs CMD

Image
  RUN - Specify commands to make changes to your Image and subsequently the Containers started from this Image. This includes updating packages, installing software, adding users, creating an initial database, setting up certificates, etc. These are the commands you would run at the command line to install and configure your application. Let's start with a basic dockerfile , where we are building an image with ubuntu as base image. Let's build the image. The size of the image which we build is "78.1" MB. I am going to install packages like "curl", "wget" on the base image. Now, the image size has increased from 78MB to 136MB. RUN command add another layer to the base image. RUN is primarily used for software installation and any configuration changes. ENTRYPOINT - Must be used if you want to start or a define a container main application or command. It always runs regardless of an additional CMD parameters. This image is build using base "a...

K8s - ETCD

Image
  etcd is a "strongly consistent , distributed key-value store". Why etcd? 1. Consistency : Since the API server is the central coordination point of the entire cluster; strong consistency is essential. It would be a disaster if, say, two nodes tried to attach the same persistent volume over iSCSI because the API server told them both that it was available. 2. Availability: API downtime means that the entire Kubernetes control plane comes to a halt, which is undesirable for production clusters. The  CAP theorem  says that 100% availability is impossible with strong consistency, but minimizing downtime is still a critical goal. 3. Consistent Performance: The API server for a busy Kubernetes cluster receives a fair amount of read and write traffic. The secret behind etcd's balance of strong consistency and high availability is the  Raft algorithm . Raft solves a particular problem: how can multiple independent processes decide on a single value for somethin...

K8s - Creating a User and Group

Image
  In the previous blog we saw about role and role binding. In this post, we will see how to create a user and group. Technically, there is no concept called "User" and "Group" in K8s.   But, K8s provides ways to authenticate an external user/group with K8s. In this blog, we will see how to use certificate based authentication. Below are steps to onboard a user: 1) Create a private key. 2) Create a certificate signing request (CSR) using the above private key. 3) Generate a CSR request. 4) Approve the CSR request. 5) Extract the approved CRT file from the approved CSR request. 6) Build the config file. When we create a CSR, we mention the USERNAME and GROUPNAME . Let's see practically. Generating a private key. I am going to create a user called " demouser ". Now, we have the private key. Using that we are going to create a CSR. Note the highlighted portion, which is the subject where CN(Common Name) refers to username and O(Organization) refers to grou...

K8s - User and Groups

Image
  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 :...