Kubernetes Storage and Kubernetes Security

Kubernetes is an open-source container orchestration platform that enables the deployment and management of containerized applications at scale. As such, it provides many features for managing containerized workloads, including storage and security.

Kubernetes provides robust storage and security features that can help to manage containerized workloads in a cluster efficiently and securely.

Kubernetes Storage

In Kubernetes, storage is used to provide persistent data storage for containers running in a cluster. Kubernetes provides several types of storage options, including local storage, network-attached storage (NAS), and cloud storage. Storage volumes can be mounted to a pod and accessed from multiple containers or pods within the same or different nodes. Kubernetes also provides built-in support for storage orchestration, which automates the creation, deletion, and resizing of storage volumes, and dynamic provisioning, which allows for the automatic creation of new storage volumes when needed. This makes it easier to manage persistent data in a containerized environment.

Persistent Volume (PV)

Containers are immutable, meaning that when a container shuts down, all data created during its lifetime is lost. This is suitable for some applications, but in many cases, applications need to preserve the state or share information with other applications. A common example is applications that rely on databases.

Kubernetes provides a convenient persistent storage mechanism for containers. It is based on the concept of a Persistent Volume (PV).

Persistent volumes are independent of the lifecycle of the pod that uses it, meaning that even if the pod shuts down, the data in the volume is not erased.

Kubernetes persistent volumes are administrator-provided volumes. They have predefined properties including file system, size, and identifiers like volume ID and name.

An example of a Persistent Volume manifest file is:

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

Persistent Volume Claim (PVC)

A Persistent Volume Claim (PVC) is a request for a specific amount of storage in Kubernetes, which is matched with a Persistent Volume (PV) that satisfies the request. This allows users and applications to use storage resources without needing to manage the underlying infrastructure.

An example of a Persistent Volume Claim manifest file is:

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

The following manifest file can be used to attach the aforementioned Persistent Volume to a pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongo
  labels:
      app: mongo
spec:
  selector:
    matchLabels:
      app: mongo
  template:
    metadata:
      labels:
        app: mongo
    spec:
      containers:
        - name: mongo
          image: mongo
          ports:
            - containerPort: 27017
          volumeMounts:
            - name: storage
              mountPath: /data/db
      volumes:
        - name: storage
          persistentVolumeClaim:
            claimName: mongo-pvc

Storage Class

A StorageClass in Kubernetes enables the dynamic allocation of storage resources based on demand. Each StorageClass can be customized and assigned with PVs (Persistent Volumes) according to its specific type of storage. Different types of storage, such as fast SSD, magnetic drives, or cloud storage, can be represented by different Storage Classes. As a result, Kubernetes clusters can accommodate diverse storage needs based on the demands of different workloads.

Kubernetes Security

Kubernetes is an open-source container orchestration platform that enables organizations to deploy, manage, and scale containerized applications. As with any technology, security is an essential aspect of Kubernetes deployment.

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a Kubernetes feature that provides a way to restrict and control access to Kubernetes resources based on the user's role and permissions. With RBAC, you can define who can perform which actions on which resources within a Kubernetes cluster.

RBAC defines three key components: roles, role bindings, and subjects.

Roles: A role is a collection of permissions that define a set of operations that can be performed on Kubernetes resources. For example, you can define a role that allows users to create and delete pods but restricts them from accessing nodes or other sensitive resources.
```
 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"]
```

Role Bindings: A role binding is a way to attach a role to a specific user, group, or service account. By creating a role binding, you can grant specific permissions to a user or group of users.

 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

Subjects: Subjects are the entities to which roles are bound. Subjects can be users, groups, or service accounts. Users can be authenticated by various mechanisms like LDAP, OAuth2, OpenID Connect, or X509 certificates.

RBAC is implemented using the Kubernetes API server. When a user or service account tries to access a Kubernetes resource, the API server checks the user's permissions against the RBAC policies defined in the cluster. If the user has the required permissions, the request is allowed, and if not, the request is denied.

RBAC is a powerful tool for securing your Kubernetes cluster and ensuring that only authorized users have access to sensitive resources. By using RBAC, you can define granular permissions for each user or service account and manage access control more effectively.

Pod Security Policies (PSPs)

Pod Security Policies (PSPs) in Kubernetes allow administrators to define a set of security policies that pods must adhere to, such as user and group IDs, file system permissions, and types of volumes. PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25.

Secrets

Secrets in Kubernetes are a way to securely store sensitive information, such as passwords or API keys, as key-value pairs. They are stored as encrypted data and can be used by applications running in a Kubernetes cluster. Secrets can be mounted as volumes or used as environment variables in containers. They are managed by the Kubernetes API server and can be updated or deleted as needed. Secrets provide a secure way to manage sensitive data in a containerized environment.

apiVersion: v1
kind: Secret
metadata:
 name: db-password
type: Opaque
data:
 password: cBFza3dvnmQ=

Network policies

Network policies in Kubernetes are a set of rules that control the communication between pods in a cluster based on labels. They allow for fine-grained control over network traffic, including allowing or denying access to specific ports and protocols. Network policies are implemented using the Kubernetes network plugin, which intercepts network traffic and enforces the defined rules. They are an important tool for enforcing security and isolation within a Kubernetes deployment.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

TLS(Transport Layer Security)

In Kubernetes, TLS is used to provide secure communication between various components within a cluster. Kubernetes supports the use of TLS certificates to authenticate and encrypt communication.

The certificates.k8s.io API allows for the provisioning of TLS certificates signed by a user-controlled Certificate Authority (CA) to establish trust in workloads.

TLS can secure communication between the API server and kubelets, as well as between pods and services. TLS in Kubernetes is essential for maintaining a secure containerized environment.

Conclusion

Kubernetes provides robust storage and security features to manage containerized workloads efficiently and securely. For storage, Kubernetes offers various options for persistent data storage and file sharing between containers. For security, Kubernetes has built-in features like role-based access control, network policies, secure communication, image security, auditing, and secret management. Overall, Kubernetes enables secure and reliable container orchestration at scale.

Thank you.

#Kubernetes #Devops #Trainwithshubham #Kubeweek #kubeweekchallenge #Day5challenge