We have recently been looking at controlling access to some of our application features via custom fields in our license. These fields would determine which charts get applied when the application is configured and deployed via the replicated UI.
What I am trying to understand is how best to protect these features from unlicensed use since users can easily download the application bundle, remove the license check, and re-upload it (this is how I often develop changes to the application config).
How would you recommend handling this sort of use case? Is the best solution to just add the different configuration as a separate replicated application? On that same note, is it possible to build an airgap bundle that doesn’t include images for services that may not be enabled for all customers so as not to bulk out the airgap bundle so much?
We can certainly go down the route of managing these as separate replicated applications, but since there is so much overlap in our use cases, we were wondering if there was a better way.
Does your application determine that a feature is enabled only by checking if the Helm chart / service exists in the cluster?
You make a valid point. Controlling application features via custom license fields is not tamperproof since as you said, the user can download the archive, modify the manifests directly, then upload.
I can’t think of a way with the current functionality in KOTS to solve this issue in your scenario using a single application without adding logic to the application itself to control feature access. I can create a feature request if you like. In the meantime, one option would be to deploy those charts as separate replicated apps like you mentioned.
Thanks,
Salah Al Saleh
Senior Software Engineer @ Replicated
Thanks for the response! It sounds to me like using a separate application will be our best bet for controlling access. If you guys ultimately build in support for this into a single app, I think we would be interested in playing with it.
Thanks @salahalsaleh ! To add a little more color, one thing I was thinking @David , if you wanted to add custom logic into your application code, you could consume the entire Replicated License file, and there is a (probably undocumented) way to ingest those license fields from the YAML file, and validate the signature contained in there using a public key embedded in your app code. Then you could query those validated entitlement values on startup or in hot code paths (e.g. in an HTTP middleware) to validate access. Like I said, while this is technically possible, it would require app changes on your side, and is likely undocumented / untested today. If you’re interested in exploring that path, let’s continue the conversation.