A tough, but important, problem to solve when creating your on-prem software distribution architecture is how to enforce license terms at runtime. It’s one of the most common questions we’re asked at Replicated. One of the greatest values of on-prem is also its downfall in this regard - because the software is running in your customers’ environments, sometimes completely disconnected from the internet and air gapped, it’s difficult to ensure that customers who should no longer have access to your software are cut off or restricted from upgrading.
At Replicated, our licensing provides ways for your company to restrict access to your software. We enforce the license at distribution time—no one can access your Helm chart, pull your images, or install your software without a valid license. At runtime, it’s a bit harder for us to know what works best for your business. Instead of trying to guess, we provide tooling that lets you enforce your license terms in your software. For some, this means that once a license expires the customer immediately loses access to the software. For others, this means that the customer is warned that they are out of compliance and continue to work with your application. Still, others may want to take different approaches. We let you decide.
Our Director of Solutions Engineering, Chuck D’Antonio, used the Replicated platform to do just this type of enforcement. He created an init container that goes out and checks the license and won’t allow a Kubernetes pod to start when the software license is invalid, so the customer immediately loses access to the software. Take a look at his solution using his own application, SlackerNews, as an example.
You can see in this screenshot that his application, SlackerNews, is currently running.
On the Replicated platform, he sets the license to expire.
He then goes back over and deletes the pod. He does this to make sure the pod restarts and hits his license enforcement code, which is implemented as an init container. He could also have built the checks directly into SlackerNews.
When he goes back into the terminal to describe the pod, he can see an error that the license is not valid, and that it expired on the date Chuck set on his customer within the Replicated portal. Behind the scenes, the init container found that the license was expired. Not only did it loop until it tried to get a valid license but it also sent a Kubernetes event that said the license wasn’t valid.
Chuck then goes back and sets the license to expire next year.
When describing the pod again, we can see that the license is now valid and has a new expiration date.
This is just one technique you can use to set and enforce license expirations. Chuck shared this code on GitHub, as well, so please take a look! Don’t hesitate to reach out to the Replicated team if you have any questions or would like to learn more.
Want to learn more about what Replicated does to help vendors distribute software to self-hosted environments? We would love to show you -- click here to schedule a demo.