Day 05:Kubernetes Storage Kubernetes Security

Persistent Volumes

Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim.

A?PersistentVolume?(PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using?Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

A?PersistentVolumeClaim?(PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see?AccessModes).

Here is the configuration file for the hostPath PersistentVolume:

apiVersion: v1
kind: PersistentVolume
metadata:
? name: task-pv-volume
? labels:
? ? type: local
spec:
? storageClassName: manual
? capacity:
? ? storage: 10Gi
? accessModes:
? ? - ReadWriteOnce
? hostPath:
? ? path: "/mnt/data"        

Persistent Volume claim:

If a user deletes a PVC in active use by a Pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any Pods. Also, if an admin deletes a PV that is bound to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is no longer bound to a PVC.

You can see that a PVC is protected when the PVC's status is?Terminating?and the?Finalizers?list includes?kubernetes.io/pvc-protection:

kubectl describe pvc hostpath
Name:          hostpath
Namespace:     default
StorageClass:  example-hostpath
Status:        Terminating
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-class
example-hostpath
               volume.beta.kubernetes.io/storage-provisioner
example.com/hostpath
Finalizers:    
[
kubernetes.io/pvc-protection
]        

The StorageClass Resource

Each StorageClass contains the fields?provisioner,?parameters, and?reclaimPolicy, which are used when a PersistentVolume belonging to the class needs to be dynamically provisioned.

The name of a StorageClass object is significant, and is how users can request a particular class. Administrators set the name and other parameters of a class when first creating StorageClass objects, and the objects cannot be updated once they are created.

Administrators can specify a default StorageClass only for PVCs that don't request any particular class to bind to: see the?PersistentVolumeClaim section?for details.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:  
  name: standard
  provisioner: kubernetes.io/aws-ebs
  parameters:  
    -type: gp2
 reclaimPolicy:Retain
 allowVolumeExpansion: true
 mountOptions:
    - debug
 volumeBindingMode:Immediate        

StatefulSets

StatefulSet is the workload API object used to manage stateful applications.

Manages the deployment and scaling of a set of?Pods,?and provides guarantees about the ordering and uniqueness?of these Pods.

Like a?Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

apiVersio:v1
kind: Service
metadata:  
name:nginx
labels:    
app:nginx
spec:  
ports: 
- port:80    
name: web 
clusterIP: None  
selector:
app: nginx
---
apiVersion:apps/v1
kind:StatefulSet
metadata:  
name:web
spec:
  
selector:
matchLabels:
app:nginx  
serviceName:"nginx"  
replicas:3  
minReadySeconds:10
template:
metadata:     
labels:       
app:nginx
spec:
terminationGracePeriodSeconds:10     
containers:
- name:nginx
image:registry.k8s.io/nginx-slim:0.8
ports:
- containerPort:80
name:web
volumeMounts:
- name:www         
mountPath:/usr/share/nginx/html
  
volumeClaimTemplates:
- metadata:
name:www
spec:     
accessModes: 
[ 
"ReadWriteOnce" 
]      
storageClassName:"my-storage-class"      
resources:
requests:
storage:1Gin        

RBAC

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.

RBAC authorization uses the?rbac.authorization.k8s.io?API group?to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.

To enable RBAC, start the?API server?with the?--authorization-mode?flag set to a comma-separated list that includes?RBAC; for example:

Role example

Here's an example Role in the "default" namespace that can be used to grant read access to?pods:

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

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.

Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods. Kubernetes, and applications that run in your cluster, can also take additional precautions with Secrets, such as avoiding writing secret data to nonvolatile storage.

Uses for Secrets

There are three main ways for a Pod to use a Secret:

• As?files?in a?volume?mounted on one or more of its containers.
• As?container environment variable.
• By the?kubelet when pulling images?for the Pod.

apiVersion:v1
kind:Pod
metadata:  
name:mypod
spec:
containers:
- name:mypod
image:redis
volumeMounts:
- name:foo
mountPath:"/etc/foo"
readOnly:true  
volumes:
- name:foo
secret:
secretName:mysecret
optional:true        

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. NetworkPolicies are an application-centric construct which allow you to specify how a?pod?is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections.

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:
? name: test-network-policy
? namespace: default
spec:
? podSelector:
? ? matchLabels:
? ? ? role: db
? policyTypes:
? ? - Ingress
? ? - Egress
? ingress:
? ? - from:
? ? ? ? - ipBlock:
? ? ? ? ? ? cidr: 172.17.0.0/16
? ? ? ? ? ? except:
? ? ? ? ? ? ? - 172.17.1.0/24
? ? ? ? - namespaceSelector:
? ? ? ? ? ? matchLabels:
? ? ? ? ? ? ? project: myproject
? ? ? ? - podSelector:
? ? ? ? ? ? matchLabels:
? ? ? ? ? ? ? role: frontend
? ? ? ports:
? ? ? ? - protocol: TCP
? ? ? ? ? port: 6379
? egress:
? ? - to:
? ? ? ? - ipBlock:
? ? ? ? ? ? cidr: 10.0.0.0/24
? ? ? ports:
? ? ? ? - protocol: TCP
? ? ? ? ?port: 5978
        

Thanks For Reading!!!!