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
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
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
7. Extend Your Image Scanning To Deploy Phase
8. Use Labels And Annotations Appropriately
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
Like to know how all of these best practices are implemented in Otomi Container Platform?
Hit the button below!
