“How do I enable GitOps for my network policies?” That is a common question we hear from security teams. Getting started with Kubernetes is relatively simple, but moving production workloads to Kubernetes requires alignment from all stakeholders – developers, platform engineering, network engineering, security. Most security teams already have a high-level security blueprint for their data centers.
Over my last two posts (part 1 and part 2), I have investigated user authentication in Kubernetes and how to create a single sign-on experience within the Kubernetes ecosystem. So far I have explained how Open ID Connect (OIDC) works, how to get started with OIDC and how to perform a login from the command line. The final piece of this puzzle is the Kubernetes dashboard, often used by our engineers alongside kubectl.
Researchers at Netflix and Google recently reported a vulnerability in the HTTP/2 protocol that enables adversaries to execute a DOS attack by legitimate use of the protocol. These types of attacks are very difficult to detect and mitigate because the traffic is valid HTTP/2 traffic. While HTTP/2 is a relatively new protocol it should be noted that even after several years of hardening we still see vulnerabilities for the TCP protocol like the recently reported SACK vulnerability.
AquaSec’s Daniel Sagi recently authored a blog post about DNS spoofing in Kubernetes. TLDR is that if you use default networking in Kubernetes you might be vulnerable to ARP spoofing which can allow pods to spoof (impersonate) the IP addresses of other pods. Since so much traffic is dialed via domain names rather than IPs, spoofing DNS can allow you to redirect lots of traffic inside the cluster for nefarious purposes.
We are excited to announce the general availability of Tigera Secure 2.5. With this release, security teams can now create and enforce security controls for Kubernetes using their existing firewall manager.
One of these problems is that Kubernetes has no login process. Ordinarily, the client software would initiate this login flow, but kubectl does not have this built in. Kubernetes leaves it up to you to design the login experience. In this post, I will explain the journey we took to get engineers logged in from the terminal and the challenges we faced along the way. The first step to SSO was to set up Dex as our Identity Provider.
Early adopter enterprises across verticals such as Retail, Manufacturing, Oil & Gas are looking to incorporate containers and Kubernetes as a way of modernizing their applications. Choosing k8s as a standard ensures that these applications can be deployed these on different data center infrastructures (bare metal/VMware/KVM on OpenStack etc) or on public clouds (AWS/Azure/GCP etc).
An emerging use case for containerized platforms has been the ability to deploy applications in what is termed as an air-gapped deployment. This deployment pattern is particularly pronounced around edge computing (more on that later in the blog series) – though there exist significant differences between edge clusters and air-gapped deployments. Air-gapped applications are those that run isolated from datacenter or internet connectivity.
In this article, we’ll explore Calico’s denial-of-service (DoS) mitigation features, including XDP-optimisation support introduced in Calico v3.7.
In an ideal scenario, security would be baked into the development process from the very beginning. Security teams would primarily exist to verify that best practices have been followed at every step in the process. In practice, security is an enormous challenge for most organizations. This challenge is compounded by the increasingly complex and fast-paced nature of modern service-oriented architectures, such as Kubernetes.
