Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

With the constant threat of malware weighing on cloud teams, AWS is introducing new ways to identify malicious software with Amazon GuardDuty. Amazon GuardDuty Malware Protection, a fully managed malware detection service launched today at Re:inforce by AWS, provides agentless scanning to identify when suspicious activity occurs.

Despite being a large open-source and complex project, Kubernetes keeps on evolving at an impressive pace. Being at the center of various platforms and solutions, the biggest challenge for the Kubernetes project is to remain vendor-neutral. This is the reason the community has come up with Kubernetes Gateway API.

Companies are introducing new apps and services to enable remote work, improve supply chains and handle disruptions caused by the pandemic. Our digital-first world thrives on speed and efficiency, and containers play a huge part in getting applications up and running quickly. Though containers offer many advantages over traditional virtualization, they also introduce significant security risks.

The desire to take advantage of the modern cloud-native paradigm has forced many enterprises to rush to production with Kubernetes and containerized applications. Often, the incorrect expectation with cloud-native adoption is that Ops teams would be able to easily transition their existing security and operational practices, workflows and tooling to these new software development platforms and everything would still work as before.

Kubernetes is the de-facto container management platform of today and the future. It has increased the scalability and flexibility of applications and eliminated vendor lock-in. Kubernetes also brings a lot of security native features; however, with security, the devil is always in the details. By default, the security of cloud services, applications, and infrastructure is not in the scope of Kubernetes. This does not mean that running Kubernetes is destructive and makes your applications vulnerable.

Cross-cluster migration of Kubernetes workloads continues to be challenging since workloads are isolated from each other by design. There are several reasons why you may want to separate your workloads, whether it is to reduce complexity or to have the cluster closer to the user base. However, this can be complex as Kubernetes has many components.

Enterprises are embracing the cloud native paradigm for agility, scalability, composability, and portability. Kubernetes, the open source container orchestration engine, is the foundation of modern, cloud native workloads. AWS customers can leverage managed Kubernetes available in the form of Amazon Elastic Kubernetes Service (EKS) or deploy a cluster based on upstream Kubernetes distribution running in a set of Amazon EC2 instances.

From a people perspective and an organizational standpoint, many CISOs have said that their security teams are not ready for containers and Kubernetes. This isn’t surprising, given the stark contrast between where we were less than a decade ago and where we are today in terms of systems architecture. I am of course referring to the cloud-native era, which has ushered in a whole new architectural approach.

Kubernetes leverages various deployment objects to simplify the provisioning of resources and configuration of workloads running in containers. These objects include ReplicaSets, lSets, Sets, and Deployments. A pod is the smallest deployment unit in Kubernetes that usually represents one instance of the containerized application.

Container-based web applications built on microservices architecture, whether public-facing or internal, are critical to businesses. This new class of applications is commonly referred to as cloud-native applications. Read on to find out why traditional WAFs are no longer enough to protect cloud-native applications and how Calico’s new workload-centric WAF solves this problem.