Shift left, Zero Trust and the principle of least privilege are among the measures organisations need to take to address security concerns around Kubernetes.
This is according to Jaco Nel, CTO at Deimos, and Jonathan Frankel, customer engineer at Google Cloud, who were addressing a webinar hosted by Deimos, a Google Premier Partner and DevSecOps specialist, in partnership with Google, ITWeb and ITWeb Africa.
Globally and across Africa, the move to remote work, PaaS and SaaS is resulting in significant traction for Kubernetes, Nel said. “Kubernetes is becoming a vital and cornerstone technology. According to the 2021 Kubernetes adoption report, 83% of organisations now use Kubernetes in production, 28% have more than 11 Kubernetes clusters, 5.6 million developers use Kubernetes worldwide and 90% of them have been leveraging cloud-managed services. Kubernetes is enabling 59% accelerated deployment frequency, 54% increased automation and 46% cost reduction,” he said.
However, many organisations are still challenged in identifying attack surfaces and securing Kubernetes infrastructure, Nel said.
“The Red Hat State of Kubernetes Adoption Report 2021 found that misconfiguration is a top concern in Kubernetes, with 94% of respondents experiencing at least one security incident in their Kubernetes environments in the past 12 months, and this is hindering innovation. 55% of respondents saying they had to delay an application rollout because of security concerns. Responsibility for Kubernetes remains decentralised, although DevOps is now taking the leading role and almost 75% of organisations now have a DevSecOps initiative in place.”
Nel said: “We have detected a few possible attack surfaces in Kubernetes, in the areas of infrastructure, access control, container security, secret management and runtime security.
When working on Google Kubernetes Engine (GKE), the first security priority should be to ensure that the cluster is made private by enabling private endpoints and disabling public access. "Configure your worker nodes to be in a private subnet with no public IP available, configure authorised networks to limit access to the K8s API, and use Cloud NAT to enable outgoing access from private worker nodes. Use a custom Google Service Account and apply least-privilege principle, enable workloads to access Google Services using Workload Identities, let GKE automatically manage the cluster’s control plane version and enable application-layer secrets encryption for GKE clusters.”
For container security, start small and trusted, with no secrets embedded, scan for vulnerabilities, store privately, be careful with versioning and use your CICD, he advised.
“Utilise the built-in Kubernetes Secrets or Google Secret Manager for secret management. If you need to commit secrets to version control, encrypt it before committing to version control. For runtime security, the one key thing to do is ‘say no to root’. Very few containers require the ability to run as root, yet the majority of containers in public registries still have their process running as root. Utilise network policies and container and pod security context to limit the functionality of workloads running in Kubernetes.”
Jonathan Frankel, demonstrating Binary Authorisation with GCP and Google Kubernetes Engine (GKE), noted that supply chain exploits are being put directly into build pipelines, making it crucial to shift left.
Share