Maintaining Governance and Security in Multi-Tool Environments

The massive shift to hybrid cloud architectures means enterprises are choosing a multi-tool approach to IT. However, the new multi-tool world inevitably creates security and governance challenges.

The more tools you add, the more complicated things get. Each new tool requires comprehensive integrations to fit into your stack and access and orchestrate underlying IT technologies, such as IPAM, DNS, networking and security and cloud backup.

Think about it: How many tickets have you issued to make that happen?

The Perils of Custom Coded Integrations for Multi-Tool Environments

In a multi-tool world, a best-of-breed approach is a good thing. In fact, it’s often necessary to meet evolving user needs and capitalize on the agility and scalability that hybrid cloud promises. The downside is that every new tool must be integrated with your existing stack. These integrations usually entail varying levels of custom coding and often require the assistance of expensive third-party system integrators.

Many cloud management platforms (CMPs) offer “out-of-the-box” integrations for various networking, security and automation tools, but these integrations often provide limited functionality—usually little more than what is needed to “tick the box.” Due to the limitations of these plug-in solutions, custom coding becomes unavoidable.

Unfortunately, custom coding inevitably creates two major challenges for hybrid cloud management: the accumulation of technical debt and a lack of adequate governance. And these governance issues translate into increased security and compliance risks.

The Burden of Technical Debt  

Custom coding integrations are typically provided by systems integrators or, almost half the time (43%), the tool provider’s PSO. The custom integration process can be long and arduous, adding months to your time-to-value. Furthermore, the resulting code is not re-usable or shareable between tools. In multi-tool environments, this results in duplicate integrations being created for each tool or even different versions of the same tool, compounding your technical debt.

Also, anytime you have to custom code an integration, you also have to maintain that code. Every time there’s an update or APIs change (which inevitably happens), you have to rewrite it. Achieving a single, unified view of all of your integration policies becomes difficult, if not impossible. Finally, troubleshooting and auditing integrations require IT teams to sift through a labyrinth of spaghetti code involving multiple logs from multiple systems.

A lot of tools provide capabilities such as access controls, code verification and logging changes to code. The problem is that these capabilities are often confined to the actions performed within a single technology.

For example, let’s say you use VMware’s vRealize Automation to automatically handle VM provisioning. Your vRA environment may have an integration with BlueCat to assign an IP address during the provisioning process, but if you’re also using Infoblox for DNS registration, you’ll need another integration for that—and the nature of plug-ins means your integrations will only go so deep.

The end result is varying levels of integration, with different parameters and policies for each tool you’re using. Anything “outside the box” is left to scripts and code, accumulating mountains of technical debt and increasing maintenance requirements.

The Risks of Non-Governed Integrations

Custom code can become a major obstacle to centralized visibility and governance in multi-tool environments and the more custom code you have, the more your threat surface grows.

As we mentioned above, a number of CMPs offer built-in, out-of-the-box integrations for certain tools, but these integration services are not re-usable or consumable across different toolsets, resulting in a proliferation of non-compliant automation services across your enterprise. Identifying these services, applying organizational policies and enforcing compliance becomes impossible.

Things can go wrong when non-governed integrations creep into the enterprise. As your hybrid cloud grows more complex over time, resources may be given duplicate names or the same IP address might be assigned to different workloads. Collisions in names and overlapping IP addresses could result in application failures or outages. If all of the existing silos in IT don’t adhere to the same standardized policies, robust naming and validating functionality isn’t possible.

Each tool you use will also require different role-based access controls (RBAC). If one person on your team needs access to seven different tools; you will need to create seven different profiles for a single employee. If that employee leaves the organization, you will have to make sure all seven profiles are deleted from the system.

You might say that you can automate RBAC so this isn’t a problem for you, but automated access controls are often all or nothing, meaning you have to give full credentials to everyone involved. You won’t be able to enforce least-privileged access levels to ensure that only the right people have access to the right things at the right time.

The Need for a Dynamic Abstraction Layer in Your CMP

As hybrid cloud architectures grow more complex, how do you square the circle of ensuring as many options as possible, while at the same time maintaining visibility, standards and protocols, access control and robust validation, regardless of how many tools you adopt?

The best solution is to make sure you have a CMP that provides a dynamic abstraction layer with pre-built integrations for any tool you want to add. This facilitates deep, software-based integrations and end-to-end visibility from a single panel. This single, 360-degree view of all cloud workloads and resources makes it easy to identify areas of risk, sprawl and inefficiency, and the nuts and bolts of cloud governance and security fall squarely into place.

Such a solution also gives you the ability to fit new tools into your existing infrastructure with simple software commands, instead of painstakingly written custom code. The sprawl and maintenance issues that arise from custom coding are eliminated, and upstream automation tools can now easily consume downstream integration policies.

Finally, a dynamic abstraction layer lets you rapidly write and implement standardized policies across the entire organization. Naming standards for cloud resources can be enforced, policies can be validated and evolving security protocols can be maintained. This significantly reduces risk and minimizes attack vectors because everyone is now on the same page adhering to the same rules. At the same time, compliance leaders can easily audit integrations, names and policies.

In the multi-tool era, you need CMPs that offer more than surface-level integrations and limited interoperability. Your CMP should not only provide deep, pre-built integrations, but also give you the ability to govern these integrations by providing centralized policy management, seamless RBAC and robust validation capabilities. If you don’t have that, your integrations won’t be deep enough, your visibility won’t be clear enough, your technical debt will continue to mount and your governance and security will suffer.

Avatar photo

Grant Ho

Grant Ho is the Chief Marketing Officer of CloudBolt, a cloud management platform that helps IT provision, orchestrate, and manage all their cloud resources and give developers access to those resources through a self-service catalog.

grant-ho has 2 posts and counting.See all posts by grant-ho

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)