Using OPA with GitOps to speed cloud-native development

One risk in deploying fleets of powerful and flexible clusters on constantly changing infrastructure like Kubernetes is that mistakes happen. Even minute manual errors that slip past review can have substantial impacts on the health and security of your clusters. Such mistakes, in the form of misconfigurations, are reportedly the leading cause of cloud breaches, for example. And, with everything that can happen in the containerized world, these types of mistakes are virtually guaranteed to occur.

The question, then, is how developers and platform engineers can, under today’s accelerated development timeframes, minimize these errors — if not eliminate them entirely for the vast majority of common cases.

For many dev teams and platform engineers, an emerging solution is GitOps, or the practice of using Git repositories as a single source of truth for configuration and deployment specs in your build pipeline. An “as-code” practice, GitOps allows developers to access declarative, version-controlled, peer-reviewed descriptions of the master architecture in deployment — and use pull requests to flag any changes they hope to make to that architecture. In addition to performing configuration checks, teams will also ensure that any infrastructure-as-code changes adhere to company security and compliance policies.

For these reasons, GitOps is emerging as a best practice for many devops teams in the pursuit of delivering error-free code, faster. However, humans remain at the core of these new practices, and with humans comes fallibility. The next logical step, then, is to automate security and compliance checks — using policy-as-code to verify infrastructure-as-code changes.

Leveraging GitOps to reduce cloud-native errors

Every cloud-native developer or platform engineer knows the feeling of putting a cluster configuration in place that looks good, only to find out in peer review — or even worse, after deploying it into production — that its behavior is less than ideal. Traditional strategies like change control review boards have been replaced with peer review in the GitOps model and serve to prevent many of those eventualities.

Still, in today’s devops environments, manual configuration checks can become significant bottlenecks, and they result in more work for people who are often already overburdened. Moreover, given the complexity and scale of platforms like Kubernetes, it can be a challenge for teams to manually apply security and compliance policies (that are typically stored in PDFs, wikis, or team members’ brains) to every proposed infrastructure-as-code change. In other words, not only does peer review slow development, but errors still sometimes get through.

Copyright © 2021 IDG Communications, Inc.

Source link