One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 4687661 |
| Date de publication | 2022-05-18 09:03:33 (vue: 2022-05-18 13:05:59) |
| Titre | Privileged pod escalations in Kubernetes and GKE |
| Texte | Posted by GKE and Anthos Platform Security Teams At the KubeCon EU 2022 conference in Valencia, security researchers from Palo Alto Networks presented research findings on “trampoline pods”-pods with an elevated set of privileges required to do their job, but that could conceivably be used as a jumping off point to gain escalated privileges.The research mentions GKE, including how developers should look at the privileged pod problem today, what the GKE team is doing to minimize the use of privileged pods, and actions GKE users can take to protect their clusters.Privileged pods within the context of GKE securityWhile privileged pods can pose a security issue, it's important to look at them within the overall context of GKE security. To use a privileged pod as a “trampoline” in GKE, there is a major prerequisite – the attacker has to first execute a successful application compromise and container breakout attack. Because the use of privileged pods in an attack requires a first step such as a container breakout to be effective, let's look at two areas:features of GKE you can use to reduce the likelihood of a container breakoutsteps the GKE team is taking to minimize the use of privileged pods and the privileges needed in them.Reducing container breakoutsThere are a number of features in GKE along with some best practices that you can use to reduce the likelihood of a container breakout:Use GKE Sandbox to strengthen the container security boundary. Over the last few months, GKE Sandbox has protected containers running it against several newly discovered Linux kernel breakout CVEs.Adopt GKE Autopilot for new clusters. Autopilot clusters have default policies that prevent host access through mechanisms like host path volumes and host network. The container runtime default seccomp profile is also enabled by default on Autopilot which has prevented several breakouts.Subscribe to GKE Release Channels and use autoupgrade to keep nodes patched automatically against kernel vulnerabilities.Run Google's Container Optimized OS, the minimal and hardened container optimized OS that makes much of the disk read-only.Incorporate binary authorization into your SDLC to require that containers admitted into the cluster are from trusted build systems and up-to-date on patching.Use Secure Command Center's Container Threat Detection or supported third-party tools to detect the most common runtime attacks.More information can be found in the GKE Hardening Guide.How GKE is reducing the use of privileged pod |
| Envoyé | Oui |
| Condensat | 2022 able above access account across actions added adding addition additional admission admitted adopt advantage against along also alto anetd announced anthos application applications are areas:features attack attacker attacks attempts audit authorization authorizer automatically autopilot autoupgrade available baked because below best binary blocks boundary breakout breakout:use breakouts breakoutsteps breakoutsthere build but called can center certain channels cluster clusters code command common community components compromise conceivably conference config container containers context controller could create created credentials customers cves date dedicated default detect detection developers discovered disk documentation doing earlier effective elevated enabled escalated escalating escalation escalations especially example execute fact feature features findings first found from function gain gke gke/anthos google guide hardened hardening has have held highly host how however identifies illustrate important improve including incorporate information install integrated introducing isolate isolation issue job jumping keep kernel kubecon kubelet kubernetes last let levels like likelihood limit limits linux look major makes manage managed management many measures mechanisms mentioned mentions method minimal minimize modify months more most much needed network networks new newly node nodes not now number objects off only open operation opt optimized other outlines over overall overprivileged palo part party patched patching path perform permission permissions platform pod pods pods” point police policies pools pose posted practices prerequisite presentation presented prevent prevented previously privilege privileged privileges problem processes profile protect protected protection rbac read recently recommend reduce reducing release removed require required requires research researchers restriction results review risk run running runtime sandbox scan scanning sdlc seccomp secrets secure security securitywhile sensitive service set settings several should single some source standard step steps stops strengthen subscribe successful such supported system systems take taken taken: takes taking task team teams at testing them third those threat through today tool tools trampoline trusted two unable uncommon use used users using valencia volumes vulnerabilities well what when where which within worked workload workloads works you your “trampoline “trampoline” “update |
| Tags | Tool Threat |
| Stories | Uber |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.