GitOps and IaC Security

In this post, I’d like to give a brief overview of GitOps framework and how IaC security fits into GitOps concept.

GitOps Introduction

  1. The entire system is described declaratively
  2. The desired system state is managed in Git
  3. Reviewed and approved changes can be applied automatically
  4. Software agents ensure system state correctness and alert on drift

Let’s take a look into each one of them:

  • The entire system is described declaratively means that you have declarative configuration not only for your actual workloads, but for the entire infrastructure and services on the top of which your applications are running. For example: your servers, third-party services, add-ons, communication, firewalls, operating systems, orchestrators — everything is described declaratively.
  • Your system declarative configuration is version-controlled, meaning managed and versioned in Git.
  • Since your declarative configuration is managed in Git, you can use development practices such as code review, and CI/CD pipelines in order to automate changes testing and deployments.
  • And software agents within the system validates correctness of those deployments and changes.

So, there is no implementation spec of GitOps, it’s really the extension of processes and best practices we’re using as a part of our DevOps flows. So the question is how GitOps is different from DevOps?

The key characteristic of GitOps as opposed to DevOps is this d eclarative configuration and the reconciliation in the system. So it really revolve around convergence to the desired state.

Why GitOps?

First is the fact that our pipelines run from within the system, as opposed to the traditional approach where you’re using external CI/CD systems. The immediate implication of this changes is the security aspect. Instead of giving administrative permissions to our external CI/CD systems, we’re keeping our keys and secrets within the cluster.

Second, the system is simple and consistent. We can scale from workflows of simples OS patches to an entire fleet provisioning.

Third, is the access to the production environment — it’s inherently controlled and guarded by multi-gated process. Since the configuration is source controlled, we can define fine-grained policies about who can access which repos, specify code reviewers, pull-requests merge policies and so on.

Next, with GitOps the system state is observable and immutable at any point of time. It really comes down to knowing our system state, the differences between the present state and the desired one, potential drifting and so on.

Finally, all those benefits boil down to better progressive delivery (velocity) and reduced operational overhead.

GitOps and IaC Security

We can see GitOps as an opinionated implementation of CI/CD and DevOps practices and security should be an inherent part of it. With GitOps we can get stronger security guarantees, which could be “hands-free”, but they are not “for-free”.

To make security to be an indivisible part of GitOps practices, we must “shift left” infrastructure-as-code security and that’s how KICS open-source project comes into play.

As shown in the diagram above, we can integrate KICS into our continuous integration flow or a a pre-deployment gate in the GitOps pipeline. This way infrastructure code undergoes ongoing security analysis to make sure security issues and misconfigurations do not leak into protected branches or production environment.

Conclusion

Watch KICS Demo

https://www.youtube.com/watch?v=eaD-tGMOKe8

I am an experienced software development team leader with proven leadership skills in an agile environment, and an ability to work with top-notch engineers.