In 2018, we learned about several Kubernetes security vulnerabilities, with the latest Kubernetes security flaw being the most severe. The last few Kubernetes releases have both introduced new security features and also provided critical security patches to help resolve some of the most impactful Kubernetes security issues and shortcomings to date.
As you start the new year, take a look at the version of your Kubernetes clusters. If you are still using an older version, we highly recommend you promptly upgrade to the latest release.
To get you motivated, we’ve compiled the top reasons you should upgrade your Kubernetes clusters!
Security patches are confined to the last three Kubernetes releases, making it all the more critical that you update now. The further behind the latest release you fall, the more difficult your path to upgrade becomes when the next major CVE is found. For example, etcd2 has been deprecated in Kubernetes 1.13 so the upgrade path would be considerable if you haven’t been keeping up with the Kubernetes releases. Getting behind in releases leaves you in the undesirable position of doing large migrations to mitigate vulnerabilities. Upgrade now to ensure you are using the most secure version of Kubernetes, since the Kubernetes community is quick to act and remediate any known security risks.
Network policies are the backbone of pod-to-pod firewalling and help ensure tenant isolation and network least privilege. The graduation of IPBlock and Egress means that restricting network access to the outside world now falls within the capabilities of Kubernetes. The configurable aspects of the network policies now include pod-to-pod traffic (including between namespaces) and IPBlocks controlling both ingress and egress protocols and ports. This more granular approach to network policies makes the entire offering fine grained and extensible. You gain a significant reduction in attack surface for critical services when you use network policies.
If you’re running an on-premises Kubernetes cluster, you’re probably familiar with how arduous it was to add a node to the cluster. In the best case, you were provisioning certificates manually and bootstrapping the nodes. In the worst case, you were reusing the certificates for each Kubelet. The new method allows for nodes to send a certificate signing request to a cluster-wide manager and effectively bootstrap itself securely. The automation of this process and stabilization to v1 guarantees that tooling can be effectively built around it.
One major concern in the Kubernetes community has been that the storage of secrets and other metadata in etcd was not encrypted. To allay the security concerns, recent integrations with cloud providers and other security managers will now encrypt traffic before it is sent to etcd, reducing yet another attack surface.
Audit logging for Kubernetes is now at your fingertips. Dynamic configuration of audit backends moves to Alpha status, which means that you won’t need to modify the api-server configuration to forward the logs to another aggregator. As a result, you can easily integrate your SIEM or other tools into your audit logging pipeline. These audit logs can be used for a multitude of purposes, including determining privilege escalations, RBAC misconfigurations, compliance audits, and post-incident forensic investigation.
A pod security policy helps restrict Linux capabilities, user privileges, and mount privileges to containers by defining configurations that pods must satisfy. A newly added configuration is the restriction on volume mounts from the host to be read-only. A majority of the time, pods should not write to the host filesystem, because this data will be persisted between restarts and is usually accidental. The pod security policy now enforces that specific prefixes will be read-only so users don’t accidentally overwrite critical host files or write over data that needs to be available on the next pod restart. As an attack vector, host persistence is a very serious concern if someone were able to breach your container and drop files onto the host filesystem. These new features help reduce your attack surface.
Specifying SupportPodPidsLimit allows you to configure your kubelet to set a pod pid limit max to prevent fork bombs and cascading failure of nodes.
Pod security policies can now control which sysctl parameters are allowed to be configured on your pods. This control helps prevent instability caused by incorrectly set sysctls.
GCP had several addons (fluentd-gcp-scaler, prometheus-to-sd, and event-exporter) that had small vulnerabilities. Recent version updates have mitigated these issues.