Introducing Cisco Cloud Network Controller on Google Cloud Platform – Part 2

Part 1 of this blog series demonstrated how Cisco CNC can automate cloud networking within GCP independently of security policies. Part 2 goes over additional capabilities pertaining to contract-based routing and firewall rules automation by extending the same policy model.

One of the reasons for decoupling routing and security is to give customers more flexibility. Often, organizations may have different teams responsible for cloud networking and security policies definitions in the cloud. However, for those use cases where policy consistency is a top priority followed by more governance of cloud resources, a common policy model is a must.

Policy Model Translation

Below is a high-level one-to-one mapping of the Cisco CNC policy model to native GCP cloud constructs.

Essentially, a tenant maps to a project and is the top-level logical container holding all the other policies. For cloud networking, Cisco CNC translates the combination of VRF and Cloud Context Profile into global VPC networks and regional subnets. In the scenario below, Cisco CNC will also translate security policies by combining cloud EPGs (Endpoint Groups) with contracts and filters into firewall rules and network tags in GCP.

By definition, a cloud EPG is a collection of endpoints sharing the same security policy, can have endpoints in one or more subnets and is tied to a VRF.

Scenario

This scenario has two VRFs: network-a and network-b. Additionally, cloud EPGs Web & App will be created and associated to contracts with specific security policies defined by filters. A Cloud External EPG will also be created as Internet EPG to allow internet access on network-a.

On GCP, these policies are translated into proper VPC networks, subnets, routing tables, peering, firewall rules, and network tags. Note that for this scenario, VPCs and subnets were already pre-provisioned.

Contract-based Routing

On Part 1 of this blog series, a route leak policy was created to allow inter-VRF routing between network-a and network-b. For this scenario, only contract-based routing will be enabled, which means contracts will drive routing where needed. Therefore, the leak route policy created previously was removed and peering between VPCs disconnected.

Contract-based Routing is a global mode configuration available in the Cloud Network Controller Setup. Note that when contract-based routing is enabled, the routes between a pair of internal VRFs can be leaked using contracts only in the absence of a route leak policy.

Note: a brief overview of the Cisco CNC GUI was provided on Part 1.

Firewall Rules Automation

The configuration below illustrates the creation of Web and Internet EPGs tied to network-a, along with their associated endpoint selectors. Those are used to assign endpoints to a Cloud EPG, and can be based on IP address, Subnet, Region, or Custom tags (using a combination of key value pairs and match expressions).

For the Web EPG, a key value pair is used with specific tags to be matched (custom: epg equals web). For the Internet EPG, a subnet selector is used allowing all traffic. Furthermore, Internet EPG needs to be type External as internet access will be allowed on network-a.

The Cloud EPG App configuration is not depicted for brevity but is similar to that of cloud EPG Web. However, it is tied to network-b and set with its unique endpoint selector (custom: epg equals app).

On GCP, these policies get translated to dedicated ingress firewall rules and network tags for Web and App as highlighted using the following format: capic-<app-profile-name>-<epg-name>.

Note: Rebranding from Cloud APIC to Cloud Network Controller is covered on Part 1.

In the example below, cloud endpoints instantiated in GCP with labels matching the endpoint selectors are assigned to network tags and firewall rules automated by Cisco CNC.

Associating Contracts to EPGs

Now, let’s associate the web-to-app contract between Web and App EPGs using the concept of consumer and provider to define rules direction.

Upon associating the contract, additional ingress and egress firewall rules are programmed depending on the consumer and provider relationship specified. Specifically, these firewall rules are updated based on security policies defined through contracts and filters. For brevity, all traffic is allowed but granular filters can be added per requirements. On another note, these rules are only programmed once cloud endpoints matching the rules are instantiated.

Wait, what about peering between these VPCs? Since contract-based routing is enabled, it also drives routing by enabling peering and auto generating routes to each other accordingly.

Lastly, let’s allow internet access to web services residing on network-a by adding the internet-access contract between Internet and Web EPGs.

As soon as the contract is associated, Cisco CNC adds an ingress firewall rule with network tags representing the Web EPG which allows internet access to endpoints behind it.

From this point on, internet access to web-server is allowed as well as connectivity from the web-server to the app-server.

root@web-server:/home/marinfer# ifconfig ens4
ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1460
        inet 172.16.1.2  netmask 255.255.255.255  broadcast 172.16.1.2
        inet6 fe80::4001:acff:fe10:102  prefixlen 64  scopeid 0x20<link>
        ether 42:01:ac:10:01:02  txqueuelen 1000  (Ethernet)
        RX packets 19988  bytes 3583929 (3.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17707  bytes 1721956 (1.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
root@web-server:/home/marinfer# ping 172.16.128.2
PING 172.16.128.2 (172.16.128.2) 56(84) bytes of data.
64 bytes from 172.16.128.2: icmp_seq=1 ttl=64 time=58.3 ms
64 bytes from 172.16.128.2: icmp_seq=2 ttl=64 time=56.0 ms
64 bytes from 172.16.128.2: icmp_seq=3 ttl=64 time=56.0 ms
64 bytes from 172.16.128.2: icmp_seq=4 ttl=64 time=56.0 ms

Cloud Resources Visibility

Using a cloud-like policy model, Cisco CNC provides a topology and hierarchical view of cloud resources on a per tenant basis with drill down options. Moreover, application profile containers group together cloud EPGs and associated contracts for easy visibility of policies and dependencies.

More granular visibility is provided all the way to cloud endpoints. Firewall rules are also visible via Cisco CNC GUI under Ingress and Egress Rules.

Summary

Defining and managing security policies can be challenging, which can result in increased operational overhead and policy inconsistency. Besides automating and giving more visibility into firewall rules in GCP, Cisco CNC is also providing an additional layer of governance from a centralized management plane.

Part 3 completes this blog series by showing how Cisco Cloud Network Controller builds and automates external cloud connectivity from and to GCP.

Resources

Cisco Cloud Network Controller for Google Cloud Installation Guides

Cisco Cloud Network Controller for Google Cloud User Guides

Blog Series: Introducing Cisco Cloud Network Controller on Google Cloud Platform

Part 1: Native Cloud Networking Automation

Part 3: External Cloud Connectivity Automation – Coming Soon

Share: