As increased businesses adopt DevOps methodologies to increase agility, action must be taken to ensure that agility doesn’t come at the expense of security. With the heightened importance of security placed on teams, they must navigate not only how to ensure that their infrastructure is secure at the time of deployment, but also that it stays secure throughout the entire lifecycle.
This new practice is commonly referred to as DevSecOps and its quickly becoming an industry-standard practice. In this article, we’ll discuss how GitOps and Continuous Security can help harden your CI/CD pipeline, shift security concerns left, and turn your DevOps team into DevSecOps heroes.
First and foremost, GitOps is an operational model. It defines a way of operating your systems. It takes DevOps best practices such as version control, compliance, CI/CD tooling, and collaboration and applies them to infrastructure automation.
While the name implies otherwise, GitOps is technology agnostic. Meaning you can use this model with other forms of version control. It’s important to remember that GitOps is not a single product, plugin, or platform. GitOps is a set of principles and workflows that help teams manage IT infrastructure using the same processes they already use in application development.
The above diagram depicts a typical CI/CD pipeline. There are typically several credentials that are used throughout a CI/CD process. They can be shared within logical security boundaries, but crossing these boundaries is less than ideal.
In this example, there is read/write access given to the code repository so that the application developer can check in her code. Once the code change is checked in there is a CI tool, with read-only access to the code repository, that monitors changes and will trigger a build. As a part of that CI process, a container image is generated. So, the CI tool then requires read/write access to the container registry to push the container image to the registry. In a usual pipeline scenario where there is continuous delivery using a pipelining tool, that CI tool will also have credentials to the destination Kubernetes cluster or environment. In this scenario, those credentials are crossing a logical security boundary. This means if the CI system is compromised, each Kubernetes cluster or environment that the CI system has access to is compromised.
In the GitOps pipeline, three essential changes are made. Primarily, the CI system isn’t doing the deployment. Next, a GitOps agent has been deployed into the cluster. Finally, we have introduced a configuration repository that will declare our desired state for that environment.
In GitOps, a configuration repository is a Git repository that stores configuration files, such as Chef Infra recipes, for your infrastructure and applications. The configuration repository serves as the source of truth for the desired state of your systems. It is used to automate the deployment and management of those systems by using Git as the central place to track and version changes to the configuration.
The GitOps agent will only require read-only access to the configuration repository. It will monitor the configuration repository to reconcile the actual state vs. the desired state. In this scenario, the GitOps agent will be the only entity with rights to deploy to the Kubernetes cluster or environment and it is running within the cluster itself.
In a GitOps model, the DevOps team will need to make changes to the configuration repository using familiar version control processes like branching and merging. This creates a single point of entry to implement process control practices. For example, a team may require two approvals for deployments, or that an application has first been deployed to lower environments.
Sometimes that’s still not enough, so this pipeline offers numerous opportunities to integrate additional security measures like image and code scanning in the CI process or artifact scanning in the CD process.
All the security measures mentioned thus far have been what the industry calls point-in-time security checks. What happens when an application has been deployed into the cluster or environment and has been running for weeks and a vulnerability is found? The security checks wouldn’t detect vulnerabilities after the fact. Instead, some sort of continuous security process would need to be implemented.
To have a successful and trusted CI/CD pipeline, we need to implement security and compliance measures within our pipeline. The goal here is to shift the conversation with the security team from approving each release to approving the CI/CD process while giving them the ability to monitor and audit the process at any time.
DevSecOps, GitOps, and continuous security are still new concepts in the industry, but they are certainly here to stay. The days of allowing security to be an afterthought or simply tossing a completed application over the wall to the security team are over. This shift may seem daunting to some, but it doesn’t have to be. Simply adopting GitOps best practices in your CI/CD pipeline significantly increases the security of your applications. For organizations that operate under high compliance requirements, implementing a continuous security process to your GitOps workflow will be the key to success.