One of the services our team offers is what we call a Kubernetes Security Assessment. In this assessment, we attempt to give you broad insights about your Kubernetes security posture, covering everything from your infrastructure to your applications.
This can serve as a template for an internal security assessment that your team could perform (based largely on the other articles we have sent out), or you could hire us to perform this assessment. We have experienced, certified Kubernetes Security experts on staff and would be happy to perform this assessment.
The Linux Foundation likes to divide Kubernetes Security into 3 facts: Cloud, Cluster, and Container Security.
This facet is actually, ironically, not very much about Kubernetes, but it is important to call out. The underlying infrastructure and the cloud accounts (VMWare, AWS, Azure, Google, etc) used to manage that infrastructure must be secured, access limited, and devices kept up to date with the latest security patches.
I will, nonetheless, mention several things here:
- 2-Factor Authentication: Make sure all cloud accounts have 2FA so that remote hackers have a significantly harder time gaining access to an account.
- Virus Scanners and Security Patches: Make sure your physical devices and your employees’ physical devices have up to date security patches and regular virus scans to detect if their devices have been compromised.
- Virtual Private Networks: Make it so that someone has to authenticate with a VPN from their device to access your cloud accounts or to connect to your Kubernetes Security cluster or, in smaller environments, at least use IP-address whitelisting to prevent unauthorized connections. This significantly reduces your attack surface.
- Web Application Firewalls: Use WAFs to block many malformed and/or suspicious HTTP requests. Most cloud providers now offer pay-as-you-go access to WAFs which can protect against many forms of buffer overflow or denial of service vulnerabilities.
- Billing Alerts / Monitoring: Add billing alerts so that if a hacker spins up new servers or otherwise incurs charges, you get alerts. 99% of hackers are script kiddies spinning up bitcoin miners.
- Encryption: Enabling proper encryption on load balancers, wifi, email, and your VPN so that sniffers cannot pick up keys, tokens, or authentication tokens and gain unauthorized access to things.
- Access Audits: Regularly review and limit users’ access to just the systems they truly needs access to.
- Training: Regularly give your staff security awareness training to help them to identify suspicious requests from potential hackers.
I will not spend much time on this as this facet of the 3 is covered by an established field of materials in the CISO/CISSP space.
You need to make sure that your cluster is secured.
- Cluster is Up To Date: Do not run extremely old versions of Kubernetes (those that are end of life) and ensure that you are running the latest security patches.
- CIS Benchmarks: Run tools like Kube Bench to assess that you are following best practices related to cluster security – everything from disable insecure modes of authentication (ex: anonymous authentication) to insecure encryption settings.
- Pen testing: Run tools like Kube Hunter regularly to perform benchmarks and detect regressions in your cluster’s configuration.
- Intrusion Detection: Tools like Project Falco can detect and alert on suspicious activities, such as command shells being opened in production.
- Network Policies: Setup default network policies cluster-wide that limit access between different namespaces.
- RBAC: Ensure that developers and teams are given limited privileges and just privileges to the applications that they are working on.
We should make sure that the applications you are deploying as well as the way you are deploying them is secure:
- Trivy: Scan your applications for obvious, repairable vulnerabilities from the vulnerabilities database.
- KubeSec: Scan your pod settings for obvious shortcomings or improperly configured privileges.
- Gatekeeper / Pod Security Policies / OPA: Ensure and prevent applications from being deployed with escalated privileges. Run Gatekeeper in audit mode initially to identify problem and then begin enforcing after you have had time to modify your deployments to deploy securely to prevent regressions.
- Network Policies: Limit your applications to only be able to connection to applications they have a legitimate reason to connect with.
- Linux Privileges: Configure Security Contexts’ Linux Capabilities, AppArmor profiles, and/or Secomp profiles to ensure applications have the minimum privileges that they require.
We hope you have enjoyed this series! Please reach out to us with feedback or questions, and let us know if there is any way we can help!