Cisco Blogs


Cisco Blog > Data Center and Cloud

Application Configuration Management: What’s your Approach?

October 21, 2014 at 7:27 pm PST

Last we spoke, it was about network device configuration management. Let’s move our focus up the stack to applications and management of their configuration. Whether enterprise or cloud-architected, running on physical servers, in virtual machines or in containers, how are you managing your applications?

Puppet, Chef, Ansible and Salt are popular answers to this question and leading contenders for initial provisioning and management of configuration drift of data center applications -- whether they be common off the shelf (COTS) or custom built applications. Two of these configuration management technologies, Puppet and Chef, are supported by Cisco Intelligent Automation for Cloud 4.1. The collection of features enveloping these two Ruby-based technologies within Cisco IAC is referred to as Application Configuration Management (ACM).

Approach to Agent Bootstrapping

Puppet and Chef are similar in nature -- in more ways that we’ll discuss in this post. An example of similarity being that both of these ACM technologies require an agent (Puppet) or client (Chef) installed on the server under management (node).

cisco-iac-agent-bootstrapping

Agent Bootstrapping Methods

Both types of ACM technologies support client-only and client/server deployment models, referred to as agent/master for Puppet and client/server for Chef installations. Whether only using an agent-only (client-solo -- Chef) or using an agent/master deployment model, unless your virtual or physical server image has the agent preinstalled, you’ll need to go perform the prerequisite work of agent installation.

IAC performs this dirty work by bootstrapping the appropriate agent (or client) whether on initial server provisioning or on-demand on any existing server when a user assigns an application to a server. Mechanics used to perform agent installation varies. The mechanics used within IAC are listed in the “Agent Bootstrapping Methods” chart. Initially, IAC used WinRM as its mechanism to bootstrap agents on Windows severs until customer feedback drove use of an alternative mechanism -- psexec. We found that customer security teams were either uncomfortable with or had policy in place against the use of WinRM as a method to execute scripts remotely and made the switch to psexec, which “is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software”.

Part of the agent installation involves establishing a connection between the ACM server (Puppet Master or Chef Server) and the node (server with agent/client installed). IAC orchestrates the registration of the node with it’s respectively, assigned ACM server. This process is different depending on whether Puppet or Chef is used.  In the case of Chef, IAC has the chef-client register with the Chef server using the private key assigned to the chef-validator, which IAC loads into the node during client installation. In the case of Puppet, IAC performs an initial puppet agent run, which lodges a certificate authorization request on the Master, which IAC subsequently orchestrates the signing of on the Master. With agent bootstrap complete and authorized, secure communication between the ACM server and client, attention is turned to the management of connections IAC may have established with number of Puppet or Chef servers.

Cisco IAC System Health - ACM

System Health -- ACM

Connection and System Health

In the case of client/server deployments, IAC will establish connection to one or more Puppet Masters and one or more Chef Servers. Each connection is treated with care as the health of each connection facilitates IAC’s ability to successfully orchestrate applications. Connections are established using a service account permissioned appropriately. The health of the connection between each ACM server is evaluated once every 30 minutes by default. Connection health is determined by performing connectivity, authentication and authorization tests. Details of these tests and a screenshot of the System Health console can be seen in the  ”System Health -- ACM” chart.

Cisco IAC CloudSync Finite State Machine

CloudSync Finite State Machine

Cloud Object Model and CloudSync

Immediately after establishing a healthy connection, CloudSync runs. CloudSync is a synchronization process driven by a finite state machine whose responsibility is to not only perform initial object discovery and granular fingerprinting -- essentially a deep interrogation of cloud objects and their attributes -- but also, manage ongoing reconciliation of infrastructure changes with respect to their representation of the provider’s cloud infrastructure as modeled within the service catalog. Note the “CloudSync Finite State Machine” chart, which is laced with Extension Points, where cloud administrators may insert custom logic on state transition for any give object within the model. Once collected, this inventory (e.g. a Chef Role) is presented to the cloud administrator for  the ACM server for use within their cloud. Cloud administrators may choose to register the discovered objects for use by end users.

Cisco IAC Cloud Object Model - Chef

Cisco IAC Cloud Object Model -- Chef

Cisco IAC Cloud Object Model - Puppet

Cisco IAC Cloud Object Model -- Puppet

For example, the cloud administrator may choose to register a Puppet Role as being available for end users to assign to a server. Registration of this role may include assignment of additional metadata, including price of the role as a one-time or recurring charge for use of the application and assignment of tenant permissions (whether to make the role available to all tenants or only select tenant(s)).

It’s through the relationships derived within the Cloud Object Model and assignment of tenant permissions that the specific applications are presented to a given end user. Service Resource Containers are used as a logical construct owned by the cloud administrator wherein tenant-specific resources may be hosted. Applications delivered to tenants may be created in a virtual data center that is serviced by either a Puppet Master or Chef Server. See the Cisco IAC documentation for further details on other constructs within these and other models.

Cisco IAC My Servers - Manage Applications - Node Classification

Manage Applications -- Node Classification

Approach to Node Classification

Once registered for use, applications become visible to end users, who may assign applications to their servers whether during initial server provisioning or to an existing server. Upon selection of application(s) by the end user, IAC classifies the node by writing a hiera file (Puppet) or by writing a run-list (Chef) on the respective ACM server and forces an immediate agent run to ensure application configuration is promptly enforced.

In this sense, IAC provides a common user experience for node classification irrespective of the underlying technology chosen by the cloud provider (the organization running and administering IAC). As the IAC product suite evolves, so has our approach in terms of classification via Puppet and the more programmatically effective use of a custom-written External Node Classifier, taking advantage of the ability for the node_terminus configuration to to interact with an ENC.

Application Configuration Management Highlights

Cisco IAC CloudSync'ed Application Infrastructure

CloudSync’ed Applications

  • Integration with Puppet and Chef
    • Connections to number of servers
    • System health checks for these servers
    • Application infrastructure discovery (CloudSync)
    • Bootstrapping of agents (green and brownfield)
  • Financial Management
    • Pricing of applications
    • Showback for application orders
    • Run rates including application consumption by user, org, tenant
  • Multi-tenancy
    Financial Management - Application Pricing & Showback

    Financial Management -- Application Pricing & Showback

    • Tenant-specific application catalogs
    • Tenant/application consumption dashboards
  • Provisioning
    • Application provisioning for virtual machines, physical servers
    • “My Applications” interface for application management
  • Service Offering Elections
    • 3-tiers of control on enable/disable application configuration management services at provider, tenant and organization levels
  • Multi-Cloud Platform Support
    • Support same services ubiquitously across all platforms

    Financial Management - Application Run Rates

    Financial Management -- Application Run Rates

  • Application User Persona
    • “My Application” interface for application management
    • ACM Server and application usage dashboard

Cognizant of the plethora of application configuration management tools available to Cisco customers, including commercial, open source, and homegrown tools, we’re very interested to hear which ones you have found to be the best fit in your environment. Have you established revision control practices as you manage infrastructure as code?Having reviewed Cisco’s approach within its cloud management platform, IAC, whether you manage configuration of physical servers, virtual machines or use CM to build containers or hosts that run containers, how does your approach compare?

Tags: , , , , , ,

The Golden Key to Any Cloud

As cloud technology and organizations mature, customers are shifting their focus from the provisioning of individual servers to richer cloud-based application platform stacks. Why? Servers usually do not exist as standalone entities but are designed to run something tangible for the business. For example, multi-tier application platform stacks have in their design multi-server elements such as database, application and web servers.

In this era of the cloud, creating golden templates for each of the elements required to configure these multi-tier stacks and the servers they reside on, is not only unwieldy for IT to maintain and manage but they are monolithic. This means if one single element changes, the whole golden image needs to be revised. Golden images are not configurable and frequently require additional manual configuration to complete installation.

What’s the solution? It begins with the concept of DevOps.

DevOps is a software development method that permits better collaboration between software development and IT operations in a way that these multi-tier application servers can be consumed in the cloud without human intervention. There are a number of disciplines included under the DevOps category, but this blog will be focusing on configuration management.

Puppet and Chef are two of the leading configuration management vendors in the DevOps segment delivering the following benefits:

• Elastic and continuous configurations
• Increased productivity to handle hundreds to thousands of nodes
• Improve IT responsiveness by reducing time to deploy changes
• Eliminate configuration drift and reduce outages

There is a lot of buzz about this capability. How much buzz? Watch this video from CiscoLive Orlando.

Within the next month, Cisco will be releasing a cloud accelerator that delivers configuration management of multi-tier application stacks. Based on the TOSCA-modeled graphical user interface, customers utilize a canvas that simplifies the design of these stacks into templates. Each element: server, network device and storage; is represented on the canvas with a graphical icon. Behind each icon are configuration details for each component. For example, network device configuration may include firewall rules and load balancing algorithms. For servers, Cisco is leveraging Puppet and Chef or home-grown scripts. The result is a blueprint that allows for consumption of the complete application stack by end users, on demand, delivered by the cloud.

So now we have blueprints. Where’s the real advantage?

Cisco Intelligent Automation for Cloud (IAC) is the golden key that gives you the advantage because it unlocks this new approach to cloud efficiency. Providing blueprints for multi-tier application stacks on their own do nothing if they cannot be ordered by customers from a standardized menu of services and acted upon by an orchestrator to automatically deploy the entire configuration. Extending functionality for DevOps is just another example of Cisco IAC’s ability to go beyond IaaS without requiring a solution rip and replace or major push-ups by customers.

Why just provision servers and continue to increase IT costs with manual “last mile” provisioning?
Cisco IAC and the configuration management accelerator simplify the delivery of multi-tier application stacks through self-service ordering and repeatable delivery. Cloud accelerators are designed to follow the vision and strategy of Cisco IAC eliminating code islands that become problematic when you upgrade to the next generation Cisco IAC edition.

To browse through the current cloud accelerators, go here. First time visitors will need to sign the register.

If you would like to learn more or comment, tweet us at: http://twitter.com/ciscoum

Tags: , , , , , , , , , , , ,

Evolving Continuous Monitoring to a Dynamic Risk Management Strategy

Organizations implementing Continuous Monitoring strategies are remiss if they are not taking into account the value of network telemetry in their approach. NIST Special Publication 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations provides guidance on the implementation of a Continuous Monitoring strategy, but fails to address the importance of network telemetry into that strategy. In fact the 38 page document only mentions the word “network” 36 times. The SP 800-137 instead focuses on two primary areas: configuration management and patch management.  Both are fundamental aspects of managing an organizations overall risk, but to rely on those two aspects alone for managing risk falls short of achieving an effective Continuous Monitoring strategy for the following reasons

First, the concepts around configuration and patch management are very component specific. Individual components of a system are configured and patched. While these are important the focus is on vulnerabilities of improper configuration or known weaknesses in software. Second, this approach presumes that with proper configuration control and timely patch management that the overall risk of exploitation to the organization’s information system is dramatically reduced.

While an environment that has proper configuration and patch management is less likely to be exposed to known threats, they are no more prepared to prevent or detect sophisticated threats based on unknown or day-zero exploits. Unfortunately, the customization and increase in sophistication of malware is only growing. A recent threat report indicated that nearly 2/3 of Verizon’s data breach caseload were due to customized malware. It is also important to keep in mind that there is some amount of time that passes between a configuration error is determined and fixed or the time it takes to patch vulnerable software. This amount of time can potentially afford an attacker a successful vector.  For these reasons organizations looking to implement a Continuous Monitoring strategy should depend on the network to provide a near real-time view of the transactions that are occurring. Understanding the behavior of the network is important to create a more dynamic risk management focused Continuous Monitoring strategy.

Network telemetry can consist of different types of information describing network transactions in various locations on the network. Two valuable telemetry sources are NetFlow and Network Secure Event Logging (NSEL). NetFlow is a mechanism that organizations can use to offer a more holistic view of the enterprise risk picture. NetFlow is available in the majority of network platforms and builds transaction records of machine-to-machine communications both within the enterprise boundary as well as connections leaving the enterprise boundary. These communication records provide invaluable information and identify both policy violations and configuration errors. Additionally, NetFlow also provides insight into malicious software communications and large quantities of information leaving an enterprise. Network Secure Event Logging uses the NetFlow protocol to transmit important information regarding activities occurring on enterprise firewalls. This is valuable data that can be aggregated with other NetFlow sources to bring additional context to the network behavior occurring.

Coupling the configuration and patch management guidance in SP 800-137 with an active NetFlow monitoring capability will provide organizations with a Continuous Monitoring strategy that is more system focused and more apt to fostering a dynamic risk management environment. Cisco will be discussing NetFlow, NSEL and other security topics at the March 21st,  Government Solutions Forum in Washington, D.C. If you’re interested in learning more, click on the following URL:

www.cisco.com/go/gsf

Tags: , , , , , , , , ,