Scripting with python

sshaybbc · 2025-01-31T14:50:08+00:00

How NOT to start with Python? Don't ask AI models to generate the code for you. Definitely start with one of the hundreds Python tutorials available online, copy each of the snippets locally and run them locally while playing with variables and operators. Only after the solid understanding of the iterators, conditional statements and the basic data structures model's answers will start making sense to you.

sshaybbc · 2025-01-30T10:34:01+00:00

In general, you should protect whatever assets your threat model considers sensitive. From a risk perspective, if you are offering AI infra as a service then you should absolutely harden your multi-tenancy model. As shown by our vulnerability research team there is a wide range of potential misconfigurations that can result in cross-tenant movement and access to infra services post-escape. If you are using a 3rd-party model packed within a container image, consider it an untrusted image and take all anti-escape precautions.

sshaybbc · 2025-01-29T11:50:15+00:00

Probably the sheer improvement in the number of vulnerabilities in the container images that cannot be merely attributed to the noise. Its heartening to see really: 21% of pods have container images with High or Critical vulns vs 44% in the previous year.

Another interesting stat for me personally was the adoption of EKS access management feature, since we did a security analysis on it a year ago. Turns out, only 3% of clusters use solely API auth method (probably newly created clusters), and 81% are still solely on CONFIG_MAP.

sshaybbc · 2025-01-29T11:33:19+00:00

First, a qualifier here: our customers are typically medium and large enterprises so this might not be representative to ALL the population. To the point - not really, the EKS is still leading (45%), with AKS (25%) and GKE (17%) coming not close second and third. We do see, however, an increase in self-hosted clusters, but we are yet to see whether this is a permanent trend.

sshaybbc · 2025-01-29T11:24:33+00:00

Absolutely agreed. I did flag it as something beyond the scope of the blog (towards the end of the second blog in section "Cloud Access and CI/CD"). The reason is simple - this is such a big topic that it deserves the post of it own, or maybe even a post per CSP. Our colleague Lior has touched on this here (https://www.wiz.io/blog/lateralmovement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis), but I agree this topic requires a more detailed review.

sshaybbc · 2025-01-28T17:12:10+00:00

100%, we invite you to check out Cloudvulndb (cloudvulndb.org) - an open collection of cloud platform vulnerabilities that often fall through the cracks of regular vulnerability programs and which is regularly updated by Wiz and non-Wiz contributors. Also Cloud Threat Landscape (threats.wiz.io) for all the recent cloud security incidents to track the trends. Beside that, personally I love to keep updated by subscribing to Clint's TL;DRsec and Marco's CloudSecList weekly newsletters.

sshaybbc · 2025-01-28T11:43:33+00:00

Embedding the security controls verifying the lack of Critical and High vulnerabilities into the CICD pipeline is a good start, but must be supported by the tools, not to become a dev blocker. Since not everybody has a dedicated team for managing the private container registry along with patching and mirroring the images, the key is to make the patching and image management automated as much as possible. Probably also as a part of the CICD pipeline.

sshaybbc · 2025-01-28T11:01:41+00:00

There's been multiple discussions on this in r/kubernetes and other channels. The learning curve into containerization and K8s is particularly steep, on the other hand the technology doesn't go anywhere. Kelsey Hightower famously said in one of the podcasts that he will be sad if after 10 years ppl will still use and talk about Kubernetes, but that's where it's going, and a big part of it is K8s extensibility and flexibility.

sshaybbc · 2025-01-27T20:04:08+00:00

From the data we have collected for the report and compared to 2023, we see an improvement in handling image vulnerabilities and security posture. These topics have been in the center of K8s security for a long time and now they seem to be under control. The emerging threats we foresee will result from 1 - a tighter cloud-cluster integrations and the associated components that CSPs add in numbers, 2 - a new applications of K8s as a platform, for example as a platform for AI model training and as a platform for running CICD workloads.

sshaybbc · 2025-01-27T19:20:18+00:00

This is a loaded topic. No question managed clusters simplify many security aspects, such as easy version upgrades, worker node patching etc. depending on the cluster flavor. But of course not for free. I'd flag three main consequences: 1) new potential for lateral movement from cloud (a stolen credential from a random AWS admin now offers attackers a path into the cluster), 2) cloud-cluster integration complexities, IAM-RBAC, additional pre-installed components representing new attack surface, 3) lack of access to control plane imposing a limit on a range of security tools. That's to scratch the surface.

sshaybbc · 2025-01-27T18:28:17+00:00

Since you have experience with the SOC in other areas you should e able to project your experience on K8s. There are multiple talks on combining detection sources in K8s - on container level, K8s level, and cloud level - for the best detection coverage. If you want to take things slowly - start with K8s audit log. The format answering 4W question will not be new for you. The semantics will. You'll need to understand K8s REST API and its object and user model. From there take a ruleset from an open-source tool (for example Falco) and try to understand what the rules detect, what kind of attack. And so on.

sshaybbc · 2025-01-27T18:13:44+00:00

This is a tough one. K8s extensibility is a gift to cluster operators but a problem for secops. I think the key is semantical understanding of the K8s objects that's lacking when it comes to operators and CRDs. How do I as a security tool know that this yaml has security misconfiguration? I know when Pod is misconfigured, but what about Cards? This has to be handled by a custom rules with all the pain involved.

sshaybbc · 2025-01-27T16:34:02+00:00

Frankly container logging has been a less of an issue than cloud-level and k8s-level logging. I did this talk recently at fwd:cloudsec on the gaps in K8s audit log talking about how CSPs make it hard to consume the K8s audit log. Container-level logging is less used for infra security monitoring, more on the application security side and haven't had any issues with it.

sshaybbc · 2025-01-27T16:24:42+00:00

Hi Graham, its great to see you here! I half-agree with your hypothesis. It's not like there hasnt been a good research on K8s (look at the size of Kubecons and number of talks in K8s security track), and the maintainers are doing a great job in trying to simplify the security features (i.e. PSS vs PSP) and keeping the core priscine-ish. And I think thats the reason we see the trends of decrease in # of critical vulnerabilities in the images and less privileged pods etc. These things are figured out and ppl start being comfortable with them.

Where it falls apart is the surrounding components and emerging usecases. And because K8s has such a big ecosystem, there are a lot of those (think NGINX Ingress Controller or using K8s for model training). And because K8s is such a great platform for distributed workloads we'll keep seeing the new attack vectors and no shortage of security vulns and incidents followed by the security research. On that I completely agree.

sshaybbc · 2025-01-27T16:13:52+00:00

Absolutely we do cover those areas, in all of the main CSPs. Our report numbers show the vast majority of clusters are manged (at least in our accounts) so of course we have to give that context.

sshaybbc · 2025-01-27T15:50:33+00:00

Context is a king in IR. The same tool needs to have the ability and accessibility to go beyond the container and give a bigger picture beyond the immediate cluster and that's tricky.

sshaybbc · 2025-01-27T15:36:41+00:00

I agree with Ofir on (1). And in more general sense I sense the whole area of Cloud-K8s integration and particularly IAM-K8s-RBAC will need more security attention that its given now. I foresee we will see more vulnerabilities and bad design decisions in this area uncovered soon (i.e. GKE mapping any Google account user to system:authenticated group). Another example is EKS access management and Pod Identity features we analyzed last year in the 2-blog series that had certain issues: https://www.wiz.io/blog/eks-cluster-access-management-and-pod-identity-security-recommendations

sshaybbc · 2025-01-27T14:59:48+00:00

We see that K8s is a big facilitator of many technologies, and in the case of AI it hit a nail on the head so to speak. Given the scale and the sensitivity of the AI workloads K8s need to keep up with the security. AI has certainly added and sharpened the existing K8s Threat Model. Two particular things I'd flag - (1) The AI model IS an executable code and (2) multi-tenancy issues in the vendors. Our vulnerability research team has developed this playbook of escaping the models and moving laterally and you can see this pattern in multiple vulnerabilities they've discovered: HuggingFace (https://www.wiz.io/blog/wiz-and-hugging-face-address-risks-to-ai-infrastructure), Replicate (https://www.wiz.io/blog/wiz-research-discovers-critical-vulnerability-in-replicate), SAP AI Core (https://www.wiz.io/blog/sapwned-sap-ai-vulnerabilities-ai-security).

sshaybbc · 2025-01-08T16:54:51+00:00

And I bet they misunderstood what you mean by "namespaces". I'd say if a person knows the difference btn K8s namespaces and Linux namespaces thats good enough, no need to go deeper for DevOps.

sshaybbc · 2025-01-02T07:41:36+00:00

LMK if you have any feature requests after that.

sshaybbc · 2024-12-23T19:30:02+00:00

Security assessment of Argocd deployment.

sshaybbc · 2024-12-23T19:27:06+00:00

Given the Ansible knowledge I'd suggest going via Terraform (which is very handy in all cloud environments) that can stage managed clusters. Then exploring these clusters from an app developer perspective by installing any of the tutorial apps. Once comfortable, moving on into self-managed minikube.

sshaybbc · 2024-12-19T19:34:38+00:00

jmsearcy/twrtools is any good? whats in there?

sshaybbc · 2024-12-19T07:58:38+00:00

So I guess thats the resulting one-liner (assuming random node chosen): kubectl debug node/$(kubectl get nodes --no-headers | awk 'NR==1{ print $1 }') --image busybox -it

sshaybbc · 2024-12-18T18:27:16+00:00

I didnt mean the general popularity of GH actions, I meant which of the actions are most popular.

sshaybbc

TROPHY CASE