Apache SkyWalking, the observability platform and open source application performance monitor (APM) project, today announced the general availability of its 8.0 release. Known for its powerful metrics, tracing and service mesh capabilities, SkyWalking extends its functionality with the new release by addressing user demand for metrics integration with other metrics collection systems, including Prometheus.
Istio and the Envoy proxy security team have announced releases that address HIGH severity CVE-2020-11080, with a CVSS score of 7.5.
The identified vulnerability relates to excessive CPU usage when processing HTTP/2 SETTINGS frames that would cause denial of service. A malicious attacker might repeatedly construct a SETTINGS frame with a length of 14,400 bytes (2400 individual settings entries), causing the CPU to spike at 100%.
To address the vulnerability, we encourage Envoy users to upgrade to Envoy proxy 1.12.4, 1.13.2 or 1.14.2. You can get the latest release from GetEnvoy.
Istio users should update to 1.5.5 or later for 1.5.x deployments and 1.6.2 or later for 1.6.x deployments.
Istio’s 1.6 release brings improvements to existing features and new features that will make things easier for developers. Upgrades to 1.6 will also be a jumping off point for even more significant improvements to come: for managing hybrid services, and integrating VM and bare metal into the Istio mesh. A VM-friendly definition of a service will allow you to migrate VM workloads to a Kubernetes cluster without disrupting traffic flow.
This post originally appears on The New Stack
This post introduces a way to automatically profile code in production with Apache SkyWalking. We believe the profile method helps reduce maintenance and overhead while increasing the precision in root cause analysis.
These are the set of steps I walk through any time I sit down to debug an Istio setup, regardless of how much experience I have with the deployment. Most Istio errors in my experience are simple, “stupid” mistakes; having a checklist to walkthrough helps me catch problems a lot more quickly. With that said, these are the steps I generally walk through:
It’s been a common problem that we’ve been asked to address, and something that pops up frequently. Can I use Istio with other ingress proxies? In a word? Yes.
Users of Istio and Envoy are strongly encouraged to upgrade to Istio 1.4.6 and Envoy 1.13.1 or 1.12.3 to address four newly discovered security vulnerabilities. The Envoy update is also available via GetEnvoy.io.
CVE-2020-8659 (CVSS score 7.5, High): Excessive CPU and/or memory usage when proxying HTTP/1.1 Envoy version 1.13.0 or earlier may consume excessive amounts of memory when proxying HTTP/1.1 requests or responses with many small (e.g., 1 byte) chunks.
The Identity Management & Access Control for Multi-Cloud Conference co-hosted this January by Tetrate and NIST drew 300 attendees to Maryland and and some 600 more participants online. A major takeaway: a Zero Trust Architecture needs service mesh technologies (Istio and Envoy) and Next Generation Access Control (NGAC).
A Service Mesh is the only option for addressing a number of security requirements in service to service interactions in the modernized world of microservices and cloud-based applications, according to a NIST Special Publication that was released today.
TC Currie sat down with Autotrader UK’s Karl Stoney– a DevOps thought leader– to discuss what led them to Istio.
Karl explains that the main reason for the move had been their wish for transparent, mutual TLS, which they wanted to implement without modification to existing apps. He explains that they understood the best way to do this was using a sidecar model, and began their transformation with the use of Google’s managed Kubernetes offering ‘GKE’ when the conversations then pointed to Istio.
