Shiwam Tiwari's Blog
Kubernetes Storage & Kubernetes Security

Kubernetes Storage & Kubernetes Security

Shiwam Tiwari's photo
Shiwam Tiwari
·

6 min read

Table of contents

Persistent Volumes

In Kubernetes, a Persistent Volume (PV) is a storage abstraction that provides a way for users to access persistent storage in a cluster. A Persistent Volume is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a storage class.

Once a Persistent Volume has been created, it can be accessed by creating a Persistent Volume Claim (PVC). A PVC is a request for a specific amount of storage from a Persistent Volume. When a PVC is created, Kubernetes finds a suitable Persistent Volume that matches the requirements specified in the PVC and binds them together.

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-ebs
      name: test-volume
  volumes:
  - name: test-volume
    # This AWS EBS volume must already exist.
    awsElasticBlockStore:
      volumeID: "<volume id>"
      fsType: ext4

Persistent Volume Claims

In Kubernetes, a Persistent Volume Claim (PVC) is a request for a specific amount of storage from a Persistent Volume (PV). PVCs are used by applications to request storage that will be available to them throughout their lifecycle, even if the pods they are running in are deleted or rescheduled to other nodes.

PVCs allow users to consume storage without having to know the details of the underlying storage system. They also allow administrators to manage storage in a cluster, providing users with the appropriate storage resources based on their needs.

kubectl describe pv task-pv-volume
Name:            task-pv-volume
Labels:          type=local
Annotations:     <none>
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Terminating
Claim:
Reclaim Policy:  Delete
Access Modes:    RWO
Capacity:        1Gi
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/data
    HostPathType:
Events:            <none>

Projected Volumes

In Kubernetes, Projected Volumes are used to combine multiple sources of data into a single volume that can be mounted in a container. Projected Volumes allow a container to access multiple files or data sources in a single mount point.

Projected Volumes can be used to combine data from different sources such as ConfigMaps, Secrets, and ServiceAccount tokens, and mount them all as a single volume in the container. This is useful for applications that require access to multiple configuration files or secrets.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    projected:
      sources:
      - configMap:
          name: my-config
      - secret:
          name: my-secret
      - downwardAPI:
          items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels

Storage Classes

In Kubernetes, a Storage Class is an abstraction layer that provides a way to define different types of storage and their associated properties, such as access mode, replication factor, and backup policies. Storage Classes are used to dynamically provision storage for Persistent Volume Claims (PVCs).

When a PVC is created with a specific Storage Class, Kubernetes provisions a new Persistent Volume that matches the requirements specified by the Storage Class. The PVC can then use this Persistent Volume to store data. If the requested storage size is not available in an existing Persistent Volume, Kubernetes can dynamically create one that meets the requirements.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage-class
provisioner: example.com/provisioner

Dynamic Volume Provisioning

creation of Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) as needed. With dynamic volume provisioning, Kubernetes can automatically create a new PV and associate it with a PVC when a new claim is made for storage that matches a specific Storage Class.

Dynamic volume provisioning removes the need for manual intervention to create and configure Persistent Volumes, making it easier to manage storage in Kubernetes clusters. It also enables administrators to optimize storage utilization by automatically allocating only the required amount of storage and deallocating it when no longer needed.

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

Volume Snapshots

Volume snapshots in Kubernetes is a feature that allows you to take point-in-time snapshots of a Persistent Volume (PV) and use them to create new PVs, or restore an existing PV to a previous state. This is useful for creating backups, disaster recovery, and testing scenarios.

Kubernetes provides a native snapshot API that can be used to manage snapshots of PVs. The snapshot API is implemented as a Kubernetes Custom Resource Definition (CRD) that extends the Kubernetes API to provide snapshot functionality.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  snapshotClassName: my-snapshot-class
  source:
    name: my-pv
    kind: PersistentVolumeClaim

CSI Volume Cloning

CSI Volume Cloning is a feature in Kubernetes that allows for the creation of new volumes by cloning an existing volume. This feature is available through the Container Storage Interface (CSI) and is used to create new volumes quickly and efficiently from an existing volume.

When a volume is cloned, the data is copied from the source volume to the destination volume. The source and destination volumes can be on the same storage system, or they can be on different storage systems that support the CSI volume cloning operation.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-source-pvc
spec:
  storageClassName: my-storage-class
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Storage Capacity

Storage capacity in Kubernetes refers to the amount of disk space available to store data on a node in a Kubernetes cluster. Each node in a Kubernetes cluster has a finite amount of storage capacity, which is typically provided by local disks or network-attached storage (NAS) devices.

To manage storage capacity in Kubernetes, you can use Persistent Volumes (PVs) and Persistent Volume Claims (PVCs). PVs represent a piece of storage in the cluster, while PVCs are used by Pods to request a certain amount of storage from a PV.

RBAC (Role-Based Access Control)

RBAC in Kubernetes allows fine-grained access control to resources within a cluster. It enables administrators to define roles and bind them to users or groups, ensuring proper authorization.

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


kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: my-role-binding
subjects:
  - kind: User
    name: alice
    api Version: rbac.authorization.k8s.io/v1 
    roleRef: kind: Role name: my-role 
    apiGroup: rbac.authorization.k8s.io 
subjects:
  - kind: User 
    name: alice 
    apiGroup: rbac.authorization.k8s.io

Pod Security Policies

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: my-pod-security-policy
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  volumes:
    - 'configMap'
    - 'secret'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  allowedCapabilities: []
  requiredDropCapabilities: []

Secrets

Secrets in Kubernetes provide a way to store and manage sensitive information, such as API keys, passwords, and certificates. They are encrypted and can be mounted as volumes or used as environment variables in pods.

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

Network Policies

Network Policies control the ingress and egress network traffic for pods in a Kubernetes cluster. They enable you to define granular network rules and segment your applications.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
        - namespaceSelector:
            matchLabels:
              project: my-project
      ports:
        - protocol: TCP
          port: 80

TLS (Transport Layer Security)

TLS (Transport Layer Security) provides secure communication between clients and servers. In Kubernetes, TLS can be configured for various components, such as ingress controllers, API servers, and service-to-service communication.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/cluster-issuer: my-cluster-issuer
spec:
  tls:
    - hosts:
        - example.com
      secretName: my-tls-secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80