Kubernetes Container Security – Deployment Phase

Kubernetes infrastructure ought to be designed firmly before workloads being deployed. From a security perspective, you initially need visibility into what you’re deploying – and the way. Then you’ll determine and reply to security policy violations. At a minimum, you would like to know:

• What is being deployed
• Where it’s planning to be deployed
• How it’s deployed
• What it will access
• Is it complies along with the policies and security necessities

With this data, you’ll begin to focus on areas for correction and hardening and implement correct segmentation.

Some Security Practices in Deploy Phase

1. Namespaces are a key isolation boundary for Kubernetes resources. they supply a reference for network policies, access management restrictions, and alternative vital security controls. Separating workloads into namespaces will facilitate contain attacks and limit the impact of mistakes or damaging actions by licensed users.

2. By default, Kubernetes permits each pod to contact each different pod. Network segmentation policies are a key security management which will stop lateral movement across containers within the case that an offender breaks in. we have a tendency to the way to found out Kubernetes network policies:

• Building Kubernetes network policies to regulate ingress traffic
• Building Kubernetes network policies to regulate egress traffic

3. As a primary step, make certain deployments mount solely the secrets they really need to stop unessential exposure.

4. As a rule of thumb, don’t set up code from unknown sources. For Kubernetes, this indicates the usage of images from recognized registries which can be on permit lists only.

5. The set of capabilities, role bindings, and privileges given to containers will greatly impact the security risk. The aim is to stick to the principle of least privilege and permit the minimum privileges and capabilities that may enable the container to perform its intended perform.

Pod Security Policies are a technique to manage the security-related attributes of pods, as well as container privilege levels. These will permit an operator to specify the following:

• Do not run application processes as root.
• Do not allow privilege escalation.
• Use a read-only root filesystem.
• Use the default (masked) /proc filesystem mount
• Do not use the host network or process space.
• Drop unused and unnecessary Linux capabilities.
• Use SELinux options for more fine-grained process controls.
• Give each application its own Kubernetes Service Account.
• Do not mount the service account credentials in a container if it does not need to access the Kubernetes API.

6. consider labeling your deployments with the name, email alias, or Slack channel of the team answerable for associate application. this can create it easier to alert the accountable team for triaging security problems.

7. RBAC provides a technique for dominant authorization to access a cluster’s Kubernetes API server, each for users and repair accounts within the cluster. Kubernetes RBAC is extremely configurable.

8. As an extension of image scanning, enforce policies at the deploy part supported scan results. a way to enforce would be to use the confirming Admission Controller, a feature of Kubernetes to reject deployment creation once they specify images while not scanning results or crucial vulnerabilities, or if the images are designed over ninety days past. Images that haven’t been scanned recently may contain vulnerabilities that are new disclosed since the time of the last scan.