What is Kubernetes Storage?

Kubernetes is a free and open-source container orchestration platform. It provides services and management capabilities needed to efficiently deploy, operate, and scale containers in a cloud or cluster environment.

In Kubernetes, the most basic type of storage is non-persistent—also known as ephemeral. Each container has ephemeral storage by default—this storage uses a temporary directory on the machine that hosts the Kubernetes pod. It is portable, but not durable.

Kubernetes supports multiple types of persistent storage. This can include file, block, or object storage services from cloud providers (such as Amazon S3), storage devices in the local data center, or data services like databases. Kubernetes provides mechanisms to abstract this storage for applications running on containers, so that applications never communicate directly with storage media.

Volumes

Volumes are basic entities in Kubernetes, used to provide storage to containers. A volume can support all types of storage, including network file system (NFS), local storage devices, and cloud-based storage services. You can also build your own storage plugins to support new storage systems. Access to volumes can be achieved directly via pods or through persistent volumes (explained below).

Non-Persistent Storage

The default storage configuration in Kubernetes is non-persistent (temporary). As long as a container exists, it stores data in the temporary storage directory of the host, and when it shuts down the data is removed.

Persistent Volumes (PV) and Persistent Volume Claims (PVC)

To enable persistent storage, Kubernetes uses two key concepts:

PersistentVolume (PV) is a storage element in a cluster, defined manually by an administrator or dynamically defined by a storage class (explained below). A PV has its own lifecycle, separate from the lifecycle of Kubernetes pods. The PV API captures storage implementation details for NFS, cloud provider-specific storage systems, or iSCSI.

PersistentVolumeClaim (PVC) is a user’s storage request. An application running on a container can request a certain type of storage. For example, a container can specify the size of storage it needs or the way it needs to access the data (read only, write, read/write, with one-time or ongoing access).

StorageClasses:

You can configure StorageClass and assign PVs to each one. A StorageClass represents one type of storage. For example, one StorageClass may represent fast SSD storage, while another can represent magnetic drives, or remote cloud storage. This allows Kubernetes clusters to configure various types of storage according to workload requirements.

A StorageClass is a Kubernetes API for setting storage parameters using dynamic configuration to enable administrators to create new volumes as needed. The StorageClass defines the volume plug-in, external provider (if applicable), and the name of the container storage interface (CSI) driver that will enable containers to interact with the storage device.

Kubernetes Security:

Kubernetes Security is based on the 4C’s of cloud-native security: Cloud, Cluster, Container, and Code:

• Cloud (or Corporate Datacenter/Colocation facility): The underlying physical infrastructure is the basis of Kubernetes security. Whether the cluster is built on one’s own datacenter or a cloud provider, basic cloud provider (or physical security) best practices must be observed.

• Cluster: Securing a Kubernetes cluster involves both the configurable components such as the Kubernetes API and security of all the applications that are part of the cluster. Since most cloud-native applications are designed around microservices and APIs, applications are only as secure as the weakest link in the chain of services that comprise the entire application.

• Container: Container design best practices consist of: starting with the smallest code base possible (excluding unnecessary libraries or functions), avoiding granting unnecessary privileges to users in the container, and ensuring that containers are scanned for vulnerabilities at build time.

• Code: Code presents a major attack surface for any Kubernetes environment. Simple policies such as encrypting TCP using TLS handshakes, not exposing unused ports, scanning, and testing regularly can help prevent security issues from arising in a production environment.

RBAC:

RBAC in Kubernetes is the mechanism that enables you to configure fine-grained and specific sets of permissions that define how a given user, or group of users, can interact with any Kubernetes object in the cluster or a particular cluster namespace.

Kubernetes implements an RBAC model for protecting resources in the cluster.

POD Security Policy:

A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it can access. ThePodSecurityPolicy objects define a set of conditions that a pod must run with to be accepted into the system.

Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to. These settings fall into three categories:

• Controlled by a boolean: Fields of this type default to the most restrictive value.

• Controlled by an allowable set: Fields of this type are checked against the set to ensure their value is allowed.

• Controlled by a strategy: Items that have a strategy to provide a mechanism to generate the value and a mechanism to ensure that a specified value falls into the set of allowable values.

Kubernetes 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.

Kubernetes offers a solution to this that follows the path of least privilege. Kubernetes Secrets act as separate objects which can be queried by the application Pod to provide credentials to the application for access to external resources.

There are several options to create a Secret:

• Creating a Secret via kubectl.

• Creating a Secret from config file.

• Creating a secret using kustomize.

Network Policies:

If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.

A Kubernetes network policy defines the access permissions for groups of pods the same way a security group in the cloud is used to control access to VM instances.

Like all other objects in Kubernetes, network policy can be defined in a YAML file.

#policy1-do.yaml
apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy
metadata:
    name: policy1 
namespace: dev 
spec:
    podSelector:
        matchLabels:
            app: webserver-dev 
        policyTypes:
        -    Ingress
        -    Egress 
        ingress:
        -    from:
        -    ipBlock:
            cidr: 10.169.25.20/32
        -    namespaceSelector:
        matchLabels:
            project: jtac
        -    podSelector:
            matchLabels:
                app: client1-dev 
    ports:
    -    protocol: TCP 
    port: 80
egress:
    -    to:
        -    podSelector:
            matchLabels:
        app: dbserver-dev 
    ports:
        -    protocol: TCP 
        port: 80

TLS Certificates:

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.

You can secure an application running on Kubernetes by creating a secret that contains a TLS (Transport Layer Security) private key and certificate.

Thank you for reading! Happy Learning!!

Santosh Chauhan