Eventually you will need to securely migrate containers and Kubernetes workloads into production and connect them to applications and resources outside of the cluster. Before you can do that, you’ll need to limit access to external endpoints on a granular, per-pod basis. But Kubernetes workloads are ephemeral and their IP addresses can’t be predicted, making it challenging to control Kubernetes access to resources with any granularity.
Rolling out an application without appropriate access controls can expose a business to multiple risks, including:
Calico provides you with three methods to enable fine-grained access controls between your microservices and external databases, cloud services, APIs, and other applications that are protected behind a firewall.
Each of these approaches utilizes Calico’s common network policy model using Kubernetes constructs like labels and selectors to provide granular, pod-based control and restrict access to specific external resources.
Control access to resources outside of the cluster, like databases, cloud-managed services, third-party APIs, and other applications that are not yet containerized
Safely and securely transition container and Kubernetes workloads from pilot to production
Maintain compliance with existing enterprise and regulatory security requirements
Integrating Kubernetes with firewalls, monitoring platforms, and other external systems is difficult because most of those tools struggle to identify Kubernetes workloads.
Calico security policies are designed to abstract away from IP addresses in favor of label selectors, but still require external services outside of the cluster to be identified by an IP address.
The Egress Access Gateway enables you to define a fixed, routable IP address and assign it to a Kubernetes namespace. All egress pod traffic from that namespace will be assigned that IP to identify the workload running within that namespace. The cluster can be securely scaled while preserving the limited number of routable IPs available by leveraging non-routable IPs for all other pod traffic within the cluster.
A single firewall rule can be defined that allows all pods within a namespace to securely access resources outside of the cluster, in effect establishing a universal firewall. The platform team only has to manage one firewall rule instead of many, saving time and eliminating the burden of multiple firewall change requests to the security team. Beyond the cluster, enterprise monitoring systems such as SIEMs can identify an application/workload in a Kubernetes namespace via its source IP address.
The Egress Access Gateway can be used in conjunction with DNS policies for an added layer of protection.
Establishing service-to-service connectivity within your cluster is easy. But how do you enable workloads to securely connect to services like Amazon RDS, ElastiCache, and others that are outside the cluster?
Calico enables DevSecOps teams to author DNS policies that implement fine-grained access controls between an individual pod or namespace and external services it needs to connect to.
Calico ‘s DNS policy enables fully-qualified domain names and DNS endpoints to be used within policy rules. DNS policies support wildcard values (e.g. https://api.twilio.com/* ).
Security policies based on domain names enable fine-grained controls that are enforced at the source pod, eliminating the need for a firewall rule or equivalent.
Once a DNS policy has been implemented, no other pods will be allowed to communicate with that DNS endpoint unless allowed by the policy.
The DNS policy model enables enforcement of workload access control policies from within the cluster. If security policies need to be enforced from an external control point such as a firewall, our Egress Access Gateway is recommended.
Kubernetes workloads typically integrate with third-party APIs, applications, and SaaS services that live outside a Kubernetes cluster. To securely enable access to those integrations, security teams must be able to limit IP ranges for egress and ingress traffic to workloads. This includes using IP lists, or ranges, to deny-list known threats.
Using a CIDR range, (Classless Inter-Domain Routing), a single IP address can be used to designate a subnetwork, or network set, consisting of many unique IP addresses.
Calico GlobalNetworkSets and Namespaced NetworkSets are used to specify the IPs/CIDRs to use in a network policy, and eliminate the need for users to manually update all the access control policies when one end of the communication is a large set of IP CIDRs.
Calico network sets can be used to apply policy to control traffic going to or coming from external, non-Calico networks. Using Calico network sets, you can easily scale out by using the same set of IPs in multiple policies.
Calico can help you granularly restrict container and Kubernetes workload access to resources outside the cluster in different ways. This not only protects your workloads, it provides you with the flexibility to align with your specific architecture.
You can enforce workload access controls from a firewall outside the cluster using the Egress Access Gateway. Domain names (FQDN / DNS) can be used to apply policies that control access from a pod or set of pods to an external resource. Or you can use Global and Namespaced NetworkSets to apply policy to control traffic going to or coming from external, non-Calico networks.