Search for a command to run...
Hey, Y'all 👋 Kratik Here :)
Hailing from The City of Lakes, India.
I love to learn and share stuff about DevOps, SRE, Security, Cost Optimization, etc.
Join me on this journey where we will learn together with the help bunch of interesting blogs.
No comments yet. Be the first to comment.
DNS Search Domains, ndots, and Kubernetes Resolver Behavior
Understand how IAM Access Entries can replace aws-auth for managing EKS IAM authentication.
Effective Techniques for Providing IAM Access to EKS Pods
Ever wondered how can you create your own custom Github Action and publish it to the GitHub Marketplace? Let's learn it step by step in this blog.
Let's setup Vault with External-secrets to manage secrets in Kubernetes like never before!
When we set up Kubernetes the default config file (aka kubeconfig file) has admin privileges. This is fine when you are the only one who is going to access the cluster(still not a good practice tho!) but what if there are multiple teams/devs involved and they also need to access the cluster for some use case, obviously, they don't need the full access, So now what? Will you give them your kubeconfig file(or the access) which has full permissions? Absolutely not!
Have you heard about the Principle of least privilege? It dictates - A subject should be given only those privileges needed for it to complete its task. If a subject does not need an access right, the subject should not have that right.
So we should create users as per the requirements and assign them the minimum permissions to function properly, right? but how do we do it?
Just to be clear, Kubernetes does not have the support for users natively. And from the documentation - "Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call."
There are multiple ways to create/manage users(basically the AUTHENTICATION part) in Kubernetes, for example -
--basic-auth-file=name_of_auth_file argument. This file contains list of users in password, user-name, user-id format. Note - There are a bunch of other methods also available for the authentication in a k8s cluster. Check this for the same.
We will stick to the flow which we defined earlier. Suppose we want to create a user for Kratik Jain which is a newly joined Intern in XYZ Technologies. We don't want him to make any changes in our cluster which can mess things up, so we will be giving him read-only access. Let's Start -
We will be using OpenSSL for the generation and analysis of the certificates.
Private keys are meant to be kept private and used in encryption, so only ones who have this private key can decrypt the data. but here, it is used only to identify a user.
openssl genrsa -out kratik.key 2048
We will create a CSR for our user with our private key. Basically, it's encoded info requesting a certificate. Later we will use our Certificate Authority's credentials to create a valid certificate. Read more about CSRs here.
A CSR contains various properties but for our use case, one property is most important - Common Name aka CN.
Remember! using this common name, our K8s cluster will identify us. Whatever CN we define here, becomes our username in K8s.
So let's fire the below command to create a CSR -
openssl req -new -key kratik.key -out kratik.csr -subj "/CN=kratik/O=XYZ-Technologies"
!Important - Locate your CA Credentials - the CA Cert and CA Key. Depending on your installation procedure, it may be stored at different locations.
For example, If you are using -
K3s, you'll find your creds at /var/lib/rancher/k3s/server/tls/client-ca.crt & /var/lib/rancher/k3s/server/tls/client-ca.key
Kind - As kind is Kubernetes in docker - you need to find the control-plane Docker container and there in the path /etc/kubernetes/pki/ you will find the ca.crt & ca.key.
Tip - Use docker cp command to copy those files to your local machine.
Kubeadm - you will find your CA creds in /etc/kubernetes/pki/ directory.
Assuming you have these creds in the current working directory as ca.crt & ca.key, fire the below command to use your CA Creds and approve the CSR, and generate the certificates.
openssl x509 -req -in kratik.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out kratik.crt -days 365
Awesome! your key and cert are ready to be used!
kubectl uses kubeconfig files to organize information about clusters, users, namespaces, and authentication mechanisms.
kubectl config set-credentials kratik --client-certificate=kratik.crt --client-key=kratik.key
kubectl config set-context kratik-context --cluster=default --user=kratik
Context in Kubeconfig file - From the official docs, "A context element in a kubeconfig file is used to group access parameters under a convenient name. Each context has three parameters: cluster, namespace, and user. By default, the kubectl command-line tool uses parameters from the current context to communicate with the cluster."
this will fail because we haven't assigned any role to it yet. (Which is EXPECTED!)
Notice that I am using a newly created context using the --context flag in the kubectl command. (BTW I am using k3s and k3 in my terminal is an alias for that )
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: role-for-read-only-access
rules:
- apiGroups: ["extensions", "apps", ""] # "" indicates the core API group
resources: ["*"]
verbs: ["get", "watch", "list"]
kubectl apply -f ro-role.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-only-role-binding
subjects:
- kind: User
name: kratik
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: role-for-read-only-access
apiGroup: rbac.authorization.k8s.io
kubectl apply -f ro-role-binding.yaml
Fire the same command which we fired previously to check if the error is gone or not.
kubectl --context=kratik-context get po -A
Also, Let's try deleting the pod, let's see what happens 🤔
So this worked out finally as we wanted!!!
Now you can also tweak and fine-tune your Cluster role to give more granular access. I wanted to create something which is not bounded to some namespace but is usable throughout the cluster, so I chose the ClusterRole.