Control Cisco Secure Workload Using APIs, Ansible, and Terraform

Cisco Secure Workload, (formerly Cisco Tetration) provides policy lifecycle services, micro-segmentation, and cloud workload protection. Furthermore, it is completely accessible via open APIs and by using Ansible and Terraform. It is also part of Cisco Application-First Security and a pillar of the Cisco Zero Trust architecture.  

Do you want to learn more about Cisco Secure Workload, and how to control it using APIs, Ansible and Terraform?
Register here for the webinar
Tuesday, June 15th, 8:00 AM PDT  |  5:00 PM CET.
Can’t make the webinar? Get started here about Secure Workload! 

Get to know Ansible

Now since this blog post is about Ansible, and the new module for Secure Workload, let’s first dive into Ansible itself. Ansible is a deployment, orchestration, and configuration management tool that is well known for its ease of use. It is open source, simple to work with and powerful enough to help automate complex solutions. Its goal is to provide productivity gains to a wide variety of automation challenges.

One of the largest benefits of Ansible versus other configuration control software is that Ansible has no agent. This allows Ansible to be extremely lightweight compared to its competitors. Ansible works by having access to the end devices (usually through SSH or API calls). It executes a series of instructions on those devices through a range of methods, but commonly through the python programming language.

Ansible aims to be “idempotent,” meaning that you can run your ansible configuration several times and get the same outcome. Ansible does not maintain a ‘state’ file of the current configurations of devices. Rather, looks at the current state of the device vs the desired state as defined within Ansible.

Cisco Secure Workload Ansible Modules

The Cisco Secure Workload Ansible modules have many functions. In the sections below we will walk through them briefly. In the webinar we will take a closer look at them, and see some live demos.

Secure Workload users with Ansible

With the Ansible tetration_user module you can add, remove and validate Secure Workload users. The objective is to enable IT Operations automation teams to run Ansible playbooks to validate users and their roles and the scopes. This can be very handy when onboarding users, or to integrate with other systems.

Secure Workload scopes with Ansible

Want to modify Secure workload scopes with Ansible? Using the newly created Ansible scope module, you can add, remove and modify Scopes in Secure Workload. The objective is to enable IT Operations automation teams to run Ansible playbooks to create scopes and group devices according to defined business logic.

Scopes are key to working with many objects in Secure Workload. The ability to create, but also look for scopes is required to be able to work with many of the objects using the `tetration_ansible` role.

Scopes are used to group datacenter applications, assign permissions to Roles, and used throughout the product for defining access to resources and creating micro-segmentation policies.

In each Secure Workload deployment there is a root scope. All scopes in the system originate from this scope. In addition, names in Secure Workload can be duplicated, as long as the scope has a different parent scope, so knowing how to find a specific scope is critical to correctly building objects.

Secure Workload roles with Ansible

Control Secure Workload with Ansible using the `tetration_role` module to add, remove and modify Secure Workload `roles`. The objective is to enable IT Operations automation teams to run Ansible playbooks to create Role Based Access controls for end users. Roles are used to implement Role Based Access (RBAC) in Secure Workload. A role is assigned one or many App Scope / Ability combination. Each App Scope / Ability combination can be assigned one or more actions.

Secure Workload agents with Ansible

Secure Workload agents are software agents running on the host system. They have a small footprint and are used to monitor and collect network flow information as well as some internal workload details (if possible). The data gathered by agents is ingested within Secure Workload and analyzed. Agents can also be set to ‘Enforcing’ mode, where they will manipulate local firewall rules on the host based on policy that is discovered, analyzed, and enforced via Secure Workload.

Upon removal of agents or decommissioning workloads, IT Operators can clean up the workload-specific agents from the Cisco Secure Workload system and delete workload and tags entry from the Secure Workload inventory. This enables searching for software agents based on a number of preconfigured filters. It also returns a list of matching software agents based on the passed in criteria. The agent status will show whether the agent is active, when it was last updated, what is it’s scope, and if it is enforcing.

An example Ansible playbook could be one that can verify that our new workload has been registered to the Secure Workload manager. The Playbook provides a blue/green response so the user can stop execution if there is a problem. It can validate that agent was successfully installed by name, IP Address, or other distinguishing item and then stops if the server isn’t registered. If it is registered, we can provide the agent hostname and type.

Join us for the live webinar 

Congratulations, you made it to the end of this blog post! Do you want to learn more about Cisco Secure Workload, and how to control it using APIs, Ansible and Terraform? 

Tuesday, June 15th, 8:00 AM PDT  |  5:00 PM CET.
Register here for the webinar
Can’t make the webinar? Get started here about Secure Workload! 

Related resources

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel

Share: