vRA and NSX – Application Services and Design

In the Intro to App-Centric Networking and Security post, I introduced some of the value and benefits of brining vRealize Automation and NSX together (be sure to give that a review before continuing). Now we’ll dive a bit deeper into the technical details of the integration to gain an understanding of how these solutions can transform application security.

vRealize Automation (vRA) supports deployment topologies to align with business and IT needs. The topology can be based on application or access requirements, network and security constraints or, in the case of consumption-only mode, as a means of easing into automation ahead of going all-in.

The integration of vRA and NSX can be leveraged to simply consume existing networking and security services managed by the endpoint (Existing), or set to dynamically deploy application-centric services during machine provisioning (On-Demand) using native platform integration to automate otherwise manual tasks. You can also opt for combining the two options in a single blueprint. Each of these services can be dragged and dropped onto the unified canvas to be incorporated into the blueprint design. Once properly bound to the machine components and configured, the corresponding service will be automatically deployed per the blueprint’s policy.

Existing Networking and Security

For customers itching to utilize the power of NSX in vRA, but aren’t quite ready to embrace full automation (let’s have a discussion about that one day), leveraging Existing services can provide a comfortable middle ground. These services are collected during endpoint inventory (in this case, vSphere and NSX Manager) and may include a combination of traditional vSphere and NSX-backed services for consumption-only topologies…

• Existing Network – Endpoint networks that are presented as network paths once they are collected by vRA. These may include traditional vSphere port groups, dvPortgroups, or logical networks (switches) backed by NSX.

  

• Existing Security Group – Pre-created Security Groups made available by the security admins, for example. Once collected by vRA, these security groups can be simply dragged onto the canvas and bound to one or more component machines. Using existing security groups will provide options for security admins that prefer a little more control vs. automation.
• Existing Security Tag – Pre-created NSX Security Tags collected during endpoint inventory. Security Tags are used to tag machines with specific metadata, which results in those machines being dynamically added to an existing Security Group and the associated policy. One or more tags can be dragged to the unified canvas and will apply to all machine components on the canvas.

NSX On-Demand Services

In contrast, customers who are ready for all the benefits of automating networking and security can leverage On-Demand services, including On-Demand Security Groups, On-Demand Routed Networks, On-Demand NAT Networks and On-Demand Load Balancing..

• On-Demand Security Groups – Creates a new Security Group and binds one or more existing Security Policies. The desired security policies are added to the ODSG during blueprint configuration.*if a blueprint is configured with both an ODLB and ODNAT, only one ESG will be deployed and configured for both services accordingly

  

• On-Demand Routed Networks – On-Demand Routed Networks are dedicate application networks that are provisioned during deployment. Once requested, vRA + NSX create a dedicated interface on an upstream distributed logical router (prerequisite); creates a new logical switch; wires the router interface and machine vnics; then applies IP policy as defined in the corresponding Network Profile.
• On-Demand NAT Networks – On-Demand NAT Network (ODNAT) deploy a dedicated NSX Edge Services Gateway (ESG) and logical switch; automatically configures the appropriate NAT policy based on the corresponding network profile. On-Demand NAT supports both 1:1 and 1:Many NAT configurations. A new capability added in vRA 7.3 enables the ability to modify NAT Port Forwarding Rules (1:Many NAT networks) as an entitled/governed Day-2 operation. Entitled owners can modify port forwarding rules of provisioned applications to without powering down the target machines. NAT rules can be added, removed and reordered as needed by the application owner.
• On-Demand Load Balancing – vRA and NSX support several network topologies to provide unique granularity for each application. In the case of Load Balancers, both One-Arm and Inline load balancers are supported, which is automatically decided and provisioned based on the canvas design. At request time, NSX will deploy a dedicated Edge Services Gateway and automatically configure the logic to make it all work. Scaling out a load-balanced tier automatically adds the new node to the server pool.

  

   

  Starting in vRA 7.3, granular load balancer controls are built in to the Converged Blueprint Designer, allowing authors to configure load balancing policies unique to the application. Exposed policies include LB Algorithm details, Session Persistence, Health Monitors, Transparency Mode, Logging, and others. Once an on-demand load balancer is deployed, the application owner can be entitled to modify several of these settings as a lifecycle action.
  
  NSX On-Demand Load Balancing in vRA (one-arm topology)

Application Deployment Scenarios

vRA supports several different deployment scenarios for applications leveraging NSX networking and security services. These scenarios are designed to align with each application’s unique networking and security needs or can be driven by IT standard practices…or both. Most importantly, vRA doesn’t force customers into any one direction — use existing services to start, then gain the benefits of on-demand services as part of an established maturity model. In either case, vRA has your back. Below are some example deployment scenarios available out-of-the-box.

Application Deployment into Existing Network and Security Services

For starters, vRA collects the NSX inventory, including pre-configured logical networks and security groups, tags, and policies once the NSX Endpoint is added to the mix. Any of these existing services can be used by simply dragging them to the design canvas, providing a consumption-only design…

Watch the video: Existing Network Services

Application Deployment with On-Demand Networking & Security

Next up, we have now warmed up to on-demand networking and security – because why not? – and are leveraging vRA and NSX to build these services dynamically, at request time. This may include on-demand NAT’d or Routed networks, an on-demand load balancer, and even creating on-demand security groups for each of my application tiers for true app-centric security…

Watch the video: NSX On-Demand Networking

Application Deployment with Security, Load Balancing & App Isolation

Last example here is the use of on-demand load balancing to provide HA services to a particular tier within the canvas. The on-demand load balancer can be used with existing or on-demand networks (showing existing in this example). In addition, here we’re using the App Isolation option at the blueprint level. This provides auto segregation of the app by dynamically creating a security boundary around the entire deployment, only permitting network traffic that is specifically called out by a component-level security policy. App Isolation is enabled by simply clicking the check box…

Watch the video: NSX On-Demand Load Balancer and App Isolation

More on App Isolation

App Isolation provides an additional layer of security that protects the entire application deployment from all other deployments (e.g. those provisioned from the same blueprint). For example, assume the machine components of a multi-tier blueprint — webtier and dbtier — are wired to the same existing (external) network, each bound to their own unique security groups. Once deployed, the webtier and dbtier will share the same external network and be protected from each other thanks to their security groups and associated security policies. However, with each subsequent deployment, you’ll be adding additional webtier and dbtier machines to the same network…and while the security group protects the tiers from each other, there is no default protection between the webtier machines provisioned in deployment 2, 3, 4…100. App Isolation addresses this by dynamically adding the needed security layer at the component level to automatically block the cross-deployment traffic. Only a component-level security group or policy has a higher priority and will expose the needed traffic.

LifeCycle Actions

vRealize Automation 7.3 added several new capabilities in the area of lifecycle (Day-2) actions. This includes the ability to modify NAT Port Forwarding Rules for deployed On-Demand NAT Networks (1:Many), modifying Security Tags and Security Group membership, and modifying the On-Demand Load Balancer policies for deployed applications. This allows quick access to the modifying critical network services based on an application’s needs throughout it’s lifecycle. Lifecycle actions can be invoked without powering down the target application. Additionally, these Day-2 lifecycle actions are available only if the user is entitled to the action and can also be bound to approval policies to wrap governance and control around these changes.

NSX Day-2 NAT Policy Actions

NSX Day-2 Security Actions

Watch the video: NSX Day-2 Lifecycle Actions

Summary

Network and security automation — and specifically the use of on-demand services — will play an increasingly-significant role as NSX (and network virtualization in general) continues to be widely adopted by the enterprises globally. There’s a false perception (mainly by the networking and security teams) that automation reduces control and visibility into the services that traditionally involve a ton of ownership, red tape, and several siloed personalities. In some cases, it’s job security. But in others…it’s the fear of letting go. Once these folks realize vRA + NSX together will provide greater control, more governance, and better visibility than they’ve ever had before, things tend to shift in favor of automation. On their own, vRA and NSX continue set new operating standards for modern datacenters. But, when combined, the story shifts to IT Transformation.

Presentation: App-Centric Networking and Security with vRealize Automation and NSX

+++++
virtualjad