If your GitOps deployment model has security issues (for example, a misconfigured permission because of a typo), this will be propagated until it is hopefully discovered at runtime, where most of the security events are scanned or found. What if you can fix potential security issues in your infrastructure at the source? Let’s start with the basics.

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.

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.

When running containers in a Kubernetes cluster, trusting the images you deploy is key to enforce security. The use of mutable images represents a risk to the secure Kubernetes deployment and highlights the importance of having a reliable mechanism to ensure you run what you expect. In this blog, you will learn step-by-step how to implement a secure Kubernetes deployment.

AWS offers a large spectrum of services and compute. The “shared responsibility” model in cloud presents a simplified structure of organization responsibilities and cloud provider responsibilities. Generally, identity and access management (IAM), applications, and data form the dividing line, but lines blur depending on the given cloud service the organization is consuming. This is true of all cloud providers, including the AWS Shared Responsibility Model.

You might think that your metrics are harmless from a security point of view. Well, that’s not true, and in this talk at KubeCon Valencia 2022, we share the risk of exposed Prometheus server and how attackers use this information to successfully access a Kubernetes cluster. The slides are available here, and we also collected some mentions in social media and blogs and the feedback was very positive: It was our first time as speakers at KubeCon and expectations were really high.