add-kexp-rbac

content/en/k8s/_overview.md

@@ -21,6 +21,14 @@ aliases:
 git clone https://github.com/kubernetesdaily/k8sworkshop.git
 ```
 
+k'exp - Kubernetes Explorer
+
+```
+GOOS=darwin
+GOARCH=arm64
+curl -Ls -o kexp.tar.gz "https://github.com/iximiuz/kexp/releases/latest/download/kexp_${GOOS}_${GOARCH}.tar.gz"
+tar xvzf kexp.tar.gz
+```
 
 Table of content 
 | Title | Link |
@@ -35,7 +43,7 @@ Table of content
 |8.Service Type: NodePort,ClusterIP,LoadBalancer|[lab](https://kubedaily.com/k8s/service-type-nodeportclusteriploadbalancer/)| 
 |9.Ingress Controller|[lab](https://kubedaily.com/k8s/ingress-controller/)| 
 |10.ConfigMap|[lab](https://kubedaily.com/k8s/configmap/)| 
-
+|11.RBAC | [lab](https://kubedaily.com/k8s/rbac/)
 
 
 What next >> 

content/en/k8s/c11.RBAC.md

@@ -3,16 +3,201 @@ title: "RBAC"
 slug: "RBAC"
 ---
 
-#### Role Based Access Control (RBAC)
+### Steps to Set Up X509 Certificate Authentication
+
+```
+mkdir newusercrt
+cd newusercrt 
+openssl genrsa --out sangam.key 2048
+openssl req -new -key sangam.key -out sangam.csr -subj "/CN=sangam/O=group1"
+```
+
+This creates a private key (sangam.key) and a CSR (sangam.csr). The CN (Common Name) is set to the user's name, and O (Organization) is an optional field to specify a group.
+
+### Create a CertificateSigningRequest in Kubernetes
+
+Encode the CSR in base64 and create a YAML file for the Kubernetes CSR object:
+
+```
+cat sangam.csr | base64 | tr -d '\n'
+LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1p6Q0NBVThDQVFBd0lqRVBNQTBHQTFVRUF3d0djMkZ1WjJGdE1ROHdEUVlEVlFRS0RBWm5jbTkxY0RFdwpnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDelJOOHNFYWNkcmsxdVlPTndNejRaCjVqUUYwUTBNNnBqTk9GTVQxM3JMVXV1NzBzMkNhR1lVUEV4bk52Q01kOTk0cTU3bUc0Y3Z6Ny96VTdpcVFRQ3UKcjc5b0xCVEk5YjlPT0EzZXF2TC9uenZrbGxqUGpCcUFuZitYOGRPdEx4ZTJOYnlja1cyamNHOThKdSsvaVR4YgpiWkVHaXZDeHVXQmNiMktnRHRuczYyZHhxWi8vdU9NVW1nK0J3ZFBBbkx0dUl3enR3ZzYzZlNrMHNSSCt3VGwzCjB3ZFVSblJWU1QzaDE4ZXI4ejBHS3g5RFBZSlBjRzJFT2FUTU5uaklUUUoyRzkrNWdDMFBBa1V1SGJNdjQ4NXQKN3U5alZJT09SUVB6bHd5VHdwQndtV0NjR3ZwNnNKNEtzNmRicWVvc2lHem1KbnZ3QjJxejYzZm5ubmI5aElaMwpBZ01CQUFHZ0FEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFSZ1FHVU13TDFZRmhlZHhNOE9HUHY4ODJ6SEpPCjRRd1IzaW8ySXUyZG9Dc3hGL2RhNTV4K0VNQlBwN1Y5UXhHM2tyTitDNDgyOUdrcTh1WHk1MVJENjNMeWNkM20KdGVHQkZVMEZXeTVUYmVzTjJoMVdEQlMySDYrUmtEelI1dHZzclo3dnlZb2crbDQrckxVRFJNM2t4UWZ3WkExdQoyOTdTSWhQUllqSjJXd2xZeU9mMUJhUDRpa1NtT1JkaVZ5OWNKOGFKZDBjQkFBQ3JxVlppTGRtSTNlT3g4bUtnCklwL3lJRzN5K2hhNTFXQUVWdGdtdllPRVphMVRqZFhsWFRMc3VZNzNwdGJyTFBJYldUVVozdytBcHJwWjVCc3QKWXd3Z2F2NTROQmd1TzVKMTlRL3hlK1RBZXRDdTBVdmN6aHhLUVVFT0ZnMHZSREVNNUgzaG1yYll6QT09Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=%  
+
+```
+
+#### sangam-csr.yaml with following content 
+
+cat <<EOF | kubectl apply -f -
+apiVersion: certificates.k8s.io/v1
+kind: CertificateSigningRequest
+metadata:
+  name: sangam
+spec:
+  groups:
+  - system:authenticated
+  request: $(cat sangam.csr | base64 | tr -d "\n")
+  signerName: kubernetes.io/kube-apiserver-client
+  usages:
+  - client auth
+EOF
+
+
+output 
+
+```
+cat <<EOF | kubectl apply -f -
+apiVersion: certificates.k8s.io/v1
+kind: CertificateSigningRequest
+metadata:
+  name: sangam
+spec:
+  groups:
+  - system:authenticated
+  request: $(cat sangam.csr | base64 | tr -d "\n")
+  signerName: kubernetes.io/kube-apiserver-client
+  usages:
+  - client auth
+EOF
+certificatesigningrequest.certificates.k8s.io/sangam created
+
+```
+
+#### check csr with kubectl 
+
+```
+➜  newusercrt git:(main) ✗ kubectl get csr
+NAME     AGE   SIGNERNAME                            REQUESTOR       REQUESTEDDURATION   CONDITION
+sangam   57s   kubernetes.io/kube-apiserver-client   minikube-user   <none>              Pending
+```
+
+#### Approve the CSR in Kubernetes
+
+List CSRs and approve yours:
+
+```
+  newusercrt git:(main) ✗ kubectl certificate approve sangam
+certificatesigningrequest.certificates.k8s.io/sangam approved
+```
+
+### Retrieve the Signed Certificate
+
+Once approved, retrieve the signed certificate from the CSR:
+
+```
+kubectl get csr sangam  -o jsonpath='{.status.certificate}' | base64 --decode > sangam.crt
+
+```
+
+### Set up kubectl for the User
+
+Configure kubectl to use the certificate:
+
+```
+ kubectl config set-credentials sangam --client-certificate=sangam.crt --client-key=sangam.key
+kubectl config set-context sangam --cluster=minikube --user=sangam
+User "sangam" set.
+Context "sangam" created.
+
+```
+
+ Now it is time to create context so that the new user can use the cluster. I will name the context as sangam-context. You can name differently as you wish.
+
+```
+ kubectl config set-context sangam-context --cluster=minikube --user=sangam
+
+Context "sangam-context" created.
+
+``` 
+
+### Test the Configuration
+
+Switch to the new context and test:
+
+```
+kubectl config use-context sangam-context
+ kubectl get nodes
+Error from server (Forbidden): nodes is forbidden: User "sangam" cannot list resource "nodes" in API group "" at the cluster scope
+
+```
+
+
+pod-reader-role.yaml
+```
+kind: Role
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  namespace: default
+  name: pod-reader
+rules:
+- apiGroups: [""]
+  resources: ["pods"]
+  verbs: ["get", "watch", "list"]
+
+```
+
+readpods-rolebinding.yaml
+
+```
+kind: RoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: read-pods
+  namespace: default
+subjects:
+- kind: User
+  name: "sangam"
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: Role
+  name: pod-reader
+  apiGroup: rbac.authorization.k8s.io
+
+```
+
+```
+ kubectl config use-context minikube
+ kubectl apply -f pod-reader-role.yaml
+kubectl apply -f readpods-rolebinding.yaml
+role.rbac.authorization.k8s.io/pod-reader created
+rolebinding.rbac.authorization.k8s.io/read-pods created
+```
+
+## run test ngnix pod 
+```
+ kubectl run test2 --image=nginx
+pod/test2 created
+kubectl get pods
+NAME    READY   STATUS    RESTARTS   AGE
+test2   1/1     Running   0          49s
+
+
+kubectl config use-context sangam-context
+Switched to context "sangam-context".
+
+ kubectl get pods
+NAME    READY   STATUS    RESTARTS   AGE
+test2   1/1     Running   0          2m1s
+
+
+kubectl run test3 --image=nginx
+Error from server (Forbidden): pods is forbidden: User "sangam" cannot create resource "pods" in API group "" in the namespace "default"
+
+
+you would have more robust systems for managing certificates.
+The kubectl commands assume that Minikube is your current context and you have the necessary permissions to perform these actions.
+The certificate signing process in a real-world scenario might involve additional steps or approvals, depending on the organization's policies.
+```
+
+
+#### Learn more around Role Based Access Control (RBAC)
 
 Role-Based Access Control (RBAC) in Kubernetes is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In the context of Kubernetes, RBAC allows you to control who has access to the Kubernetes API and what they can do with those resources
 
-    - Rules: A rule is a set of operations (verbs) that can be carried out on a group of resources which belong to different API Groups.
+- Rules: A rule is a set of operations (verbs) that can be carried out on a group of resources which belong to different API Groups.
 
 ##### kubectl explain role.rules 
 
-    ```
-     kubectl explain role.rules     
+```
+kubectl explain role.rules     
 GROUP:      rbac.authorization.k8s.io
 KIND:       Role
 VERSION:    v1
@@ -52,13 +237,14 @@ FIELDS:
     Verbs is a list of Verbs that apply to ALL the ResourceKinds contained in
     this rule. '*' represents all verbs.
 
-    ```
+```
 
-    - Roles and ClusterRoles: Both consist of rules. The difference between a Role and a ClusterRole is the scope: in a Role, the rules are applicable to a single namespace, whereas a ClusterRole is cluster-wide, so the rules are applicable to more than one namespace. ClusterRoles can define rules for cluster-scoped resources (such as nodes) as well. Both Roles and ClusterRoles are mapped as API Resources inside our cluster.
+- Roles and ClusterRoles: Both consist of rules. The difference between a Role and a ClusterRole is the scope: in a Role, the rules are applicable to a single namespace, whereas a ClusterRole is cluster-wide, so the rules are applicable to more than one namespace. ClusterRoles can define rules for cluster-scoped resources (such as nodes) as well. Both Roles and ClusterRoles are mapped as API Resources inside our cluster.
 
 
 ##### kubectl explain role
-    ```
+
+```
 kubernetesdaily.github.io git:(main) ✗ kubectl explain role      
 GROUP:      rbac.authorization.k8s.io
 KIND:       Role
@@ -87,7 +273,7 @@ FIELDS:
   rules <[]PolicyRule>
     Rules holds all the PolicyRules for this Role
 
-    ```
+```
 
 ##### kubectl explain clusterroles
 
@@ -128,19 +314,19 @@ FIELDS:
 ```
 
 
-    - Subjects: These correspond to the entity that attempts an operation in the cluster. There are three types of subjects:
+- Subjects: These correspond to the entity that attempts an operation in the cluster. There are three types of subjects:
 
-    - User Accounts: These are global, and meant for humans or processes living outside the cluster. There is no associated resource API Object in the Kubernetes cluster.
+- User Accounts: These are global, and meant for humans or processes living outside the cluster. There is no associated resource API Object in the Kubernetes cluster.
 
-    - Service Accounts: This kind of account is namespaced and meant for intra-cluster processes running inside pods, which want to authenticate against the API.
+- Service Accounts: This kind of account is namespaced and meant for intra-cluster processes running inside pods, which want to authenticate against the API.
 
-    - Groups: This is used for referring to multiple accounts. There are some groups created by default such as cluster-admin (explained in later sections).
+- Groups: This is used for referring to multiple accounts. There are some groups created by default such as cluster-admin (explained in later sections).
 
-    - RoleBindings and ClusterRoleBindings: Just as the names imply, these bind subjects to roles (i.e. the operations a given user can perform). As for Roles and ClusterRoles, the difference lies in the scope: a RoleBinding will make the rules effective inside a namespace, whereas a ClusterRoleBinding will make the rules effective in all namespaces.
+- RoleBindings and ClusterRoleBindings: Just as the names imply, these bind subjects to roles (i.e. the operations a given user can perform). As for Roles and ClusterRoles, the difference lies in the scope: a RoleBinding will make the rules effective inside a namespace, whereas a ClusterRoleBinding will make the rules effective in all namespaces.
 
 #### kubectl explain rolebinding
 
-    ```
+```
     ✗ kubectl explain rolebindings
 GROUP:      rbac.authorization.k8s.io
 KIND:       RoleBinding
@@ -178,6 +364,7 @@ FIELDS:
     Subjects holds references to the objects the role applies to.
 
 ```
+
 #### kubectl explain clusterrolebindings
 
 ```
@@ -221,7 +408,6 @@ FIELDS:
 #### Start Minikube with RBAC enabled:
 
 ```
-
 ➜  kubernetesdaily.github.io git:(main) ✗ minikube start --extra-config=apiserver.authorization-mode=RBAC
 
 😄  minikube v1.32.0 on Darwin 14.2 (arm64)
@@ -237,7 +423,7 @@ FIELDS:
 🌟  Enabled addons: storage-provisioner, default-storageclass
 🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
 
-
+```
 #### create new namespace 
 
 ```
@@ -308,6 +494,7 @@ kubectl apply -f admin-service-account.yaml
 #### define role and Rolebindings 
 
 developer role 
+
 Permissions to manage pods in the development namespace.
 
 
@@ -322,11 +509,13 @@ rules:
   resources: ["pods"]
   verbs: ["get", "list", "watch", "create", "delete"]
 ```
-  k8s git:(main) ✗ kubectl apply -f development-role.yaml 
+
+```  
+k8s git:(main) ✗ kubectl apply -f development-role.yaml 
 role.rbac.authorization.k8s.io/development-role created
-
-
+```
 read-only access to all resources in the qa namespace.
+
 qa-role.yaml
 ```
 apiVersion: rbac.authorization.k8s.io/v1
@@ -339,10 +528,11 @@ rules:
   resources: ["*"]
   verbs: ["get", "list", "watch"]
 
-
 ```
- k8s git:(main) ✗ kubectl apply -f qa-role.yaml
+```
+k8s git:(main) ✗ kubectl apply -f qa-role.yaml
 role.rbac.authorization.k8s.io/qa-role created
+```
 
 Admin Team ClusterRole (admin-clusterrole.yaml):
 Read access to all resources cluster-wide.
@@ -359,8 +549,10 @@ rules:
 
 
 ```
- kubectl apply -f admin-clusterrole.yaml
+```
+kubectl apply -f admin-clusterrole.yaml
 clusterrole.rbac.authorization.k8s.io/admin-clusterrole created
+```
 
 #### ngnix deploymemt 
 
@@ -416,8 +608,9 @@ nginx-deployment   1/1     1            1           31s
 ❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
 
 
-
+```
 #### can qa role able to access it no 
-
+``` 
 kubectl auth can-i get deployments --as=system:serviceaccount:qa:qa-role -n development
-no
+no
+```