In part 1 of the GitOps blog series, we discussed the value of using GitOps for Calico policies, and how to roll out such a framework. In this second part of the series, we will expand the scope to include decentralized deployment and GitOps.

“How do I enable GitOps for my network security policies?” This 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, and security. Most security teams already have a high-level security blueprint for their data centers.

Organizations are rapidly moving more and more mission-critical applications to Kubernetes (K8s) and the cloud to reduce costs, achieve faster deployment times, and improve operational efficiencies, but are struggling to achieve a strong security posture because of their inability to apply conventional security practices in the cloud environment. Commitment to cloud security grows, but security safeguards are not keeping up with the increased use of the various cloud platforms.

We are excited to announce the general availability of Calico Enterprise 2.6 (formerly known as Tigera Secure). With this release, it is now possible to fully-automate Security-Policy-as-Code within a CI-CD pipeline, including the ability to implement security as a Canary rollout, which is the most critical requirement to automating network security.

We are proud to partner with Fortinet and join their Fabric-Ready Technology Alliance Partner program. With this partnership, Fortinet customers will be able to extend their network security architecture to their Kubernetes environments. Our partnership was driven from interest from Fortinet’s customers to protect their Kubernetes based infrastructure. Kubernetes adoption is growing like wildfire and nearly every enterprise on the planet is at some stage of their Kubernetes journey.

“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.