Persistent Volumes (PV):

• A Persistent Volume is a piece of networked storage in a cluster that has been provisioned by an administrator or dynamically created by a StorageClass.

• It can be used by one or many pods, and provides durable storage that can survive container restarts and rescheduling.

• PVs are independent of pods, and can exist independently of the pod lifecycle.

• They can be statically or dynamically provisioned.

• Statically provisioned volumes are created manually by an administrator and dynamically provisioned volumes are created automatically by Kubernetes when a claim is made for storage.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongo-pv
spec:
  capacity:
    storage: 256Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /tmp/db

Persistent Volume Claims (PVC):

• A Persistent Volume Claim is a request for storage by a user or pod.

• It requests a specific amount of storage and access mode(s) for the pod.

• When a PVC is created, Kubernetes attempts to find a matching PV that satisfies the request. If a matching PV is found, it is bound to the PVC.

• PVCs are bound to a single PV, and cannot be shared across multiple PVs.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongo-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 256Mi

Storage Classes:

• Storage Classes are used to define different types of storage that can be dynamically provisioned by Kubernetes.

• They allow administrators to define different classes of storage with different performance and availability characteristics.

• When a user requests storage using a PVC, they can specify which StorageClass to use, and Kubernetes will provision a new PV that matches the characteristics defined in the StorageClass.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  zone: us-west-2a

StatefulSets:

• StatefulSets are used to manage stateful applications in Kubernetes.

• They provide guarantees about the ordering and uniqueness of pods, which is important for stateful applications that require unique identities or persistent storage.

• StatefulSets also provide support for scaling, rolling updates, and graceful termination.

• They are often used to run databases, messaging queues, and other stateful applications in Kubernetes.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: webapp
spec:
  serviceName: webapp
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: web
        image: nginx:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
      volumes:
      - name: config
        configMap:
          name: nginx-config
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

RBAC (Role-Based Access Control)

Role-Based Access Control (RBAC) is a method of restricting access to resources in a system based on the roles assigned to individual users or groups. In Kubernetes, RBAC is used to control access to the Kubernetes API and to resources within the cluster, such as pods, services, and deployments.

Kubernetes RBAC defines four key primitives

• Role:- A Role is a set of rules that specify the actions that can be performed on resources within a namespace.

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

• RoleBinding:- A RoleBinding binds a role to a user or a group within a namespace.

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

• ClusterRole:- A ClusterRole is similar to a Role, but it applies to the entire cluster instead of a single namespace.

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

• ClusterRoleBinding:- A ClusterRoleBinding binds a ClusterRole to a user or a group across the entire cluster.

      kind: ClusterRoleBinding
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: read-pods-global
      subjects:
      - kind: User
        name: jane
        apiGroup: rbac.authorization.k8s.io
      roleRef:
        kind: ClusterRole
        name: pod-reader
        apiGroup: rbac.authorization.k8s.io
  

Pod Security Policies

• Pod Security Policies (PSPs) is a Kubernetes feature that allows administrators to control the security aspects of the pods running on a cluster.

• PSPs define a set of conditions that must be met by the pods in order to be created or run on the cluster.

• PSPs can help to enforce security policies, such as preventing the use of privileged containers or ensuring that pods run with a specific user ID.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrictive
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

Secrets

• Secrets are Kubernetes objects that allow you to store and manage sensitive information, such as passwords, tokens, or certificates.

• Secrets can be used to provide secure communication between pods, authentication with external services, and other security-related tasks.

• Secrets can be stored in the Kubernetes API server and can be mounted into pods as volumes or environment variables.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: dXNlcm5hbWU=
  password: cGFzc3dvcmQ=

Network Policies

• Network Policies is a Kubernetes feature that allows you to define rules for incoming and outgoing traffic to and from a pod.

• Network Policies use labels to select the pods to which the policies apply and specify the traffic rules for those pods.

• Network Policies can help to increase the security of your cluster by restricting access to certain pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-internal
spec:
  podSelector:
    matchLabels:
      role: internal
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: internal

TLS (Transport Layer Security)

• TLS is a protocol that provides secure communication over a network.

• In Kubernetes, TLS can be used to secure the communication between the API server and the kubelets, as well as the communication between pods and services.

• Kubernetes supports the use of TLS certificates to authenticate and encrypt the communication between the various components in a cluster.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256"
spec:
  tls:
  - secretName: tls-secret
  rules:
  - host: my-domain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Thank you for reading!!

Irfan