Puppet by Perforce: Mastering multi-cloud misconfiguration mayhem

Key Takeaways

The proliferation of multi-cloud environments has increased complexity, leading to higher risks of misconfiguration and security vulnerabilities.

Maintaining a desired state in cloud-native configurations is critical, especially given the rise in cyber-attacks and changing compliance requirements.

Organizations should minimize customization, use preconfigured Infrastructure-as-Code solutions, and incorporate controlled self-service options to balance user demands with compliance and security needs.

Cloud grew. There are a lot of clouds – and we don’t just mean in terms of Cloud Service Provider (CSP) hyperscaler instances (although, okay yeah, that too), there are a lot of compute cloud formations across what is now an essentially multi-cloud world of deployment in the cloud-native universe.

The result of the cloud proliferation (or cloud sprawl, if you’re a glass-half-empty person) is that we’re seeing growing complexity, clearly… and this means multi-cloud deployments are harboring more misconfigurations and hence security risks. If we accept this basic proposition to be true, what should we do about the situation in hand?

According to David Sandilands, principal solutions architect at Puppet by Perforce, the introduction of cloud has greatly increased the complexity and variety of infrastructure. What he means here is that while perhaps 10-years ago organizations spent a large amount of time limiting what hardware and software options they configured to reduce their complexity and simplify their configuration, now they find modern cloud-native solutions – because they have so much inherent breadth, scope and scale – open those options back out again.

All at sea, configuration drift

“With most organizations looking at a multi-cloud approach are likely to still have considerable in-house private cloud investments, this leads to what can be a clashing intersection point between a huge variety of complex cloud-native technologies which themselves are constantly changing. This in turn leads to a higher risk of misconfiguration and configuration drift, which in turn create vulnerabilities that can then be exploited,” said Sandilands.

Consequently, then, the need to keep on top of configuration – to achieve the ‘desired state’ – has never been higher. This is especially so if we agree that there has been (and is now) a big increase in global cyber-attacks, instances of ransomware and data breaches. In addition, there is a far higher degree of government legislation and compliance requirements, which continue to change and grow in volume.

Speaking from experience gained with Puppet by Perforce customers, Sandilands and team highlight the fact that with constantly changing cloud-native technology and escalating compliance and legal requirements, trying to maintain a fully customised set of standards (even with the benefit of a layer of cloud-native Infrastructure-as-Code, or IaC) is a predicament that will inevitably lead to mistakes.

“To combat this, ensuring the selection of the right compliance standards, frameworks and regulations to follow and avoiding unnecessary customization, while using solutions with preconfigured IaC and compliance scanning, will greatly reduce this burden on organizations and allow IaC to deliver on its promise,” said Sandilands.

Systematic system strategies

But is it that simple? We know that customization is inevitable and in some cases endemic. What other aspects of wider system architecture management and strategic planning do we need to consider here?

“Ultimately users and customers want to consume the quickest and most compliant path they can to deliver their solutions, so organizations must work with their users’ expectations of self-service to plan differing levels of customization and exceptions,” explained Sandilands. “Some customizations are relatively harmless (even if we would desire uniformity to reduce risk) and have no regulatory or standard impact. These can just be processed using self-service APIs/portals with sensible limits of options or at least checks to protect against any malicious inputs.”

Even with compliance and regulation systems, Sandilands recommends that we should allow for both permanent and temporary exceptions to rules that are clearly visible, owned, approved and dated. If we pretend no exceptions are possible, this is more likely just to lead to shadow IT and compliance evasion. This should be balanced with process and authorization which reflects the relative risk of the exceptions in place.

“Ultimately, we will never fully remove the risk of variation and change. However, by helping users have what they need through controlled self-service, with processes that are fair and balanced to deal with exceptions to regulatory and standard configuration, we can achieve the best possible compliance while understanding our exposure and limitations,” concluded Sandilands, with gusto.