Eventually you will need to securely migrate 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 egress 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.
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. You can enforce controls from within the cluster using DNS egress policies, from a firewall outside the cluster using the egress gateway, or integrate with security groups if you are deployed to AWS.
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 Kubernetes workloads from pilot to production
Maintain compliance with existing enterprise and regulatory security requirements
Establishing service-to-service connectivity within your cluster is easy. But how do you enable some of your workloads to securely connect to services like Amazon RDS, ElastiCache, and others that are external to the cluster?
With Calico, you can author DNS policies that implement fine-grained access controls between a workload and the external services it needs to connect to.
Calico Enterprise’s DNS policy is an extension to the Calico Open Source policy model that enables fully-qualified domain names and DNS endpoints to be used within your policy rules. DNS policies support wildcard values (e.g. https://api.twilio.com/* ).
Once a DNS policy has been implemented, no other pods will be allowed to communicate with that DNS endpoint unless allowed by the policy. With the DNS policy model, you are enforcing your egress security policies within your cluster. If you also need to enforce security policies at an external control point (e.g. a firewall), then take a closer look at the Egress Gateway.
Integrating Kubernetes with firewalls, monitoring platforms, and other external systems is difficult because most of those tools struggle to identify Kubernetes workloads. It would be easier to integrate Kubernetes with external systems if there was a way to assign a fixed IP address to a microservice.
The Egress Gateway enables you to define a fixed IP and assign it to a Kubernetes namespace. All egress traffic from that namespace will be assigned to the fixed IP address.
You can use the namespace’s fixed IP address as the identity of the application(s) running within that namespace. This enables you to integrate with firewalls, monitoring systems, and other systems that don’t understand the dynamic nature of container orchestration.
The Egress Gateway can be used in conjunction with DNS policies for an added layer of protection.
Whether you are using a self-managed Kubernetes cluster on AWS, or using a managed service like Amazon EKS, you will need to figure out how to connect your pods to other AWS resources outside of your cluster. Restricting access is done using AWS security groups.
Calico Enterprise and Calico Cloud can be deployed along with an additional security group to manage pod-level security. All you need to do is annotate your pod to connect to the Calico-provided security group and you will achieve pod-level access controls to AWS resources.
Calico helps you granularly restrict Kubernetes access to resources outside the cluster in different ways. This not only protects your cluster resources, it provides you with the flexibility to align with your specific architecture. Domain names (FQDN / DNS) can be used to control access from a pod or set of pods to an external resource. You can enforce the controls from a firewall outside the cluster using the Egress Gateway. Or you can integrate with security groups if you are deployed to AWS.