Welcome to the May 2020 edition of Calicomm! – our monthly newsletter for customers and partners. In the April edition, we discussed audit logs. This edition covers egress access control, which is an important aspect of micro-segmentation.
What problems are we solving?
Consider an enterprise datacenter deployment with hundreds of nodes and thousands of pods. These systems are running business applications with different levels of security requirements. A first-order security and compliance requirement in such a scenario is to ensure that a pod or host is only allowed to talk to authorized destinations. Now consider the real life scenario where there’s a churn rate (pods/hosts being added/removed) of hundreds of pods/minute. The challenge is to continue enforcing the microsegmentation in near real time despite a high churn rate.
An efficient mechanism for micro-segmentation has a direct impact on productivity. Ideally, you do not want to wait days for an access policy to be granted through a ticketing process, nor do you want to wait precious minutes for a policy change to take effect.
Micro-segmentation has two broad categories, East-West (E-W) and North-South (N-S). The following are typical use cases of egress access control within the N-S category:
- Configure default-deny without blocking access to essential services
- Permit access to specific Internet APIs (slack, twilio, watson etc.)
- Permit access to internal resources in the corporate network (database, VMs etc.)
- Automatic enforcement of egress policy on VM’s as they come up (autoscaling, new node provisioning etc.)
Network Policy in Calico Enterprise helps you address the use cases above.
How does it work?
Calico Enterprise uses a single policy language across all resources (pods, VMs, bare metal). The egress access control for pods is enforced on the pod-to-host interfaces. The egress access control for hosts is enforced on the host interface. At the heart of the enforcement is the concept of labels.
Consider a simple example as shown below. This policy applies to a selector with key=my-pod-label, and value=my-value. This label can be present on a pod or a host.
The access rule of the policy permits access to any destination with key=color and value=red. That destination can be any resource (pod, host, networkset etc.). This is the elegance of having a single policy language across all your hosts and pods.
The backend processing of access policies is equally simple. Calico runs a daemon on every kubernetes node and non-kubernetes host that you protect. Any change in configuration is sent to etcd (kubernetes datastore). Calico-nodes watch for any change and pull the change. Calico is proven to scale in large-scale deployments with thousands of nodes.
Why does this matter?
- Egress access control with default-deny is the first order requirement for security and compliance in any data center.
- Calico network policies reduce operational overhead in managing access control. You create declarative access policies which do not need to be changed often, if designed properly.
- With one policy, you can enforce access controls across pods and hosts. No hidden clause. All you need is labels on the pods/hosts. Configuration is stored in the same kubernetes datastore (etcd), simplifying operations.
How do I enable Egress Access Control?
It is a core feature of Calico Enterprise.
The important part is to have a solid egress control framework that scales as you expand clusters, teams and applications.
- Establish a process on who is authorized to manage the egress policies. Define and enforce the policy life-cycle from access request to enforcement to monitoring.
- Implement a design so you have to make minimal changes to policies. The way to achieve this is to group the resources into (global) network sets. As the external resource access requirement changes, you simply update the network set. As new pods need access to external resources, you simply label the pods.
- Have the deny-all in place.
Need help? Please contact your Tigera Customer Success Engineer.