Understanding kubectl & kubeconfig

• Refer Here for cheatsheet
• Refer Here for kubeconfig file

Users in kubernetes

• Types of users in k8s
• User Accounts: K8s doesnot store users
• Service Accounts: These are stored in k8s
• Every container will have service account credentials mounted in /var/run/secrets/kubernetes.io/serviceaccount. Not a good practice

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  automountServiceAccountToken: false
  containers:
    - name: test 
      image: alpine
      command:
        - sleep
        - 1d

• Refer Here for configuring service account for pods
• When kubernetes is setup it creates a certificate authority (CA)
  • in kubeadm /etc/kubernetes/pki/ca.crt and /etc/kubernetes/pki/ca.key
• During setup all component of k8s like api server, etcd etc will get a certificate so that all communication is secured
• To create a user in k8s, you need create a csr and get it signed by CA use it in your kubeconfig Refer Here here for authentication

To create a user for a Kubernetes cluster managed by kubeadm, you typically use x509 client certificates—not native Kubernetes user objects. The process has several steps:

1. Generate a Certificate Signing Request (CSR) and private key for the user:

openssl genrsa -out kim.key 2048
openssl req -new -key kim.key -out kim.csr -subj "/CN=kim/O=devops-team"

Here, kim is the username, and devops-team is the group this user belongs to[2][1].

1. Sign the CSR with the Kubernetes cluster’s Certificate Authority:

Copy the root CA certificate and key from your master node. For kubeadm clusters, these are typically in /etc/kubernetes/pki/ca.crt and /etc/kubernetes/pki/ca.key[6].

openssl x509 -req -in kim.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out kim.crt -days 365

1. Configure kubectl with the new user’s credentials:

kubectl config set-credentials kim --client-certificate=/path/to/kim.crt --client-key=/path/to/kim.key

Replace /path/to/kim.crt and /path/to/kim.key with your actual file locations[1].

1. Set up a context for the user:

kubectl config set-context kim-context --cluster= --namespace=default --user=kim

1. (Optional) Set the context to use this user:

kubectl config use-context kim-context

1. Create appropriate RBAC (Role/ClusterRole and RoleBinding/ClusterRoleBinding) resources to grant permissions to the user.

Notes:

• Kubernetes does not have “users” as API objects, except for ServiceAccounts. Users are managed externally (e.g., certificates, tokens)[2][5].
• The steps above are standard practice recommended for kubeadm clusters[6].
• Always secure root CA credentials and private keys.

This procedure provides secure authentication for human users accessing a kubeadm-managed cluster.

[1] http://kubernetes-tutorial.schoolofdevops.com/configuring_authentication_and_authorization/
[2] https://kubernetes.io/docs/reference/access-authn-authz/authentication/
[3] https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/
[4] https://www.scaleway.com/en/blog/user-authentication-in-kubernetes-primer/
[5] https://pwittrock.github.io/docs/admin/authentication/
[6] https://cloudhero.io/creating-users-for-your-kubernetes-cluster/
[7] https://github.com/kubernetes/kubeadm/issues/3014
[8] https://pwittrock.github.io/docs/admin/kubeadm/

Namespace

• Refer Here for official docs
• Namespace is kind of logical cluster for creating logical boundaries.
• Every k8s resource is either scoped at namespace level or at cluster level

How about authorization

• K8s authentication & authorization flow
  • Authentication –> Authorization –> Admission Controllers

Role & ClusterRole

• Refer Here for official docs
• Role: This acts at namespace level
• ClusterRole: This acts at cluster level

Rolebinding & ClusterRoleBinding

• Refer Here for official docs
  

Lets create a dev role

• This is about creating pods, rs, deployments

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev
rules:
  - apiGroups: [""] 
    resources: ["pods", "services"]
    verbs: ["get", "watch", "list", "create", "update", "patch", "delete", "deletecollection"]
  - apiGroups: ["apps"]
    resources: ["replicasets", "deploymets"]
    verbs: ["get", "watch", "list", "create", "update", "patch", "delete", "deletecollection"]

• Role Binding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-rb
  namespace: default
subjects:
- kind: User
  name: dev # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: dev # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

Lets create a qa role

• This is about reading pods, rs, deployments

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: qa
rules:
  - apiGroups: [""] 
    resources: ["pods", "services"]
    verbs: ["get", "watch", "list"]
  - apiGroups: ["apps"]
    resources: ["replicasets", "deployments"]
    verbs: ["get", "watch", "list"]

• Role Binding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: qa-rb
  namespace: default
subjects:
- kind: User
  name: qa # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: qa # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

• Exercise:
  • Try cluster role binding
  • Try creating users for namespaced access
  • Connect k8s to your container registry (private registry)
  • Try running a pod with database (nop) and establish connection using service.