Kubernetes Storage & Kubernetes Security

1. Persistent Volumes & Persistent Volume Claim (PV & PVC)

• A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.

• It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV.

• This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

Step 1 : Create a Persistent Volume (PV)

• Create a YAML file named pv.yml,

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data

• Apply,

kubectl apply -f pv.yml

Step 2 : Create a Persistent Volume Claim (PVC)

• Create a YAML file named pvc.yml,

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

• Apply,

kubectl apply -f pvc.yml

Step 3 : Use the PVC in a Pod

• Create a YAML file named pod.yml,

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: my-storage
  volumes:
    - name: my-storage
      persistentVolumeClaim:
        claimName: my-pvc

---

2. Storage Classes

• A StorageClass provides a way for administrators to describe the classes of storage they offer.

• Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators. Kubernetes itself is unopinionated about what classes represent.

Step 1 : Create a Storage Class

• Create a YAML file named storageclass.yml,

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage-class
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

• and Apply.

Step 2 : Create a PVC that Uses the Storage Class

• Create a YAML file named pvc-with-sc.yml,

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-using-sc
spec:
  storageClassName: my-storage-class
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

• Apply,

---

3. StatefulSets

For detailed explanation, refer -> StatefulSets module.

---

4. Role-Based Access Control (RBAC)

• Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.

• RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.

Step 1 : Create a Role

• Create service account,

• Create a YAML file named role.yml,

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Step 2 : Create a RoleBinding

• Create a YAML file named rolebinding.yml,

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "ojas"  # Replace with your Kubernetes user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

• Test RBAC autorization,

• Run commands using --as=user flag (Where user is the name of the user you wish to impersonate.)

• Trying to create daemonSet using ojas user, as same user don't have rights to create any deployments, hence action if forbidden.

---

5. Secrets

• A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code.

• Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods. Kubernetes, and applications that run in your cluster, can also take additional precautions with Secrets, such as avoiding writing sensitive data to nonvolatile storage.

• Secrets are similar to ConfigMaps but are specifically intended to hold confidential data.

Step 1 : Create a Secret

• Create a YAML file named secret.yml,

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: bXl1c2VybmFtZQ==  # base64 for 'myusername'
  password: bXlwYXNzd29yZA==  # base64 for 'mypassword'

Step 2 : Use the Secret in a Pod

• Create a YAML file named pod-using-secret.yml,

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: mycontainer
      image: nginx
      env:
        - name: USERNAME
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: username
        - name: PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: password

---

6. Network Policies

• NetworkPolicies are an application-centric construct which allow you to specify how a pod is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections.

Step 1 : Create a Network Policy

• Create a YAML file named networkpolicy.yml,

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: myapp
    ports:
    - protocol: TCP
      port: 80

---

7. Transport Layer Security (TLS)

• Kubernetes provides a certificates.k8s.io API, which lets you provision TLS certificates signed by a Certificate Authority (CA) that you control. These CA and certificates can be used by your workloads to establish trust.

Step 1 : Create TLS Certificates

• Generate TLS certificates using OpenSSL,

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=my-app/O=my-org"

Step 2 : Create a Secret for TLS

• Create a secrets,

kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key

Step 3 : Use the TLS Secret in an Ingress

• Create an Ingress that uses the TLS secret,

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name

---

Connect With Me

Thank you for reading. I hope you were able to understand and learn something new from my blog.

Happy Learning!

LinkedIn | GitHub