A step by step guide to Kubernetes Storage Kubernetes Security
Kubernetes is a powerful tool for managing and scaling containerized applications, but it also requires careful attention to storage and security to ensure your deployment is reliable and secure. In this blog, we'll explore Kubernetes Storage and Kubernetes Security, two important aspects of running Kubernetes in production.
Kubernetes Storage :
Storage is a critical component of any application deployment, and Kubernetes provides several options for managing storage in a containerized environment. Let's take a look at some of the storage options available in Kubernetes:
- Persistent Volumes (PV) and Persistent Volume Claims (PVC): Persistent Volumes are a way to store data outside of the container in a durable and scalable way. A Persistent Volume Claim is a request for storage that can be fulfilled by a Persistent Volume. By using PVs and PVCs, you can separate the storage concerns from the application concerns, making it easier to manage and scale your storage independently of your application.
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
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 :
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 of 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 :
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
By using these security features in Kubernetes, you can reduce the risk of unauthorized access and ensure that your deployment is secure.
Conclusion :
In conclusion, Kubernetes Storage and Kubernetes Security are two important aspects of running Kubernetes in production. By using the storage options available in Kubernetes, you can build reliable and scalable applications that can easily manage their storage needs. By using the security features available in Kubernetes, you can reduce the risk of unauthorized access and ensure that your deployment is secure. By paying careful attention to storage and security in your Kubernetes deployment, you can build a powerful and reliable platform for your containerized applications.
Subscribe to my newsletter
Read articles from Subho Dey directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Subho Dey
Subho Dey
"DevOps engineer with a passion for continuous improvement and a drive to build better software, faster. I'm a strong believer in the power of collaboration, automation, and agile methodologies to transform the world of software development and delivery. My expertise includes continuous integration and delivery, infrastructure as code, Docker, Kubernetes, and configuration management. Follow along as I share my insights and experiences on Hashnode and let's build better software, together!"