Although containers enable speed, portability, and the ability to take advantage of microservices architectures, they can also create security blind spots and increase your attack surface. As more containers are deployed, maintaining adequate visibility into your cloud-native infrastructure components becomes more difficult.

In this post, we’ll explore Kubernetes security risks and challenges you’re likely to encounter, especially in production and at scale, and provide 10 best practices and practical recommendations to help you secure cloud-native infrastructure and applications.

1. Use An Image Scanner To Identify Known Vulnerabilities

Your image scanner sho­uld be able to identify vulnerabilities within your images, including by layer, and tell you whether they are fixable or not. It must be able to scan for vulnerabilities in OS packages and third-party runtime libraries for the languages being used in your containerized applications.

2. Use NameSpaces To Isolate Sensitive Workloads

Namespaces are a key isolation boundary for Kubernetes resources. They provide a reference for network policies, access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of mistakes or destructive actions by authorized users.

3. Use Kubernetes Network Policies To Control Traffic Between Pods And Clusters

By default, Kubernetes allows every pod to contact every other pod. Network segmentation policies are a key security control that can prevent lateral movement across containers in the case that an attacker breaks in.

4. Prevent Overly Permissive Access To Secrets

As a first step, make sure deployments mount only the secrets they require to prevent unnecessary exposure.

5. Asses The Privileges Used By Containers

The set of capabilities, role bindings, and privileges given to containers can greatly impact your security risk. The goal here is to adhere to the principle of least privilege and provide the minimum privileges and capabilities that would allow the container to perform its intended function.

Pod Security Policies are one way to control the security-related attributes of pods, including container privilege levels.

These Can Allow 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 services account.
• Do not mount the services account credentials in a container if it doesn’t need to access the Kubernetes API.

6. Asses Image Provenance, Including Registries

As a rule of thumb, don’t deploy code from unknown sources. For Kubernetes, this means using images from known registries/ones that are on allow lists only.

7. Extend Your Image Scanning To Deploy Phase

As an extension of image scanning, enforce policies at the deploy phase based on scan results. One way to enforce would be to use the Validating Admission Controller, a feature of Kubernetes to reject deployment creation when they specify images without scanning results or critical vulnerabilities, or if the images have been built over 90 days ago. Images that haven’t been scanned recently might contain vulnerabilities that have been newly disclosed since the time of the last scan.

8. Use Labels And Annotations Appropriately

For example, consider labeling or annotating your deployments with the name, email alias, or Slack channel of the team responsible for an application. This will make it easier to alert the responsible team for triaging security issues.

9. Enable Kubernetes Role-Based Access Control (RBAC)

RBAC provides a method for controlling authorization to access a cluster’s Kubernetes API server, both for users and service accounts in the cluster. Kubernetes RBAC is highly configurable, so make sure you’re not making any of these 5 Kubernetes RBAC mistakes.

10. Use Kubernetes Built-In Controls When Available To Tighten Security

Configure the security context for pods to limit their capabilities. These controls can eliminate entire classes of attacks that depend on privileged access. Read-only root file systems, for example, can prevent any attack that depends on installing software or writing to the file system.

‍

If you need to make sure all of these best practices are implemented, then we have great news. All of the below recommendations have already been implemented in the Otomi Container Platform. Like to know how all of these best practices are implemented in Otomi Container Platform? Request a free demo here.