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.
DevOps is now mainstream and practiced in nearly every major enterprise; it has transitioned from what was a competitive differentiator a few years ago to the industry standard today.
DevOps relies on automation to continuously optimize the cycle time from code to production. DevOps automation manifests itself in 2 forms.
Security has become an integral part of the DevOps team’s responsibilities. A quick sample of DevOps jobs on LinkedIn is a quick example; nearly every DevOps job posting has “security” as a required responsibility. It’s no longer enough to automate the infrastructure, it is now necessary to implement security within the delivery pipeline and perhaps link SW CI-CD pipelines with the corresponding security policies that they should be deployed with. DevOps teams have struggled to automate this step, and it has been a complex cross-organizational process that slows everything down.
Security-as-code is not a new concept to Kubernetes-based applications. Kubernetes Network Policies are developer-friendly YAML files that can be deployed as part of any CI/CD pipeline to enforce Network Security rules.
It makes sense, so why hasn’t security-as-code been more widely adopted? It comes down to the power of network security and the risk of unintentionally creating outages by blocking valid communication between services, or potentially bringing down connectivity across an entire cluster. Until now, practitioners have treated Security Policy as a manual step in the DevOps process due to the risk of deploying an incorrectly configured policy and committing it to the cluster.
With Calico Enterprise 2.6, security policy as code is now operationally ready for the enterprise. Security policies are stored alongside infrastructure code and deployed via the CI-CD pipeline. The critical gap that this release closes is the ability to run the network security policies in a canary mode with automatic promotion and rollback that can be through automated testing of the deployed policy.
We have also added many new exciting capabilities that help platform engineers securely adopt Kubernetes at each stage of the journey to enterprise-wide adoption. Other key highlights of this release are
By default, Kubernetes allows all workloads to communicate with each other, commonly referred to as an “open cluster.” An open cluster is not good practice for supporting more than a single application, and Kubernetes Network Policies are the industry standard solution.
Network Policies are difficult to create and a misconfigured Network Policy can result in connectivity problems between your services or potentially outages across your entire cluster.
Calico Enterprise 2.6 enables Network Policies to be created, tested, deployed, and updated safely in your cluster using the following workflow.
Calico Enterprise 2.6 takes the heavy lifting out of Network Policy adoption, for both new clusters and existing clusters running multiple applications.
Writing Network Policies from scratch requires a DevOps engineer to know how to define a Network Policy YAML file defining each rule. There is a learning curve and hand-crafting a Network Policy is time-consuming and error-prone. DevOps engineers generally prefer to use an open cluster than go through the effort of defining and deploying Network Policies.
Calico Enterprise 2.6 enables you to select network flows in your cluster as input to auto-generate suggested Network Policies to segment your cluster. The Network Policies are backstopped by a default deny rule, moving you from open cluster to a secure least privileges model with minimal effort.
Auto-generated Network Policies are passed through the Calico Enterprise Network Policy Workflow, enabling validation and debugging before you commit your Network Policies.
The Operator Framework has become the industry standard for installing and managing Kubernetes applications and greatly simplifies installation and application lifecycle management.
Calico Enterprise 2.6 now standardizes on the Tigera Operator for all Kubernetes distributions and platforms in our support matrix.
The Tigera Operator supports the installation of open-source Project Calico as well as Calico Enterprise.
Threat intelligence feeds enable organizations to leverage malware data to protect against threats. Since version 2.4, Calico Enterprise consumes open source and commercial threat intelligence feeds to block egress to known bad actors.
More sophisticated malware can skirt threat feed detection by using dynamically generated domains that have not yet been curated by the threat feed. The malware uses a Domain Generation Algorithm (DGA) to generate random domain names and try to connect to them. The malware’s command and control servers also use the same DGA and seed to register domains. Eventually, the domain generated by the malware and the domain registered by the command and control server will match, and a connection is established, delivering additional instructions to the malware for exfiltrating data.
Calico Enterprise 2.6 monitors outbound DNS connection attempts and uses machine learning to detect evidence of a domain generation algorithm running in your cluster. Alerts can be sent to your SOC for further investigation, and the suspected workload can be quarantined blocking all network traffic.
Calico Enterprise 2.6 provides additional Network Policy controls that enable Platform Engineering and Security teams new ways to define granular and targeted policies
These new selectors provide new facilities to adopt best practices for zero-trust networking in Kubernetes.
Tigera was founded as the company behind the open-source Project Calico. We launched Tigera Secure as open-core software that builds on Project Calico, adding features that enable the widespread enterprise adoption of Kubernetes.
The name “Tigera Secure” was originally used to differentiate the advanced network security capabilities that are part of our enterprise offering. However, regardless of what we called it, our customers often refer to “Tigera Secure” as “Calico Enterprise”. Our enterprise product name was going across the grain from what both our commercial and open-source users expected.
The open-source Project Calico is a strategic project at the core of our company, and by renaming our enterprise product to Calico Enterprise we are signaling our continued investment in the market-leading Kubernetes CNI and Network Policy engine.
Free Online Training
Access Live and On-Demand Kubernetes Tutorials
Calico Enterprise – Free Trial
Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption
Get updates on blog posts, new releases and more!