Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Kubernetes uses secret objects, called Secrets, to store OAuth tokens, secure shell (SSH) keys, passwords, and other secret data. Kubernetes Secrets allow us to keep confidential data separate from our application code by creating it separately from pods. This segregation, along with well-formed role-based access control (RBAC) configuration, reduces the chances of the Secret being exposed — and potentially exploited — when interacting with pods, thereby increasing security.

Helm is being used broadly to deploy Kubernetes applications as it is an easy way to publish and consume them via a couple of commands, as well as integrate them in your GitOps pipeline. But is Helm secure enough? Can you trust it blindly? This post explains the benefits of using Helm, the pitfalls, and offers a few recommendations for how to secure it. Let’s get started!

As innovations in the world of application development and data computation grow every year, the “attack surface” of these technologies grows as well. The attack surface has to be understood from two sides—from the attacker’s side and from the organization being attacked.

Cyber attacks are an unfortunate reality in our interconnected world. The art of keeping up with malicious actors is challenging, but even more so with the move to cloud-native technologies. As a result, security is evolving. Developers, DevOps, and cloud teams must now learn a new set of best practices that balance shift-left and shield-right security approaches to reduce risk. There has never been a more critical time to revisit your cybersecurity strategy.

Many of the benefits of running Kubernetes come from the efficiencies that you get when you share the cluster – and thus the underlying compute and network resources it manages – between multiple services and teams within your organization. Each of these major services or teams that share the cluster are tenants of the cluster – and thus this approach is referred to as multi-tenancy.

TL;DR: AWS Object Lamba can authorize requests to S3. We can create an Object Lambda that calls Open Policy Agent (OPA) to get a policy decision. This delegation allows us to implement policies using Rego and manage them in Styra Declarative Authorization Service (DAS).

The awaited OpenSSL 3.0.7 patch was released on Nov. 1. The OpenSSL Project team announced two HIGH severity vulnerabilities (CVE-2022-3602, CVE-2022-3786), which affect all OpenSSL v3 versions up to 3.0.6. These vulnerabilities are remediated in version 3.0.7, which was released Nov. 1. The vulnerabilities fixed include two stack-based buffer overflows in the name constraint checking portion of X.509 certificate verification.