In this article, we will show how it’s easily possible to monitor AWS Fargate with Sysdig Monitor. By leveraging existing Prometheus ingestion in Sysdig, you will be able to monitor serverless services with a single-pane-of-glass approach, giving you confidence in running these services in production.
This CVE is a Server Side Request Forgery (SSRF) vulnerability in kube-controller-manager that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master’s host network (such as link-local or loopback services).
Reverse shell is a way that attackers gain access to a victim’s system. In this article, you’ll learn how this attack works and how you can detect it using Falco, a CNCF project, as well as Sysdig Secure. Sometimes, an application vulnerability can be exploited in a way that allows an attacker to establish a reverse shell connection, which grants them interactive access to the system.
Today, we are pleased to announce the expansion of Sysdig’s relationship with IBM to extend cloud security governance with IBM Cloud Pak for Multicloud Management. Through a new OEM agreement, Sysdig Secure and the Sysdig Secure DevOps Platform are now available through IBM and IBM Business Partners. The combined IBM and Sysdig offering delivers centralized cloud visibility, governance and automation with in-depth container security intelligence for Red Hat OpenShift.
A Prometheus CloudWatch exporter is a key element for anyone wanting to monitor AWS CloudWatch. Exporting CloudWatch metrics to a Prometheus server allows leveraging of the power of PromQL queries, integrating AWS metrics with those from other applications or cloud providers, and creating advanced dashboards for digging down into problems. But, who watches the watcher? Despite those advantages, using the wrong exporter or an incorrect configuration can have bad consequences in production environments.
A few weeks ago, we announced that Sysdig is offering fully compatible Prometheus monitoring at scale for our customers, as well as a new website called PromCat.io hosting a curated repository of Prometheus exporters, dashboards and alerts. This got me thinking about how we were actually able to implement the changes necessary to offer this in our platform.
Innovative companies are looking to take advantage of cloud-native technologies beyond the data center to deliver faster innovation and competitive advantage at the edge. Recognizing the need for a common approach to create, deploy, run, secure, monitor, maintain and scale business logic and analytics applications wherever your business takes you, IBM today announced its edge computing offerings, including the IBM Edge Application Manager.
Chances are, if you’re not already moving applications to containers and Kubernetes, you’re considering it. However, it’s likely that security and compliance implications are something you haven’t fully thought through. Addressing container security risks later in the development life cycle negatively impacts the pace of cloud adoption while simultaneously raising security and compliance risks. The use of containers and Kubernetes changes your security calculus.
In this blog post, we’re going to explain how to monitor Open Policy Agent (OPA) Gatekeeper with Prometheus metrics. If you have deployed OPA Gatekeeper, monitoring this admission controller is as relevant as monitoring the rest of the Kubernetes control plane components, like APIserver, kubelet or controller-manager. If something breaks here, Kubernetes won’t deploy new pods in your cluster; and if it’s slow, your cluster scale performance will degrade.
In this post we will talk about using image scanning on admission controller to scan your container images on-demand, right before your workloads are scheduled in the cluster. Ensuring that all the runtime workloads have been scanned and have no serious vulnerabilities is not an easy task. Let’s see how we can block any pod that doesn’t pass the scanning policies before it even runs in your cluster.
