Archive

Category Archives for "Tigera.io"

Calico Enterprise 3.0 with Calico Multi-Cluster Management

As our enterprise customers build out large, multi-cluster Kubernetes environments, they are encountering an entirely new set of security challenges, requiring solutions that operate at scale and can be deployed both on-premises and across multiple clouds.

Today we are thrilled to announce the release of Calico Enterprise 3.0 and the availability of Calico Multi-Cluster Management, a game-changing solution that provides centralized management for network security across every Kubernetes cluster in your organization.

Calico Multi-Cluster Management

Calico Multi-Cluster Management provides a centralized management plane and single point of control for multi-cluster and multi-cloud environments. Calico Enterprise’s centralized control simplifies and speeds routine maintenance, leaving more time for your platform team to address other important tasks.

For example, instead of logging in to 50 clusters one-at-a-time to make a policy change, with a single log-in to Calico Enterprise you can apply policy changes consistently across all 50 clusters. You can also automatically apply existing network security controls to new clusters as they are added.

Calico Multi-Cluster Management includes centralized log management, troubleshooting with Flow Visualizer, and cluster-wide IDS (intrusion detection). It also provides compliance reporting, and alerts on non-compliance and indicators of compromise. Alerts are sent to SIEMs, including Splunk and Continue reading

Calico Enterprise 3.0 – Global Network Security Center for Kubernetes

As our enterprise customers build out large, multi-cluster Kubernetes environments, they are encountering an entirely new set of security challenges, requiring solutions that operate at scale and can be deployed both on-premises and across multiple clouds.

Today we are thrilled to announce the release of Calico Enterprise 3.0 and the availability of our Global Network Security Center, a game-changing solution that provides a central management plane for network security across every Kubernetes cluster in your organization.

Global Network Security Center for Kubernetes

The Calico Enterprise Global Network Security Center for Kubernetes is a centralized management plane and single point of control for multi-cluster and multi-cloud environments. Calico Enterprise’s centralized control simplifies and speeds routine maintenance, leaving more time for your platform team to address other important tasks.

For example, instead of logging in to 50 clusters one-at-a-time to make a policy change, with a single log-in to Calico Enterprise you can apply policy changes consistently across all 50 clusters. You can also automatically apply existing network security controls to new clusters as they are added.

Calico Enterprise also includes centralized log management, troubleshooting with Flow Visualizer, and cluster-wide IDS (intrusion detection). GNSC provides compliance reporting, and alerts on non-compliance Continue reading

Deploying to Kubernetes: The GitOps Way

Kubernetes adoption comes with a lot of challenges. One of them is consistently deploying applications to the platform. GitOps is a strategy which solves this problem and solves it at scale. In this blog, we will share how to leverage TravisCI and ArgoCD to design a highly scalable production-ready CI/CD workflow. 

Deployment Workflow

GitOps follows one simple principle “Git is the Source of Truth”. The entire pipeline can be divided into two broad categories. (1) Continuous Integration, where we enable our developers to develop new features, test the code and merge it into a master. (2) Continuous Delivery, where we release new versions of the code for our customers.

Repo Structure

The application and the Kubernetes manifests/helm chart both reside in a git repository. The application source code’s git repo consists of various branches. Following the same principle, we also keep the helm charts for our microservices in a git repo itself. For the sake of this blog we will assume that each source code repository will have at least three (3) branches.

  1. Dev Branch: This gets deployed to the Dev Kubernetes Environment
  2. Staging Branch: This gets deployed to the Staging Kubernetes Environment
  3. Master Branch Continue reading

Designing On-Prem Kubernetes Networks for High Availability

Designing and maintaining networks is hard.  When deploying Kubernetes in your on-prem data center, you will need to answer a basic question: Should it be an overlay network on top of an existing network, or should it be part of an existing network? The Networking options table provides guidelines to choose the right type of networking based on various factors. If you decide to use native peering (pre-dominant option for on-prem), you will have to configure the network to ensure availability in the event of network outage (ex. Cable disconnected, TOR switch failure etc.). We cover a typical L3 highly-available network design in this post.

A cluster spans multiple racks. In an L3 deployment, these racks have different CIDR ranges. So the nodes in different racks should be able to talk to each other. Referring to the diagram below, that traffic goes through the network fabric. If you want to build out such a lab for your own learning, here is the example.

If you have a leaf-spine fabric with a single TOR (top-of-rack, or leaf switch), then that TOR becomes a point of failure for the entire rack. If all the master nodes are on the same Continue reading

Introducing the Calico eBPF Dataplane

eBPF is a hot topic right now; most of the infrastructure-focused conferences and events have included talks on eBPF over the past year, which is creating a lot of interest in the technology.

You might be wondering what eBPF is. eBPF stands for “extended Berkeley Packet Filter” which is a feature in modern Linux kernels that allows you to write mini-programs that are attached to low-level hooks in the Linux kernel, that execute based on certain events (e.g. filtering network traffic). While Calico is primarily focused on networking and security use cases, eBPF is a broad technology that applies to many other use cases as well.

We’ve always been tracking eBPF and it’s potential to enhance Calico, however, most users have not been ready for it. Improving on Calico’s already excellent dataplane using eBPF requires the latest Linux kernels, that are not always available to our enterprise customers that require a vendor-supported Linux distribution to run in production. Nevertheless, we decided to add an eBPF dataplane to support those users that are able to use the latest Linux kernels, as well as provide a future-proofed path for those who will wait until their vendor-supported Linux distributions will support the Continue reading

Why use Typha in your Calico Kubernetes Deployments?

Calico is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports a broad range of platforms including Kubernetes, OpenShift, Docker EE, OpenStack, and bare metal. In this blog, we will focus on Kubernetes pod networking and network security using Calico.

Calico uses etcd as the back-end datastore. When you run Calico on Kubernetes, you can use the same etcd datastore through the Kubernetes API server. This is called a Kubernetes backed datastore (KDD) in Calico. The following diagram shows a block-level architecture of Calico.

Calico-node runs as a Daemonset, and has a fair amount of interaction with the Kubernetes API server. It’s easy for you to profile that by simply enabling audit logs for calico-node. For example, in my kubeadm cluster, I used the following audit configuration

 

To set the context, this is my cluster configuration.
As we are running Typha already, let us profile the API calls for both Calico and Typha components. I used the following commands to extract the unique API calls for each.

 

If you ignore the license key API calls from calico-node, you will see that the API calls Continue reading

How Fortinet and Tigera Protect Kubernetes in the Enterprise

What Problems are We Solving?

Container use continues to grow, and Kubernetes is the most widely adopted container orchestration system, managing nearly half of all container deployments.1 Successful integration of container services within the enterprise depends heavily on access to external resources such as databases, cloud services, third-party application programming interfaces (APIs), and other applications. All this egress activity must be controlled for security and compliance reasons. In a recent container adoption survey, 61% of correspondents, a super-majority, listed data security as their top challenge.2

Kubernetes Requires a Different Approach to Access Control

Traditional IP-based access control doesn’t work in Kubernetes, where workloads are ephemeral, typically stateless, and use short-term IP addresses. While the Calico Enterprise security management interface provides customized control within the Kubernetes environment, using Calico Enterprise security in isolation from existing enterprise network security leaves organizations with disparate policy-enforcement regimes.

Disparate Network Security Systems Introduce Unwanted Complexity

Maintaining two separate network security systems hinders visibility into routing and connectivity within and between Kubernetes clusters. This complicates the process of troubleshooting issues that span Kubernetes and external environments. Because enterprise monitoring tools lack Kubernetes context, the impact of security policy changes are hard to predict, and Continue reading

How to Efficiently Detect Domain Generation Algorithms (DGA) in Kubernetes with Calico Enterprise

Introduction

2020 is predicted to be an exciting year with more organizations adopting Kubernetes than ever before. As critical workloads with sensitive data migrate to the cloud, we can expect to encounter various Advanced Persistent Threats (APT) targeting that environment.

Domain Generation Algorithm (DGA) – What is It?

DGA is a technique that fuels malware attacks. DGA by itself can’t harm you. But it’s a proven technique that enables modern malware to evade security products and counter-measures. Attackers use DGA so they can quickly switch the command-and-control (also called C2 or C&C) servers that they’re using for malware attacks. Security software vendors act quickly to block and take down malicious domains hard-coded in malware. So, attackers used DGA specifically to counter these actions. Now DGA has become one of the top phone-home mechanisms for malware authors to reach C2 servers. This poses a significant threat to cloud security.

Mitre defines DGA as “The use of algorithms in malware to periodically generate a large number of domain names which function as rendezvous points for malware command and control servers”. Let’s examine this definition more closely. DGA at its core generates domains by concatenating pseudo-random strings and a TLD (e.g. .com, . Continue reading

Now Available: Calico for Windows on Red Hat OpenShift Container Platform

Approximately one year ago, Kubernetes 1.14 made support of Windows containers running on Microsoft Windows Server nodes generally available. This was a declaration that Windows node support was stable, well-tested, and ready for adoption, meaning the vast ecosystem of Windows-based applications could be deployed on the platform.

Collaborating with Microsoft, Tigera leveraged the new Windows platform capabilities to create Calico for Windows, the industry’s first cross-platform Kubernetes solution to manage networking and network policy for Kubernetes deployments on Windows and Linux.

We are excited to announce that Calico for Windows now supports the latest Windows Dev Preview on the Red Hat OpenShift Container Platform (OCP). Built on Red Hat Enterprise Linux and Kubernetes, OCP v4 provides developers and IT organizations with a hybrid and multi-cloud application platform for deploying both new and existing applications on scalable resources, with minimal configuration and management overhead. OCP enables organizations to meet security, privacy, compliance, and governance requirements.

Calico for Windows is the only Kubernetes networking solution for teams using Windows on OpenShift. The combination of Calico for Windows and Red Hat OpenShift Container Platform represents a major leap forward in productivity for organizations that are deploying Windows on Kubernetes. DevOps teams Continue reading

Extend Fortinet FortiGate to Kubernetes with Calico Enterprise 2.7

We are excited to announce the general availability of Calico Enterprise 2.7. With this release, Fortinet’s 400,000 customers can use FortiGate to enforce network security policies into and out of the Kubernetes cluster as well as traffic between pods within the cluster.

  • Kubernetes workloads populate the Fortigate GUI
  • The network team can then create and enforce policies in Fortigate and have them enforced as Calico Policy
  • Saves time and money and lets the network team retain the firewall responsibility (which also frees up time for ITOps)

We have also added many new exciting capabilities that help platform engineers blow through barriers blocking their path to production, and advanced cybersecurity capabilities for those already running production workloads.

  • Manage Network Security Across Multiple Kubernetes Clusters
  • Enforce a Common Set of Security Controls Across Multiple Clusters
  • Detect and Alert on Unauthorized Changes and Other Attack Vectors
  • Self-Service Troubleshooting for End Users
  • Detect and Prevent Malicious Data Exfiltration

Manage Network Security Across Multiple Kubernetes Clusters

As the adoption of Kubernetes continues to accelerate, our customers are seeing the number of clusters in their environments rapidly multiplying. This has created a management challenge for IT Ops teams who are constantly pushed to find ways Continue reading

Supercharging Workload Security in Your K8s Cluster

Introduction

2019 was a big year for Kubernetes adoption, and 2020 is sure to exceed that pace. Already, we have seen a large number of organizations migrating their workloads to Kubernetes (k8s) both in public and private clouds as they embrace a hybrid cloud strategy. With so much at stake, what are you currently using for network security inside your k8s cluster?

 

Quick Retro

Let’s take a step back to a time when you were deploying applications to VMs in AWS, GCP or Azure (in the case of public clouds) or vSphere, etc. in private clouds. One of the most important tasks before provisioning infrastructure and deploying applications was to chalk out firewall considerations. These requirements were fulfilled using security group rules in the case of AWS or firewall rules in GCP. We all understand their importance. But doing the same involving Kubernetes was extremely challenging. Today, we can solve those problems for you with just a few clicks.

 

Present Scenario – What If?

Most recently with the increase in k8s adoption we have seen operations and platform teams hustling to implement a plethora of monitoring tools, logging backends and CI/CD tools. While all of this is Continue reading

Decentralized Calico Network Security Policy Deployment for GitOps – Part 2

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.

We see different personas among our customers deploying three types of controls:

  1. Cluster hardening policies are enforced and controlled by the platform admin
  2. Organizational security controls are enforced and controlled by the security admin
  3. Each application team may have their own unique requirements. This is controlled by the DevOps admin for the specific application.

This is different from the traditional firewall world, where the security admin is responsible for managing security policies, and the change management window could be several weeks in duration. Adopting that model in Kubernetes is simply counter to the very principles of enabling the developers. So how can we make policy creation and enforcement simple, yet adhere to organizational processes? The answer lies in simple tooling, GitOps and governance.

Policies have business logic that must be implemented in YAML. The business logic (allow access for service A to service B, open port 443 inbound on service B, permit access to slack webhook Continue reading

Decentralized Calico Network Security Policy Deployment for GitOps – Part 2

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.

We see different personas among our customers deploying three types of controls:

  1. Cluster hardening policies are enforced and controlled by the platform admin
  2. Organizational security controls are enforced and controlled by the security admin
  3. Each application team may have their own unique requirements. This is controlled by the DevOps admin for the specific application.

This is different from the traditional firewall world, where the security admin is responsible for managing security policies, and the change management window could be several weeks in duration. Adopting that model in Kubernetes is simply counter to the very principles of enabling the developers. So how can we make policy creation and enforcement simple, yet adhere to organizational processes? The answer lies in simple tooling, GitOps and governance.

Policies have business logic that must be implemented in YAML. The business logic (allow access for service A to service B, open port 443 inbound on service B, permit access to slack webhook Continue reading

Enforcing Network Security Policies with GitOps – Part 1

“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. The challenge is in implementing that in the context of a Kubernetes cluster and workload security. Network policy is a key element of Kubernetes security. Network policy is expressed as a YAML configuration and works very well with GitOps.

We will do a three-part blog series covering GitOps for network security policies. In part one (this part), we cover the overview and getting started with a working example tutorial. In part two, we will extend the tutorial to cover an enterprise-wide decentralized security architecture. In the final part, we will delve into policy assurance with examples.

Note that all policies in Calico Enterprise (network security policy, RBAC, threat detection, logging configuration, etc.) are enforced as YAML configuration files, and can be enforced via a GitOps practice.

By adopting GitOps, security teams benefit in the following ways:

Five Ways to Quickly Uncover Malicious Activity and Protect Your Kubernetes Workloads

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. Regardless of the cloud provider or service model, individual organizations are ultimately responsible for the security of their data.

According to a 2019 Ponemon Institute Global Cloud Data Security Study, 70 percent of respondents find it more complex to manage privacy and data protection regulations in a cloud environment than on-premises. Meanwhile, the percent of corporate data stored in the cloud environment has grown from an average of 30 percent in 2015 to an average of 48 percent in 2019. In the same study, 56 percent of respondents say the use of cloud resources increases compliance risk.

The downside associated with a security breach is severe for any organization, but especially so for companies in regulated environments like financial services, healthcare and telecommunications. Now there’s a new and highly effective way Continue reading

Security Policy as Code Now Fully Automated with Calico Enterprise 2.6

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.

  1. Automation of the underlying infrastructure (infrastructure as code)
  2. Automation of the software delivery process (Continuous Integration and Continuous Delivery (CICD) pipeline)

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 Continue reading

Tigera Joins the Fortinet Fabric-Ready Program and Partners with Fortinet to Secure Kubernetes Environments

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.

The Tigera and Fortinet joint solution will support all cloud-based and on-premises Kubernetes environments. With this architecture, Tigera Secure will map security policies from FortiManager into each Kubernetes cluster in the cloud or on-premises. The joint solution will enable Fortinet customers to enforce network security policies for traffic into and out of the Kubernetes cluster (North/South traffic) as well as traffic between pods within the cluster (East/West traffic).

Tigera Secure will also integrate with threat feeds from FortiGuard to detect and block any malicious activity inside the clusters. Tigera will monitor the cluster traffic and send these events to FortiSIEM, enabling the security operations team to quickly diagnose the situation.

If you are attending Microsoft Ignite join us at our respective booths to learn more about our solution (Fortinet Booth #519 Continue reading

Enable GitOps for Kubernetes Security – Part 1

“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. The challenge is in implementing that in the context of a Kubernetes cluster and workload security. Network policy is a key element of Kubernetes security. Network policy is expressed as an YAML configuration, and works very well with GitOps.

We will do a 3 part blog series covering GitOps for network policies. In part 1 (this part), we cover the overview and getting started with a working example tutorial. In part 2, we will extend the tutorial to cover an enterprise-wide decentralized security architecture. In the final part, we will delve into policy assurance with examples. Note that all policies in Tigera Secure (network policy, RBAC, Threat detection, Logging configuration, etc.) are enforced as YAML configuration files, and can be enforced via a GitOps practice.

By adopting GitOps, security teams benefit as follows.

3 Layers to Defend Your Kubernetes Workloads

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.

 

Vulnerability Scanning and Patching

So how do we ensure that Kubernetes workloads are protected from these types of vulnerabilities? 

Security researchers work to identify new vulnerabilities and then help developers develop security patches. You can apply those patches to keep your software secure from the lastest known vulnerabilities.

The simple answer then is to scan workload images and patch your software and update your software to use the latest patches. However, that approach essentially means you have to wait for the next attack and then will need to repeat the cycle. While this works, it is not sufficient and quite disruptive to implement as we play into the hands of the adversaries where they are working on the next vulnerability while Continue reading

Single Sign-On for Kubernetes: Dashboard Experience

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. To complete our move to SSO, we wanted to ensure that, when using the Dashboard, our engineers logged in to the same account they used for kubectl.

Since Kubernetes version 1.7.0, the dashboard has had a login page. It allows users to upload a kubeconfig file or enter a bearer token. If you have already logged into the command line, this allows you to copy the OIDC id-token from your kubeconfig file into the bearer token field and login. There are, however, a couple of problems with this:

  • The login page has a skip button — If you aren’t using any authorization (RBAC) then this would permit anyone to access the dashboard with effective admin rights.
  • Copy and pasting a token from a Continue reading