In the ever-evolving landscape of technology, platform engineers often face a challenging task: managing multiple versions of platforms used by developers to deploy applications. These platforms can range from on-premises infrastructure to public cloud resources. Over time, this leads to what is commonly known as “platform sprawl,” where engineers spend more time maintaining older versions of platforms while also managing new ones. This situation can fragment workflows across an organization, complicating cross-platform improvements, monitoring, debugging, and patching.
To tackle these challenges and reduce technical debt, a concerted effort is required to refactor applications, infrastructure, and security. The goal is to standardize new patterns and workflows, which can significantly streamline compliance and remediation at scale. This article aims to provide insights into refactoring infrastructure provisioning and patching workflows across multiple platforms and application teams, all while minimizing the effort required for risk discovery and remediation.
### The Struggle for Standardization
Consider an organization that operates five different platforms across a data center and two public clouds. Each platform has its own automation and security approach, leading to a diverse range of automation and change management styles. This diversity can make it difficult to manage security issues uniformly across all platforms, as each platform may require a different approach for upgrades and patches.
One of the first steps toward standardization involves abstracting workflows across multiple platforms, such as using an internal developer portal. This approach requires significant development effort but causes minimal disruption to existing applications. Another method is to import existing infrastructure onto new platforms using tools like Terraform, which allows for managing infrastructure as code. This provides a foundation for standardization, albeit with some disruption to existing applications. Lastly, migrating resources from older platforms to newer ones may involve a high level of development effort and create significant disruption to dependent applications.
Regardless of the chosen approach, practices like policy as code and principles of immutability are crucial for maintaining standards across teams, platforms, and workflows.
### Policy as Code
Policy as code is a method of automating, documenting, and versioning rules for infrastructure, such as approved database versions or Terraform modules. This automation reduces the time and effort required for manual policy enforcement and can be applied to various organizational policies related to security, compliance, cost controls, and operational resilience.
Tools like Terraform Enterprise and HCP Terraform can utilize Open Policy Agent (OPA) or native systems like Sentinel to codify these policies. This codification enables organizations to test infrastructure configurations for compliance before they are applied, using both static and dynamic analysis. Static analysis offers quick feedback on whether Terraform code meets organizational requirements, while dynamic analysis continually checks the production environment for compliance.
### When to Use Policies vs. Custom Conditions
In Terraform, Sentinel or OPA policies and custom conditions may overlap in functionality. Policies are best used for rules that apply to any Terraform run, such as checking module versions or ensuring the use of private Terraform registry modules. Custom conditions, on the other hand, validate attributes against third-party services or dependencies, such as comparing resource-specific tags to a configuration management database (CMDB).
### Using Policy Sets
Organizing individual policies into a policy set allows for the distribution of standard policies across multiple teams. These policy sets centralize policy definitions and encourage modularization by grouping relevant policies. This organization simplifies updates and ensures compliance with specific industry standards or geographic regulations.
### Standardizing on Policy as Code: An Example Scenario
Imagine an organization aiming to standardize platforms in a public cloud. Platform C uses Terraform and Sentinel policies for secure image checks, while Platform B allows manual resource provisioning without policy checks. Monthly security scans reveal vulnerabilities on Platform B, while Platform C, having already caught issues with Sentinel checks, has none.
To address this, Platform B aims to adopt Platform C’s time-saving workflows by standardizing on HCP Terraform. By sharing Sentinel policy sets from Platform C, Platform B can avoid writing new policies. As a result, developers receive immediate feedback on security and compliance best practices, reducing the list of vulnerabilities.
### Immutability
In scenarios like image vulnerability patch management, immutability plays a crucial role. When a team fails a Sentinel policy for secure images, they update configurations to use a new image. With Terraform, they can apply immutability by destroying old resources and creating new ones, minimizing disruption.
Immutability offers several benefits: it simplifies dependency management, minimizes disruption to upstream dependencies, and scales for larger refactoring use cases. For instance, migrating a Java application to a HashiCorp Nomad cluster can use immutability principles, such as blue-green deployment, to reduce risks during migration.
### How Policy as Code and Immutability Speed Up Discovery and Remediation
Organizations often spend excessive time firefighting security and compliance risks. Implementing policy as code accelerates risk discovery, placing it ahead of deployment. Standardization reduces security practice fragmentation and speeds up remediation, as all platforms use similar automation for changes. Immutability further reduces remediation time by preventing configuration drift.
### How Policy as Code and Immutability Help with Refactoring
In the face of platform sprawl, standardizing across multiple platforms can be daunting. Instead of refactoring every resource, selectively refactoring portions of platforms to meet policy as code standards is more feasible. Policy as code communicates compliance and security standards, encouraging organic adoption and standardization.
Applying immutability mitigates risks associated with migration and refactoring, providing a repeatable foundation for changes. This approach reduces the time needed for future remediation of infrastructure and security.
To learn more about policy as code, explore Sentinel’s documentation and tutorials on using HCP Packer and Terraform for identifying and remediating compromised artifacts.
For more Information, Refer to this article.
