4 min read
If you’re delivering software in a regulated space, and you’re using Kubernetes, you’ll know how problematic change management is. On one hand you have a highly dynamic container based system that’s constantly changing. On the other hand regulatory obligations mean you must have a controlled and documented way of managing all of the changes in those systems.
And that’s not all. Knowing exactly what’s running in production at any given time is difficult enough, but it’s only half the battle. You also have to know how it got there and whether it’s in compliance with your defined process.
In this article I’ll explain how Kosli can automate the change management needs for your Kubernetes workloads.
What’s in production?
The most important use case for auditors and development teams is to be able to give clear and reliable answers to what’s running in production.
You can get this information from several different sources
- Using the kubectl command line
- Navigating the cloud console
- Digging through pipeline deployments
These methods require access permissions and technical understanding that might not cross team boundaries. They are also likely to be barriers to non-technical stakeholders and auditor/compliance functions. In addition, these systems make it nearly impossible to “rewind the clock” and view the historical state of production, which is essential for compliance.
Kosli helps teams answer this question in a way that is easy to set up with the rest of your DevOps tools. The Kosli client periodically sends the metadata of the workloads running in the cluster to the Kosli server. When Kosli receives this information, it is written to the append-only journal for that particular environment.
Once this is in place you have observability over your production workloads for debugging, troubleshooting, auditing, and security purposes. And Kosli stores the complete history, so you can now also look through the changes over time. What’s in production? Now? Last Thursday? On Christmas eve? What are the recent changes to production? The answers to these questions are now at the tips of your fingers.
How did it get there?
You now have a full picture of how production is changing. But production is only the final part of the compliance story. For compliance purposes you also need to understand why systems change. You need to know that correct processes have been followed, with audit trails you can trust, across your entire software development landscape.
Basically, you want to track all of the changes that will have occurred to an artifact on its journey from initial commit to production. That’s a lot of metadata, but it’s what is required to keep a dynamic, container based system in compliance.
With Kosli, capturing all of this information is as simple as adding reporting commands in your DevOps pipeline. Again, Kosli stores all of this information in tamper-proof, append-only journals, giving your stakeholders confidence that all binary provenance, risk controls, and guardrails are in place.
Kosli makes it easy to:
- Record binary provenance based on content addressable storage
- Attest evidence of risk controls being performed
- Create and record release approvals
- Log deployments
Implementing Continuous Compliance
Ok, so now you have the complete change history and event logs for production. You also have all of the metadata for each artifact’s journey to production. That means you have the building blocks required to achieve Continuous Compliance.
Continuous Compliance helps you to detect:
- Unknown or undocumented workloads in production
- Unapproved deployments
- Failed deployments
Kosli uses the information from the pipelines (what should be in production) and compares this with what is actually in production. This provides you with a real time continuous audit. If there is a mismatch in expectations, or if any policies are not met, Kosli will alert you to take action in real time.
The Kosli vision
We are strong believers in the potential for DevOps Change Management to free regulated teams to do their best work. For us it means giving them the ability to deploy compliant software changes without the manual documentation, gatekeeping, and other delays that are usually found in these industries.
We hope this has shown you how Kosli’s solution for continuous compliance and change management works for Kubernetes. We also support many other types of runtime such as web servers, s3, lambda, ecs, fargate, and more. And if you have any questions about how Kosli can help you please get in touch.
