Cisco Tetration - Hands-On Lab

Module07 - Scopes

Scopes are used in Tetration to break down an IP scheme of an organization into manageable blocks that represent a function, such as an application. Scopes are organized in a tree structure, with a Root Scope at the top of the tree which represents all IP addresses; both internal and external. The root scope is tied to the VRF, which in turn represents the IP space of a Tenant. In Tetration Cloud, there can be only a single Tenant and hence only a single VRF and Root Scope. With an on-prem Tetration cluster, you could possibly have multiple Tenants and VRFs. Each leaf of the scope tree is tied to a query, with the queries typically being more broad at the higher levels of the tree and becoming more specific as you traverse down the tree structure. For example, consider the following scope structure that will be used in this lab:

  Root  
    └── Pod (PodSubnet=internal)    
        └── Cloud (orchestrator_Cloud=AWS)      
            └── Region (orchestrator_Region=us-east-1)  
                ├── CommonApps (orchestrator_AppName=Common)  
                    ├── OpenCart (orchestrator_AppName=OpenCart)  
                    ├── SockShop (orchestrator_AppName=SockShop)  
                    └── nopCommerce (orchestrator_AppName=nopCommerce)  

In this tree structure, the Pod matches our annotation PodSubnet=internal which is assigned in our annotations file to match all RFC1918 IP address space. At each level of the tree our query results will become less broad until at the bottom of the tree we are matching workloads that are specific to an application. With this scope hierarchy, policy can be applied at any level of the tree and will be collapsed into a single policy that will be applied on matching workloads. This allows us to create very broad policy, such as policy that applies to everything in AWS by applying the policy at the Cloud level, while applying policy that is required specifically for the application to function at the lower-level application scopes. This way we can define policy for the services that are common across the organization or across a particular region or cloud, such as DNS, DHCP, Active Directory, etc. once in the higher level scope and have those policies applied across all workloads, while creating smaller rulesets at the lower level application scopes. Breaking the policy into smaller subsets of rules makes the ruleset much easier to digest by administrators. It also provides the ability for the security team to set broad policy at a higher level of the scope tree that implements a corporate policy, for example “Dev can’t talk to Prod”.

In this module, we’ll define the Scope tree that will be used throughout the rest of the lab exercises.

Click here to view a video highlighting the creation of Scopes.

Click here to view a video showing the verification of Scope members.

Steps for this Module

Step 001 - Navigate to Scopes
Step 002 - Create a new scope under the root
Step 003 - Create the Pod scope
Step 004 - Enter the Pod scope
Step 005 - Create a new scope under the Pod scope
Step 006 - Create the Cloud scope
Step 007 - Enter the Cloud scope
Step 008 - Create a new scope under the Cloud scope
Step 009 - Create the Region scope
Step 010 - Enter the Region scope
Step 011 - Create a scope under the Region scope
Step 012 - Create the nopCommerce scope
Step 013 - Create a second scope under the Region
Step 014 - Create the OpenCart scope
Step 015 - Create a third scope under the Region
Step 016 - Create the Common Apps scope
Step 017 - Commit scope updates
Step 018 - Observe the commit status
Step 019 - View the query results for AppGroup = Common
Step 020 - Observe workloads associated with Common Apps
Step 021 - View the query results for AppGroup = nopCommerce
Step 022 - Observe workloads associated with nopCommerce
Step 023 - View the query results for AppGroup = OpenCart
Step 024 - Observe workloads associated with OpenCart

Click the Gear icon in the right-hand corner and select Scopes

Here we will create our first scope under the root scope. Click Create New Scope.

Your root scope will be named based on your StudentID in the lab. In a real customer deployment in Tetration Cloud, it would be the company name.

The name of the first scope will be Pod, to represent your student Pod. Set the query to * PodSubnet = internal. This was a static annotation that we set in the previous module on annotations. It matches all RFC1918 private address space.

Click on Pod to navigate to the next level in the scope tree. Notice how the path at the top now changes to ROOT : Pod.

Create a new child scope under the Pod scope.

Name this scope Cloud, and enter the query *orchestrator_Cloud = AWS. From here on out, we’ll be matching on tags that are set on your instances running in AWS. Recall that these tags are being pulled in from the External Orchestrator configuration for AWS. All instances will be tagged with the Cloud = AWS tag.

Click on the Cloud scope to move down to the next level in the scope tree.

Create a new Scope under the Cloud scope.

Name the new scope Region, and enter the query *orchestrator_Region = us-east-1.

Click on the Region scope to navigate to the next level in the scope tree.

Create a new scope under the Region scope. We will create three scopes under the Region.

Name the first scope under the Region nopCommerce, and set the query to *orchestrator_AppName = nopCommerce. This query will match the Windows app servers.

Create another scope under the Region scope.

Name the scope OpenCart, and enter the query *orchestrator_AppName = OpenCart.

Create another scope under the Region scope.

Enter Common Apps for the name and enter the query *orchestrator_AppGroup = Common. This will match the Windows Active Directory and Ansible servers.

Click Commit Scope Updates to approve the new scopes and have the new scope structure take affect.

After a few minutes, the warning icon that indicates scopes have not been committed will disappear.

You may have to refresh your screen a few times.

Now we will verify that the queries match the workloads in the lab environment. Click on the query orchestrator_AppGroup = Common.

Here you should see listed the Active Directory server as well as CentOS machine which is the Ansible server. Cross check the IP addressing against your pod information. Click the back button on the browser to return to the previous screen.

Click on the query *orchestrator_AppName = nopCommerce.

Here we should see the IIS and MSSqlServer Windows servers that make up the nopCommerce application. Click back in the browser to return to the previous screen.

Click on the *orchestrator_AppName = OpenCart query.

The workloads listed here are the Linux machines running Apache and MySQL that make up the OpenCart web application.

You have reached the end of this module.